Related
UPDATE:
It seems that something not related to this driver relies on the old wakelock and it's now causing some partial wakelocks and causing some failed attemps to suspend:
Code:
PM: Device power.0 failed to suspend late: error -11
Restore the old module if you think your battery life is worse than before.
You can do that by flashing your favourite kernel, your current ROM or restoring the backuped module as explained here below.
I'll see if I can solve the problem.
_______________
I did some changes to decrease samsung-battery wakelock total time doing some optimizations, getting good results.
Ideally, the changes I made would save some battery, but I didn't properly verify this.
What I'm sure about is that samsung-battery wakelock total time is now very low, which means less time spent awake when the screen is off.
BetterBatteryStats screenshot after 3 and a half hours of use: 2 seconds of total time for samsung-battery. Not bad considering that the fixed duration of a single wakelock request was 3 seconds.
The driver had never been directly built into the kernel (EDIT: Adi_Pat did it in his kernel, read the notes below), we had always used a module, so you don't need to change kernel or ROM in order to use this, it shouldn't matter which ROM you are on as long as it's a CyanogenMod (9+) based ROM. You just need to flash the zip attached, which will replace the module in /system.
Flashing this on stock ROMs won't do anything.
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
A backup is automatically created after the flash, you can find it in:
Code:
/sdcard/backup-battery/m-d-y-H.M.S/samsung_battery.ko
To restore it, simply copy samsung-battery.ko in /system/lib/modules/ overwriting the existing one, set its permission to 644 and then reboot.
There's a backup copy for each flash you made, each copy is in a different subdirectory. The name of the subdirectory is the time and date of the flash.
Or more simply reflash the ROM or restore a CWM backup.
I've tested the changes for some time, but I can't guarantee everything is working correctly. Flash at your own risk.
Source code:
battery-monitor: minimize awake time
battery-monitor: make polling timer deferrable
battery-monitor: don't use boot_complete flag
battery-monitor: add wakelock...
Notes:
A reflash of this zip could be required after flashing custom kernels.
I had to add an additional wakelock (samsung-battery-charge), but it's only used when charging the battery. It behaves as the old samsung-battery wakelock.
I looked around and I can say that Adi_Pat's SIRI kernel is the only incompatible kernel. The driver is inbuilt and my module will be ignored. Flashing this zip won't do anything, you need to rebuild the kernel with the above changes.
loSconosciuto said:
A reflash of this zip could be required after flashing custom kernels.
Click to expand...
Click to collapse
Maybe i should try this but sir what do you mean by this? You mean a custom kernel for CM is required before flashing this? Cant we flash this with the stock lets say CM10 kernel?
marshygeek said:
Maybe i should try this but sir what do you mean by this? You mean a custom kernel for CM is required before flashing this? Cant we flash this with the stock lets say CM10 kernel?
Click to expand...
Click to collapse
What my zip does is to replace a kernel module located in /system.
Custom kernels usually include modules in their flashable zips, so if you first flash my zip and then a custom kernel, my modified samsung-battery.ko will be overwritten.
Custom kernels are not required for this. They could actually be incompatible with this module (to know whether it's working or not, read the OP), but in that case you can restore the original module as written above.
Ohhhh hahaha. I've read again today, i was confused a while ago. LOL. That was a dumb question of mine. Sorry. Ok ill try and feedback after few cycles.
---------- Post added at 09:22 PM ---------- Previous post was at 09:11 PM ----------
loSconosciuto, can you check what ive noticed before. I was on Alpha 3 and im using BetterBatteryStats. I just tried freezing the Calendar sync and Contacts sync. I dont know if its just my mind saying or it was really a lucky try and i got INSTANT noticeable battery performance for the whole cycle.
Flashed! So far so good....
Sent from my Samsung Galaxy SL on CyanogenMod 9 !
Flashing it now. Will report back with impressions in the morning. Will check night time battery drop. CM10A4, crackersizer! kernel.(1200-300, Smartassv2,NOOP)
EDIT: First impressions, night time battery drop was 30 % as compared to usual 50-60 % in my case. Also due to some network issues the testing was halted. Will report back when i get a couple of battery cycles done with this tweak.
EDIT: Testing halted as installed the SIRI kernel of adi!!!
Did anyone try this with Siri Kernel v2?
Does it work correctly?
Thanks!
BachuArg said:
Did anyone try this with Siri Kernel v2?
Does it work correctly?
Thanks!
Click to expand...
Click to collapse
Mate, the OP said it doesn't work on Siri Kernel. I doesn't know about Siri Kernel v.2 but I think it's not a bright idea.
Sent from Galaxy SL Powered by JellyBam
BachuArg said:
Did anyone try this with Siri Kernel v2?
Does it work correctly?
Thanks!
Click to expand...
Click to collapse
adi pas insert the module to siri kernel v2
loSconosciuto said:
I did some changes to decrease samsung-battery wakelock total time doing some optimizations, getting good results.
Ideally, the changes I made would save some battery, but I didn't properly verify this.
What I'm sure about is that samsung-battery wakelock total time is now very low, which means less time spent awake when the screen is off.
BetterBatteryStats screenshot after 3 and a half hours of use: 2 seconds of total time for samsung-battery. Not bad considering that the fixed duration of a single wakelock request was 3 seconds.
The driver had never been directly built into the kernel (EDIT: Adi_Pat did it in his kernel, read the notes below), we had always used a module, so you don't need to change kernel or ROM in order to use this, it shouldn't matter which ROM you are on as long as it's a CyanogenMod (9+) based ROM. You just need to flash the zip attached, which will replace the module in /system.
Flashing this on stock ROMs won't do anything.
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
A backup is automatically created after the flash, you can find it in:
Code:
/sdcard/backup-battery/m-d-y-H.M.S/samsung_battery.ko
To restore it, simply copy samsung-battery.ko in /system/lib/modules/ overwriting the existing one, set its permission to 644 and then reboot.
There's a backup copy for each flash you made, each copy is in a different subdirectory. The name of the subdirectory is the time and date of the flash.
Or more simply reflash the ROM or restore a CWM backup.
I've tested the changes for some time, but I can't guarantee everything is working correctly. Flash at your own risk.
Source code:
battery-monitor: minimize awake time
battery-monitor: make polling timer deferrable
battery-monitor: don't use boot_complete flag
battery-monitor: add wakelock...
Notes:
A reflash of this zip could be required after flashing custom kernels.
I had to add an additional wakelock (samsung-battery-charge), but it's only used when charging the battery. It behaves as the old samsung-battery wakelock.
I looked around and I can say that Adi_Pat's SIRI kernel is the only incompatible kernel. The driver is inbuilt and my module will be ignored. Flashing this zip won't do anything, you need to rebuild the kernel with the above changes.
Click to expand...
Click to collapse
I have one question. What is normal discharging time of battery,moderate use,stand by n normal use what so ever .As i saw in my case it wont lost more than 4 hour of continues use of net both wen i was on stock rom and after custom rom.
Sent from my GT-i9003 using xda premium
loSconosciuto said:
I did some changes to decrease samsung-battery wakelock total time doing some optimizations, getting good results.
Ideally, the changes I made would save some battery, but I didn't properly verify this.
What I'm sure about is that samsung-battery wakelock total time is now very low, which means less time spent awake when the screen is off.
BetterBatteryStats screenshot after 3 and a half hours of use: 2 seconds of total time for samsung-battery. Not bad considering that the fixed duration of a single wakelock request was 3 seconds.
...
Click to expand...
Click to collapse
Question: Are you referring to this line if you talk about the standard wakelock length of 3 seconds? Because I would think that this actually means that the wakelock length is 3*HZ with HZ=1/128 s (see config entry), resulting in 0.0234375 s. This, in turn, gives roughly 2.8125 s of battery monitor wakelock every hour if the system wakes up every 30 s. Am I wrong?
Anyway, your patch is very cool and should result in improved standby times
XDA_Bam said:
Question: Are you referring to this line if you talk about the standard wakelock length of 3 seconds?
Click to expand...
Click to collapse
Yes.
XDA_Bam said:
Because I would think that this actually means that the wakelock length is 3*HZ with HZ=1/128 s (see config entry), resulting in 0.0234375 s. This, in turn, gives roughly 2.8125 s of battery monitor wakelock every hour if the system wakes up every 30 s. Am I wrong?
Anyway, your patch is very cool and should result in improved standby times
Click to expand...
Click to collapse
That's what I thought too, but then, I can't remember why, I opened wakelock.c to verify this.
This is what conveinced me that the they are 3 seconds. See how timeout is converted when it's printed.
With timeout=3*HZ, the result of that operation should be 3.000.
Because I'm lazy, instead of reading the rest of the code I looked for commented piece of code on the internet and found few examples that confirmed my hypothesis. Here two examples I've just found: 1, 2.
I've also tried something. I plugged in the phone, waited for "samsung-battery-charge", unplugged it and got this in /proc/wakelocks
Code:
name [COLOR="Blue"][B]count[/B][/COLOR] expire_count wake_count active_since [B][COLOR="Red"]total_time[/COLOR][/B] sleep_time max_time last_change
"samsung-battery-charge" [COLOR="Blue"][B]1[/B][/COLOR] 1 0 0 [B][COLOR="Red"]2988677920[/COLOR][/B] 825195313 2988677920 957372533720
I assume those are nanoseconds: 2988677920 ns = 2.989 s.
I'm still not sure of this, because it doesn't make so much sense to me, I mean, what's the purpose of this?
By the way the battery is checked more often than I thought, sometimes I have even less than a second of interval between two checks. Not a big deal with this patch .
You can easly see how often the battery is checked with:
Code:
dmesg | grep "monitor BATT"
loSconosciuto said:
Yes.
That's what I thought too, but then, I can't remember why, I opened wakelock.c to verify this.
This is what conveinced me that the they are 3 seconds. See how timeout is converted when it's printed.
With timeout=3*HZ, the result of that operation should be 3.000.
Because I'm lazy, instead of reading the rest of the code I looked for commented piece of code on the internet and found few examples that confirmed my hypothesis. Here two examples I've just found: 1, 2.
I've also tried something. I plugged in the phone, waited for "samsung-battery-charge", unplugged it and got this in /proc/wakelocks
Code:
name [COLOR="Blue"][B]count[/B][/COLOR] expire_count wake_count active_since [B][COLOR="Red"]total_time[/COLOR][/B] sleep_time max_time last_change
"samsung-battery-charge" [COLOR="Blue"][B]1[/B][/COLOR] 1 0 0 [B][COLOR="Red"]2988677920[/COLOR][/B] 825195313 2988677920 957372533720
I assume those are nanoseconds: 2988677920 ns = 2.989 s.
I'm still not sure of this, because it doesn't make so much sense to me, I mean, what's the purpose of this?
By the way the battery is checked more often than I thought, sometimes I have even less than a second of interval between two checks. Not a big deal with this patch .
You can easly see how often the battery is checked with:
Code:
dmesg | grep "monitor BATT"
Click to expand...
Click to collapse
Ahhh, I think I got it, thanks! The kernel expects all time values in jiffies. Therefore, X*HZ gives you the value of X seconds converted to jiffies (and HZ actually is 128, not 1/128).
Re: Optimized Samsung battery driver [CM]
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
Excuse me what do u mean by battery percentage here i flashed zip now how will i know it is working? Thanks alot
Sent from my GT-i9003 using xda premium
Re: Optimized Samsung battery driver [CM]
Just set permission
Sent from my GT-I9003 using xda premium
I sadly discovered, not so much time ago, that this module is making "Android System" use more battery than normal. At first I thought it was a roughly made app, but I then found that the problem is this module.
From my kernel logs I can see that sometimes when the device tries to enter into deep sleep right after it woke up, it can't because there's something blocking the process (I don't know what yet) and it has to try again before it succeeds. This is causing increasing the number of alarms (Partial wakelocks in BBS) and the saved time is not as much as I hoped.
I don't think the problem is in this module, because the same thing happens when the module is not loaded. I'd say is something which normally would require a wakelock, but not in our case because of the omnipresent samsung-battery (correct me if I'm wrong). I did some changes here and there, but the resulting driver is not so different from the original one, so, for the moment, if you think your battery is worse than before (the mentioned problem was pretty random on my device) just restore the original module as explained in the first post.
I'll maybe look better into that when I'll have some time and in case I'll discover something, I'll let you know.
latief.makhdoomi said:
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
Excuse me what do u mean by battery percentage here i flashed zip now how will i know it is working? Thanks alot
Click to expand...
Click to collapse
Sorry for the late reply. To check if it's working, just look for samsung-battery-charge inside /proc/wakelocks. If it's there, it's working (plug and unplug your phone if you can't see it immediately).
With "can't see the battery percentage" I meant that you can't see how much battery is left: instead of the usual icon you have the battery icon with an exclamation point in it and you can't see the percentage from the settings.
hi losconoscuit i got a problem,when my phone screen is off or in standby mode am getting IM messages late i mean in watsapp or any IM messages are delivered to me late or at time wen i unlock my screen at least 10 mints late is it related to wake lock or anything else .please help.
Sent from my GT-i9003 using xda premium
latief.makhdoomi said:
hi losconoscuit i got a problem,when my phone screen is off or in standby mode am getting IM messages late i mean in watsapp or any IM messages are delivered to me late or at time wen i unlock my screen at least 10 mints late is it related to wake lock or anything else .please help.
Sent from my GT-i9003 using xda premium
Click to expand...
Click to collapse
Which rom/kernel are you on? Maybe something to do with the new sync bug workaround...
Sent from my Samsung Galaxy SL on CyanogenMod 9 !
Ehndroix ROM with Dhiru's kernel
Sent from my GT-i9003 using xda premium
Really, it comes down to installing Xposed framework and Greenify.
Sometimes we need to be told straight up what works, and its installing XPosed Framework, and installing Greenify to identify what's waking up and consuming battery - and then telling Greenify to put it to sleep.
I'm doing this write up because it's something I know a lot of us are facing with our Relay's as they age and we try to stay current with new roms.
Like quite a few of us I've sacrificed battery life for an updated rom that looks decent and runs fast. Between builds and Kernels I was lucky to get through the day let alone to 24 hours without my phone needing a charge - even if I didn't play any games.
I tried flashing clean and not using titanium backup - didnt have any effect once I had the apps I desired installed.
I checked OS Monitor, wakelock detector, battery usage things, juice defender... nothing really extended or identified what he true cause, things said Android System UI or Display or Graphics was eating it all up. I started wondering if it was the latest roms with the transparent pull down notifications or the annoying pop ups that show you text messages and emails in the top foreground of the screen ..
Turns out for me, it was my "Transparent Weather Widget" I wanted something that showed a 5 day forecast and this sucker was DRAINING my battery.
I'm now running SlimKat initial build (Mar 15 2014) with Xposed framework, Juice Defender and Greenify. Everything is working perfect on my phone now. I keep checking in greenify and sleeping apps that don't need to be using any resources until I execute them. One item about SlimKat is you need to 2 finger pinch together the recent tasks to close all apps at once, other than that it has every feature I wanted, less annoying pop ups than the most recent KitKat's and my battery today - 50% after 14 hours. Usually at the most by a day like today I would have is 15% but more likely 6%.
This may be long winded, but its the steps we've all been mystified on why System UI or Display is the leading cause of battery use.. I think it has to do with the transparency of my widgets .. Food for thought if it helps others.
yohan4ws said:
Really, it comes down to installing Xposed framework and Greenify.
Sometimes we need to be told straight up what works, and its installing XPosed Framework, and installing Greenify to identify what's waking up and consuming battery - and then telling Greenify to put it to sleep.
I'm doing this write up because it's something I know a lot of us are facing with our Relay's as they age and we try to stay current with new roms.
Like quite a few of us I've sacrificed battery life for an updated rom that looks decent and runs fast. Between builds and Kernels I was lucky to get through the day let alone to 24 hours without my phone needing a charge - even if I didn't play any games.
I tried flashing clean and not using titanium backup - didnt have any effect once I had the apps I desired installed.
I checked OS Monitor, wakelock detector, battery usage things, juice defender... nothing really extended or identified what he true cause, things said Android System UI or Display or Graphics was eating it all up. I started wondering if it was the latest roms with the transparent pull down notifications or the annoying pop ups that show you text messages and emails in the top foreground of the screen ..
Turns out for me, it was my "Transparent Weather Widget" I wanted something that showed a 5 day forecast and this sucker was DRAINING my battery.
I'm now running SlimKat initial build (Mar 15 2014) with Xposed framework, Juice Defender and Greenify. Everything is working perfect on my phone now. I keep checking in greenify and sleeping apps that don't need to be using any resources until I execute them. One item about SlimKat is you need to 2 finger pinch together the recent tasks to close all apps at once, other than that it has every feature I wanted, less annoying pop ups than the most recent KitKat's and my battery today - 50% after 14 hours. Usually at the most by a day like today I would have is 15% but more likely 6%.
This may be long winded, but its the steps we've all been mystified on why System UI or Display is the leading cause of battery use.. I think it has to do with the transparency of my widgets .. Food for thought if it helps others.
Click to expand...
Click to collapse
Really good post, I can say I using 20140315 version (last working camera) and last kernel for it (don't remember the version) get really good performance and similar battery, using the same xposed
OmniToad now includes methods to turn off specific alarms and wakelocks at a lower level than greenify and/or Xposed.
Magamo said:
OmniToad now includes methods to turn off specific alarms and wakelocks at a lower level than greenify and/or Xposed.
Click to expand...
Click to collapse
You can try the battery performance already?
yohan4ws said:
I'm now running SlimKat initial build (Mar 15 2014) with Xposed framework, Juice Defender and Greenify. Everything is working perfect on my phone now. I keep checking in greenify and sleeping apps that don't need to be using any resources until I execute them. One item about SlimKat is you need to 2 finger pinch together the recent tasks to close all apps at once, other than that it has every feature I wanted, less annoying pop ups than the most recent KitKat's and my battery today - 50% after 14 hours. Usually at the most by a day like today I would have is 15% but more likely 6%.
Click to expand...
Click to collapse
What kind of wireless networks do you use throughout the day and what kind of screen on time are you juicing out in your 14 hours??
hbk.vix said:
What kind of wireless networks do you use throughout the day and what kind of screen on time are you juicing out in your 14 hours??
Click to expand...
Click to collapse
30 second timeout on the screen, i check it to read emails and texts, the odd phone call, sometimes i will run a wifi diagnostic for the networks i support using fing and wifi analyzer.. i keep my phone off and locked otherwise. in the car bluetooth is enabled. i was going wifi diagnostic yesterday when i got such great battery life.
today i have android weather and clock widget (cant recall the exact name) running w 3hour update .. after 8 hours i have 58% remaining, im in an area with horrible cell coverage , stats say 38mins screen on time.
there is nothing different of my usage over the passed cpl weeks, just enabling greenify and sleeping a voip app, facebook, google maps and the weather widget.
yohan4ws said:
there is nothing different of my usage over the passed cpl weeks, just enabling greenify and sleeping a voip app, facebook, google maps and the weather widget.
Click to expand...
Click to collapse
I'm using dashclock with 15min weather update, greader app with over 120feeds (aggregated in feedly) with 15 min update interval too and lots of other apps including the evil facebook+messenger. I switched recently from latest LiquidSmooth to Omnitoad and the result is I got the battery dropped by 9% overnight (10 hours) in idle mode.
Nota bene: without any tweaking.
I installed the Xposed framework and successfully used it to get rid of the "Just Once" app picker annoyance.
Edit: the play store has a Greenify which requires Xposed framework. Tutorial on Greenify use is on Youtube. Up and running now, but noticed that I am not getting a GPS fix now ever since the altrnt app picker MOD. It's always something!
Sent from my SGH-T699 using XDA Free mobile app
How can install xposed on cm 11?
subzerobob said:
I installed the Xposed framework and successfully used it to get rid of the "Just Once" app picker annoyance.
Edit: the play store has a Greenify which requires Xposed framework. Tutorial on Greenify use is on Youtube. Up and running now, but noticed that I am not getting a GPS fix now ever since the altrnt app picker MOD. It's always something!
Sent from my SGH-T699 using XDA Free mobile app
Click to expand...
Click to collapse
Hi! Do you have your relay with CM11 or stock ROM? I can't manage to install xposed with CM11. Thanks!
ninguno2 said:
Hi! Do you have your relay with CM11 or stock ROM? I can't manage to install xposed with CM11. Thanks!
Click to expand...
Click to collapse
I'd be curious to know too. I recently tried to install xposed again (last time I used it was probably a couple of years ago) on my Relay running the last official CM11 nightly, and it didn't work either. First the installer complained that xposed isn't compatible with my version of the Android SDK, but there is a fix for that (I forget where, but it is somewhere on XDA). But even when I applied the fix, it still failed, I started getting bootloops. So yeah, I'd love to know how to install xposed on the Relay too...
I have to say, I have been using my Relay more lately, as my main phone has been having some issues, and the main thing that keeps me from using it more is battery life. I'm not crazy about the screen, but I can live with it, and I have just about everything else running fairly smoothly - and the keyboard is just a joy to use. This thing is a real workhorse. But when the battery plummets down to ~70% or 60% within a couple of hours of use, that's just not cool...
cucumbers said:
I'd be curious to know too. I recently tried to install xposed again (last time I used it was probably a couple of years ago) on my Relay running the last official CM11 nightly, and it didn't work either. First the installer complained that xposed isn't compatible with my version of the Android SDK, but there is a fix for that (I forget where, but it is somewhere on XDA). But even when I applied the fix, it still failed, I started getting bootloops. So yeah, I'd love to know how to install xposed on the Relay too...
I have to say, I have been using my Relay more lately, as my main phone has been having some issues, and the main thing that keeps me from using it more is battery life. I'm not crazy about the screen, but I can live with it, and I have just about everything else running fairly smoothly - and the keyboard is just a joy to use. This thing is a real workhorse. But when the battery plummets down to ~70% or 60% within a couple of hours of use, that's just not cool...
Click to expand...
Click to collapse
Hi, i got it working with the files in this posts
https://forum.xda-developers.com/showpost.php?p=72133164&postcount=210
https://forum.xda-developers.com/showpost.php?p=72133164&postcount=209
I download both files, first I install the apk and got a bootloop, and then flash the zip from recovery. That fixes the bootloop and keep xposed installed.
ninguno2 said:
Hi, i got it working with the files in this posts
https://forum.xda-developers.com/showpost.php?p=72133164&postcount=210
https://forum.xda-developers.com/showpost.php?p=72133164&postcount=209
I download both files, first I install the apk and got a bootloop, and then flash the zip from recovery. That fixes the bootloop and keep xposed installed.
Click to expand...
Click to collapse
So - install .apk, then flash the .zip - correct? And xposed is working well now for you?
[EDIT] So the .apk you posted worked just fine for me, no need to flash the .zip! Odd, but grateful this worked. Thanks!
Just wanted to confirm: Greenify (root) + Greenify xposed module + Amplify xposed module make a huge difference. Battery lasts much longer, and I have this sneaking suspicion the phone is generally smoother and less laggy. Might well be placebo, I know, but with useless background processes being sht down it might well have an effect on performance...
cucumbers said:
So - install .apk, then flash the .zip - correct? And xposed is working well now for you?
[EDIT] So the .apk you posted worked just fine for me, no need to flash the .zip! Odd, but grateful this worked. Thanks!
Click to expand...
Click to collapse
Great! I don't know why, but i had to flash the second one too.
Could you tell me which options have you check in Greenify and Amplify with xposed to get better battery life?
Thanks!
Greenify: Root mode + Xposed, of course. I've got automatic hibernation set, and for xposed features, I set all of them except Deep Hibernation
Amplify: even just selecting the default wakelock blocks in the free version helps a lot, but I use the paid version and I limited just about every wakelock that the app said was safe to limit (but only ones that were also described as safe in their blurb - some in the "safe" list are described as "we don't have any information for this wakelock yet") except for a few that were really light wakelocks.
Sup XDA!
When I updated to android 5.1.1 (cm12.1, rooted) android system started to drain my battery, even more than my screen would. This wasn't an issue back on 5.0 and I wonder what the problem is, and I thought you guys could be able to help me out as this forum has helped me before, thx for that!
Ive attached 3 screens, first is from battery monitor and the other 2 are screens of my battery 'page' in settings. Let me know if you need any additional information and or screenshots and I'll be happy to provide.
Thanks in advance
Disable all of the google services you feel that take RAM (and so, battery) using the Disable Service app. Don't disable GCM Service. Don't disable FusedLocation Service if you use GPS. The only google service running on my phone is GCM. Disable location services, key chain, pppreferences, CM logger, dev tools, etc. just anything that you find isn't important and takes battery! Use apps like Greenify, Disable Service and Titanium backup to greenify, disable and freeze the apps/services.
TheHighLife said:
Sup XDA!
When I updated to android 5.1.1 (cm12.1, rooted) android system started to drain my battery, even more than my screen would. This wasn't an issue back on 5.0 and I wonder what the problem is, and I thought you guys could be able to help me out as this forum has helped me before, thx for that!
Ive attached 3 screens, first is from battery monitor and the other 2 are screens of my battery 'page' in settings. Let me know if you need any additional information and or screenshots and I'll be happy to provide.
Thanks in advance
Click to expand...
Click to collapse
This seems to be a common issue.... the fix involves downgrading the modem. However downgrading the modem requires downgrading your TWRP Recovery... which you cannot do if you are running CM12.1, the downgrade will fail every time no matter which "tricks" you use.
lotherius said:
This seems to be a common issue.... the fix involves downgrading the modem. However downgrading the modem requires downgrading your TWRP Recovery... which you cannot do if you are running CM12.1, the downgrade will fail every time no matter which "tricks" you use.
Click to expand...
Click to collapse
You don't need to downgrade TWRP to flash a modem. You can very easily flash a modem without TWRP even installed; fastboot. It isn't even certain that the modem is causing this drain either.
Working on the likely assumption that it is the same problem, the modem is indeed not to blame.
I have moved through COS12.1, CM12.1, sultan, paranoid android, and exodus, with and without flashing the modem and gapps, using both stock and Boeffla kernel.
They all exhibit the same drain, 9-11% overnight or 16-40mA/h (via dumpsys). This is regardless of wifi/cellular/ambient and other features being disabled.
The only obvious anomalies differing from 5.0.2 are high system_server cpu (25-450% via top) when asleep, and intermittent floods of "unknown" wakeups without wakelocks (Observed by dumping batterystats, and are not registered by settings - battery).
On one of my many reflashes Exodus 12.1 suddenly began behaving reasonably, with 6-10mA/h drain and 2% overnight.
The high System_sever cpu and intermittent wakeups were still present at this point, and may be unrelated oddities.
I later made the mistake of flashing a newer nightly (and later the correct modem), upon which the problem reappeared.
Doing a wipe and reflashing in the same manner did not resolve the issue, and many attempts later I have been unable to reproduce the same state.
Coming from kitkat I figured 5.0.2 would be the same, but it has been smooth sailing since flashing it last night (Exodus), with 6-10mA/h drain and 0% overnight.
Roughy said:
Working on the likely assumption that it is the same problem, the modem is indeed not to blame.
I have moved through COS12.1, CM12.1, sultan, paranoid android, and exodus, with and without flashing the modem and gapps, using both stock and Boeffla kernel.
They all exhibit the same drain, 9-11% overnight or 16-40mA/h (via dumpsys). This is regardless of wifi/cellular/ambient and other features being disabled.
The only obvious anomalies differing from 5.0.2 are high system_server cpu (25-450% via top) when asleep, and intermittent floods of "unknown" wakeups without wakelocks (Observed by dumping batterystats, and are not registered by settings - battery).
On one of my many reflashes Exodus 12.1 suddenly began behaving reasonably, with 6-10mA/h drain and 2% overnight.
The high System_sever cpu and intermittent wakeups were still present at this point, and may be unrelated oddities.
I later made the mistake of flashing a newer nightly (and later the correct modem), upon which the problem reappeared.
Doing a wipe and reflashing in the same manner did not resolve the issue, and many attempts later I have been unable to reproduce the same state.
Coming from kitkat I figured 5.0.2 would be the same, but it has been smooth sailing since flashing it last night (Exodus), with 6-10mA/h drain and 0% overnight.
Click to expand...
Click to collapse
So right now you are on the 5.0.2 exodus builds and having minimal battery drain? Which modem are you using?
f41lbl0g said:
So right now you are on the 5.0.2 exodus builds and having minimal battery drain? Which modem are you using?
Click to expand...
Click to collapse
Correct, with the Xposed Mobile Radio Active fix applied.
bacon_firmware_update_2015_04_03.zip from ... <10 posts and am not allowed to post links yet.
It's on Exodus' 5.0.2 download page along with the roms.
As usual the modem will not flash in TWRP, and has to be done manually via fastboot.
Paresh Kalinani said:
Disable all of the google services you feel that take RAM (and so, battery) using the Disable Service app. Don't disable GCM Service. Don't disable FusedLocation Service if you use GPS. The only google service running on my phone is GCM. Disable location services, key chain, pppreferences, CM logger, dev tools, etc. just anything that you find isn't important and takes battery! Use apps like Greenify, Disable Service and Titanium backup to greenify, disable and freeze the apps/services.
Click to expand...
Click to collapse
I did all of this but it's still draining battery, should I post new screenshots?
TheHighLife said:
I did all of this but it's still draining battery, should I post new screenshots?
Click to expand...
Click to collapse
As you have tried many things to improve your battery life, last option I wanna suggest you to use your device in safe mode for one complete charge cycle from 94% down to 5% (I know that this mode is pathetic).
If you still find that it's causing battery drain, you need to reflash the ROM and please do not restore any backup(restore only those which are most important).
If you find that Android system is not causing anymore battery drain, then it's one of the third party app that is doing so.
Mr hOaX said:
As you have tried many things to improve your battery life, last option I wanna suggest you to use your device in safe mode for one complete charge cycle from 94% down to 5% (I know that this mode is pathetic).
If you still find that it's causing battery drain, you need to reflash the ROM and please do not restore any backup(restore only those which are most important).
If you find that Android system is not causing anymore battery drain, then it's one of the third party app that is doing so.
Click to expand...
Click to collapse
Ive only tried to disable some services that show up under android system. How do I put it in safe mode tho?
By the way, I just noticed that the CPU total time for android system is exactly the same time as the SOT, what does this mean? It only drains this much battery when the screen is on?
TheHighLife said:
Ive only tried to disable some services that show up under android system. How do I put it in safe mode tho?
By the way, I just noticed that the CPU total time for android system is exactly the same time as the SOT, what does this mean? It only drains this much battery when the screen is on?
Click to expand...
Click to collapse
Boot your device into safe mode https://support.google.com/nexus/answer/2852139?hl=en
Just post some screenshots of the battery (complete overview of graph screen and app list screen) after using your OPO in safe mode atleast for one charge cycle (90%+ down to 10%)
This will help us to figure out what is the exact issue you are facing.
If you are not interested in troubleshooting, just flash fastboot images of this build(CMOS12.1) using following guide
forum.xda-developers.com/oneplus-one/general/guides-bacon-timmaaas-how-to-guides-t2839471
For OnePlus One, about a month ago after systems update, my battery started draining fats and it has gotten worse over the past week. The battery barely holds four hours of after a full charge and the phone gets very hot. Also, over the past week, my main SMS messaging app (SMS) crashes nine out of 10 times -- I can start the app but when I click any of the messages I was to read or type, it freezes and crashes. Also, since yesterday, my phone dilaer crashes very often. Any thoughts/help? I am not familiar with how to flash ROM, etc. Also, since yesterday, charging has been very slow -- overnight, the charge went from 35% full to 74% full. I tried safe mode as well and no luck -- battery still keeps draining at 1% every three minutes.
I have the same issue. Any fixes which work ?
Is there anyway way to get this feature
I think it should be a default feature in android in general
The asus rog phone got it officially as "bypass charging" in a new update
In a nutshell the feature allows the phone to use power directly from the charger bypassing the battery altogether this is especially good for gamers and long sessions because u can use the phone without wasting even a fraction of battery life cycle
It can extend battery life a great deal.
After some searching I found out it can be done with a magisk module called advanced charging controller
Any chance we can implement this in a flashable zip or in a rom without the need for rooting?
It is certainly possible since there is kernels that support this for some devices and since it was implemented on the asus rog phone 3 by a software update
.. it's explained in detail here https://android.stackexchange.com/q...tery-but-use-connected-power-to-run-the-phone
This could be a very interesting feature.
For exemple I drive all day long with android auto and this could be a real life saver for the battery.
Zaboon26 said:
This could be a very interesting feature.
For exemple I drive all day long with android auto and this could be a real life saver for the battery.
Click to expand...
Click to collapse
True
eddie1 said:
After some searching I found out it can be done with a magisk module called advanced charging controller[/url]
Click to expand...
Click to collapse
Battery idle mode needs kernel support to be possible, and this phone's kernel does not support it--not on stock (global), and not on Xiaomi.eu. ACC cannot turn on something that isn't available. And there are no third party kernels for this phone on this site. The closest thing you can do is get a low wattage charger that can only supply roughly the same amount of current the phone is using. Charging from a laptop's USB port might be suitable. This obviously does not require root, but will slowly charge or discharge the battery. The effect will be almost the same as battery idle mode, except that you may still end up charging the battery a bit while the phone is warm, which is not ideal. It should still be better than charging at high current as you would with the OEM charger and cable.
If you charge slowly as recommended above, ACC can be complementary. ACC can stop charging when your battery reaches a certain percent, so can operate the battery in a less stressful region, such as 60-80%.
fenstre said:
Battery idle mode needs kernel support to be possible, and this phone's kernel does not support it--not on stock (global), and not on Xiaomi.eu. ACC cannot turn on something that isn't available. And there are no third party kernels for this phone on this site. The closest thing you can do is get a low wattage charger that can only supply roughly the same amount of current the phone is using. Charging from a laptop's USB port might be suitable. This obviously does not require root, but will slowly charge or discharge the battery. The effect will be almost the same as battery idle mode, except that you may still end up charging the battery a bit while the phone is warm, which is not ideal. It should still be better than charging at high current as you would with the OEM charger and cable.
If you charge slowly as recommended above, ACC can be complementary. ACC can stop charging when your battery reaches a certain percent, so can operate the battery in a less stressful region, such as 60-80%.
Click to expand...
Click to collapse
It's actually possible even without kernel support
There is a generic way using acc
Here is a screenshot from the acc GitHub stable channel documentation
So it's possible
but my question was if it would be possible to implement the code in a rom or a flashable zip instead of magisk module
I'm still kinda hesitant to use magisk
I created a thread on the xiaomi.eu forums but didn't get any response
eddie1 said:
It's actually possible even without kernel support
There is a generic way using acc
Here is a screenshot from the acc GitHub stable channel documentation
So it's possible
but my question was if it would be possible to implement the code in a rom or a flashable zip instead of magisk module
I'm still kinda hesitant to use magisk
I created a thread on the xiaomi.eu forums but didn't get any response
Click to expand...
Click to collapse
I see what you mean about emulating battery idle mode. (Though I'll believe it when I see it, since the two features described are something similar to battery idle mode, not battery idle mode itself.)
The way ACC and AccA are implemented requires root. It's the way the software is written and installed. In fact after you install the Magisk ACC module, you will see a flashable .zip in your Downloads folder. So you have the zip, but it won't install without Magisk. (I did try flashing it without Magisk.) And according to the ACC readme, some root solution is necessary (not necessarily Magisk). I assume it is possible to create flashable software that runs as root without requiring an external root solution (after all, Magisk and SuperSU provide root without depending on an external solution), but that's not the way ACC was implemented.
fenstre said:
I see what you mean about emulating battery idle mode. (Though I'll believe it when I see it, since the two features described are something similar to battery idle mode, not battery idle mode itself.)
The way ACC and AccA are implemented requires root. It's the way the software is written and installed. In fact after you install the Magisk ACC module, you will see a flashable .zip in your Downloads folder. So you have the zip, but it won't install without Magisk. (I did try flashing it without Magisk.) And according to the ACC readme, some root solution is necessary (not necessarily Magisk). I assume it is possible to create flashable software that runs as root without requiring an external root solution (after all, Magisk and SuperSU provide root without depending on an external solution), but that's not the way ACC was implemented.
Click to expand...
Click to collapse
I see
Thanks for explaining
It can be implemented in the rom without root if the kernel supports it tho
I posted on akr-developers (one the hiirakernel thread) about the feature if it's possible to implement
Hopefully the developers will implement it
eddie1 said:
It's actually possible even without kernel support
There is a generic way using acc
Here is a screenshot from the acc GitHub stable channel documentation
So it's possible
but my question was if it would be possible to implement the code in a rom or a flashable zip instead of magisk module
I'm still kinda hesitant to use magisk
I created a thread on the xiaomi.eu forums but didn't get any response
Click to expand...
Click to collapse
This command just stopped charging... Battery drain is still there
This needs more attention. Im also interested in it to be able this to work whenever needed not only in gaming.
Hi there,
i've been using the app "battery charge limit" on my htc u11 for years without any issues.
Now i've switched to P7a and the app doesn't work. If the battery reaches the set limit, it doesn't stop charging.
Same with AccA. I use the CalyxOS Rom with MicroG.
Any Ideas?
Probably a dumb question, but are you rooted? AccA is a frontend for the acc Magisk module.
yes root with magisk
BunkerBert said:
yes root with magisk
Click to expand...
Click to collapse
And Acca did ask if it should install the module, right? And it says "ACC Daemon is Running" at the top?
Maybe a kernel issue then. I only ever experienced issues with battery idle (drawing power directly from plug) with some kernels, everything else worked usually.
yes daemon is Running, but it seems to stop randomly
battery optimizing for acca / battery charge limit is off
edit: Battery Charge Limit App works now. Had to set the correct path to the control/systemfile ->
Pixel 7a:
/sys/devices/platform/google,charger/charge_stop_level
Enable Value: 100
Disable Value: 5