This ROM has gone "Alpha" and is basically ready for daily use https://forum.xda-developers.com/dr.../crdroid-3-8-nougat-xt907-xt905-jbbl-t3697571 or you could also check ResurrectionRemix at https://forum.xda-developers.com/dr...resurrectionremix-nougat-xt907-xt905-t3697567
See the following post for the current status of this experimental build.
https://forum.xda-developers.com/showpost.php?p=74272802&postcount=59
all the below is regarding previous build attempts
DO NOT FLASH GAPPS!
Make a nandroid (you will definitely be going back) And remember, a nandroid is NOT 100%! if you don't understand this, maybe trying this is not for you.
Flash the ZIP
It is unrooted, so I personally flash Magisk v12 (I have the zip and know its working). I also flash UnSu and Busybox remover
DO NOT FLASH GAPPS!
Reboot
Install the Magisk Manager (if you went down this path for root)
This is an experimental build of crDroid 7.1.2
The good
It's crDroid!
It's Nougat!
It Builds
It Boots!:highfive:
It has all the eyecandy!:angel:
It feels really "snappy"
The bad
If you flash Gapps it falls to pieces in a never ending cycle of crashes!:crying:
It is buggy even without GApps
My Hopes:
People will flash this, get some logs and maybe someone with more knowledge (maybe the xt897 LOS device maintainers?) will be able to decipher the logs and determine whats missing. Maybe someone here has a direct line to one of the maintainers of the xt897 LineageOS?
How I built it:
Set up a virtual Box (on Win7 64b) to build Lineage OS 14.1 (followed their instructions)
Source: https://github.com/crdroidandroid/android -b 7.1
I used a working device tree (ie local manifest) from my working LineageOS 14.1 Build machine (see attached) for an XT897 (with the touch drivers for an XT907)
Basically, I have done no "magic" here, it all just kinda worked. up to a point as its pretty buggy. BUT IT BOOTS!
I also have a ResurrectionRemix 7.1.2 I will also upload.
Almost forgot, flash this at your own risk and i take no responsibility for what happens to your device.
DiamondJohn said:
DO NOT FLASH GAPPS!
Click to expand...
Click to collapse
Since GApps seem to be the only limiting factor, did you try the various available flavors of GApps?
Also, there's one more alternate to GApps, which is the microg project. Did you try that instead? There's an unofficial flashable installer available here but that page also has links to the various components if you wish to install those manually...
rahimali said:
Since GApps seem to be the only limiting factor, did you try the various available flavors of GApps?
Also, there's one more alternate to GApps, which is the microg project. Did you try that instead? There's an unofficial flashable installer available here but that page also has links to the various components if you wish to install those manually...
Click to expand...
Click to collapse
I tried Open (Pico) & Beans from memory.
I think the real answer will be to look into the logs. The very first build I did I got ADB over WiFi turned on before it all went bad, so have a catlog of the SystemUI crashes, but it was an earlier build , and its from ResurectionRemix
I think this is the smoking gun:
Code:
07-19 20:14:36.665 5929 5929 D AndroidRuntime: Shutting down VM
07-19 20:14:36.669 5929 5929 E AndroidRuntime: FATAL EXCEPTION: main
07-19 20:14:36.669 5929 5929 E AndroidRuntime: Process: com.android.systemui, PID: 5929
[COLOR="Red"][B]07-19 20:14:36.669 5929 5929 E AndroidRuntime: java.lang.NoClassDefFoundError: Failed resolution of: Lcom/android/keyguard/R$bool;
[/B][/COLOR]07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.keyguard.KeyguardUpdateMonitor.shouldListenForFingerprint(KeyguardUpdateMonitor.java:1199)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.keyguard.KeyguardUpdateMonitor.updateFingerprintListeningState(KeyguardUpdateMonitor.java:1186)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.keyguard.KeyguardUpdateMonitor.<init>(KeyguardUpdateMonitor.java:1177)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.keyguard.KeyguardUpdateMonitor.getInstance(KeyguardUpdateMonitor.java:993)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.systemui.keyguard.KeyguardViewMediator.setupLocked(KeyguardViewMediator.java:683)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.systemui.keyguard.KeyguardViewMediator.start(KeyguardViewMediator.java:735)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.systemui.SystemUIApplication.startServicesIfNeeded(SystemUIApplication.java:180)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.systemui.SystemUIApplication.startServicesIfNeeded(SystemUIApplication.java:134)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.systemui.keyguard.KeyguardService.onCreate(KeyguardService.java:45)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at android.app.ActivityThread.handleCreateService(ActivityThread.java:3231)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at android.app.ActivityThread.-wrap5(ActivityThread.java)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1597)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at android.os.Looper.loop(Looper.java:154)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6236)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:891)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:781)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: Caused by: java.lang.ClassNotFoundException: Didn't find class "com.android.keyguard.R$bool" on path: DexPathList[[zip file "/system/priv-app/SystemUI/SystemUI.apk"],nativeLibraryDirectories=[/system/priv-app/SystemUI/lib/arm, /system/lib, /vendor/lib, /system/lib, /vendor/lib]]
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at java.lang.ClassLoader.loadClass(ClassLoader.java:380)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
07-19 20:14:36.669 5929 5929 E AndroidRuntime: ... 18 more
07-19 20:14:36.672 2801 3134 W ActivityManager: Process com.android.systemui has crashed too many times: killing!
07-19 20:14:36.673 2801 3134 W ContextImpl: Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:877 com.android.server.am.AppErrors.crashApplicationInner:375 com.android.server.am.AppErrors.crashApplication:309 com.android.server.am.ActivityManagerService.handleApplicationCrashInner:13757 com.android.server.am.ActivityManagerService.handleApplicationCrash:13739
wierd, I just reflashed the ROM and it wasn't anywhere near as stable as it was the first time I flashed it
DiamondJohn said:
wierd, I just reflashed the ROM and it wasn't anywhere near as stable as it was the first time I flashed it
Click to expand...
Click to collapse
I took a big batch of logs, read them (as much as you can with that amount of crashes), did some MAJOR changes (but "impolite" and took some major shortcuts though not so quick to actually do), and now its a LOT more stable, and I even managed to install and boot with GApps, connect to the market and download a couple of apps. :highfive::victory: But don't get me wrong, it still crashes like a &@%#$
ie there are still "some" force closes
I'm moving off of this one (ie crDroid) and give ResurrectionRemix a similar "attack " :fingers-crossed: On previous attempts/builds it acted the same as crDroid, but much worse.
But most importantly, my phone is on the fritz and I think (ie hope thats it's only:fingers-crossed the recovery image is corrupt
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
i flashed crrdroid for the xt907 and first boot it works like a charm but when u reboot it it goes bonkers and endless force closes
i hope u can get this stable because i have crdroid installed on all of my devices my favorite nougat rom
I hope someone can keep the development going for this ROM for the xt907
my last build available in post #3 that I managed to get to work with GApps / Google play
hmmm... I'm giving it another go to get some logs and it actually seems MORE stable after a few wipes of dalvik and cache...
Can't install apps package installer force closes as well as the keyboard ?
Trey n said:
Can't install apps package installer force closes as well as the keyboard ?
Click to expand...
Click to collapse
Tell me something I dont know!
I have found its a bit of a random number generator, in that sometimes I flash and the FC's are MANY times less and others much more. But generally speaking, the faster you set the device up, the more chance you have. Also, when it starts to fail, go to recovery and clean cache and dalvik. Also delete /system/priv-app/OmniSwitch & /syatem/app/NFC/
I kicked off a new build and flashed it. As part of the build, I undid my "hacky" changes which seemed to improve stability (orig didnt allow GApps), and refreshed all crDroid code to source. I found that the new build was almost as stable as my modified build. ie as crDroid fixes bugs for their official devices, our unofficial build inherits these fixes and also becomes more stable :highfive:. So, hopefully as their builds become more mature, we may end with a stable build as well. This state of affairs (ie pure crDroid code) is the best situation / goal.
I also trued flashing (and building) one of their official devices (a Nexus 5 / hammerhead). I found that there were a number of issues even in the official builds. For example, I found that OmniSwitch caused a number of force closes in my build. In the official Nexus 5 build, although it didnt force close, it didn't actually work. ie there is work to be done in Omniswitch, which we will inherit. I also found that the official build din't have working Lockscreen album art nor music visualiser. So there is clearly a lot of coding ahead for crDroid; which again, we will inherit.
Also the more I think about it, we are more stable without GApps, and its nowhere near a daily yet, so I am seeing it more and more as a preview / test that we may have a very customizable Nougat ROM for our phones (in the future :fingers-crossed
I also noriced that for our screen resolution, the code falls back to the old B/W bootanimiation instead of the newer one. That wont do for my builds in the future
I would suggest that if anyone is really interested to see this ROM "running" and its features, then do not flash GApps; its simply a preview of what is hopefully to come.
On a side, does anyone know of a free, non registration, low advertising, fast to upload(the ones i found take 4Hrs to upload!) hosting website I can post future builds onto?
I think I will also generate a pure xt897 build to hopefully garner some interest by other devs, as the xt897 is an official LineageOS device, which is the vendor and device tree I am using to build crDroid (and ResurectionRemic and possibly other LOS based custom ROMs)
DiamondJohn said:
Tell me something I dont know!
I have found its a bit of a random number generator, in that sometimes I flash and the FC's are MANY times less and others much more. But generally speaking, the faster you set the device up, the more chance you have. Also, when it starts to fail, go to recovery and clean cache and dalvik. Also delete /system/priv-app/OmniSwitch & /syatem/app/NFC/
I kicked off a new build and flashed it. As part of the build, I undid my "hacky" changes which seemed to improve stability (orig didnt allow GApps), and refreshed all crDroid code to source. I found that the new build was almost as stable as my modified build. ie as crDroid fixes bugs for their official devices, our unofficial build inherits these fixes and also becomes more stable :highfive:. So, hopefully as their builds become more mature, we may end with a stable build as well. This state of affairs (ie pure crDroid code) is the best situation / goal.
I also trued flashing (and building) one of their official devices (a Nexus 5 / hammerhead). I found that there were a number of issues even in the official builds. For example, I found that OmniSwitch caused a number of force closes in my build. In the official Nexus 5 build, although it didnt force close, it didn't actually work. ie there is work to be done in Omniswitch, which we will inherit. I also found that the official build din't have working Lockscreen album art nor music visualiser. So there is clearly a lot of coding ahead for crDroid; which again, we will inherit.
Also the more I think about it, we are more stable without GApps, and its nowhere near a daily yet, so I am seeing it more and more as a preview / test that we may have a very customizable Nougat ROM for our phones (in the future :fingers-crossed
I also noriced that for our screen resolution, the code falls back to the old B/W bootanimiation instead of the newer one. That wont do for my builds in the future
I would suggest that if anyone is really interested to see this ROM "running" and its features, then do not flash GApps; its simply a preview of what is hopefully to come.
On a side, does anyone know of a free, non registration, low advertising, fast to upload(the ones i found take 4Hrs to upload!) hosting website I can post future builds onto?
I think I will also generate a pure xt897 build to hopefully garner some interest by other devs, as the xt897 is an official LineageOS device, which is the vendor and device tree I am using to build crDroid (and ResurectionRemic and possibly other LOS based custom ROMs)
Click to expand...
Click to collapse
AWESOME time will tell
and i have noticed that bootanimation too and i hate it i love the new one
and u could upload it to ur google drive and share the file ..........
Trey n said:
AWESOME time will tell
and i have noticed that bootanimation too and i hate it i love the new one
and u could upload it to ur google drive and share the file ..........
Click to expand...
Click to collapse
Google drive not an option. Any other ideas?
DiamondJohn said:
Google drive not an option. Any other ideas?
Click to expand...
Click to collapse
Y not?
Onedrive
Dropbox
Mediafire
Mega
also see the second half of this post https://forum.xda-developers.com/showpost.php?p=73211646&postcount=79
I also just found the following post of a user having what appears to be the exact same issues with LineageOS 14.1, when they install GApps
https://forum.xda-developers.com/droid-razr-m/development/lineage-os-xt907jbbl-t3577746/post72841480
Its a pity they dont have an xt897 so that they could post an issue/bug directly with LineageOS
Bad news all I had a chance to flash a build and actually take the logs, ie on top of all the logs you guys posted... NOT!
Anyway, in short, we are getting "GPU Page Faults" in the kernel. The GPU is Graphics Processing Unit, which would explain the systemUI crashes. The bad news is that I looked at our kernel code and compared it to another device which does work, and our kernel code is way behind. eg hammerhead code file on the line that logs the error is 2000 lines, ours is only 1000 lines.
I tried slowly updating more and more of our kernel, but each file I brought up to newer code triggered a dependency on another 2 files, and that file triggered a dependency on another few files. as you can imaging it got out of hand very quickly.
So, unless LineageOS does some major changes to their kernel, I don't think we are going to be running a heavily customised ROM too soon.:crying:
I also tried AICP just in case it was compatible with our "old" kernel, but no.All nougat of course,
I also have tried ResruectionRemix, also no.
Also tried DirtyUnicorns, which is an AOSP based ROM (instead of LiineageOS based like the rest) and that also has kernel issues.It doesn't even show the boot animation. Boot loop All of these require mods to make them compatible with their specific build process ie time :angel
I have compiled and have a working ResurectionRemix marshmallow.:good:
I have spent a lot of time trying to update our kernel, but failed every time or just got overwhelmed with the amount of change required
Lineage does do minor fixes to their Kernel, but most I have seen have been stability around the file system and not the display/GPU; where our problem is.
Additionally, the kernel code is shared between JBBL and KKBL, so I very much doubt we would have any better success with a KKBL ROM.
Why not stick to MM ROMs for now? Could you try and build a few for KKBL and/or JBBL? MM should be good enough for now on these devices and building these should give you the necessary exposure and experience to move ahead to N in the future. Just my thoughts tho m not a dev
DiamondJohn said:
I have compiled and have a working ResurectionRemix marshmallow.:good:
Click to expand...
Click to collapse
And where might I be able to obtain this?
rahimali said:
Why not stick to MM ROMs for now? Could you try and build a few for KKBL and/or JBBL? MM should be good enough for now on these devices and building these should give you the necessary exposure and experience to move ahead to N in the future. Just my thoughts tho m not a dev
Click to expand...
Click to collapse
Because Nougat is newer! Building M will not give the depth of experience needed to rebuild the kernel.
I am currently running as my daily, a custom build of LOS 13.0 (with a heap of Xposed modules). The custom build is basically a de-bloated MM with the Nougat Kernel overclocked to 1.98GHz. I compiled a RR marshmallow (with the OC'd N kernel), but during my install I noticed it had a bug whereby all my restored messages returned to being unread after every reboot. Should be an easy fix, but still a fix to be built and tested. The idea of compiling RR was to remove the need for Xposed.
After this experience, I realised that the LOS MM ROM with Xposed was pretty good, until I get N running...
NB: LOS13 has not had many code changes since they switched to Nougat. Hence my use of the Nougat kernel AND the fact their official xt897 builds should be pretty close to mine (apart from the kernel & OC)
I am guessing that noone rememebrs or tried the following. But, if you flashed the ROM and GApps, and then when it booted, NOT TOUCH the screen, did it fail / crash?
I ask because I have been working on trying to update the kernel, and after many many MANY attempts, I got one to build , flash and boot, but the touch screen drivers are not right, so the touchscreen does not work. But there is also not any force closes popping up. So I am wondering if I have solved the force closes or if it takes touching the screen to trigger their start?
Hi
OK guys. I had missed the information.
Our G5s seems to be ready to support customized ROMS :
androidpolice.com/2017/10/12/motorola-releases-kernel-source-code-moto-g5s
techdroider.com/2017/10/moto-g5s-kernel-source-code-released.html
(sorry for links)
kernel source montana > https://github.com/MotorolaMobilityLLC/kernel-msm/releases/tag/MMI-NPP26.102-41
Pardon me if it is a wrong thread to ask this question. If it is, moderator please delete this post.
I don't see any custom ROM development happening for this device. May be I am not aware of. Or May be it is very early to expect a custom ROM. I heard that Moto G5 and G5s has same technical specification. Would I be able to flash a G5 custom rom on G5s with a little bit of tweak in build.prop (like device_name, etc)?
Thanks
Kalyan
Hello, you can try, but I do not think it works, but you will also have to modify the updater script.
I do not think it works either, but if you try it and if it works, thank you for telling us.
lohanbarth said:
Hello, you can try, but I do not think it works, but you will also have to modify the updater script.
Click to expand...
Click to collapse
Thanks for the response. I haven't rooted my device yet. I understand that would void device warranty status. I am just waiting for the OREO update to happen. It seems OREO has in-built theme support (At least that's what I read in various articles).
Couple of questions. Suppose if I unlock boot loader; play around with installing G5 custom roms and later on if I relock boot loader, would I get OTA updates?
Additionally, to the minimum I need to know the partition/blocks layout to verify with G5 updater script. Does anyone know partition/blocks layout of G5s?
Thanks
Kalyan
hello, I always unlock my motorola and I always received the updates, and if you do not receive it, there will be the rom to install the fastboot
lohanbarth said:
hello, I always unlock my motorola and I always received the updates, and if you do not receive it, there will be the rom to install the fastboot
Click to expand...
Click to collapse
Hi all, I am interested in building a ROM for this device. But as I am new to this, I don't know where to start. To the minimum, I need device_tree and vendor_tree for the device. I searched internet and went through various github repositories, but I couldn't find anything for MONTANA device.
All I found is an empty repository here https://github.com/moto8937/android_device_motorola_montana
Can anyone help me?
Thanks in advance.
Regards
KS
I suppose repo will be filled as soon as scripts for montana will be ready; maybe in next few days/weeks.
I am also interested in a ROM. AOSP or AOSP Extended would be nice.
I have much experience with Linux, bootloaders and low-level stuff. But no experience
with building Android (can't be so hard). If someone is making a ROM I can help if needed.
But I guess we must wait for source code.
janhieber said:
I am also interested in a ROM. AOSP or AOSP Extended would be nice.
I have much experience with Linux, bootloaders and low-level stuff. But no experience
with building Android (can't be so hard). If someone is making a ROM I can help if needed.
But I guess we must wait for source code.
Click to expand...
Click to collapse
Hello, normally squid2 work to get out lineageOS 15, so I think what should not be coming out soon.
lohanbarth said:
Hello, normally squid2 work to get out lineageOS 15, so I think what should not be coming out soon.
Click to expand...
Click to collapse
I am able to build a Resurrection Remix 5.8.5 custom rom using CEDRIC device code.
1) I downloaded android_device_motorola_cedric, android_vendor_motorola_cedric and android_kernel_motorola_msm8937 repositories as ZIP files from https://github.com/moto8937.
2) I changed all files in sub-directories that has 'cedric' in its name to 'montana'.
3) Replaced all file contents that had 'cedric' with 'montana'.
4) Pulled in RR code base from its GIT repository using REPO tool. I followed the instructions provided in https://github.com/ResurrectionRemix/platform_manifest
5) Copied the modified device, vendor and kernel files to appropriate directory within RR directory (~/RR/kernel/motorola/msm8937, ~/RR/device/motorola/montana and ~/RR/vendor/motorola/montana).
6) Started a brunch montana. Failed after 50% because of missing piece of code related to qcom dtbtool. So I downloaded qcom_common repository from https://github.com/LineageOS/android_device_qcom_common and placed the contents under ~/RR/device/qcom/common.
7) Started brunch montana again. Completed the build after 8 hours.
8) Took a TWRP backup of stock rom and flashed RR build.
9) Flash went through and device started without issues.
10) Now RIL, WIFI, Bluetooth, Tethering, Mobile Data, Dual SIM, etc works.
11) SOUND NOT WORKING. NO SOUND AT ALL, as if speakers are dead. I can make a call and receive a call. But I cannot hear other party. Microphone works.
12) SENSORS are not working. Like autorotate, proximity, etc.
13) It was beautiful to see 7.1.2 Nougat with October 2017 Security Patch.
----
14) Then I noticed that kernel code in https://github.com/moto8937/android_kernel_motorola_msm8937/tree/cm-14.1/arch/arm/configs already has a file called montana_defconfig. I compared that with cedric_defconfig. Both are different. The build process uses montana_defconfig by default, but the values in it are not valid. At least that is my assumption.
15) So now I renamed montana_defconfig to montana_defconfig.bak. Took a copy of cedric_defconfig and renamed the copy to montana_defconfig.
15) Tomorrow I would rebuild again.
16) Before that I have to do some cleanup as well. My Fedora LINUX box is nearly out of space. I have only few GBs left out of 120GB.
Point here is CEDRIC code works with MONTANA device.
This is the first time I am building a custom ROM and it was good to see most of the things working.
Updated you guys later tomorrow or a day after.
Thanks
KS
Hey. Thats really nice! I hope you share with us when its working
Maybe Ill try to build AOSP extended with your advice.
Hello,
@kalyansundhar , did you manage to advance on your rom?
will be some roms on moto g5s?When? I bought this phone today
I think we'll be more and more hope and wait for customs roms.
patgou.007 said:
I think we'll be more and more hope and wait for customs roms.
Click to expand...
Click to collapse
Main requirements are the device_tree and vendor_tree. Using system image dump, I tried my best to separate vendor and device files. But being a first timer, I couldn't do it. In other words, I am confused which file should go into vender_tree and which one to device_tree. But I haven't given up. Still trying to work out something. I am sure other experienced ROMers might also be working on coming up with a vendor and device tree. So let us wait.
Thanks
KS
Thanks for your hard work. We know it's not so easy. We have just to wait. And that, it's easy.
Device tree, Vendor blobs adn LOS7 build
Somehow I managed to come up with a device tree and vendor blobs for G5s.
Device: https://github.com/kayesk/android_device_motorola_montana
Vendor: https://github.com/kayesk/android_vendor_motorola_montana
Initial build of UNOFFICIAL LOS7 build is here: https://1drv.ms/f/s!Ahq68S0B7zYZjmVhmIHwvYGoz3gq.
This is completely based on STOCK. For any reason, if the shared file is not accessible, please let me know. I would upload it in GDrive.
The file size is around 450MB. Lot of clean up needs to be done. As I mentioned in my earlier posts, I don't have any mobile device software development experience. I played around the system image, placed files here and there, made some modifications and finally came up with this stuff. I don't know what files are used by the device and what are not. Don't laugh at me.
I request experienced developers help in fix issues. So feel free to access/modify source tree.
What works:
RIL (dual sim, volte)
WIFI
Tethering
Camera (Front and Back)
Bluetooth
Sensors
MTP
Sound
Fingerprint
Bugs:
Developer Options crashes. I think it could be permission related or some missing files may be. Whenever I hit the option, I get the following in logcat.
12-28 13:31:29.511 1805 3622 E UserRestrictionsUtils: Unknown restriction: null
12-28 13:31:29.515 1805 1862 E UserRestrictionsUtils: Unknown restriction: null
Not sure what it is.
Another issue is the inclusion of CMHW in Boardconfig.mk and CMActions in device.mk. When I include it in the build, I get the following error in logcat.
12-28 13:28:53.095 21735 21735 E AndroidRuntime: Process: com.cyanogenmod.settings.device, PID: 21735
12-28 13:28:53.095 21735 21735 E AndroidRuntime: java.lang.RuntimeException: Unable to create service com.cyanogenmod.settings.device.ServiceWrapper: java.lang.IllegalArgumentException: sensor cannot be null
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.app.ActivityThread.handleCreateService(ActivityThread.java:3226)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.app.ActivityThread.-wrap5(ActivityThread.java)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1586)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.os.Looper.loop(Looper.java:154)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6186)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: Caused by: java.lang.IllegalArgumentException: sensor cannot be null
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.hardware.SystemSensorManager.requestTriggerSensorImpl(SystemSensorManager.java:205)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.hardware.SensorManager.requestTriggerSensor(SensorManager.java:1669)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.cyanogenmod.settings.device.SensorHelper.requestTriggerSensor(SensorHelper.java:108)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.cyanogenmod.settings.device.GlanceSensor.screenTurnedOff(GlanceSensor.java:56)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.cyanogenmod.settings.device.CMActionsService.screenTurnedOff(CMActionsService.java:95)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.cyanogenmod.settings.device.CMActionsService.updateState(CMActionsService.java:103)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.cyanogenmod.settings.device.CMActionsService.<init>(CMActionsService.java:72)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at com.cyanogenmod.settings.device.ServiceWrapper.onCreate(ServiceWrapper.java:47)
12-28 13:28:53.095 21735 21735 E AndroidRuntime: at android.app.ActivityThread.handleCreateService(ActivityThread.java:3216)
Our device is not using a regular sensorhub stuff. It uses sensors.montana, sensors.rp and sensors.ssc. Above error could be related to that. Or may be a source code modification is required.
Everything works fine even without the inclusion of CMHW and CMActions, except the "Developer options" thing.
BTW, this build is for testing. So if you end up with a bricked/dead device by flashing this build, please don't hold me responsible. Flashing steps are as usual. Take a TWRP backup and Do a clean flash.
I haven't tried with GAPPS installation or rooting. But that shouldn't be an issue, I believe.
HAPPY NEW YEAR !!!
Thanks
KS
Many thanks for your work , maybe some developers will help us .....
@Tkkg1994 @flar2 @geiti94
Has anybody managed to get a custom kernel working with a proper working clipboard? I've tried with and without TEE, with and without securestorage but it still breaks. Tried various kernels for verification and all of them seem broken.
To verify the issue, just use PCMark 2.0 Work test and it will force close during the writing test with the following:
Code:
04-03 12:03:22.137 ? I/com.futuremark.haka.textediting.tasks.Copy: Paste to clipboard
04-03 12:03:22.162 ? W/System.err: at com.futuremark.haka.textediting.tasks.Copy.lambda$startCopyTask$9(Copy.java:71)
04-03 12:03:22.162 ? W/System.err: at com.futuremark.haka.textediting.tasks.Copy.access$lambda$0(Unknown Source:0)
04-03 12:03:22.162 ? W/System.err: at com.futuremark.haka.textediting.tasks.Copy$$Lambda$1.run(Unknown Source:2)
04-03 12:03:22.163 ? D/com.futuremark.haka.textediting.results.Result: Storing name: copy value: 19.0 ms used in results: true
.....
04-03 12:03:28.769 ? I/com.futuremark.haka.textediting.tasks.Paste: Get text from clipboard and paste
04-03 12:03:28.772 ? W/System.err: at com.futuremark.haka.textediting.tasks.Paste.executePaste(Paste.java:71)
04-03 12:03:28.773 ? W/System.err: at com.futuremark.haka.textediting.tasks.Paste.lambda$startPasteTask$3(Paste.java:51)
04-03 12:03:28.773 ? W/System.err: at com.futuremark.haka.textediting.tasks.Paste.access$lambda$0(Unknown Source:0)
04-03 12:03:28.773 ? W/System.err: at com.futuremark.haka.textediting.tasks.Paste$$Lambda$1.run(Unknown Source:2)
04-03 12:03:28.775 ? E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.futuremark.pcmark.android.benchmark:workload, PID: 19337
java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.ClipData$Item android.content.ClipData.getItemAt(int)' on a null object reference
at com.futuremark.haka.textediting.tasks.Paste.executePaste(Paste.java:71)
at com.futuremark.haka.textediting.tasks.Paste.lambda$startPasteTask$3(Paste.java:51)
at com.futuremark.haka.textediting.tasks.Paste.access$lambda$0(Unknown Source:0)
at com.futuremark.haka.textediting.tasks.Paste$$Lambda$1.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6938)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
04-03 12:03:28.780 ? W/ActivityManager: crash : com.futuremark.pcmark.android.benchmark,0
04-03 12:03:28.783 ? W/ActivityManager: Force finishing activity com.futuremark.pcmark.android.benchmark/com.futuremark.haka.textediting.TextEditingWorkload
Something on the secure side is broken and it doesn't affect stock kernel images.
Knox has to be v30 in build.prop afaik.
Nice to see you here Andrei
We need a kernel with your commits that disable hotplugging.
Copy and paste works fine for me. The PC Mark 2 test also completes.
I have not yet updated to the latest system update. I'm using G960FXXU1ARC5, with ElementalX 1.04 and rooted with latest SuperSU.
It's related to the thing reported here:
Link
Tkkg1994 said:
It's related to the thing reported here:
Link
Click to expand...
Click to collapse
Ugh!!! Thought something was broken with the kernel and in the end it was one of the kernels which I quickly tested at the beginning which messed with system props for no reason. I wish people would stop messing with system files when kernels can override everything...
Anyway thanks a lot, I'm now on a squiky clean ARCC system and custom kernel and everything works.
AndreiLux said:
Ugh!!! Thought something was broken with the kernel and in the end it was one of the kernels which I quickly tested at the beginning which messed with system props for no reason. I wish people would stop messing with system files when kernels can override everything...
Anyway thanks a lot, I'm now on a squiky clean ARCC system and custom kernel and everything works.
Click to expand...
Click to collapse
Which Kernel do you use?
iamnotkurtcobain said:
Which Kernel do you use?
Click to expand...
Click to collapse
Check @AndreiLux profile, especially "Most thanked" section and you will get the answer