[DISCUSSION] Wifi drop-out issue on custom roms - OnePlus 7 Pro Guides, News, & Discussion

** SEE THE EBD OF THIS POST FOR A WORKAROUND! **
Hey all,
I'm bringing the discussion from across a few custom rom threads (Havoc etc.) in to one place to hopefully work towards finding a solution. The issue being on custom roms, some users (myself included) experience Wifi disconnecting/reconnecting when the signal is low - when in the same environment, this does not occur on stock OOS. For example, when I'm in my bedroom, on Havoc for example the signal shows itself to be low but will periodically disconnect/reconnect, despite still actually having a connection, albeit weak. As mentioned, this does not occur on stock.
What I've tried/things to consider:
- It was mentioned that someone who flashed he global rom (I'm on EU) didn't experience this issue. However after a full clean flash I unfortunately encountered the same issue. In hindsight, I didn't boot the rom in to OOS before flashing Havoc, would that make a difference? I wouldn't have thought so though.
- The Magisk module Wifi Bonding, which was thought to perhaps help, didn't make a difference
- The dev (@SKULLSHADY) informed me that Havoc has the Wifi config from OOS, so that unfortunately can't be a solution
- Toggling Wifi scan throttling in developer settings made no difference. Though on this point, it's almost like the custom rom - annoyingly only for some users - is detecting a weak connection and switching to mobile data, despite still having a connection. Like it's got a threshold of what signal strength should be, realises it hasn't, cuts it off but then reconnects.
I've attached a log of when the issue occurs. I'm no expert and don't have a clue what to look for (perhaps someone else does?) but one thing I noticed was this bit upon the disconnection:
04-02 17:43:06.429 I/BugleRcsEngine(6806): [383] uzw.d: Connected state: [1], networkType: [WIFI] 04-02 17:43:06.954 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:08.958 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:10.968 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:13.362 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:13.990 D/ConnectivityService(1667): Lingering NetworkAgentInfo [WIFI () - 150] for 30000ms 04-02 17:43:13.993 D/ConnectivityService(1667): Sending DISCONNECTED broadcast for type 1 NetworkAgentInfo [WIFI () - 150] isDefaultNetwork=true 04-02 17:43:18.604 D/QCNEJ/WlanStaInfoRelay(2492): Received action: android.net.wifi.RSSI_CHANGED
So with my absolute amateur analytical observation here, I note the below as perhaps relevant to the disconnection:
"android.net.wifi.RSSI_CHANGED"
After Googling this, I came across the following Reddit page:
[url]https://amp.reddit.com/r/tasker/comments/ccezew/intent_received_context_no_longer_working/[/URL]
They talk of "signal strength verification" - which perhaps is what's going on here as in when further away from the router, something is going and resulting on WiFi disconnecting/reconnecting just because the signal is low, despite still having signal. However, this may or may not be of relevance - I don't have a clue! Lol
There's also this:
D/ConnectivityService(1667): Switching to new default network
Though unsure why its disconnecting in the first place...
So in my humble summary, its like something at some level is monitoring signal strength and disconnecting/reconnecting as the result. But I could be completely wrong. I recall it mainly doing so when further from the router but I'm sure it had a couple times too when very close to it.
I just really wanna solve this issue and seemingly if we can, it could possibly fix it for all custom roms that face this WiFi issue.
Any help would be greatly appreciated!
UPDATE: This issue seemingly is NOT present on the new CarbonROM!!! So whatever the difference is in terms of settings or source code, this rom does no suffer with the Wifi drop out issue!!
WORK AROUND :
Just wanted to update that I'm nicely settled in Havoc now. A workaround was found that when mobile data is disabled, the WiFi doesn't disconnect!
Therefore you can either manually toggle this, or I'm using Macrodroid to automate mobile data enabling upon WiFi disconnect and disable up on WiFi reconnect, via a Macro. I've even used The Data Disabled Icon in Havoc to hide the fact that mobile data is disabled, as that little cross in the icon was bugging me lol
I did test without disabling data for a while yesterday and whilst it did still cut out every now and then, it really is only when signal was quite low. Still though, I'm really liking this workaround as I'd manually toggle WiFi anyway when at home or leaving, so in ways, this workaround is perfect and doesn't present an issue, as such, to me any more.

I've had this issue since early 10 custom ROMs in late 2019. Wi-Fi was working just fine on Pie custom ROMs.
I also had a Nexus 6P before with Pie custom ROMs, same house, same router, same location, no issue.
As stated in OP, Wi-Fi is perfectly stable on OxygenOS at the same location in the house.
As far as I'm concerned, signal strength is "Poor" on custom ROMs and either "Fair" or "Good" on OxygenOS. I guess Wi-Fi signal is weaker on custom ROMs than on OOS but it shouldn't disconnect.
ROMs I've flashed with the issue:
Bliss
crDroid
EvolutionX
HavocOS
MSM Xtended
CarbonROM
Potato Open Sauce Project
Paranoid Android
Omni Treskmod
Kernels I've used/flashed (doesn't make any difference):
Smurf
Kirisakura
Whatever kernels that came with the ROMs above mentioned
Other things that were suggested that I've tried:
Using static MAC address instead of randomized in device Wi-Fi settings
Switching to Google or Cloudflare DNS in my router settings
Wi-Fi would drop very often and I had to wait for about 30 seconds before it reconnects, so I went back to stock OxygenOS for now.

I have the same problem, please @skullsHADY fix it, cause that's currently the biggest problem in Havoc on the OP 7 PRO

Sounds like somerhing is amiss when it comes to the roaming threshold in those customs ROMs. Perhaps some value is misaligned causing the roaming to kick in to soon?

Maximilian Gaedig said:
I have the same problem, please @skullsHADY fix it, cause that's currently the biggest problem in Havoc on the OP 7 PRO
Click to expand...
Click to collapse
You tagged the wrong person.

From CarbonROM thread:
musicman5844 said:
Just to give you a heads up flashing global oos prior will not help I'm in the USA and I now after one month have started having the wifi drop out issue now for 26 hours and 5 different roms including this one I've only found one without the issue and it's Omni tresksmod I really thought I was the lucky one that never had the issue guess I was wrong .
Click to expand...
Click to collapse
So both Omni and Carbon wouldn't have the issue?

I have the same issue with LineageOS 17.1

Thanks for everyone's input so far. This is a fundamental issue which I hope can be addressed!

Toutatis_ said:
From CarbonROM thread:
So both Omni and Carbon wouldn't have the issue?
Click to expand...
Click to collapse
Technically if all these devs would realize stop using lineage os as there base are items from lineageos like there kernel these things wouldn't happen Omni treskmod uses redflare kernel but that's just my thought on this .

musicman5844 said:
Technically if all these devs would realize stop using lineage os as there base are items from lineageos like there kernel these things wouldn't happen Omni treskmod uses redflare kernel but that's just my thought on this .
Click to expand...
Click to collapse
Well, the vast majority of users don't seem to have the issue, including those who use a LOS based custom ROM (crDroid for instance). Wi-Fi breaking every couple of minutes is a real PITA, we would have many more reports in OnePlus 7 Pro forums if it was a widespread issue.
Regarding whether it's kernel related or not, I don't know, maybe. As I said in my previous post, I tried many different kernels and it didn't make any difference.
Carbon is based on AOSP and as far as I know, Omni is based on OxygenOS. Since the issue doesn't occur on stock OxygenOS, Wi-Fi is probably just as stable on Omni (didn't try it so I can't tell). Maybe the difference between Carbon and others AOSP based ROMs that results in stable Wi-Fi would be the kernel then?
I might try Carbon later to see if Wi-Fi is actually stable, I'm a bit tired of clean flashing right now. Carbon doesn't have enough custom features for me so I'm not going to keep it anyway. Same for Omni.

Toutatis_ said:
Omni is based on OxygenOS. .
Click to expand...
Click to collapse
it's new this?

c3drik 67 said:
it's new this?
Click to expand...
Click to collapse
My bad, I've just read on official website that it's AOSP based. Sorry.

Toutatis_ said:
Well, the vast majority of users don't seem to have the issue, including those who use a LOS based custom ROM (crDroid for instance). Wi-Fi breaking every couple of minutes is a real PITA, we would have many more reports in OnePlus 7 Pro forums if it was a widespread issue.
Regarding whether it's kernel related or not, I don't know, maybe. As I said in my previous post, I tried many different kernels and it didn't make any difference.
Carbon is based on AOSP and as far as I know, Omni is based on OxygenOS. Since the issue doesn't occur on stock OxygenOS, Wi-Fi is probably just as stable on Omni (didn't try it so I can't tell). Maybe the difference between Carbon and others AOSP based ROMs that results in stable Wi-Fi would be the kernel then?
I might try Carbon later to see if Wi-Fi is actually stable, I'm a bit tired of clean flashing right now. Carbon doesn't have enough custom features for me so I'm not going to keep it anyway. Same for Omni.
Click to expand...
Click to collapse
https://treskmod.ru/
---------- Post added at 04:16 PM ---------- Previous post was at 04:15 PM ----------
musicman5844 said:
https://treskmod.ru/
Click to expand...
Click to collapse
Also mokee don't have that issue and we are working on aicp for op7 op7pro op7tpro and at some point op8pro

musicman5844 said:
https://treskmod.ru/
---------- Post added at 04:16 PM ---------- Previous post was at 04:15 PM ----------
Also mokee don't have that issue and we are working on aicp for op7 op7pro op7tpro and at some point op8pro
Click to expand...
Click to collapse
Thanks, I didn't know about Treskmod and MoKee. I might give them a try as well.
Links for those who would be interested:
https://dl.treskmod.ru/oneplus7pro/
https://download.mokeedev.com/guacamole.html
Indeed, AICP website lists guacamole but there isn't any build yet. Will test too!

I flashed a couple of other ROMs today.
CarbonROM (CARBON-CR-8.0-PAX-WEEKLY-guacamole-20200424-1620.zip): Wi-Fi disconnected during the initial setup / once more ~5 minutes later / once more ~10 minutes later @cd993
Potato Open Sauce Project (potato_guacamole-10-20200413-croquette.v3.1.7+12.Community.zip): Wi-Fi disconnected during the initial setup / once more ~5 minutes later
Paranoid Android (pa-quartz-2-oneplus7pro-20200425-release.zip): Wi-Fi disconnected during the initial setup / once more ~10 minutes later
Omni Treskmod (omni-10-20200414-oneplus7pro-treskmod.zip) : Wi-Fi disconnected about 10 minutes after the initial setup was complete
MoKee: I flashed a nightly build (MK100.0-guacamole-202005020704-NIGHTLY.zip) and got stuck into a boot loop for some reasons. I'm not going to flash latest stable release (MK90.0-guacamole-200425-RELEASE.zip) since it's based on Pie anyway (never had Wi-Fi issues on Pie ROMs).
Sounds like anything but OxygenOS won't work for me.
Edit: My flash steps just in case (using OnePlus7ProOxygen_21.E.25_OTA_025_all_2003270113_4588ebe57af551.zip as base, also tried Open Beta 11 a few weeks ago to no avail)
Boot to TWRP
Format Data
Reboot to TWRP
Flash OOS, ROM, TWRP
Reboot TWRP
Flash OOS, ROM, TWRP
Reboot TWRP
Flash GApps (pico package, also tried nano package in the past) except for Paranoid Android and Omni Treskmod because they have built-in GApps, - Magisk
Reboot System
All ROMs md5 checksums were correct.

Toutatis_ said:
I flashed a couple of other ROMs today.
CarbonROM (CARBON-CR-8.0-PAX-WEEKLY-guacamole-20200424-1620.zip): Wi-Fi disconnected during the initial setup / once more ~5 minutes later / once more ~10 minutes later @cd993
Potato Open Sauce Project (potato_guacamole-10-20200413-croquette.v3.1.7+12.Community.zip): Wi-Fi disconnected during the initial setup / once more ~5 minutes later
Paranoid Android (pa-quartz-2-oneplus7pro-20200425-release.zip): Wi-Fi disconnected during the initial setup / once more ~10 minutes later
Omni Treskmod (omni-10-20200414-oneplus7pro-treskmod.zip) : Wi-Fi disconnected about 10 minutes after the initial setup was complete
MoKee: I flashed a nightly build (MK100.0-guacamole-202005020704-NIGHTLY.zip) and got stuck into a boot loop for some reasons. I'm not going to flash latest stable release (MK90.0-guacamole-200425-RELEASE.zip) since it's based on Pie anyway (never had Wi-Fi issues on Pie ROMs).
Sounds like anything but OxygenOS won't work for me.
Edit: My flash steps just in case (using OnePlus7ProOxygen_21.E.25_OTA_025_all_2003270113_4588ebe57af551.zip as base, also tried Open Beta 11 a few weeks ago to no avail)
Boot to TWRP
Format Data
Reboot to TWRP
Flash OOS, ROM, TWRP
Reboot TWRP
Flash OOS, ROM, TWRP
Reboot TWRP
Flash GApps (pico package, also tried nano package in the past) except for Paranoid Android and Omni Treskmod because they have built-in GApps, - Magisk
Reboot System
All ROMs md5 checksums were correct.
Click to expand...
Click to collapse
Thanks for the post. Really hope someone with the technical knowledge can look at the logs and get to the bottom of this!

Did y'all try unselecting mobile data always on in dev options. Also maybe try MSM tool to Android 10. On the Pixel 3 / 3XL some had issues with sensors not working properly having to revert to pie to fix issue sorta sounds like what could be happening to some here. Or might need to pull build.props from stock and a custom ROM. From system and vendor to eye ball the differences might find some extra data or wifi props from stock that ain't there on custom roms. Also try flashing the persist.img after flashing the ROM helped some on the pixels
---------- Post added at 03:28 AM ---------- Previous post was at 02:57 AM ----------
cd993 said:
Hey all,
I'm bringing the discussion from across a few custom rom threads (Havoc etc.) in to one place to hopefully work towards finding a solution. The issue being on custom roms, some users (myself included) experience Wifi disconnecting/reconnecting when the signal is low - when in the same environment, this does not occur on stock OOS. For example, when I'm in my bedroom, on Havoc for example the signal shows itself to be low but will periodically disconnect/reconnect, despite still actually having a connection, albeit weak. As mentioned, this does not occur on stock.
What I've tried/things to consider:
- It was mentioned that someone who flashed he global rom (I'm on EU) didn't experience this issue. However after a full clean flash I unfortunately encountered the same issue. In hindsight, I didn't boot the rom in to OOS before flashing Havoc, would that make a difference? I wouldn't have thought so though.
- The Magisk module Wifi Bonding, which was thought to perhaps help, didn't make a difference
- The dev (@SKULLSHADY) informed me that Havoc has the Wifi config from OOS, so that unfortunately can't be a solution
- Toggling Wifi scan throttling in developer settings made no difference. Though on this point, it's almost like the custom rom - annoyingly only for some users - is detecting a weak connection and switching to mobile data, despite still having a connection. Like it's got a threshold of what signal strength should be, realises it hasn't, cuts it off but then reconnects.
I've attached a log of when the issue occurs. I'm no expert and don't have a clue what to look for (perhaps someone else does?) but one thing I noticed was this bit upon the disconnection:
04-02 17:43:06.429 I/BugleRcsEngine(6806): [383] uzw.d: Connected state: [1], networkType: [WIFI] 04-02 17:43:06.954 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:08.958 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:10.968 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:13.362 I/WifiHAL (1046): event received NL80211_CMD_VENDOR, vendor_id = 0x1374, subcmd = 0xd 04-02 17:43:13.990 D/ConnectivityService(1667): Lingering NetworkAgentInfo [WIFI () - 150] for 30000ms 04-02 17:43:13.993 D/ConnectivityService(1667): Sending DISCONNECTED broadcast for type 1 NetworkAgentInfo [WIFI () - 150] isDefaultNetwork=true 04-02 17:43:18.604 D/QCNEJ/WlanStaInfoRelay(2492): Received action: android.net.wifi.RSSI_CHANGED
So with my absolute amateur analytical observation here, I note the below as perhaps relevant to the disconnection:
"android.net.wifi.RSSI_CHANGED"
After Googling this, I came across the following Reddit page:
https://amp.reddit.com/r/tasker/comments/ccezew/intent_received_context_no_longer_working/
They talk of "signal strength verification" - which perhaps is what's going on here as in when further away from the router, something is going and resulting on WiFi disconnecting/reconnecting just because the signal is low, despite still having signal. However, this may or may not be of relevance - I don't have a clue! Lol
There's also this:
D/ConnectivityService(1667): Switching to new default network
Though unsure why its disconnecting in the first place...
So in my humble summary, its like something at some level is monitoring signal strength and disconnecting/reconnecting as the result. But I could be completely wrong. I recall it mainly doing so when further from the router but I'm sure it had a couple times too when very close to it.
I just really wanna solve this issue and seemingly if we can, it could possibly fix it for all custom roms that face this WiFi issue.
Any help would be greatly appreciated!
UPDATE: This issue seemingly is NOT present on the new CarbonROM!!! So whatever the difference is in terms of settings or source code, this rom does no suffer with the Wifi drop out issue!!
Click to expand...
Click to collapse
4-02 17:43:03.345 W/BroadcastQueue(1667): Permission Denial: receiving Intent { act=android.net.wifi.RSSI_CHANGED flg=0x4000010 (has extras) } to ProcessRecord{3ae4f94 3939:com.teslacoilsw.notifier/u0a233} (pid=3939, uid=10233) requires android.permission.ACCESS_WIFI_STATE due to sender android (uid 1000)
Looks like its your carrier teslacoil having issues with bugle RCS system. Bugle is Google Messages
---------- Post added at 03:36 AM ---------- Previous post was at 03:28 AM ----------
https://www.xda-developers.com/enable-preferred-wifi-calling-option-verizon-pixel-pixel-xl/
Kno its Verizon but could be same issue happening
https://forum.xda-developers.com/pixel-3-xl/help/strange-issue-using-wifi-pixel-3-apps-t3857059
Another wifi issue on the Pixels

Thanks for the input.
There's some useful suggestions here, though I'm now back on stock for the time being. Has anyone else tried clean flashing with MSM tool?
Also that telsacoilsw relates to Nova Launcher somehow.

billyt1 said:
Did y'all try unselecting mobile data always on in dev options. Also maybe try MSM tool to Android 10. On the Pixel 3 / 3XL some had issues with sensors not working properly having to revert to pie to fix issue sorta sounds like what could be happening to some here. Or might need to pull build.props from stock and a custom ROM. From system and vendor to eye ball the differences might find some extra data or wifi props from stock that ain't there on custom roms. Also try flashing the persist.img after flashing the ROM helped some on the pixels
---------- Post added at 03:28 AM ---------- Previous post was at 02:57 AM ----------
4-02 17:43:03.345 W/BroadcastQueue(1667): Permission Denial: receiving Intent { act=android.net.wifi.RSSI_CHANGED flg=0x4000010 (has extras) } to ProcessRecord{3ae4f94 3939:com.teslacoilsw.notifier/u0a233} (pid=3939, uid=10233) requires android.permission.ACCESS_WIFI_STATE due to sender android (uid 1000)
Looks like its your carrier teslacoil having issues with bugle RCS system. Bugle is Google Messages
---------- Post added at 03:36 AM ---------- Previous post was at 03:28 AM ----------
https://www.xda-developers.com/enable-preferred-wifi-calling-option-verizon-pixel-pixel-xl/
Kno its Verizon but could be same issue happening
https://forum.xda-developers.com/pixel-3-xl/help/strange-issue-using-wifi-pixel-3-apps-t3857059
Another wifi issue on the Pixels
Click to expand...
Click to collapse
Sorry see above, was meant to quote you!

billyt1 said:
Did y'all try unselecting mobile data always on in dev options.
Click to expand...
Click to collapse
I've just disabled it in Developer options, rebooted and Wi-Fi dropped about two minutes later (I'm back on MSM Xtended now by the way).
billyt1 said:
Also maybe try MSM tool to Android 10. On the Pixel 3 / 3XL some had issues with sensors not working properly having to revert to pie to fix issue sorta sounds like what could be happening to some here. Or might need to pull build.props from stock and a custom ROM. From system and vendor to eye ball the differences might find some extra data or wifi props from stock that ain't there on custom roms. Also try flashing the persist.img after flashing the ROM helped some on the pixels
Click to expand...
Click to collapse
Attached build.prop from MSM Xtended (April 14th build). The issue occurs on HavocOS which uses stock OxygenOS Wi-Fi config though... could anyone post OxygenOS build.prop file so that we can compare?
I haven't tried using MSM tool yet. Thanks for the suggestion, I will in the next few days.
I read about persist.img file, it helped some people with sensors issues. I've just tried to extract it from OnePlus stock zip payload.bin using this tool.
While the extraction works fine, it doesn't pull any persist.img file (same issue than this post):
Code:
$ python extract_android_ota_payload.py OnePlus7ProOxygen_21.E.25_OTA_025_all_2003270113_4588ebe57af551.zip /tmp/
Extracting 'payload.bin' from OTA file...
Extracting 'LOGO.img'
Extracting 'abl.img'
Extracting 'boot.img'
Extracting 'dtbo.img'
Extracting 'odm.img'
Extracting 'system.img'
Extracting 'vbmeta.img'
Extracting 'vendor.img'
Extracting 'aop.img'
Extracting 'bluetooth.img'
Extracting 'cmnlib64.img'
Extracting 'cmnlib.img'
Extracting 'devcfg.img'
Extracting 'dsp.img'
Extracting 'hyp.img'
Extracting 'keymaster.img'
Extracting 'modem.img'
Extracting 'qupfw.img'
Extracting 'storsec.img'
Extracting 'tz.img'
Extracting 'xbl_config.img'
Extracting 'xbl.img'
Extracting 'oem_stanvbk.img'
Extracting 'reserve.img'
Anyone knows any other method to get it so I can flash it?
billyt1 said:
4-02 17:43:03.345 W/BroadcastQueue(1667): Permission Denial: receiving Intent { act=android.net.wifi.RSSI_CHANGED flg=0x4000010 (has extras) } to ProcessRecord{3ae4f94 3939:com.teslacoilsw.notifier/u0a233} (pid=3939, uid=10233) requires android.permission.ACCESS_WIFI_STATE due to sender android (uid 1000)
Looks like its your carrier teslacoil having issues with bugle RCS system. Bugle is Google Messages
Click to expand...
Click to collapse
As @cd993 said, com.teslacoinsw.notifier refers to TeslaUnread for Nova Launcher. Unrelated since Wi-Fi drops on all the ROMs I mentioned, even during the initial setup for most of them (except Omni Treskmod during my tests). None of them comes with Nova Launcher or TeslaUnread.

Related

l2_hsic fix P4 (GT-P7500, GT-P7501) running CM10.1

===============================================================
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

[ROM][5.{0,1}][AOSP][{Un,}Official] CM12.{0,1} (Lollipop)

CM12.{0,1} (Lollipop) official/unofficial builds for the Droid 4
CyanogenMod is a free, community built, aftermarket firmware distribution of Android 5.0/5.1 (Lollipop), which is designed to increase performance and reliability over stock Android for your device.
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at any of us for messing up your device, we will laugh at you.
* Collectively, and at the same time.
*/
CyanogenMod is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. Linked below is a package that has come from another Android project that restore the Google parts. CyanogenMod does still include various hardware-specific code, which is also slowly being open-sourced anyway.
All the source code for CyanogenMod is available in the CyanogenMod Github repo. And if you would like to contribute to CyanogenMod, please visit our Gerrit Code Review.
These are WIP builds of porting CM12.{0,1} to the Droid 4 (and also other devices using the same device/motorola/omap4-common-infrastructure). They probably won't work, so don't expect too much. Use on your own risk!
Builds:
Last official build:
http://droid.cs.fau.de/cm-12.1/official/
Old manual builds:
http://droid.cs.fau.de/cm-12.0/pre-alpha-test/new_safestrap/
Changes (only device/family specific, CM base is always synced before build and contains more changes):
2015-04-16:
Switched CM build-target, new nightlies will now be 12.1: http://review.cyanogenmod.org/#/c/94693/
2015-02-01:
No more unofficial builds! See: http://review.cyanogenmod.org/#/c/87596/
2015-01-28:
Mobile data fixes
Remaining com.android.phone crashes on VZW finally fixed (thanks @joojoobee666)
2015-01-24:
Fixed sw-keyboard popup when hw-keyboard is used (thanks @joojoobee666)
Fixed reboot to recovery
Fixed sepolicy for whisperd (dock service)
2015-01-22:
Fixed su-permissions
Crashes on Verizon most likely fixed, please report back
2015-01-20:
Fixed flashlight
2015-01-18:
SELinux updates.
This requires manual action for applications to continue being able to access their own files when upgrading from 2014-01-14 or 2014-01-15 (older versions are fine)!
Due to SELinux-bugs in 2014-01-1{4,5}, you have to relabel your data-partition on the first boot when upgrading from 2014-01-14/-15. This only needs to be done once. To do this, enable adb/usb debugging and grant root to adb (both in developer settings) and execute via an adb shell:
Code:
su -c 'for i in /data/*; do echo "${i}"; restorecon -DFrv "${i}"; done; sync; reboot'
2015-01-1{4,5}:
More fixes for {,umts_}spyder
sepolicy updates
GSM fixes
notable CM changes: su integration fixed
2015-01-11:
Updated SELinux policies (mostly for spyder/umts_spyder)
Added kernel stability fixes
Video decoding fixes
2015-01-09:
Enabled SELinux enforcing
Add SELinux-policies for motorola services
Enable ro.telephony.get_imsi_from_sim on VZW devices (thanks @joojoobee666)
2015-01-02:
Sync CM changes
2014-12-23:
Fixed stock camera
2014-12-22:
Sync CM changes
Fix build due to P2P changes (fix pushed into CM)
Enabled security for adb (keys/not root by default)
2014-11-30:
Added APN fixes for CDMA/LTE
Enabled multiuser mode (might not work yet)
Last update for a couple of weeks
2014-11-27:
Fixed graphics glitches
2014-11-26:
Fixed HW video-decoding
Enabled doze mode (no pickup sensor in the devices!)
CM resync as always
2014-11-23:
Probably fixed mobile data on LTE
Fixed WiFi-tethering
2014-11-22:
Requires a recovery supporting SELinux
What's working:
Phone (tested on Verizon and on GSM/UMTS in Europe)
Mobile data (at least on GSM/UMTS in Europe)
WiFi
WiFi-tethering
GPS
Camera
Playback of DRM-protected content (using Widevine from OnePlusOne)
What's not working:
Probably most everything else, including, but not limited to:
Some connectivity issues (should be solved now)
Data encryption
Gapps (CM-12.0):
Dhacker29 provides gapps for Lollipop:
http://d-h.st/YQG
http://d-h.st/jzr
http://droid.cs.fau.de/cm-12.0/gapps/ (Mirror)
Gapps (CM-12.1):
https://github.com/cgapps/vendor_google/releases/
Installation:
You need a new recovery supporting SELinux
An updated Safestrap (3.75) which supports SELinux can be found here: https://github.com/stargo/android_packages_apps_Safestrap/releases/tag/v3.75
Please read the instructions on how to install this version and follow the order of the steps in it.
GSM users:
To use this CM12.{0,1}-ROM on GSM-networks you should install Mentor.37's GSM patch
Source / Repositories:
maserati device-support: https://github.com/CyanogenMod/android_device_motorola_maserati
omap4-common device-support: https://github.com/CyanogenMod/android_device_motorola_omap4-common
omap4-common kernel: https://github.com/CyanogenMod/android_kernel_motorola_omap4-common
local manifest to build cm-12 for the Droid 4: http://droid.cs.fau.de/cm-12.0/pre-alpha-test/new_safestrap/local_manifest.xml
XDA:DevDB Information
CM 12.{0,1} on Motorola Droid4, ROM for the Motorola Droid 4
Contributors
stargo, Hashcode, Dhacker29
Source Code: https://github.com/CyanogenMod
ROM OS Version: 5.1.x Lollipop
ROM Kernel: Linux 3.0.x
Based On: CyanogenMod
Version Information
Status: No Longer Updated
Created 2014-11-23
Last Updated 2016-02-16
thank you @stargo, I am so pleased to see this thread, I was wondering when this thread is going to appear. Looks like I will continue to cling onto my droid 4 for a while, no virtual keyboard can beat a droid 4 keyboard.
Is data encryption enabled by default like on the nexus 6? I read that it greatly reduces the performance of the device. I meant this: http://www.xda-developers.com/android/disable-data-encryption-nexus-6/
Once again, thank you so much for your efforts in keeping this device alive.
sharptv said:
thank you @stargo, I am so pleased to see this thread, I was wondering when this thread is going to appear. Looks like I will continue to cling onto my droid 4 for a while, no virtual keyboard can beat a droid 4 keyboard.
Click to expand...
Click to collapse
Is data encryption enabled by default like on the nexus 6? I read that it greatly reduces the performance of the device. I meant this: http://www.xda-developers.com/android/disable-data-encryption-nexus-6/
Click to expand...
Click to collapse
No, data encryption is not enabled by default (and still doesn't even work for us).
Cheers,
Michael
Flipping sweet thanks y'all rock i love xda
Cast Screen
Hey stargo. thanks a lot for this! :good:
The 'Cast Screen' under settings pull-down menu is not working. It does not find any of the chromecasts that I have nearby.
Not a big deal, and not a priority at all for me, but just wanted to let you know.
Thanks again!
G'day,
just wanted to confirm the procedure for updating SafeStrap, since some people have CM11 in their stock slot:
in the first step (when you say 'go back to stock'), are you saying simply to boot the stock slot, regardless of ROM (since once SS is unistalled the 'slots' don't exist)?
Or do you mean boot to stock ROM, in stock slot?
I'm guessing it's the former, but I'd like to be sure before taking the plunge =)
thanks for your work! I gave the 2011 version a run over the weekend, it worked pretty well all things considered =)
gabhroo123 said:
Hey stargo. thanks a lot for this! :good:
The 'Cast Screen' under settings pull-down menu is not working. It does not find any of the chromecasts that I have nearby.
Not a big deal, and not a priority at all for me, but just wanted to let you know.
Thanks again!
Click to expand...
Click to collapse
May not ever work, IIRC, chromecasting the screen requires hardware we just don't have. :[
Shobai said:
G'day,
just wanted to confirm the procedure for updating SafeStrap, since some people have CM11 in their stock slot:
in the first step (when you say 'go back to stock'), are you saying simply to boot the stock slot, regardless of ROM (since once SS is unistalled the 'slots' don't exist)?
Or do you mean boot to stock ROM, in stock slot?
I'm guessing it's the former, but I'd like to be sure before taking the plunge =)
thanks for your work! I gave the 2011 version a run over the weekend, it worked pretty well all things considered =)
Click to expand...
Click to collapse
assuming that cm11 is currently installed in your stock slot and you want to update to the new test safestrap by stargo:
uninstall the existing safestrap using the original safestrap, for instance, if the existing safestrap is 3.73, you should install safestrap 3.73 and uninstall the recovery.
DO NOT REBOOT YOUR PHONE IN THE PROCESS
after you have uninstalled the existing recovery, uninstall safestrap(3.73), and then install the new safestrap by stargo, and install the recovery.
your safestrap is now updated, and nothing will be wiped.
YOU MUST NOT REBOOT YOUR PHONE DURING THE PROCESS, you can only reboot after a recovery has been installed.
hope you find this useful
thelolotov said:
May not ever work, IIRC, chromecasting the screen requires hardware we just don't have. :[
Click to expand...
Click to collapse
It need some kernel changes... but it should work...original gnex have the same cpu/gpu and they make it work... @lucize was seeing that but i dont know what happend with that
---------- Post added at 07:38 AM ---------- Previous post was at 07:37 AM ----------
By the way....thanks michael for your great work!...please make a donation link to send you some beer money!
Cheers, sharptv, much obliged =)
gabhroo123 said:
The 'Cast Screen' under settings pull-down menu is not working. It does not find any of the chromecasts that I have nearby.
Not a big deal, and not a priority at all for me, but just wanted to let you know.
Click to expand...
Click to collapse
Yes, our GPU driver does not support WFD. And in contrast to the GNEX, Motorola added much stuff to our version, so it's not easy to sync it back with the upstream kernel. Last time I tried that, I ended up with a non-working display and couldn't figure out why...
Shobai said:
just wanted to confirm the procedure for updating SafeStrap, since some people have CM11 in their stock slot:
in the first step (when you say 'go back to stock'), are you saying simply to boot the stock slot, regardless of ROM (since once SS is unistalled the 'slots' don't exist)?
Click to expand...
Click to collapse
Just boot to whatever you currently have installed in the stock slot. And I have to underline what @sharptv said, never reboot your phone in the process (it might work when you have the stock ROM in the stock slot, but it will surely break in every other case).
Cheers,
Michael
Will cm12 be pre-rooted in future? I can't seem to find anything solid on this, hopefully someone will be able to shed some light on this.
This App Camera work fine: https://play.google.com/store/apps/details?id=com.radcam.camera
---------- Post added at 11:34 AM ---------- Previous post was at 11:31 AM ----------
sharptv said:
Will cm12 be pre-rooted in future? I can't seem to find anything solid on this, hopefully someone will be able to shed some light on this.
Click to expand...
Click to collapse
See this thread: http://www.xda-developers.com/android/supersu-beta-lollipop-root-stock-kernel/
Download and install with recovery
I can confirm that at least on my phone that LTE is working. Great work .
flash these zips in recovery for root i got the from my nexus 7 root toolkit
HOPE IT WORKS FOR YOU :good::cyclops:
TheXG6HD said:
I can confirm that at least on my phone that LTE is working. Great work .
Click to expand...
Click to collapse
Yay! Thanks for confirming
It is a really bad hack, but if it works... http://review.cyanogenmod.org/78845
Cheers,
Michael
stargo said:
Yay! Thanks for confirming
It is a really bad hack, but if it works... http://review.cyanogenmod.org/78845
Cheers,
Michael
Click to expand...
Click to collapse
Data doesn't come up on its own, still needs some prodding (selecting the APN) and will go out randomly. Still not ready for prime time, sadly.... :<
It does come up a lot quicker, however.
thelolotov said:
Data doesn't come up on its own, still needs some prodding (selecting the APN) and will go out randomly. Still not ready for prime time, sadly.... :<
It does come up a lot quicker, however.
Click to expand...
Click to collapse
That's VZW weirdness
But if it comes up, then data is actually passing? Because that is what my patch was intended to fix. Before that the data-indicator would show up, but data would not actually get transmitted...
Can you probably send me the output of "ip route list" and "ip addr list" when LTE data is connected?
Would be interesting to see, what is actually happening now. I can only guess from here...
Regards,
Michael
stargo said:
That's VZW weirdness
But if it comes up, then data is actually passing? Because that is what my patch was intended to fix. Before that the data-indicator would show up, but data would not actually get transmitted...
Can you probably send me the output of "ip route list" and "ip addr list" when LTE data is connected?
Would be interesting to see, what is actually happening now. I can only guess from here...
Regards,
Michael
Click to expand...
Click to collapse
LTE was working on first build, just took 10+ mins to connect then worked good.
Sent from my XT907 using Tapatalk
stargo said:
That's VZW weirdness
But if it comes up, then data is actually passing? Because that is what my patch was intended to fix. Before that the data-indicator would show up, but data would not actually get transmitted...
Can you probably send me the output of "ip route list" and "ip addr list" when LTE data is connected?
Would be interesting to see, what is actually happening now. I can only guess from here...
Regards,
Michael
Click to expand...
Click to collapse
The deal is, the data works at first, then at random intervals it breaks and needs to be manually reset. I'm travelling right now so I can't really risk using CM12 right now, but I'll get you some logs when possible. JJB is having the same issue, I'll ask him to try and get you some details.

[Q&A] Omni

Make this pretty later
You just made my day
Sent from my Nexus 6
I just confused myself. Should i be flashing the bootloader, radio, etc from a nexus factory image and then flash omni? I have been using 20150605 build without doing this. Should i do this for the nightlies?
subterfugium said:
Code:
I:operation_start: 'Flashing'
Installing '/sdcard/Download/omni-5.1.1-20150623-shamu-NIGHTLY.zip'...
Checking for MD5 file...
MD5 matched
Verifying zip signature...
I:read key e=3 hash=20
I:1 key(s) loaded from /res/keys
I:comment is 1477 bytes; signature 1459 bytes from end
I:failed to verify against RSA key 0
E:failed to verify whole-file signature
E:Zip signature verification failed: 1
Error flashing zip '/sdcard/Download/omni-5.1.1-20150623-shamu-NIGHTLY.zip'
I guess zip verification fails because of test-keys or what does that zip verification stand for?
Click to expand...
Click to collapse
Honestly, I've never used zip verification for all the years I've been flashing ROMs and have never had any issues.
I'm probably wrong but.. My theory is that packed somewhere inside the zip you are trying to flash lies a key, which is compared next a second key once extracted. If they don't match it throws an error and aborts the operation.
Sent from my Nexus 6 using XDA Free mobile app
I've never used zip verification for this exact reason, and therefore have never looked into it. This sounds like something for the TWRP thread that @Dees_Troy could answer maybe.
Does anyone have a rundown of what this Rom has to offer beyond stock aosp? The Rom OP is a bit bare of info. Thanks
The Rom OP is a bit bare of info. Thanks
530farm said:
Does anyone have a rundown of what this Rom has to offer beyond stock aosp? The Rom OP is a bit bare of info. Thanks
Click to expand...
Click to collapse
Off the top of my head... battery icon customization, volume match orientation, volume wake, screenshot delete, advanced reboot menu, hide usb debugging icon, ambient display customization. Also, Omni is the only AOSP ROM where I don't get force closes when taking multiple HDR+ pictures in a row without pause.
Completely stable device functionality with whatever you see on gerrit :good:
I will make a "features list" tomorrow
I saw that the past few builds uploaded were all 0mb. Just wondering what's going on until the builds resume?
Gandalf said:
Completely stable device functionality with whatever you see on gerrit :good:
I will make a "features list" tomorrow
Click to expand...
Click to collapse
Not sure if feature requests are allowed or not, if not then just ignore this..
But I was wondering if the 5 second home button delay on app launchers (such as Swipepad) is something that may be removed? That'd make navigating the phone much quicker for those of us who do use app launchers.
I saw opendelta mentioned in the main thread but I haven't seen any indication it exists within the ROM. Am I just missing it?
Ngo93 said:
Not sure if feature requests are allowed or not, if not then just ignore this..
But I was wondering if the 5 second home button delay on app launchers (such as Swipepad) is something that may be removed? That'd make navigating the phone much quicker for those of us who do use app launchers.
Click to expand...
Click to collapse
jira.omnirom.org :good:
glockliberty said:
I saw opendelta mentioned in the main thread but I haven't seen any indication it exists within the ROM. Am I just missing it?
Click to expand...
Click to collapse
Updates to opendelta have not been merged yet
I am certainly interested in giving OmniRom a try. A couple of questions...
First, I'm attempting to download the Omni 5.1.1 20150725 Nightly (newest as of this writing) and the download is going exceptionally slow (20-30KB/s) on the official dl.omnirom.org mirror. Is there an issue with the server at current or an up to date mirror?
Next, is there an overall feature list for Omni (on Nexus 6)? Many ROMs place a list of their main features as well as any other ROMs/kernels they incorporate (ie based on CyanogenMod 12.1, with latest CM12.1 commits added on every update etc..)).
Thank you!
RanceJustice said:
I am certainly interested in giving OmniRom a try. A couple of questions...
First, I'm attempting to download the Omni 5.1.1 20150725 Nightly (newest as of this writing) and the download is going exceptionally slow (20-30KB/s) on the official dl.omnirom.org mirror. Is there an issue with the server at current or an up to date mirror?
Next, is there an overall feature list for Omni (on Nexus 6)? Many ROMs place a list of their main features as well as any other ROMs/kernels they incorporate (ie based on CyanogenMod 12.1, with latest CM12.1 commits added on every update etc..)).
Thank you!
Click to expand...
Click to collapse
The server is probably being slow. They just upgraded storage/cleaned it up a few days ago and it has been significantly faster, it might be your connection to the server or something else.
As far as a list of features, there isn't one to my knowledge but you can certainly check on gerrit to see what's been merged recently. Just flash it and see for yourself: highfive:
Does this rom have layers?
Omnirom 5.1.1 nightly sudden reboot+supersu freeze+bluetooth headset bugs
I installed Omnirom 3days ago and have to say; nice stuff. runs fluid, batterie's fine and overall i like user experience. BUT
I'm experiencing some bugs.
first of all sometimes there just are random sudden reboots. On stock rom this happened from time to time when battery was below 30% or something so i thought there has to be a powersaving feature or something in kernel that don't works correct.
Then i flashed TWRP+Omnirom and those sudden reboots started happening randomly; regardless of battery.
I googled and found that could be some setting that adapt display brightness(???) and/or some apps bugging/conflicting. and, from previous experience, i know that this could also be a hardware/battery failure(please not; can't send my phone back right now as i need it daily for work and my N5 has a broken touch )
i tried disabling that display feature and also installed and tested if 'Lux' has any impact on that as it, basically, does the same but no change.
i factory reseted my device multiple times and tried to find out what APP could force this but... right now there's only the bare minimum(contacts+ / messages+ / aquamail / maildroid / todoist /calengoo /business calender pro and google stock apps)and still same problem. sometimes even while calling what's very embarassing when having an important customer on phone ...
I gonna try Zen Kernel next just to see if different kernel with different cpu scheduler COULD make any difference.
Then the second bug is my bluetooth headset(Plantronics M165). Can't get it to pair. Before Omnirom this worked very well as it should. Now, most of time he finds nothing and sometimes he finds a mac address of the headset but not the name. Other bluetooth devices are working fine and the headset's still working perfectly well on my gf's HTC M8. Anyone any ideas?
Last bug i experienced is SuperSU. Always an app needs root i can't get SuperSU intercept my choice. I click on allow or deny but nothing happens and after 10seconds superSu autodenies(or allows; depends on settings )right after factory reset supersu just works fine but suddenly stops working. root's still there as i can perfectly tell supersu what to do in its settings. Only the on demand root question can't be answered. uninstalling/reinstalling supersu didn't change anything. It doesn't matter if i install supersu by playstore or by zip through recovery. also unrooting and rerooting doesn't help. only a factory reset helps; for a while.
I don't want to change my Superuser managment as i paid for the pro version ...
Hope to find some help here as it's one of my fav places for everything smartphone related since back in my tytn days
so much knowledge in here.
keep up the good work
update:
sudden Reboot Problem solved, Same for superSu Problem.
just the Bluetooth problem's still there. flashing back to Stock resolves the issue but... stock and I really start liking omnirom...
anyone any ideas ?
Sent from my Nexus 6 using XDA Free mobile app
nightfly.0684 said:
update:
sudden Reboot Problem solved, Same for superSu Problem.
just the Bluetooth problem's still there. flashing back to Stock resolves the issue but... stock and I really start liking omnirom...
anyone any ideas ?
Sent from my Nexus 6 using XDA Free mobile app
Click to expand...
Click to collapse
M builds will be ready soon enough :good:
great news
Do we get the Update for M through opendelta or is a factory reset + reflash needed?
and if i understand right you assume that the Bluetooth Problem should be gone with M?
would be nice as, right now, I sometimes have to pick up important calls while driving ... and... i don't like that at all....
would try the homemade M build IF i wouldn't need it daily for work. about time to repair my n5 i guess
Sent from my Nexus 6 using XDA Free mobile app

[XZ][F8331/2] AOSP Pie builds [Stable] [Updates]

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

[SOLVED] Porting Linage 17.1 - Modem problems

Hi,
I developed some apps and ported TWRP to some other devices already, therefore I have the feeling that this question is maybe a little bit silly
My current progress
I used the Lineage 17.1 source and the local manifests of MartinX3. Then I fixed the untracked_devices.xml, patched the TRINKET compile errors and finally patched the dialer crash in frameworks/opt/telephony/src/java/com/android/internal/telephony/uicc/UiccController.java:835 by merging the sanity check of the current AOSP upstream. Now the system is stable (as far I am concerned) and (hopefully) everything works - except the SIM card!
The problem
The logs indicate the driver successfully loads, modem starts and the TDC service registers a SIM. But then the RIL reports that no phone has been found an can therefore not use the sim card. For the full log: See attachment! Also Android registers my inserting / removal of the sim card, so... ?!
My question
I guess I have to modify one of the configs (xml) - but which one (as the local manifest I used are only lineagified automatically by GitHub actions and are currently untested with this device)? Where is a reference for the format? How can I diagnose that further? Do you know this problem or have similar experience - how did you solve it?
Greetings,
Simonmicro
Glad someone working on this! I'm looking for an alternative ROM, privacy oriented. I'd test it if it could dial, use SIM card.
Probably flashing Sony vendor image might help? They are based on Android 10 as well as LOS 17.1. https://developer.sony.com/file/download/software-binaries-for-aosp-android-11-0-kernel-4-14-seine/
Well, it works now - I just messed up to select the right configuration (and therefore triggered a ton of bugs inside the slightly dated AOSP source used by Lineage). I hope I can present my first builds in the next days. At least for me it seems stable and only the cams are stubbornly working (as also in AOSP). I'm currently working on OTA support, signing the build inside my CI (which I also plan to open source with the release) and then I must find time to write a guide (and cleanup my scripts) how to flash, as there is no TWRP right now...
EDIT: Btw I failed to use the DSDS build for the dual-sim variant (which I have), which caused the RIL to glitch out, trigger out_out_bounds exceptions inside the UiccController and so on... It was a mess.
Simonmicro said:
Well, it works now - I just messed up to select the right configuration (and therefore triggered a ton of bugs inside the slightly dated AOSP source used by Lineage). I hope I can present my first builds in the next days. At least for me it seems stable and only the cams are stubbornly working (as also in AOSP). I'm currently working on OTA support, signing the build inside my CI (which I also plan to open source with the release) and then I must find time to write a guide (and cleanup my scripts) how to flash, as there is no TWRP right now...
EDIT: Btw I failed to use the DSDS build for the dual-sim variant (which I have), which caused the RIL to glitch out, trigger out_out_bounds exceptions inside the UiccController and so on... It was a mess.
Click to expand...
Click to collapse
Well, there is a unofficial version right now https://forum.xda-developers.com/sony-xperia-10-ii/development/unofficial-twrp-xperia-10-ii-t4190089
Meloferz said:
Well, there is a unofficial version right now https://forum.xda-developers.com/sony-xperia-10-ii/development/unofficial-twrp-xperia-10-ii-t4190089
Click to expand...
Click to collapse
Hey - to be fair: It is brand new! But thanks for pointing that out. I'll may have to rethink my guide now.

Categories

Resources