Related
===============================================================
Issue closed, read:
http://forum.xda-developers.com/showpost.php?p=42638124&postcount=17
===============================================================
l2_hsic issue
l2_hsic running amok (GT-P7500, GT-P7501) is ONE considerable reason for abnormal battery drain.
The so far known counter measures (HC, Stiffmeister + its xda derivate, WiFi-ROM) do not comply to my requests:
- CM10.1 nightlies
- 3G usage
- no l2_hsic hassle
l2_hsic root cause
Analysis of kmsg files provide a consistent pattern. Function if_usb_suspend(..) from modem_link_device_hsic.c does not call wake_lock_timeout(..) in wakelock.c in case of l2_hsic is running amok.
The missed call to wake_lock_timeout is obviously caused by a non cancellable USB-connection.
It is a single non expiring wakelock, what makes trouble.
Inside of modem_link_device_hsic.c I lost track on further explanations.
Candidate to fix the issue
Since I cannot correct the root cause, I tried to fix its consequence.
Basis is the current pershoot P4 CM10.1 kernel.
There are a few spots in its source code, where one could obtain the so called prevent_suspend_time of a l2_hsic wakelock.
A monitor is installed in such place. It triggers, when a l2_hsic wakelock’s individual prevent_suspend_time exceeds >10s (empirical value).
In this case the function wake_lock_timeout is called, which ignites the wakelock’s expiration.
Next the trigger is reset and the monitoring becomes active again.
As a second and measure of last resort the tab is shutdown, once l2_hsic’s total prevent_suspend_time exceeds >1h (never happened so far).
All these events are logged:
--> /proc/grzwolf shows current status
--> /proc/kmsg is extended by a couple of messages
Verification
The described modified kernel was installed on my Tab months ago.
Since then DS works perfect to me.
Furthermore I did not experience any side effects.
This kernel-mod had been announced at
http://www.android-hilfe.de/samsung...s-10-1n-mit-stock-4-0-4-a-69.html#post5550736
Meanwhile the kernelmod is integrated:
BeeGee(Ganbarou), AAccount(A1 Kernel), kasper_h(Team Infamous/AOKP) and twa_priv(CM10.1/SGT7)
Preconditions for installation
- the kernelmod applies only for P4 devices (GT-P7500, GT-P7501)
- no need to contiue, if you don’t have a l2_hsic issue
- if you continue, you should know what you are doing
- I don’t take any warranty
- after flashing a Nightly ROM, the kernelmod needs to be installed again
- CM10.1 is installed on P4 according to the OP of thread http://forum.xda-developers.com/showpost.php?p=36077123&postcount=1
Kernelmod installation
- comply to the preconditions above
- within CWM make a Nandroid backup of a running isntallation
- copy 'P4 kernel' (see downloads below) to your Tab
- install 'P4 kernel modified' within CWM and check functionality after booting up
- if not ok, restore in CWM your Nandroid backup
Credits
- pershoot (Kernel)
- MapleSyrup (Kernel build)
- nakedninja42 (CM10.1 Installation)
Changelog
Rev. 2013.04.10-19.44
first release
Downloads
- CWM flashable kernel zip, Rev. 2013.04.10-19.44
- md5 sum of kernel zip
- source code
- readme source code
All hail grzwolf! Thank you so freaking much for finally finding the fix that no one could. I now don't need to flash a WiFi ROM to get rid of the l2_hsic issue.
Sent from my GT-P7500 using XDA Premium HD app
Great work, grzwolf!
Did you find the root cause of the wakelock based on your extended logging?
Is it OK for you if I take your code, streamline it a bit (remove logging, renaming methods, ...) and integrate it in the CM kernel?
C-o-M said:
Great work, grzwolf!
Did you find the root cause of the wakelock based on your extended logging?
Is it OK for you if I take your code, streamline it a bit (remove logging, renaming methods, ...) and integrate it in the CM kernel?
Click to expand...
Click to collapse
Root Cause
According to my current testing (next revision kernelmod), I'm almost convinced it's caused by a race condition
between modem and modem interface (most likely the "kill_urb stuff").
Just by adding the extended logging in "if_usb_suspend" seem to have wiped the issue with the missing "wake_lock_timeout".
As next I'm going to switch back to the erroneous behaviour, verifying this theory.
If this approach would stand, the extended logging could be replaced by reasonable delays.
Not impossible, that the whole silly detection & triggering in wakelock.c is not needed.
Usage
That would be fine to me, so no problems at all with code re use.
You mean the issue is fixed by just adding some delays in if_usb_suspend? So you do not enter your wake lock fix at all with the current patch?
C-o-M said:
You mean the issue is fixed by just adding some delays in if_usb_suspend? So you do not enter your wake lock fix at all with the current patch?
Click to expand...
Click to collapse
That's what I'm currently trying out.
I would never had come up with this assumption, without the wish to understand the logic behind.
Since the nature of this presumable race condition is a fickle ***** (if my assumption is correct),
it may take a while to have solid evidence.
Although, it sounds tempting.
Thank YOU!!!
Thanks for this fix grzwolf, works as it should. Now my P7500 is great with cm10.1 and good battery life. :good:
theone
Question ! Do i have to flash source code or just only p4_kernel_2013.04.10-19.44.zip ? Thanks
saigon66 said:
Question ! Do i have to flash source code or just only p4_kernel_2013.04.10-19.44.zip ? Thanks
Click to expand...
Click to collapse
Just the one you mentioned --> p4_kernel_2013.04.10-19.44.zip
CHN Kernel
grzwolf said:
Just the one you mentioned --> p4_kernel_2013.04.10-19.44.zip
Click to expand...
Click to collapse
Since the Chinese Kernel solo, solves the problem why don't you compare the kernels. Hope i'm not ofending you with probably a stupid question. I'm saying this because when i found Stifmeister zip file and solution, i installed the chinese kernel directly via odin, and just overwrited some network files (i presume), and since then, 8 months ago, never seen a wakelock and a battery drain. Some my humble assumption was that the Chinese Kernel has no l2_hsic wakelock, except, when you connect a USB sd card and unmount it without passing through settings.
Hope it helps.
PS: I should have said this first, i'm still on stock...
Great Job anyway..
Thanks
Phibs said:
Since the Chinese Kernel solo, solves the problem why don't you compare the kernels. Hope i'm not ofending you with probably a stupid question. I'm saying this because when i found Stifmeister zip file and solution, i installed the chinese kernel directly via odin, and just overwrited some network files (i presume), and since then, 8 months ago, never seen a wakelock and a battery drain. Some my humble assumption was that the Chinese Kernel has no l2_hsic wakelock, except, when you connect a USB sd card and unmount it without passing through settings.
Hope it helps.
PS: I should have said this first, i'm still on stock...
Great Job anyway..
Thanks
Click to expand...
Click to collapse
Your suggestion is absolutely conclusive and would be definitely worth a follow up.
Afaik only Samsung knows, what sources and settings were used to build this specific Chinese Kernel,
Means, they are very unlikely available. Otherwise the magic would have been unveiled long time ago.
I suppose disassembling the kernel and looking for the specific code where the wakelock is set would be too difficult?
Sent from my GT-P7100 using Tapatalk 4 Beta
doctorow said:
I suppose disassembling the kernel and looking for the specific code where the wakelock is set would be too difficult?
Sent from my GT-P7100 using Tapatalk 4 Beta
Click to expand...
Click to collapse
At least for me.
Afaik it would end up with machine code / assembler language.
Another tool were required to translate it into C.
Even then, there were no really meaningful function and variable names.
Means, one couldn't easily compare this with existing sources.
Finally the whole exercise could result in already known source code.
Not impossible, that the "magic of the China-Kernel" is caused by very specific compiler or optimization settings, which cannot reverse engineered.
Too many if and may be ...
Comparing kernel sources is a very good idea.
Pershoot's p4 kernel is based on Samsungs kernel sources for GT-P7510, Opensource Update 2, released in April 2012 (AFAIR).
For the p5 kernel, I always rebased pershoot's kernel to the latest sources (to GT-P7300_HK_ICS_Opensource_Update1.zip in September, to GT-P7300_ICS_Opensource_Update1.zip in December). No one has ever reported the l2_hsic bug on CM for p5. Neither on CM10 (where I used the chinese kernel sources), nor on CM10.1 (updated to the official ICS sources). But the bug occured for example on AAcount's kernel which isn't rebased. So Samsung seems to fixed the issue in the kernel instead of doing some "magic hacks".
I commited a lot of different p4/p5 kernels to github to make it easier to compare them. I guess you'd like to take a look on those changes:https://github.com/cmorlok/android_kernel_samsung_p5/tree/P7300_ICS_U1/drivers/misc/modem_if
Great, of course I would. Thanks.
Just kdiffed modem_link_device_hsic from your recent P5 against P4, there are non trivial differences.
I'll give it a try right away.
hi c-o-m and grzwolf.
can you please furnish the latest code to this implementation?
any SOD as a result? any other weird behavior?
i'd like to get this in to mainline, if no issue.
thx
pershoot said:
hi c-o-m and grzwolf.
can you please furnish the latest code to this implementation?
any SOD as a result? any other weird behavior?
i'd like to get this in to mainline, if no issue.
thx
Click to expand...
Click to collapse
Following C-o-M's advise with the code review between P4 and P5 modem interface was the breakthru.
The P5 modem interface has a number of non trivial changes compared to its P4 counterpart (--> git format-patch attached).
Although I didn't understand the details, I gave them a try and replaced the P4 modem interface from your github repo completely with the one coming from P5.
Non of the usual test cases made any problem regarding l2_hsic or anything else.
- long time operation
- charging w/o reboot
- USB-drive operation
- Wifi
- 3G
Currently I'm on the 20130604 CM nightly + KernelMod, means 12 days in sequence since last reboot.
BTW: Neither a single SOD, nor any other weird behavior.
To my opinion, the l2_hsic amok issue could be finally closed.
Hail to C-o-M.
Do you think this will get merged into where ever it is that the cm team get their kernals from?
grzwolf said:
Following C-o-M's advise with the code review between P4 and P5 modem interface was the breakthru.
The P5 modem interface has a number of non trivial changes compared to its P4 counterpart (--> git format-patch attached).
Although I didn't understand the details, I gave them a try and replaced the P4 modem interface from your github repo completely with the one coming from P5.
Non of the usual test cases made any problem regarding l2_hsic or anything else.
- long time operation
- charging w/o reboot
- USB-drive operation
- Wifi
- 3G
Currently I'm on the 20130604 CM nightly + KernelMod, means 12 days in sequence since last reboot.
BTW: Neither a single SOD, nor any other weird behavior.
To my opinion, the l2_hsic amok issue could be finally closed.
Hail to C-o-M.
Click to expand...
Click to collapse
cool thx grzwolf.
Lol, shows how much I pay attention. I completely missed pershoots post.
Edit:
Ok, looks like this should be in the nightlies now....
http://forum.xda-developers.com/showpost.php?p=42680093&postcount=1875
hello exhibit community,
i successfully compiled slim rom for the t599n. i need assisstance with the camera. when i run the camera from the terminal, the results are -->I/ActivityManager( 2129): START u0 {act=android.media.action.IMAGE_CAPTURE flg=0 - Pastebin.com. the camera app disables a few moments after initial boot. the logcat shows -->E/HAL ( 1672): load: module=/system/lib/hw/camera.montblanc.so E/HAL ( - Pastebin.com which is clearly the problem. the error is referencing this -->https://github.com/SlimRoms/frameworks_native/blob/kk4.4-caf/libs/binder/MemoryBase.cpp. i swapped the camera libs from various roms, showing the same result. my guess is, a build with non caf source for native. any advice is greatly appreciated.
brandonabandon said:
hello exhibit community,
i successfully compiled slim rom for the t599n. i need assisstance with the camera. when i run the camera from the terminal, the results are -->I/ActivityManager( 2129): START u0 {act=android.media.action.IMAGE_CAPTURE flg=0 - Pastebin.com. the camera app disables a few moments after initial boot. the logcat shows -->E/HAL ( 1672): load: module=/system/lib/hw/camera.montblanc.so E/HAL ( - Pastebin.com which is clearly the problem. the error is referencing this -->https://github.com/SlimRoms/frameworks_native/blob/kk4.4-caf/libs/binder/MemoryBase.cpp. i swapped the camera libs from various roms, showing the same result. my guess is, a build with non caf source for native. any advice is greatly appreciated.
Click to expand...
Click to collapse
Our device ( included in the STE Novathor family of devices ) requires several ROM level patches in order to function. Thats one of the main reasons why we have very little "official" support. My patches are located here:
https://github.com/Meticulus/android_device_samsung_codinalte/tree/carbon/patches
You may also find some on the slimroms gerrit by @Android-Andi such as this one here:
https://gerrit.slimroms.net/#/c/8269/
BTW, I believe that SlimRom's latest ROM is dubbed "SlimKat" and not "Slim Jim" LOL :laugh:
Meticulus said:
Our device ( included in the STE Novathor family of devices ) requires several ROM level patches in order to function. Thats one of the main reasons why we have very little "official" support. My patches are located here:
https://github.com/Meticulus/android_device_samsung_codinalte/tree/carbon/patches
You may also find some on the slimroms gerrit by @Android-Andi such as this one here:
https://gerrit.slimroms.net/#/c/8269/
BTW, I believe that SlimRom's latest ROM is dubbed "SlimKat" and not "Slim Jim" LOL :laugh:
Click to expand...
Click to collapse
cool. i built caf branch btw, i will cherry pick andi's diff, rebuild, and post results. my slow pc wont complete the build until tommorrow.
http://pastebin.com/cc48puVg <-patch 6 fails
i ported the libs from his slimrom and the camera works. everything works now. i dont have data atm, so testers after he allows me to host.
thanks for pemission to andi. i found a possible bug would like to squash before hosting. i found the sim i recieved with the phone and it is not detected. this is my first gsm device developing for cdma previously. when i tick network settings, screen turns blank and the proccess android.phone quit. if i tick 4g, settings quit. possibly the sim card is no good. i will host the rom tommorrow. got work.
im hosting the rom @ af if anyone is interested in testing http://androidforums.com/galaxy-exh...90-wip-rom-test-slim-jim-rom.html#post6745103. data has yet to be verified. i will update the op when it is. everything else is working.
data fixed^
I'd like to start this out by stating that these are personal builds. I'm not trying to compete with @transi1's developer prowess; on the contrary, I feel he's done a fantastic job with TWRP 3.0.0 and porting CM13 over to the kindles, and he's part of the reason why I'm motivated to do this side project. I'm releasing these for the purpose of bettering the Marshmallow experience on our aging kindles. I want to see if a different build configuration will help improve performance and reduce lag. I'm also wanting to learn my way through the nuances of ROM development, so I intend on starting small.
Click to expand...
Click to collapse
READ THIS BEFORE PROCEEDING ANY FURTHER
I don't intend to fray any circuits when I compile these builds. However, there's always a chance that something could really go wrong and inadvertently damage your device. In such an event, I (and the awesome XDA community) will try our best to help get you back up and running. However, please don't try to sue me if your device:
doesn't work as a result of flashing this;
initiates a nuclear meltdown, or;
doesn't permit your alarm clock to function normally.
By flashing, you automatically assume responsibility for any loss of data, functionality, or facial hair. Although a 10% tip would be nice if it started printing out money.
Click to expand...
Click to collapse
Downloads:
click the Downloads tab at the top of the page, or just click here. I'm also mirroring this on Google Drive for convenience. Builds will go up on AndroidFileHost. Use this link to find and download the latest releases.
OpenGapps: use ARM, 6.0, package of your choice (I'll create a custom .gapps-config later)
SuperSU: make sure to run echo SYSTEMLESS=false>>/data/.supersu in the TWRP terminal (advanced -> terminal) before flashing SuperSU, or else you'll have to perform a restore via fastboot (credit to @r3t3ch for finding the solution)
Features:
[*]Compiled with UBERTC 4.9
UBERTC toolchain causes the post-compiled builds with the 3.0.72+ kernel to break in a really embarrassing way, so this isn't used for now
based on CM13
more to come!
Known issues in post #2
Changelog in post #3
Feel free to respond to this thread to comment or report a bug. I'm open to all feedback.
Credit where credit is due
@Hashcode, because we wouldn't have CM on our kindles at all without him.
@BuQQzz for some mentoring & advice
@transi1 for porting CM13 and providing some useful fixes for build errors
XDA:DevDB Information
[jem] CM redux, ROM for the Amazon 7" Kindle Fire HD
Contributors
monster1612, Hashcode, transi1, BuQQzz
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.0.x
Based On: CyanogenMod
Version Information
Status: Alpha
Created 2016-03-29
Last Updated 2016-08-07
Known issues
Bugs affecting all CM13-based ROMs on the kindle
Screen artifacts when playing video from Snapchat, Vine, etc.
Audio chops in and out often
Other bugs currently afflicting the other CM13 ROMs for this device
Camera currently doesn't work (although it is functional in the 3/20 RR build and earlier ROMs for jem)
Side note: This camera issue is prevalent w/ transi1's CM13 3/28 build, so it's not specific to this ROM only.
Play Store & Setup Wizard FCs
CM pushed a commit to fix the FCs, so now every ROM built from this point forward should be OK with flashing the latest gapps. (thanks to @r3t3ch for the find)
Changelog
08/07/2016
experimental backtracking to kernel 3.0.84+
July '16 AOSP patches (hoping 8/1/16's patchset made it in there too)
07/01/2016
doing yet another revert to the 3.0.72+ kernel, prior to transi's backporting of the newer one (3.0.101+) that broke the camera
June '16 AOSP patches, plus just about everything CM pushed up until 7/1/16
reverting from UBERTC toolchains to native CM/AOSP one
05/20/2016
defecting to BlissRoms-Devices GH for newest device config files
05/2016 security patches from AOSP, et al.
04/27/2016
refreshing CM sources & obtaining latest sources from transi1
04/09/2016
revert the 4/4 kernel reversion; back to 3.0.101(+)
carry in latest edits from transi1 to try to fix the camera
04/04/2016
revert to kernel 3.0.72+
first build that's been mostly summoned from my local jenkins install - now future builds should automatically upload to the AFH server
03/29/2016
initial build!
Roadmap
The following is a list of features I think will make it onto future builds. Feel free to contribute any suggestions, bug reports, etc.
Layers/RRO theming support
Custom boot animation (or at least one scaled to the kindle's screen size)
Possible removal of some unused stock apps (I'll package them into a separate flashable .zip in case)
Publication of a custom .gapps-config file for use with opengapps packages
I'm going to attempt to resolve the infamous camera bug by starting from a known good point in time and backtracking up through transi's kernel commits. This means a lot more frequent builds (sometimes unstable!) in the next couple days. I hope you guys are ready for more testing.
So far, it seems like transi's github commits to the common device repos may have fixed the camera (thus the reason why I didn't release another backtrack through the kernel commits). However, I don't know for sure, as I haven't tested out today's build yet. Any testers coming from earlier builds should not dirty flash this release; a clean wipe would be preferable. Feel free to let me know how things go.
Today's nightly has nothing special in terms of features, etc. However, I'm going to start implementing features as outlined in the roadmap. As usual, do let me know if there's something you'd like to see.
Some updates...
I still haven't gotten around to trying to bring RRO to this ROM. Apparently, CM's theme engine (which should have been compatible with RRO, but isn't) has conflicts with RRO/layers, and those have discouraged me from bringing RRO in (so far).
I think TWRP 3.0.2 needs to be built for both jem & tate. That release has some important fixes regarding encrypted backups, and even the TWRP people themselves recommend you stop using 3.0.1 if you use encrypted backups. I'm going to build for another ROM (hai there, OmniROM!) and compile against that source for TWRP. EDIT: transi said he'd wait till TWRP 3.0.3 is released to compile it, so we can stand to wait for it.
More updates...
It's been a while since the last build. Obviously, this one I just uploaded is about 2 weeks old at the time of writing. You may be wondering why I took so long to drop this build. It's complicated:
I was seriously curious as to how the camera managed to break down during transi's kernel backporting in mid-/late March. Such curiosity led me to attempt to revert the device repos to a stable state so I could build against 3.0.72+ instead of 3.0.101+.
My reversion efforts were successful (for the most part). I was able to get the process to succeed like normal, but when I tested out the builds (compiled against UBERTC), there was a breaking issue. The camera worked well enough (as I expected), but as soon as I tapped any textbox at all (even the password prompt for a WiFi network that required one), the screen would glitch out and force a reboot. I thought that maybe it was an error on CM's part, so I waited a day or so and compiled again, getting the same issue. At that point, I was baffled and decided to recompile with CM's native toolchain instead of UBERTC.
That build was on 7/1, and is the build that was uploaded an hour ago. I had it built then, but was waiting for a good time to test it out to see if that issue was resolved. Sure enough, when I tested it out tonight, it didn't occur.
Also, you may have noticed that I changed the ROM project name to CM redux. I did this to signify that this project won't be a full-on verbatim port of CM. (right now it is, but that's beside the point.) The name won't officially show up in the ROM itself until the next build, most likely.
Finally, some planned changes:
I'm going to continue with my backtracking scheme. I want to know exactly which commit is responsible for the software failure of the camera.
Obvious name change in the ROM, mentioned earlier.
Replacing CM's theme engine with RRO(?)
CM bloat cleanup. The ROM itself boots in 30 seconds, which is nice and all, but I'd like to try to trim it down a little more.
Good version,thanks. But it often wifi reconnect , can it fix?
wizard_mini said:
Good version,thanks. But it often wifi reconnect , can it fix?
Click to expand...
Click to collapse
I have that same issue with other 6.x ROMs, but I'm not sure what the cause is. Could you get a logcat as soon as that issue pops up again?
monster1612 said:
I have that same issue with other 6.x ROMs, but I'm not sure what the cause is. Could you get a logcat as soon as that issue pops up again?
Click to expand...
Click to collapse
It looks like WiFi 2g link no problems, 5g often reconnect. Let me test more time
Android system cost battery drain more than screen, is it normal?
wizard_mini said:
Android system cost battery drain more than screen, is it normal?
Click to expand...
Click to collapse
That depends on what apps you have installed, how heavily you use the device, and other factors. Try installing BetterBatteryStats as a system app, using it for a few days, and then report back some of the data it collects.
I flash the opengapps pico,when I install G-mail app , it said I must add a Google account,but I already setup my Google account, then I can't open gmail. Why?
wizard_mini said:
I flash the opengapps pico,when I install G-mail app , it said I must add a Google account,but I already setup my Google account, then I can't open gmail. Why?
Click to expand...
Click to collapse
I ran into this same problem using RessurectionRemix. I had to install an older version of Gmail, then update it from the Play Store.
Try this version:
http://forum.xda-developers.com/showthread.php?t=1181033
That's not the one I used, but I used a similar version from here somewhere.
sirp0p0 said:
I ran into this same problem using RessurectionRemix. I had to install an older version of Gmail, then update it from the Play Store.
Try this version:
http://forum.xda-developers.com/showthread.php?t=1181033
That's not the one I used, but I used a similar version from here somewhere.
Click to expand...
Click to collapse
It's a good solution,, I fix it, thanks
monster1612 said:
That depends on what apps you have installed, how heavily you use the device, and other factors. Try installing BetterBatteryStats as a system app, using it for a few days, and then report back some of the data it collects.
Click to expand...
Click to collapse
I use 4hours screen on and 7hours screen off cost 92% battery.
wizard_mini said:
I use 4hours screen on and 7hours screen off cost 92% battery.
Click to expand...
Click to collapse
I have a similar issue when I let my kindle sit overnight. I'm guessing it might be a commit that I reversed when I reverted to the 3.0.72+ source. I'll do a new build within the next few days with a few kernel updates thrown in.
monster1612 said:
I have a similar issue when I let my kindle sit overnight. I'm guessing it might be a commit that I reversed when I reverted to the 3.0.72+ source. I'll do a new build within the next few days with a few kernel updates thrown in.
Click to expand...
Click to collapse
Thanks. I am expecting it!
This has reached a point that those who don't depend BT calling may be able to use it as a daily driver. Just be sure to backup first!
The flashing on first boot during setup may cause issues for those with epilepsy. This is due to how to disable the second screen.
Working:
Camera! https://www.celsoazevedo.com/files/android/google-camera/f/GCam5.1.018-Arnova8G2-V1.7Beta2.apk is recommended with Nexus 6 HDR config in advanced settings.
Bluetooth (skips with wifi, and doesn't work in call)
NFC
Wifi -- two users have reported issues on their devices, while it works for others.
GPS
Sensors
Sound
Calls
Fingerprint
Data
WiFi tethering
Second screen disable hack
Not working and issues:
Screen glitches on first boot. Reboot and will be good after (part of hack to disable 2nd screen)
Tap to wake
Flashlight tile: install flashlight tile for kenzo in play store with root to workaround.
Slight animation glitch when switching activities due to second screen hack.
BT issues above, and doesn't work in call.
If you use camera immediately after turning on, it may not work. You must wait about a minute after powering for it to work (it will always work after).
Probably more.
TODO
BT fixes
Tap to wake
flashlight tile
get a proper 2nd screen fix like v20 working without additional issues. v20 dtsi hack doesn't work for us due to dual panel depending on partial update (most likely).
Repos (kernel is lineage-15.1 branch):
Kernel
v10-common
h901
blobs
Changes from AOSCP
Using Ruthless launcher instead of Luna
Two reverts to support substratum themes in addition to CypherOS' color manager.
Use opengapps for gapps, magisk for superuser (may have issues with modules).
Download
Buy me a beer with Bitcoin: 1h9o1Ei9thLd8JKRz3z7PUGhX6dtfnktY
Bugs with workarounds:
Wifi doesn't connect and MAC address is all zeroes (only some users):
This is a misc partition that has MAC address hardcoded to a randomly generated address. This should work permanently on any device with the issue so long as two aren't on the same network. If anyone would like instructions on how to modify with a new MAC address, let me know.
Image https://www.androidfilehost.com/?fid=818222786056033811
Instructions:
Place on /sdcard
Reboot to recovery (for advanced reboot in CypherOS hold reboot button for full menu)
From twrp terminal or adb shell, run: dd if=/sdcard/misc.img of=/dev/block/bootdevice/by-name/misc
Reboot and enjoy fixed wifi
No charging indicator (but still charges):
Boot device plugged into power or USB and the indicator will work the entire power cycle. Working on a fix but not as trivial as I'd hoped.
Bootloop bug:
I recently got hit by the infinite bootloop bug, with the only workaround of disabling the big cluster. Here's a modified TWRP that only uses the little cluster (used Eliminator74's image):
https://www.androidfilehost.com/?fid=818222786056035329
And here's a little cluster only boot image from the titan kernel (our CAF kernel has msm_thermal issues with booting with disabled big cores, needs modifications):
https://www.androidfilehost.com/?fid=674106145207491774
nvm, fixed in current build
Just uploaded a new build. Changes:
Tweaked touch offset
Synced CypherOS to 6.0.0 (fixes navbar on first boot and some others)
Fixed init script to set display res (part of the second screen disable hack)
Updated Ruthless Launcher
two questions: the kernel you mention in repo is the original one or is a Lineage Kernel for LG V10? it for all variants of V10?
thanks
sun_is_shinning said:
two questions: the kernel you mention in repo is the original one or is a Lineage Kernel for LG V10? it for all variants of V10?
thanks
Click to expand...
Click to collapse
That lineage-15.1 branch that is being used is based on the lineage 14.1 g4 kernel. I added a h901 defconfig, three commits needed for v10 (incl 2nd screen hack), fast charging, all commits needed for Oreo (since g4 isn't supported on los 15.1), then merged in CAF.
Regarding the other variants (which are now all unlockable thanks to g4 guys), I added a commit by ehem which added the panel dtsi for other variants, but as of yet only h901 builds have been tested on the kernel. Other variants should work with the correct defconfigs and device repos adapted from their g4 counterparts.
Hope I answered fully.
johngalt1 said:
That lineage-15.1 branch that is being used is based on the lineage 14.1 g4 kernel. I added a h901 defconfig, three commits needed for v10 (incl 2nd screen hack), fast charging, all commits needed for Oreo (since g4 isn't supported on los 15.1), then merged in CAF.
Regarding the other variants (which are now all unlockable thanks to g4 guys), I added a commit by ehem which added the panel dtsi for other variants, but as of yet only h901 builds have been tested on the kernel. Other variants should work with the correct defconfigs and device repos adapted from their g4 counterparts.
Hope I answered fully.
Click to expand...
Click to collapse
Will you add the other version? For H960, H960TR vs.
Kasimpasali1921 said:
Will you add the other version? For H960, H960TR vs.
Click to expand...
Click to collapse
It's planned.
Hey, I just have a question, I'm sorry probably borrowing your thread to ask, but how'd you get the ROM to build using 15.1/14.1? I've been working on a port horrible the h901, but for the life of me I can't get the ROM to build.
Also, when I get a chance I'll check out your ROM, haven't gotten to play with oreo much as of yet.
TheEnekaign said:
Hey, I just have a question, I'm sorry probably borrowing your thread to ask, but how'd you get the ROM to build using 15.1/14.1? I've been working on a port horrible the h901, but for the life of me I can't get the ROM to build.
Also, when I get a chance I'll check out your ROM, haven't gotten to play with oreo much as of yet.
Click to expand...
Click to collapse
Ask any question you want here! I'm not sure specifically what issue you ran into while attempting to build, but the repo links in OP are fully up to date (incl the lineage-15.1 branches).
Unfortunately los 15.1 has the graphical glitches (due to 2nd screen hack) after the second boot as well, so I'll be sticking with cypheros for testing for now.
I'll make a project manifest shortly to further simplify building.
johngalt1 said:
Ask any question you want here! I'm not sure specifically what issue you ran into while attempting to build, but the repo links in OP are fully up to date (incl the lineage-15.1 branches).
Unfortunately los 15.1 has the graphical glitches (due to 2nd screen hack) after the second boot as well, so I'll be sticking with cypheros for testing for now.
I'll make a project manifest shortly to further simplify building.
Click to expand...
Click to collapse
Sweet, I'll have to have a look at those repos. Only ones I could find before were cm 13.1. I was working on a RR 14.1 port, since that's one of my fav roms, but basically the error I got was a brunch error as it couldn't find the needed files (maybe the manifest? It's been about a week since I poked it). It kept looking at the lineage servers and couldn't find the right cm versions. It also couldn't find other things as well, but I'll have to poke it again to remember what exactly.
Thank you though!
(I also just realized that my auto correct called the h901 horrible. It's def not horrible. xD)
TheEnekaign said:
Sweet, I'll have to have a look at those repos. Only ones I could find before were cm 13.1. I was working on a RR 14.1 port, since that's one of my fav roms, but basically the error I got was a brunch error as it couldn't find the needed files (maybe the manifest? It's been about a week since I poked it). It kept looking at the lineage servers and couldn't find the right cm versions. It also couldn't find other things as well, but I'll have to poke it again to remember what exactly.
Thank you though!
(I also just realized that my auto correct called the h901 horrible. It's def not horrible. xD)
Click to expand...
Click to collapse
For building without the manifest, clone the device and vendor repos to their correct folders, check aoscp.dependencies to clone additional repos to their correct folders, then just run . build/envsetup.sh ; breakfast aoscp_h901-userdebug, and then you can make bacon ?
I based the device repos off the g4 repos for aoscp, which are just los 14.1 with Oreo and now v10 changes. The kernel is based on the los 14.1 lge msm8992 kernel with changes necessary for Oreo, CAF merged in, fast charging support, the second screen disable hack, a commit for building properly with a lge display flag, the dtsi for other v10 variants (thanks to ehem), and a defconfig for h901.
Edit: keep in mind RR may have the same display corruption issue with our second screen hack that LOS has for us.
New build uploaded. Changes:
- Fixed touchscreen alignment. Bottom of navbar now works.
- Synced with upstream CypherOS
- Testing navbar theme settings from gerrit.
New build uploaded. Changes:
- Possibly fixed occasional no sim on boot (ty kessaras/steadfasterx)
- Synced with CypherOS
- A few upstream ALSA kernel changes
- Ruthless launcher updated
- Two upstream reverts to fix substratum themes.
There's now also a local_manifest for users who would like to build themselves https://github.com/amillogical/local_manifest
Is this compatible to my lg v10 h962 (from taiwan)?
ViciousDiplomat said:
Is this compatible to my lg v10 h962 (from taiwan)?
Click to expand...
Click to collapse
No, but it can be. Is your device bootloader unlocked? If so, I'll do a build from h815 (g4 equiv) you can test. If not, I can help bootloader unlock it with USU.
I'm not sure how many know, but all v10 variants are now bootloader unlockable with USU. I just haven't had a chance to build for them or post details.
well, will this Kernel of this ROM compatible with H960A variant? and what really changes in this Kernel?
Thank u.
sun_is_shinning said:
well, will this Kernel of this ROM compatible with H960A variant? and what really changes in this Kernel?
Thank u.
Click to expand...
Click to collapse
Yes, it only needs a config for h960 at this point. Ehem imported the panels for all the other variants so we can use a unified kernel between all g4 and v10 variants.
Will done sir i'll buy you a bear on your bitcoin wallet for sure.. Gr8 job
An old user for v10 (p20 pro now) but still love this beast
New build uploaded. This won't fix wifi issues for those that have them. This build needs a dalvik-cache wipe after dirty flash due to memory override changes (last bullet). I've also started using AndroidFileHost for uploads.
Changes:
- Synced with upstream CypherOS (bumped to april security bulletin and a few new features).
- NFC should be fixed. This needs more testing, as I don't have anything to test the functionality but it turns on/off.
- Corrected STM laser permissions (autofocus seems to be like in stock rom now).
- Changed link to modified google camera in OP since the previous version didn't have functional HDR+.
- Dalvik heap and hwui memory overrides updated for our device's 4G ram and high res display.
And thank you @sherif2222222
New build up at sx.ix5.org, use version 2018-10-30.
Changelog here: https://sx.ix5.org/changelog.html
Install guide: Flashing AOSP on Xperia XZ
XDA:DevDB Information
AOSP Pie based on Sony Open Devices Project, ROM for the Sony Xperia XZ
Contributors
local__hero, fastbooking, oshmoun
Source Code: https://git.ix5.org/felix/local-manifests-ix5/src/branch/ix5-customizations
ROM OS Version: 9.x Pie
ROM Kernel: Linux 4.x
ROM Firmware Required: .184 / .192
Based On: AOSP
Version Information
Status: Nightly
Created 2018-11-09
Last Updated 2019-05-17
Reporting bugs
Important: Read the bug list before posting. Anyone can add bugs to the list, just follow the rules.
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
Don't make me ask you for logs every time!
I will repeat the rules again here:
Rules:
New bugs must include version where error popped up and which oem version you are using
Only reproducible errors
Should include adb logcat (linked in a pastebin service like https://del.dog)
Must include clear description what is wrong
If it is a visual/SystemUI bug, only report it here
If it is an internal bug(e.g. fingerprint crashes device), report it to the Sony bugtracker as well!
Always try to fix the bug yourself first! Then submit a pull request to Sony
Must search if error has already been reported (bug tracker, this document, dev buglist)
If you've reported the issue somewhere else already and just want to track it here as well, add a link
Before reporting a bug, always make sure to isolate it. That means, wipe everything, install only the ROM without GApps and Magisk and see if the problem still exists. Only then report the bug!
---
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
---
In 9.11
1. Everything still works
2. Charging with plugged at screen off works
3. On gcam portrait mode and night photo gives purple glitched image
And phone seems to be faster.
Bug: 9.11 with oem v2- Clean install
- Hotspot not working
- Phone call issue - Mic and speaker not working, cannot hear anything or say anything << Listed in the bug
- Top speaker not working
Still testing.
An update
Yes, we know calling is kinda broken right now on both oem versions. Yes, we know you have problems with dualsim devices because you didn't flash the dualsim patcher. Yes, battery life isn't very good because we are testing out some increased CPU frequencies so video doesn't stutter. (you can go back to the 11-05 build which has the old CPU freqs and compare).
We're aware of a lot of these issues, and they are all tracked in the current buglist (see post #2).
Development happens mostly in the Sony open devices program, with a few heroic volunteers contributing. Right now, a lot of work is being done to get the current flagships(think XZ2, XZ3) to a semi-stable state, but work for our device is done as well.
You can check progress in the sonyxperiadev repos. E.g. recently, some changes to the telephony HAL integration have been made, see the common device repo.
Why is it taking so long to fix all this?
Sony buys many of their processors from Qualcomm. Lots of stuff in phones is proprietary and covered in patents, and you can only get the source code if you sign an NDA. So even if Sony wanted to, they could not release the source for a lot of things.
See all the files with the name "qti" in them? That's Qualcomm Technologies, Inc. See all the repos named something like "qcom-something-something"? That's Qualcomm.
When there's a problem, we have to report it to Sony, who report it to Qualcomm. This takes time already. And don't forget Qualcomm has suppliers as well, and so on and so on. The same is true for other parts, e.g. the Wi-Fi chips are from Broadcom.
Then, support for hardware stuff is on many levels. A lot of low-level drivers that are driving the hardware are on the /odm partition(the one that the oemv1/v2 blobs get flashed to). Then there is work to be done tweaking the actual hardware abstraction layer(HAL) interfaces that work with these driver blobs. Then there are kernel drivers that can go wrong and mess up. Then it can be a problem somewhere higher up in the Android frameworks. Lots of detective work.
If new blobs from Qualcomm come out, Sony itself needs to do some testing, and then releases a new oem version. It won't just magically work, we need to tweak the SODP vendor side as well. It could be as easy as changing a version to a newer one, but it could also be a lot harder. The sonyxperiadev crew knows what's needed to integrate these new blobs, but it still takes time and testing.
Qualcomm provide the a lot of the source code to work with their hardware and blobs from the higher-level Android side in their CodeAurora forum (CAF) repositories. The relevant changes then get merged into the sonyxperiadev repos and we can test if it works(or if something new is broken...).
For more info, read the Android documentation on hardware etc.
The chip in our phone, the MSM8996, is quite old already(even the SDM845 in the XZ2/3 is already quite old in processor standards). We can be luck that Qualcomm still provides support. But it's not a priority to them, they want to sell new
ones of course. That is also a reason updates can take longer.
Regarding full forced-reboot crashes:
Sadly, as of now, for some people the "/sys/fs/pstore" folder does not get populated after a crash. This is important to diagnose what happened.
You can apply this patch to force a kernel panic on every reboot, but I would recommend that you do
so only if you know what you are doing.
Regarding battery life:
Please install BetterBatteryStats
and find out what is draining the battery.
This could really help us out! But first, make sure you are not running any GApps, because the Google Mobile Services are a massive pile of battery drain.
If you absolutely have to use GApps, please run only the "pico" GApps version!
---
About the posts here:
Like 90% of posts here and in the old thread are full of people who just plain refuse to read, asking how to install or demanding someone help them out with something that has already been answered time and time again. This makes it extremely annoying for the us who have to scroll through pages of useless stuff to find the genuine bug reports. You do realize this site is literally named "xda-developers", right? If you're unclear on the concept, please read this: https://forum.xda-developers.com/showpost.php?p=16682226&postcount=2441
"This doesn't work!" - "This thing crashes!" - That gives us almost no clue what is happening. We need logs, or we can't do anything about it. I have only one phone, and I only use the stock ROM. There are a lot of nice testers who send others and me helpful bug reports, with detailed explanations in what circumstances it occured, with proper logs.
With that info, the Sony open devices team and us can actually look into issues.
So please, if something doesn't work AND we are not aware of it yet, post it to the bug list (not here!) and attach a link to a log that you uploaded, e.g. to a service like hastebin.com.
nhicko95 said:
how is battery life?
Click to expand...
Click to collapse
Test it out, please. And don't forget to report the diagnosed battery stats.
DarkPrinciple said:
I should be able to get to 12 lunch with my battery being more than 50%
Click to expand...
Click to collapse
I've tweaked for more performance right now, but you can use 11-05 to get old CPU freqs. Also, please help hunt down what is draining the battery, it's most likely too many held wakelocks, but it could be any number of things.
bihslk said:
So what is the latest and best working version of this rom?
Click to expand...
Click to collapse
It's literally in the first post.
bihslk said:
Rom is pretty OK but really annoying top speaker bug. Only lower one works.
Click to expand...
Click to collapse
That is already in the bug list. Please read the bug list before posting.
Update 2018-11-16
Some new developments are happening.
Oem binaries version 3 are out. This should give improved power management. The SODP team has also worked on getting audio handling during calls to work. A big thanks to oshmoun for his work on the audio manager. This change was introduced on the 11-15 build. The issue of no call audio when a bluetooth headset is connected is still present as of now.
Changed IRQ handling (PR by Angelo/"kholk"). This should give better battery life and maybe faster wakeup from deep sleep. But could also lead to instabilities and crashes. Send logs & pstore, see post #2. This change was introduced on the 11-15 build.
Testing kernel 4.9.137 i in progress (we are currently on .103). This means stability and security enhancements from upstream linux. Thanks to Nathan Chance who opened this pull request..
But some of those upstream changes might be incompatible with our Sony kernel, so we have to test that. Send logs & pstore, see post #2. This change was introduced in the 11-16 build. If the 11-15 and 11-16 builds are unstable, revert to an older one. But please be brave and run them for at least a day to get us logs of potential crashes.
---
optixperiaa said:
I am always confused about "flash latest stock ftf" part about roms as a newbie.. if we flash sony's ftf how can we flash rom ? isnt it overwrite ?
Click to expand...
Click to collapse
Your phone software is made up of many layers. The ROMs like omni or this AOSP-based one only modify your /system and /boot partitions.
But when you update your stock firmware via flashtool, you also update your phone modem firmware, your qnovo charging controller firmware, your lower-level bootloaders etc. That is why we instruct you to update to the latest stock firmware. You could theoretically skip flashing /system in flashtool(because it will get overwritten anyway, as you've already discovered) and directly flash a custom ROM afterwards.
When you're coming from omni, there is no need to flash stock firmware again in between, because your other partitions stay the same. Just a new /oem is needed.
viori said:
flash omni_kagura-2018-11-20_UNOFFICIAL_TESTBUILD-2
Click to expand...
Click to collapse
Again, please keep this thread about development for AOSP. The omni builds are not meant for you.
If you have trouble installing then simply don't use it.
DO NOT POST HERE FOR HELP OR YOU WILL BE REPORTED. Read everything before posting.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
The OP has requested that you do not post questions in this thread, please use the thread he states in the OP to do that.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
Click to expand...
Click to collapse
Thanks
Thread cleaned
General update
Newer builds will have selinux set to "enforcing". Most denials should have been fixed or are irrelevant. If you encounter any problems, selinux-related or anything else, please report them to the Sony bugtracker or - even better - submit a pull request to the selinux-policy repo.
Update 1: vendor blobs aren't binderized correctly atm, so no network. You can set selinux back to permissive to fix most issues atm.
The Wi-Fi hotspot has been fixed thanks to oshmoun. In newer builds, it should be using less battery.
Next thing we're going to tackle is deep sleep and battery drain. Big pain point and one of the last blockers, apart from the camera and bluetooth in-call audio.
You might have noticed that the omnirom device trees have been updated to 9.0. Nightly testing builds work fine, but they have the same issues as the AOSP-based ones.
Work is also under way to get a Pie-based TWRP recovery stable, with support for FDE encryption(this means that you will be able to back up your encrypted installations). Mounting /userdata works, but the builds are not ready for public release yet.
Update
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
local__hero said:
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
Click to expand...
Click to collapse
Great job.
I already built a custom Pie kernel about a week ago to gain better performance but the charging bug was driving me insane :crying:
I guess now's the time to go back to the mighty Pie and try building a nice and hopefully stable Marrow Kernel.
Cheers
Finally a new build is out!
I can't pass safety net on latest build.
Any ideas what should I use ?
Since modules for spoofing fingerprint simply don't work.
I tried universal safety net fix but with no avail.
V 12.15
Charging working fine. But i have problem with camera, photos are very dark.
Sometimes touch screen not working and i need to switch the screen and on again.
ov2rey said:
Sometimes touch screen not working and i need to switch the screen and on again.
Click to expand...
Click to collapse
Disable Dt2w
oem v4 is out
DahakePL said:
Disable Dt2w
Click to expand...
Click to collapse
Thank you It's work!
Layns said:
oem v4 is out
Click to expand...
Click to collapse
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
ov2rey said:
Thank you It's work!
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
Click to expand...
Click to collapse
I tried it works fine but the camera sucks and the sound is bad, the screen opening with double tap is running slow, the charge is a little quick