[ROM][GT-I9506][ks01ltexx] LineageOS 16.0 UNOFFICIAL for the Galaxy S4 LTE-A
- Thread starter kyasu
- Start date
Hi! I clean flashed latest Los 16.0 unoffical build but i facing battery drain overnight while screen off. I tried Naptime, Greenfy and tried without gapps but drain still there.
EDIT airplane on overnight
Note: brand new battery
EDIT airplane on overnight
Note: brand new battery
Attachments
An I reading the image correctly, as 10% over 24 hours? that is 0.4% per hour, which is not all that bad. top get better, try the following thread.
https://forum.xda-developers.com/showthread.php?t=1179809
Thanks
I would like to thank the developer, the new Android (Lineage 16) runs on my SGS4 great, thank you.
I would like to thank the developer, the new Android (Lineage 16) runs on my SGS4 great, thank you.
I notice that under Settings/Storage, there is no longer a way to clear the cache, except app by app. I noticed the same on 15.1. On 14.1, it was possible to flush the cache Setting/Storage and I did that whenever storage was running low. In 16, I can't tell but I have all the same apps and am not short of storage. So, in this version, is cache management happening behind the scenes, or do we have to go into recovery mode and clear it that way as needed?
Last edited:
@kyasu:
How do you handle ADDITIONAL_DEFAULT_PROPERTIES in 'BoardConfig.mk' for TWRP? The build system rejects setting these vars on that position ("ADDITIONAL_DEFAULT_PROPERTIES must not be set before here"). Actually, this would be a convenient way to compile TWRP on userdebug (and thus saves switching to -eng every time). But all my attempts to get ro.secure=0 and ro.adb.secure=0 on userdebug failed so far.
Are your settings just abandoned leftovers or do you have a special trick or something to make this work?
I currently have to switch to -eng beforehand to compile TWRP.
How do you handle ADDITIONAL_DEFAULT_PROPERTIES in 'BoardConfig.mk' for TWRP? The build system rejects setting these vars on that position ("ADDITIONAL_DEFAULT_PROPERTIES must not be set before here"). Actually, this would be a convenient way to compile TWRP on userdebug (and thus saves switching to -eng every time). But all my attempts to get ro.secure=0 and ro.adb.secure=0 on userdebug failed so far.
Are your settings just abandoned leftovers or do you have a special trick or something to make this work?
I currently have to switch to -eng beforehand to compile TWRP.
If you are using the latest version you don't need to do anything. The fixes have been added to the source.
I have the latest but there is still a problem with GPS
GPS is poor with this device. But to get a faster fix some people have reported that it helped to calibrate the compass, e.g. with Google maps.
I compile TWRP by using cm-14.1 tree with android_bootable_recovery (android-9.0) which are the most stable combination.@kyasu:
How do you handle ADDITIONAL_DEFAULT_PROPERTIES in 'BoardConfig.mk' for TWRP? The build system rejects setting these vars on that position ("ADDITIONAL_DEFAULT_PROPERTIES must not be set before here"). Actually, this would be a convenient way to compile TWRP on userdebug (and thus saves switching to -eng every time). But all my attempts to get ro.secure=0 and ro.adb.secure=0 on userdebug failed so far.
Are your settings just abandoned leftovers or do you have a special trick or something to make this work?
I currently have to switch to -eng beforehand to compile TWRP.
I did it and I can't do it. I am not going to pay via NFC. in 14.1 goes without a problem.
lineage-16.0-20191116-UNOFFICIAL-ks01ltexx.zip
New build is available (See the first post).
Sync with the latest LineageOS source (November 2019 Security Patch).
Changes:
https://github.com/kyasu/android_device_samsung_ks01ltexx/commits/lineage-16.0
https://github.com/kyasu/android_kernel_samsung_msm8974/commits/lineage-16.0
New build is available (See the first post).
Sync with the latest LineageOS source (November 2019 Security Patch).
Changes:
https://github.com/kyasu/android_device_samsung_ks01ltexx/commits/lineage-16.0
https://github.com/kyasu/android_kernel_samsung_msm8974/commits/lineage-16.0
I really like this ROM. For one thing, I notice it leaves a lot more free storage than 14.1 did. Thank you Kyasu.
Everything is working well except the bluetooth icon is not displaying on the status bar when bluetooth is on. It is set to be displayed, but it is not showing. I did 5 fresh installs, including the latest build and nothing changed. Is there some way to force it, maybe by altering a config file in the root directory? Does anyone else have this problem?
Everything is working well except the bluetooth icon is not displaying on the status bar when bluetooth is on. It is set to be displayed, but it is not showing. I did 5 fresh installs, including the latest build and nothing changed. Is there some way to force it, maybe by altering a config file in the root directory? Does anyone else have this problem?
Last edited:
I have the same behaviour on both of my two S4s. Don't use bluetooth much and only noticed it because of your post.
I use bluetooth a lot. To cast to my LG soundbar, to listen on my headphones, transfer various pictures between my phone, tablet and PC. Just seems simple to me. In the last few days, I've been observing my status bar when I have bluetooth turned on. You can in the notification panel that it's on. What I discovered is that the BT icon does indeed show up but only there is data moving between devices. When you finish what you're doing and close the notification related to the activity, the icon vanishes. I really think the old way made much more sense. You turn it on, you see it on the status bar. That way, you are much less likely to accidentally leave it on and drain your S4 battery even faster. And that is definitely what can happen on this ROM. So you have to be vigilant and try not to forget it's on. I don't know if any other ROMs or OEMs have addressed this in their builds.
I guess its going into powersave mode when it vanishes. Probably just a cosmetic problem. Maybe check the logs.
A lot of people (including myself) have been reporting poor GPS. Not only with this ROM, but all others. I even tried flashing stock ROM and it to had poor GPS.
I recently received a PM regarding an old device I used to build ROMs for, and the user ( @ForestCat ) mentioned something I have never heard of before. He talked on a "GPS Week Number Rollover". When I searched on it, I came across the following WiKi entry.
https://en.wikipedia.org/wiki/GPS_Week_Number_Rollover
Although it does appear to be specific to Time (ie not positioning) I do wonder if it has any effect on our positioning issues?
Maybe @kyasu could clarify it better or confirm it does not affect positioning?
I recently received a PM regarding an old device I used to build ROMs for, and the user ( @ForestCat ) mentioned something I have never heard of before. He talked on a "GPS Week Number Rollover". When I searched on it, I came across the following WiKi entry.
https://en.wikipedia.org/wiki/GPS_Week_Number_Rollover
Although it does appear to be specific to Time (ie not positioning) I do wonder if it has any effect on our positioning issues?
Does anyone remember their GPS working on any ROM much better at the start of the year?
Maybe @kyasu could clarify it better or confirm it does not affect positioning?
Last edited:
I also have a bone-stock VZW S5, and it started having gps issues this year.
Here's the thinking:
Some gps receivers may, at the device's embedded firmware level and/or the OS driver/HAL layer be using the date/time info from any given satellite's NMEA sentence to determine whether or not the data is valid. One scenario might be an algorithm that compares the NMEA date to the chipset mfg date. If the NMEA date is older than the chipset (impossible) the algorithm throws out the satellite data as bad, i.e it won't use it to establish a location.
If you're one of the "lucky" one's with a screwed up gps, if you run the 'gps status & toolbox' app, you'll see a good strong signal from a LOT of birds, (I've seen 9 of 20, for example), yet no location fix.
My gut feeling is that it's the android driver. Here's why: I have two phones with the identical gps h/w: iZat Gen8a (Snapdragon S4)
The Moto RazrHD is all messed up, no rhyme or reason
The Moto-X works like a champ.
Actually I have (3) XT926's, different stock OS's, all borked
(2) Moto X's different stock OS's (one's my wife's), both perfect.
And my S5 is messed up.
For further reading(and weeping): https://www.verizonwireless.com/legal/notices/global-positioning-system/
Here's the thinking:
Some gps receivers may, at the device's embedded firmware level and/or the OS driver/HAL layer be using the date/time info from any given satellite's NMEA sentence to determine whether or not the data is valid. One scenario might be an algorithm that compares the NMEA date to the chipset mfg date. If the NMEA date is older than the chipset (impossible) the algorithm throws out the satellite data as bad, i.e it won't use it to establish a location.
If you're one of the "lucky" one's with a screwed up gps, if you run the 'gps status & toolbox' app, you'll see a good strong signal from a LOT of birds, (I've seen 9 of 20, for example), yet no location fix.
My gut feeling is that it's the android driver. Here's why: I have two phones with the identical gps h/w: iZat Gen8a (Snapdragon S4)
The Moto RazrHD is all messed up, no rhyme or reason
The Moto-X works like a champ.
Actually I have (3) XT926's, different stock OS's, all borked
(2) Moto X's different stock OS's (one's my wife's), both perfect.
And my S5 is messed up.
For further reading(and weeping): https://www.verizonwireless.com/legal/notices/global-positioning-system/
Another thing. Recently, when the screen is off, after a bit it screen started displaying the time in small text. It seems like it's an always on thing, but I can't find a setting to control that. How do I make it stay completely off?
Last edited:
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone