Related
[Complete rewrite 26/10]
I'm writing this since the abundant misinformation about it coming across many many threads, and all other Android OS threads are too big and real information is easy to overlook.
After several weeks of analyzing and monitoring of the behavior of the device, things are starting to clear up and we can come to a conclusion.
What's the Android OS usage?
Many have noticed that on our Galaxy S2's and various other variations (Epic 4G Touch, etc) that in the Android battery stats the Android OS entry is supposedly eating away a large percentage of the battery used.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
There's been many threads old and new discussing it and theorizing and many users magically fixing it by doing god knows what changes.
The Android OS package is a bundle of processes, in this case, all root processes used by the system kernel. Please remember this when continuing to read on, as there is much more to it than meets the eye and only once specific aspect of the whole story will be treated.
A diagnosis of the main problem:
Download [APP] BetterBatteryStats adds battery history back to Gingerbread. It is your #1 friend on finding out what uses up CPU power and causes problems.
Note: The CPU time in BetterBatteryStats is normalized, meaning 100% load during full frequency for a minute will show up as 1 minute CPU time, 100% load at half-frequency for a minute will show 30 seconds CPU time. Keep this in mind when monitoring processes. The CPU time shown in the Android battery stats is useless.
As you can see in the screenshot, "suspend" and "events/0" pop up as the big consumers of CPU power. Red means it's a system/kernel process and blue means it's a user process.
The suspend process is the program that's in charge of telling the hardware to go into deep sleep mode and reawaken from it.
The events/0 is just the general events manager for the system kernel.
You can monitor this with Watchdog Task Manager. Set it up so that it monitors system processes and raises notifications. Depending on the severity of the bug at the time and some black magic, you'll see the 99% load on the system.
Due to how the hardware of the phone is designed, the default kernel settings of the phone lock its frequency to 800MHz before falling into deep sleep. This is believed to be one of the main problems as to why so much battery is drained. Compared to other the devices the Exynos 4210 in our Galaxy S2's takes a much longer time to enter deep sleep (suspend) and wake up again from sleep (resume). This can be seen in the device message logs:
<6>[ 749.242666] PM: suspend of devices complete after 171.413 msecs
<6>[ 749.250855] PM: late suspend of devices complete after 0.396 msecs
<4>[ 749.250864] Disabling non-boot CPUs ...
<7>[ 749.250909] s3c_pm_enter(3)
<7>[ 749.250916] s3c_sleep_save_phys=0x40d9fe80
<7>[ 749.250959] sleep: irq wakeup masks: 000fffdd,cb37b97f
<6>[ 0.000000] WAKEUP_STAT: 0x80000001
<6>[ 0.000000] WAKUP_INT0_PEND: 0x80
<6>[ 0.000000] WAKUP_INT1_PEND: 0x0
<6>[ 0.000000] WAKUP_INT2_PEND: 0x0
<6>[ 0.000000] WAKUP_INT3_PEND: 0x0
<7>[ 0.000000] s3c_pm_enter: post sleep, preparing to return
<7>[ 0.000000] S3C PM Resume (post-restore)
<7>[ 0.000000] Wakeup from sleep, 0x80000001
<6>[ 0.000000] L310 cache controller enabled
<6>[ 0.000000] l2x0: 16 ways, CACHE_ID 0x4100c4c5, AUX_CTRL 0x7e470001, Cache Size: 1048576 B
<6>[ 749.251252] PM: early resume of devices complete after 0.255 msecs
..
..
<6>[ 749.748189] PM: resume of devices complete after 496.599 msecsThe fact that these operations are done at a higher frequency, together with the fact that a suspend-wake cycle takes around anything from 0.6 to 0.8 seconds, while doing nothing else, will drain more power than actually needed.
The screenshot on the right is a period of 15 minutes where the processes were bugged, the timers in CPU Spy were reset, and the screen immediately turned off to collect the statistics. A screen-off profile was used to limit the maximum frequency to 200MHz, so theoretically any standard process is not allowed to use any of the frequency-states above that. Nevertheless, There you can see the device being in the 800MHz state for roughly half the time. This means that half the time the device is spending on being awake is being wasted on just entering and leaving the deep sleep state.
Note: The deep sleep state is a state in which the CPU isn't clocked anymore and caches are no longer kept coherent, basically it's turning off most of the CPU, and thus conserving a lot of power.
What's the cause of high Android OS usage?
This is where things get interesting.
Network usage
The most common cause of the device waking up often enough to cause a problem and raise the suspend process up, and thus also the AOS usage, are incoming and outgoing network traffic. These will be attributed to the operating system rather than the service or application at cause of the problem.
Wild wakelocks
Second most common cause are high-frequency wakelocks caused by some application or service. Refer to the next section for this topic.
Incorrect statistical interpretation
One has to keep in mind that when generating the percentages shown under the battery stats in Android, that those values are just an estimate. The ROM has a file called power_profile.xml in which power drain values for different uses are listed. These values are coming from Samsung. For example, the CPU running at 1200MHz is listed as using 577mAh of power, so when a task is running for 10 seconds at 1200MHz, then it means that that process will be getting attributed a power consumption of 1602µAh (577mAh/3600s *10s). ASOP ROMs like MIUI will actually list these values in the battery stats. Each entry in the battery usage as such has an estimated power consumption value, and out of which the percentages are calculated from.
The problem is, that these are all just estimates and wether they are calculated correctly is up to debate. There are issues if either dual core use is taken into account in these estimates, or not, and even if the values provided by power_profile.xml are representative of real use or not. One issue for certain is that power consumption will be wrong for people who underclock/overclock, and undervolting. There are no entries for states above 1200MHz or below 200MHz, and the ones already present are meant to be representative of default/stock voltages. If you're running 100MHz in idle, the system will use the 200MHz estimates and thus overestimate your power consumption, if you're overclocking and using 1400MHz for example, the system will underestimate your power consumption.
This part is also what causes kernels which claim to fix the problem to be nothing but red herrings: somewhere in the patching of the kernels to 2.6.35.12 there is a change which makes the whole suspend and wakeup process no longer visible to the system and thus is no longer registered. Because of that, there are no statistics of these and the drain can not be calculated. Tests have shown that this is nothing other than just hiding of the problem rather than a tangible fix.
What you can do:
First of all you need to find the cause of the problem; study your wakelocks. You can do this by using BBS as mentioned above but this will only show part of the story as it will not tell you about system wakelocks, but only user wakelocks. If there is no obvious villain listed there, then you must do some more advanced troubleshooting:
Dump your wakelocks file using a terminal or over ADB if you are familiar with it, as follows:
cat /proc/wakelocks > /sdcard/wakelocks.csvTo read this data you need to import it into a spreadsheet application like Excel or OpenOffice and you'll end up getting something like this: (Read the thread around here on how to format your spreadsheet)
You need to mainly look for high-duration wakelocks, and the wake_count frequency, meaning how often your device has woken up.
While this is all a bit advanced and all, you can do it simpler:
Avoid using application and services that use a permanent internet connections. Avoid using applications which use polling for their connectivity and instead use those who support C2DM push-notifications. This will vastly increase your battery life by vastly decreasing network traffic. If this all doesn't help, try doing a network analysis (packet capture) to inspect the source of it, please refer to discussions later in the thread for this.
What your device can be capable of:
In the first screenshot you can see two periods of around 18 hours where the battery drain is relatively flat. In this period the suspend process gained merely a few seconds of CPU time. Then I use the phone for a bit, it goes haywire, and then calms down again and then starts draining again. You can see this in the step-wise drain in the curve. It should be smooth and not like that.
In the second screenshot it's after a full charge where it didn't trigger for 8 hours. My battery is perfectly calibrated so those are real 4% of battery. So if things were to go smoothly on the software part then the phone is idling at around 0.4% of battery per hour on Wifi, and other people have been reporting down to 0.8% or even less with a good 3G signal.
Left side: low network usage, how it should be; Right side: high network usage, how it behaves sometimes in severe cases.
Same network, same location, same signal strength, same ROM (Changing my font maybe fixed it....) , same wakelocks between them, same background apps running. Not even 5 minutes screen time on the two. The only difference with .14 patched kernels I'm experiencing is that it's not showing up anymore in the stats, but it drains just as much as in the right screen, showing the same CPU state behavior. It's also happening less often, and many say it's not happening at all anymore, but how would they know it it's hidden now?
"tvout resume wo"
One might have noticed the high usage of the "tvout resume wo" (wo = work, btw) in BetterBatteryStats. This is part of the TVOut functionality/driver, and it seems that every time the CPU resumes it goes through this work wether you use TVOut or not. Due it being a kernel process it's also part of adding up to the Android OS package usage. If you are suffering from high frequency wakeups, then this will also go up as system routines for this functionality are called every time the device wakes up.
<6>[ 749.251252] PM: early resume of devices complete after 0.255 msecs
<3>[ 749.251350] [MHL]mhl_int_irq_handler() is called
Last words
The device is still superb. Even with this bug the battery is equivalent to many other high-end devices out there. The thing is, it could be much better. If you want to squeeze out most of your device read on the discussions in this thread to try to find out what's keeping the phone from wasting power. Forward this to people so they're informed and aware of it.
I really appreciate all the effort you've put into researching this!
AndreiLux said:
Summarized quick-facts:
It's caused by a bug in the drivers.
Click to expand...
Click to collapse
While I certainly do believe this, what leads you to believe it is a driver issue? And what particular driver have you found is the culprit?
AndreiLux said:
We can just hope that Samsung will fix this issue soon. For all we know they're aware of it and are working on it. The original Galaxy S had this very same issue and it has been supposedly fixed in a firmware update earlier this year. The Galaxy S2 is not the only phone having this issue, but it's the one that has it guaranteed most of the time.
Click to expand...
Click to collapse
I know that the 2.3.4 update for the original GX2 was supposed to have fixed this exact bug. You're saying that it is not in fact fixed? Shouldn't Samsung be alerted to this blunder?
AndreiLux said:
What your device would be capable of.
In the first screenshot you can see two periods of around 18 hours where the battery drain is relatively flat. In this period the suspend process gained merely a few seconds of CPU time. Then I use the phone for a bit, it goes haywire, and then calms down again and then starts draining again. You can see this in the step-wise drain in the curve. It should be smooth and not like that.
In the second screenshot it's after a full charge where it didn't trigger for 8 hours. My battery is perfectly calibrated so those are real 4% of battery. So if things were to go smoothly on the software part then the phone is idling at around 0.4% of battery per hour on Wifi, and other people have been reporting down to 0.8% or even less with a good 3G signal.
Basically Android OS should not be even showing up in the battery stats, like on many other devices. Lowest people are getting on the Galaxy S2 is about 5-10%. There's also some other issues like high usage of "tvout resume wo", but that's something irrelevant compared to the elephant in the room that is "suspend" & "events/0".
Click to expand...
Click to collapse
So you're saying it was just dumb luck and you happened to not trigger the bug? So this could account for people finding "solutions," but they were only coincidental of the bug randomly not manifesting itself?
Very weell explained.
As far as the first SGS, I can confirm that the bug was solved from the first 2.3.4.
I was experiencing a fantastic battery life with my SGS, and I was quite shocked when I had to watch helpless as Android OS went up on the S2.
That was a fantastic explanation. It does explain the vast difference in AOS between my Nexus S and SGSII. Hope this thread gets pinned to help put away the vast number of AOS threads present. And hopefully it'll help get more people to star the issue and get it the attention it badly needs!
xak944 said:
While I certainly do believe this, what leads you to believe it is a driver issue? And what particular driver have you found is the culprit?
Click to expand...
Click to collapse
It's been confirmed by a Samsung person on the original Galaxy S where it had the very same issue. Which driver exactly it is, I don't know. Supposedly it was the Wifi-driver but the bug also happens to some extent without Wifi, so I don't know. If you want you're welcome to go through 120MB of kernel source code to find the issue and change it.
xak944 said:
I know that the 2.3.4 update for the original GX2 was supposed to have fixed this exact bug. You're saying that it is not in fact fixed? Shouldn't Samsung be alerted to this blunder?
Click to expand...
Click to collapse
Look. There's Android, and then there's a complete phone firmware. People tend to call firmware versions by the Android version they're on. Android version itself is completely meaningless and it's not Google's job to fix this, the manufacturers are the ones who deliver the drivers and everything that makes Android run on the phone. There's been for example about 8 leaked firmware versions for 2.3.4 on the Galaxy S2.
xak944 said:
So you're saying it was just dumb luck and you happened to not trigger the bug? So this could account for people finding "solutions," but they were only coincidental of the bug randomly not manifesting itself?
Click to expand...
Click to collapse
Yes. Go wave a dead chicken over the phone and practice voodoo magic on it and you'll be just as successful at changing the behavior. The issue goes way too deep for the user to have any reproducible impact on it.
Thanks for great explanation and having a bit more light on the issue. I'm going to star those as soon as it goes off maintenance.
Good post thanks for your research.
AndreiLux said:
It's been confirmed by a Samsung person on the original Galaxy S where it had the very same issue.
Click to expand...
Click to collapse
Was this in a support case you opened with Samsung? A forum? Where and how?
AndreiLux said:
Look. There's Android, and then there's a complete phone firmware. People tend to call firmware versions by the Android version they're on. Android version itself is completely meaningless and it's not Google's job to fix this, the manufacturers are the ones who deliver the drivers and everything that makes Android run on the phone. There's been for example about 8 leaked firmware versions for 2.3.4 on the Galaxy S2.
Click to expand...
Click to collapse
Then why are we flagging the issues on the Android project? Shouldn't we be hammering on Samsung support channels for a fix if the problem is located in their proprietary drivers?
xak944 said:
Was this in a support case you opened with Samsung? A forum? Where and how?
Click to expand...
Click to collapse
Galaxy S XDA thread ; post in question ; response by Todd who is a Google employee.
xak944 said:
Then why are we flagging the issues on the Android project? Shouldn't we be hammering on Samsung support channels for a fix if the problem is located in their proprietary drivers?
Click to expand...
Click to collapse
You're more than welcome to show me the proper non-Korean Samsung channels. You're the one who said in big bold red letters to flag it to Google. In any way, Google forwards big issues directly to the manufacturers themselves.
AndreiLux said:
Galaxy S XDA thread ; post in question ; response by Todd who is a Google employee.
Click to expand...
Click to collapse
Oh good grief. We've really gone full circle now. That entire thread claims it was fixed in 2.3.4!
AndreiLux said:
You're the one who said in big bold red letters to flag it to Google.
Click to expand...
Click to collapse
Yeah, you're right. I should've done my own research and not assumed you knew what you were talking about.
AndreiLux said:
You're more than welcome to show me the proper non-Korean Samsung channels
Click to expand...
Click to collapse
http://www.samsung.com/us/SUPPORT/
http://twitter.com/SamsungSupport
http://facebook.com/SamsungSupport
Very good post probably the best on the subject to date.
Personally running 2.3.5 i don't find it as bad but there can be no denying the problem is still there and until Samsung sort it out it will continue to be there.
xak944 said:
Oh good grief. We've really gone full circle now. That entire thread claims it was fixed in 2.3.4!
Click to expand...
Click to collapse
It was... for the Galaxy S, we're on another phone. XXJVP fixed it, not 2.3.4. I said it earlier, firmware version != Android version.
xak944 said:
http://www.samsung.com/us/SUPPORT/
http://twitter.com/SamsungSupport
http://facebook.com/SamsungSupport
Click to expand...
Click to collapse
Well I'm not that stupid and have been that far myself. The US site doesn't even let me select my model because it doesn't officially exist there, and the international site where I'm rerouted to doesn't even have a report feature and the only contact is a phone number. And I'm not going to start FB'ing or Twittering about driver issues to a mega-conglomerate coorporation, I'll leave others to do that. Hardly a "proper" tech support channel as Google Code. Only the Korean site has that, but sadly, I can't speak Korean.
Thanks for the research.
Lets all star this so we cant get it to Samsung and they can fix this ASAP.
Great post. Lots of people are talking about battery life but without understanding how the stats work and how to interpret them.
The battery usage screenshot is funny though. Yeah, I understand it shouldn't have those steep fall-offs. But still, must be pretty nice to have 40% battery left after 2.5 days!
Thanks for your explanation, I often wondered what the android os bug was and now I know. I'm quite fortunate by the sound of things my android os is usually around 15%. Is this issue likely to be resolved with ICS?
Sent from my GT-I9100 using Tapatalk
Here's what I don't get. I've had the phone since week one back in may and from may to September - no os bug. So why now? Have I done something to trigger it? Can we isolate the cause to prevent others getting it? I can list what I've done different recently to previous months if it helps?
And if it's drivers then why doesn't it access the CPU when the charger is plugged in?
I share everyone's frustration over all this.
Sent from my GT-I9100 using XDA App
We have the same problem on the US Galaxy S II/Sprint Epic 4G Touch :\
This thread should be stickied!
Shafty said:
Here's what I don't get. I've had the phone since week one back in may and from may to September - no os bug. So why now? Have I done something to trigger it? Can we isolate the cause to prevent others getting it? I can list what I've done different recently to previous months if it helps?
Sent from my GT-I9100 using XDA App
Click to expand...
Click to collapse
I have no idea.
I've tried it on half a dozen ROMs, wiped everything clear, removed every app to the point of the ROM being pretty naked, and still didn't get to change it. There's a lot of people like you who say they don't have the bug and suddenly have it. It may be a hardware fault that doesn't trigger until some certain circumstances are fulfilled. Maybe it's just some stupid bug in the drivers and it's some synchronization problem between registers. It may be cosmic rays who change a bit in the memory. Who the **** knows.
All I know is that nobody has been able to isolate it to any common cause, and I sure haven't managed in the last 3 months, and I've had it since July myself. At the same time you ask yourself why there's such a wide variety of devices having the same issue, but different hardware. If I would be paid full time to look through the source code and find the bug then I'd do it. But until then, I just wanted to share it with everybody and just tell them to stop wasting their time.
Shafty said:
And if it's drivers then why doesn't it access the CPU when the charger is plugged in?
Click to expand...
Click to collapse
Because when the device is plugged in then a wakelock is active and the device doesn't go to deep sleep at all. Since the going to deep sleep process is what is bugging, then wakelocking it prevents it from bugging out. I mentioned this already in the post. Since you have MIUI, you can for example tell it in the battery setting to not go to deep sleep at all (there's a checkbox), and see the results for yourself.
I'll just say i got my SGS2 recently and it came with 2.3.4 - there was no AOS bug at first then oneday started noticing it. I upgraded to 2.3.5 via XXKI3 and it's better as it's "only" 11% now rather than 29-40%.
Guess i should check with CPUspy to see if the phone is actually deep sleeping - I would however assume so as it's been getting better battery life since i upgrading to 2.3.5.
TheManii said:
It's widely known that the s7 has pretty weak battery life.
In general all qisda dell devices do (the s5/s7/venue).
Many of the bugs exist in the phone/ril and some exist in the logging systems.
In a bug free rom these workarounds should be completely meaningless, but stock roms are not at all bug free.
Recommendation one: Enable airplane mode on wifi s7's
The wifi and 3/4g roms are nearly identical, including the fact that wifi roms still have a full RIL. It apparently is also still enabled even in wifi s7's. Turning airplane mode on while leaving wifi/bluetooth on (as desired) does in fact affect the system.
Ways of checking: with airplane mode off on mine, the s7 has major issues going into sleep mode. Even with the screen off if you check the battery graph it's still active most of the time. Airplane mode more or less fixes this.
Potential gains: 20-30% or so more life, I've only been testing this for half a day or so but it seems to be draining signifigantly slower in sleep.
Recommendation two: (this one is more valid for the s5 then the s7) Connect the s7 to a pc with the android SDK installed and run 'adb logcat'
The qisda devices are known to have far too much logging enabled and included in stock roms. Virtually all the custom roms for the s5/7 have it removed, but there is a known bug with logging.
If you run logcat so the output is directed to it, afterwards it takes care of another one of the bugs. I have not actually tested this specifically on the s7, but it likely is equally valid as the differences from AOSP (ie the customizations qisda does to the roms) are pretty similar in the s5 and s7.
Potential gains: nearly triple battery life after logcat and avoiding a yet different ril bug on the s5. The s5 can go from potentially 10%/hour to 0.3%/hour due to all/no bugs being active. The s7 MAY be a valid target too, but I havnt actually tested this one on the s7.
Roms used to compare:
S7: Stock 506-wifi
S5: Custom 406 based rom
Click to expand...
Click to collapse
Crosspost from the S7 forum, both are valid on the s5.
The largest battery bug is in the RIL, way of activing the bug: make a call. If you reboot everytime after making a call the battery life is much better then if you dont restart. Depending on how often you make calls though this is completly unacceptable to reboot after each call.
Are you saying that removing logcat daemon would give more battery life?
If I am not mistaken, that seems a obvious thing, am I wrong?
But if you remove the logcat daemon, then you can't hunt the bugs anymore, so for custom Roms that would be a very high price to pay for so little gain.
Running logcat with the device attached actually affects it. You dont remove it, you merely run it and let it write to your screen for a bit
TheManii said:
Running logcat with the device attached actually affects it. You dont remove it, you merely run it and let it write to your screen for a bit
Click to expand...
Click to collapse
So redirecting output from /dev/null to /dev/tty1 improves battery life ? Seems highly unlikely to me.
Can you explain the methodology used in your tests, bcs we can go somewhere this way, bcs s5 seems to have not a good battery life, and some strange things i have observed too in this device.
It's redirecting it to the adb console, this is why the bugs inherently make no sense as it should be otherwise discarding the log safely when not attached to adb.
But it's really consistant/reproducable on my device. Until it's attached it contributes about +2-3%/hour drain on standby.
TheManii said:
It's redirecting it to the adb console, this is why the bugs inherently make no sense as it should be otherwise discarding the log safely when not attached to adb.
But it's really consistant/reproducable on my device. Until it's attached it contributes about +2-3%/hour drain on standby.
Click to expand...
Click to collapse
2-3 % standby per hour is way too much , i am running the latest DSC 0.64b on top of 407 BB and have around 1-1.5 % , but that seems too much for me , you should check the background processes i think.
I can consistantly get 0.3/hour drain if the bugs taken care of.
If you also encounter the RIL bug you can easily hit 10%/hour possibly in combination with the log bug, it's relatively common too.
TheManii said:
I can consistantly get 0.3/hour drain if the bugs taken care of.
If you also encounter the RIL bug you can easily hit 10%/hour possibly in combination with the log bug, it's relatively common too.
Click to expand...
Click to collapse
So then something wrong with my system then, what Rom you running ?
TheManii said:
Running logcat with the device attached actually affects it. You dont remove it, you merely run it and let it write to your screen for a bit
Click to expand...
Click to collapse
I have the stock Olleh 407 ROM installed on my Streak. If I run the ADB LOGCAT with my Streak attached for a while, then the bug will be gone, even if I disconnect from my PC? Or the bug is only gone when Im connected to the ADB LOGCAT?
It's a heavily modified SD 2.4.4
The RIL bug seems to be more noticible in GB, I dont recall if it existed in 3xx roms. The logcat one is possible in 3xx or newer roms.
lunadomain said:
I have the stock Olleh 407 ROM installed on my Streak. If I run the ADB LOGCAT with my Streak attached for a while, then the bug will be gone, even if I disconnect from my PC? Or the bug is only gone when Im connected to the ADB LOGCAT?
Click to expand...
Click to collapse
It's really voodoo/magic, attaching it for <some unknown amount of time> will fix it for <some random amount of time>
For me it seems I just attach it until the battery is charged (as I would charge it anyway) and it seems to last for a day to a couple days. It's as voodoo as it sounds.
It doesnt stick past a reboot and more importantly the RIL bug is the more noticable one anyway.
It's only really noticible when the ril bug isnt active, as then you're going from 2-3% to 0.3%/hour. Going from <10% to 3% overshadows it if it's even active at all.
I cant really say for certian if it even effects everyone or happens every boot. I've been on the same rom for 2 months and have extremely consistant data with regards to these two bugs.
The logcat one is just as consistant for me on SD 19x roms.
You can also do it without SDK installed, you just need to download terminal emulator from market and enter:
su
logcat
And you are ready
At least when I do it, i use it as an opportunity to charge anyway. I always do it on my pc as I need the SDK for other things so I always have it installed.
On a custom SD244 not OCed with airplane mode and after running logcat previously with wifi turning off when screen is off:
getting 15hours @5% lost.
I'm gonna keep testing till tomorrow then install 407
Surprisingly: the s5 has even better battery life then the s10 (ignoring the differences in battery life).
The s10 has amazing battery life too.
Current results:
S5 : 31 hours = 24%
S7 : 54 hours = 48%
S10:61 hours = 13%
Normalizing their results to the size of the S10's batt:
S5: 5.17 hours each %
S7: 2.63 hours each %
S10: 4.7 hours each %
Roms used:
S5: SD 2.4.4 <2.3.3>
S7: Stock 506-wifi <3.2>
S10: Chimeradroid r2 <3.2>
The S5 can be explained by the RIL bugs as mentioned earlier, and by airplane mode is also turning off the radio too. All 3 devices were left to idle for the entirety, with only battery graph checks and no actual use.
Guys , i have a really vad problems with my battery life. After i go on to Power Rom EVG (before that i was with StreakDroid 2.4.4) my battery is absolutely not good. I do this logcat trick, just a few programs is running, auto-brighness and ... nothing! please, help!
My Android OS is showing a stay always time of over 17 hours (out of a 20 hour run time where my battery is completely depleted). Is there anyway I can find out what cause it?
I am already on 4.2.2
elty123 said:
My Android OS is showing a stay always time of over 17 hours (out of a 20 hour run time where my battery is completely depleted). Is there anyway I can find out what cause it?
I am already on 4.2.2
Click to expand...
Click to collapse
Android os = apps . Facebook maybe ?
You're experiencing wakelocks. Might wanna do some research on the forum so that you can post logs for people to analyze what's really eating your battery.
Sfkn2 said:
You're experiencing wakelocks. Might wanna do some research on the forum so that you can post logs for people to analyze what's really eating your battery.
Click to expand...
Click to collapse
THIS. I was having problems with wakelocks and traced them back to these few things below which got my battery life to greatly increase once disabled.
1) using dashclock extensions like FB and gmail
2) leaving google sync on in settings for the various google services
3) corporate email exchange servers
4) setting a long time variable for the phone to lock after the screen turns off (i did this to prevent putting in a pin to unlock but it kept the phone awake after the screen turned off)
5) live wall papers
There is also a known issue in the stock kernel that causes the phone to stay awake when it is supposed to go into sleep mode during extended periods of inactivity. This can be solved by using a custom kernel just as Franco r90 which has implemented patches in order to allow the phone to go into sleep to preserve battery. It is expected to be fixed in the next official OTA from google although this was also expected to be in 4.2.2 and was not fixed fully.
Same issue here. 4.2.2 stock kernel+rom, rooted
BBS shows "suspend_backoff" is at 45% no idea what's causing that.
Disabled pretty much all of the sync services but no improvement.
Interestingly right after the 4.2.2 update, the battery life was good.
Download this app and it will keep your applications from running in the background.
https://play.google.com/store/apps/...GwsMSwxLDMsImNvbS5vYXNpc2ZlbmcuZ3JlZW5pZnkiXQ..
Here's the forum for the application.
http://forum.xda-developers.com/showthread.php?t=2155737
scream4cheese said:
Download this app and it will keep your applications from running in the background.
https://play.google.com/store/apps/...GwsMSwxLDMsImNvbS5vYXNpc2ZlbmcuZ3JlZW5pZnkiXQ..
Here's the forum for the application.
http://forum.xda-developers.com/showthread.php?t=2155737
Click to expand...
Click to collapse
So far so good! totally eliminated the suspend_backoff wakeup
akiv said:
So far so good! totally eliminated the suspend_backoff wakeup
Click to expand...
Click to collapse
Update: Worked for a day now suspend_backoff is back. Happened after a recharge.
Could it be that afther the phone is charged something gets changed.
Edit: Runnig franco r90 kernel
I'm having the same problem with the Android OS draining lots of battery. When I reboot it sometimes helps but not consistently unfortunately.
Jester23 said:
I'm having the same problem with the Android OS draining lots of battery. When I reboot it sometimes helps but not consistently unfortunately.
Click to expand...
Click to collapse
I have narrowed my problem down to places where I use wifi transmitted by a lot of routers (Office wifi)
akiv said:
I have narrowed my problem down to places where I use wifi transmitted by a lot of routers (Office wifi)
Click to expand...
Click to collapse
I turn off my wifi when not home so I don't think that's the issue here.. I've tried removing a few apps like dash clock and my live wallpaper to see if it helps my issue. Will report back.
Sent from my Nexus 4 using Tapatalk 2
Google play services has something to do with the high usage. Yesterday I was near 20% usage today I disabled it and android os is at 7%. It only affects YouTube app for me, but the browser version is fine. I haven't seen any adverse affects other than maybe losing updates to the play store and ota updates which I don't care about because that's what xda and Roms are for. Now it may be placebo, but it also seems like the ui is smoother. Battery has improved greatly with sot of 3 hours with 57% left.
Hi,
how do you disable Google play services?
Try using the app greenify if your rooted.. It's been helping my battery life. Use it on maps and that will help. If maps is set as a system app, move it or just install banks minimal gapps so you can download from play store.
Sent from my Nexus 4 using xda app-developers app
Good day to you all,
Recently after a small android update (still having version 4.4.2) I noticed the battery was draining faster than I'm used to. Before that, it was consuming roughly 1% per hour in idle. This has changed now to 3-5% per hour. Looking at the battery info I noticed the Android system was the biggest batterysucker here. Not only that, there are even TWO Android systems shown and I began to think there's something wrong here.
http://forum.xda-developers.com/attachment.php?attachmentid=2908920&stc=1&d=1408796626
Also looking at the wakelocks shows that my phone is barely able to get into sleepmode.
http://forum.xda-developers.com/attachment.php?attachmentid=2908921&stc=1&d=1408796626
Before posting this thread I have literally tried every option to see if it could lessen the battery consumption:
- Disabled Google location reporting services
- Disabled GPS
- Disabled Google sync
- Disable Wifi when in Sleep mode
- I don't use Google Now so it's disabled
- Widen the Facebook refresh intervals to 4 hours
- Wiped the cache partition
None of the above worked and I started to think that the second Android system here might be the cause.
Should there be a second Android system consuming battery? What could be the problem here??
JohnnyGui said:
Good day to you all,
Recently after a small android update (still having version 4.4.2) I noticed the battery was draining faster than I'm used to. Before that, it was consuming roughly 1% per hour in idle. This has changed now to 3-5% per hour. Looking at the battery info I noticed the Android system was the biggest batterysucker here. Not only that, there are even TWO Android systems shown and I began to think there's something wrong here.
http://forum.xda-developers.com/attachment.php?attachmentid=2908920&stc=1&d=1408796626
Also looking at the wakelocks shows that my phone is barely able to get into sleepmode.
http://forum.xda-developers.com/attachment.php?attachmentid=2908921&stc=1&d=1408796626
Before posting this thread I have literally tried every option to see if it could lessen the battery consumption:
- Disabled Google location reporting services
- Disabled GPS
- Disabled Google sync
- Disable Wifi when in Sleep mode
- I don't use Google Now so it's disabled
- Widen the Facebook refresh intervals to 4 hours
- Wiped the cache partition
None of the above worked and I started to think that the second Android system here might be the cause.
Should there be a second Android system consuming battery? What could be the problem here??
Click to expand...
Click to collapse
Hi ,
is hard to tell with what you show here...get an app like Better Battery Stats
http://forum.xda-developers.com/showthread.php?t=1179809
Let it run for 3-4 hours and check it , the app will tell tell you what is going on....is the only way to find the real culprit
MAX 404 said:
Hi ,
is hard to tell with what you show here...get an app like Better Battery Stats
http://forum.xda-developers.com/showthread.php?t=1179809
Let it run for 3-4 hours and check it , the app will tell tell you what is going on....is the only way to find the real culprit
Click to expand...
Click to collapse
Will this app also show the needed info even when my phone isn't rooted? Because I'm really not into rooting it.
JohnnyGui said:
Will this app also show the needed info even when my phone isn't rooted? Because I'm really not into rooting it.
Click to expand...
Click to collapse
Hi mate
This is from the thread :
Q:Why installing BBS as a system app as everything works with root?
A: Starting with Kikat BBS has 3 modes: without root a limited mode provides a minimal set of stats. With root the set of stats is complete but some stats (other, partial wakelocks, processes) still use a workaround. Finally with the system app BBS is fully featured without any workaround.
For this cases root is good to have as it gives you a better access to all the process running , try without root and see what kind of info you get
If it's a conciliation, my android (currently on AOSP) is also running two android systems. Not exactly the same name (Android-System and Android-Besturingssysteem), but you get the idea. You mentioned quite a few things you've already tried, but what about existing widgets and or android apps you've installed? Usually (for me anyway) battery drain is an installed app not exactly behaving nicely.
MAX 404 said:
Hi mate
This is from the thread :
Q:Why installing BBS as a system app as everything works with root?
A: Starting with Kikat BBS has 3 modes: without root a limited mode provides a minimal set of stats. With root the set of stats is complete but some stats (other, partial wakelocks, processes) still use a workaround. Finally with the system app BBS is fully featured without any workaround.
For this cases root is good to have as it gives you a better access to all the process running , try without root and see what kind of info you get
Click to expand...
Click to collapse
So does this mean I'm not able to see the exact cause of my wakelocks since my phone isn't rooted?? I have installed Gsam Battery monitor from Google Play, hopefully it will give me (and you guys) the relevant information after keeping my phone on idle for a while.
@Skyrider: The weird thing is that in my case, it DOES display the same name twice. Doesn't that seem weird? I can't see any Android OS (besturingssysteem) displayed.
Also, if I have a battery heavy app, shouldn't it be displayed in the battery info screen as well? I only have the Weather widget and a News widget (NU.nl) on my homescreens. Haven't installed many apps except for Facebook and a few games that barely use background processes.
JohnnyGui said:
So does this mean I'm not able to see the exact cause of my wakelocks since my phone isn't rooted?? I have installed Gsam Battery monitor from Google Play, hopefully it will give me (and you guys) the relevant information after keeping my phone on idle for a while.
@Skyrider: The weird thing is that in my case, it DOES display the same name twice. Doesn't that seem weird? I can't see any Android OS (besturingssysteem) displayed.
Also, if I have a battery heavy app, shouldn't it be displayed in the battery info screen as well? I only have the Weather widget and a News widget (NU.nl) on my homescreens. Haven't installed many apps except for Facebook and a few games that barely use background processes.
Click to expand...
Click to collapse
Let us know what you find ....good luck
JohnnyGui said:
The weird thing is that in my case, it DOES display the same name twice. Doesn't that seem weird? I can't see any Android OS (besturingssysteem) displayed.
Also, if I have a battery heavy app, shouldn't it be displayed in the battery info screen as well? I only have the Weather widget and a News widget (NU.nl) on my homescreens. Haven't installed many apps except for Facebook and a few games that barely use background processes.
Click to expand...
Click to collapse
In my opinion, that's the problem with the default battery information. In my years of experience, it usually never knows the information that you need what exactly is braining the battery. If your battery is still being drained, I suggest to remove most of your apps. Only for a day orso. It should be enough to gather the information to know that at least one of your apps was the cause of it.
It's a pain to do it. But It always has helped me rather than relying on apps of which usually doesn't work out for me.
Also. Might be a good idea to alter your system language from Dutch to English and check the battery info again to search for the duplicate running system on google. You'd expect "Android System" being enough, but who knows that a different language might show a different name.
Ok, I don't have the slightest idea what happened but my battery duration is amazing now. After installing Gsam Battery Monitor and charging my phone to 100% I went to sleep and after 10 hours of standby I looked at my phone and it was on 93%. My phone doesn't consume more than 0,6-1,0% per hour now in the last 3 days!!
I haven't changed anything except choosing to use Wifi and mobile network for location services but not GPS. Weird thing is that I tried that option before without success.
I'm happy now
I'm still confused about the 2 Android systems in my battery info screen though. That might be a good idea to try @Skyrider but I do remember that "Android OS" was displayed differently in Dutch a while back. I'm guessing you have your phone language in Dutch as well since you're seeing "Android Besturingssysteem" on the battery info screen?
JohnnyGui said:
Ok, I don't have the slightest idea what happened but my battery duration is amazing now. After installing Gsam Battery Monitor and charging my phone to 100% I went to sleep and after 10 hours of standby I looked at my phone and it was on 93%. My phone doesn't consume more than 0,6-1,0% per hour in the last 3 days!!
I haven't changed anything except choosing to use Wifi and mobile network for location services but not GPS. Weird thing is that I did try that option before without success.
I'm happy now
I'm still confused about the 2 Android systems in my battery info screen though. That might be a good idea to try @Skyrider but I do remember that "Android OS" was displayed differently in Dutch a while back. I guess you're having your phone language in Dutch as well since you're seeing "Android Besturingssysteem" on the battery info screen?
Click to expand...
Click to collapse
Kudos for the battery mate.
JohnnyGui said:
I'm still confused about the 2 Android systems in my battery info screen though. That might be a good idea to try @Skyrider but I do remember that "Android OS" was displayed differently in Dutch a while back. I'm guessing you have your phone language in Dutch as well since you're seeing "Android Besturingssysteem" on the battery info screen?
Click to expand...
Click to collapse
Yea, I'm using the Dutch language. But I'm not using the stock ROM of the phone, so hence I am seeing different systems running in the background. But I'm glad the battery is semi-fixed.
Ok, so I changed my phone to English and behold, one of the "Android Systems" indeed changed to "Android OS"
I could have sworn it was like that when my phone was in Dutch.
Perhaps someone with the stock ROM in Dutch could check that out?
No idea if this helps but i thought might as well contribute what it sais on my phone
Edit : i have a very high idle battery drain so any advice is welcome btw
Sent from my GT-I9505 using XDA Free mobile app
Stefan0vic said:
No idea if this helps but i thought might as well contribute what it sais on my phone
Edit : i have a very high idle battery drain so any advice is welcome btw
Sent from my GT-I9505 using XDA Free mobile app
Click to expand...
Click to collapse
Thanks a lot for confirming this! I guess Android OS is indeed translated to "System" for Dutch S4's.
Have you tried my suggestions in the opening post?
Hello, there is a problem with the phone, the idle battery drain is too high, something is keeping it awake.
I've attached the screenshots of battery stats.
My mother is using the phone, so I don't have it with me all the time.
Any help is much appreciated!
adsubzero said:
Hello, there is a problem with the phone, the idle battery drain is too high, something is keeping it awake.
I've attached the screenshots of battery stats.
My mother is using the phone, so I don't have it with me all the time.
Any help is much appreciated!
Click to expand...
Click to collapse
Well Android system has lots of packages, check what packages are activated that includes ones in notification bar, GPS, NFC, Backup, Bluetooth, etc. They all absorb power at some point if they are always on it can drain the battery power. Also go to Settings / Autostart and check what packages are enabled to autostart.
hwandroid said:
Well Android system has lots of packages, check what packages are activated that includes ones in notification bar, GPS, NFC, Backup, Bluetooth, etc. They all absorb power at some point if they are always on it can drain the battery power. Also go to Settings / Autostart and check what packages are enabled to autostart.
Click to expand...
Click to collapse
This was with mobile data mostly disabled, and gps was not used heavily, as you can see from the screenshot.
I'll get back when I get more info.
Btw what I forgot to mention, the phone is brand new, like it was freshly set up a couple of days ago, and the baterry was bad since the first day.
She doesn't have a lot of apps, so it's really weird to see this battery drain.
What should I be looking for in the autostart settings?
adsubzero said:
This was with mobile data mostly disabled, and gps was not used heavily, as you can see from the screenshot.
I'll get back when I get more info.
Btw what I forgot to mention, the phone is brand new, like it was freshly set up a couple of days ago, and the baterry was bad since the first day.
She doesn't have a lot of apps, so it's really weird to see this battery drain.
What should I be looking for in the autostart settings?
Click to expand...
Click to collapse
It says Android system 34% that is too much, if you click on Android system it will list you the services and more info on power drain. For example on my device Android system does not go higher 15% usually, I have disabled autostart for the apps and services I don't really need to be running in background.
You can debloat the ROM by using xiaomi adb tools, no root needed. Then I believe battery will be much better. Search the thread in the forum
it's here, the second post
https://forum.xda-developers.com/mi-9t/how-to/debloating-mi-9t-t3958145
Also turn sync apps off automaticly.
hwandroid said:
It says Android system 34% that is too much, if you click on Android system it will list you the services and more info on power drain. For example on my device Android system does not go higher 15% usually, I have disabled autostart for the apps and services I don't really need to be running in background.
Click to expand...
Click to collapse
Yes, I've seen that it lists all the processes under Android system, but that didn't mean much, because there's a lot of them and it doesn't specify what drains the battery the most or any other details.
SUMMERBREEZE said:
You can debloat the ROM by using xiaomi adb tools, no root needed. Then I believe battery will be much better. Search the thread in the forum
it's here, the second post
https://forum.xda-developers.com/mi-9t/how-to/debloating-mi-9t-t3958145
Also turn sync apps off automaticly.
Click to expand...
Click to collapse
Perhaps the sync is on, and that might be what's causing the drain, I'll look into it.
Speaking of debloating, is there a fail safe of some kind? If something goes wrong, would a factory reset bring back the disabled/removed modules?
Thanks to both of you for the help.
I'll see if any of that fixes the issue.
adsubzero said:
Perhaps the sync is on, and that might be what's causing the drain, I'll look into it.
Speaking of debloating, is there a fail safe of some kind? If something goes wrong, would a factory reset bring back the disabled/removed modules?
Thanks to both of you for the help.
I'll see if any of that fixes the issue.
Click to expand...
Click to collapse
I think the program list only the apps that are safe to debloat and also it just disable so choose the one you don't like and leave the ones you are not sure about and if you want to know about them Google is you best friend
i have this issue as well and i think it appeared when i started using chinese vendor
adsubzero said:
Perhaps the sync is on, and that might be what's causing the drain, I'll look into it.
Speaking of debloating, is there a fail safe of some kind? If something goes wrong, would a factory reset bring back the disabled/removed modules?
Thanks to both of you for the help.
I'll see if any of that fixes the issue.
Click to expand...
Click to collapse
Factory reset would bring everything back of course but not necessary. The debloat app will bring everything back if you need. You can read many people wrote that it fixed their battery drain issue.
SUMMERBREEZE said:
Factory reset would bring everything back of course but not necessary. The debloat app will bring everything back if you need. You can read many people wrote that it fixed their battery drain issue.
Click to expand...
Click to collapse
Indeed, I believe that debloating fixed, or at least alleviated the issue.
Thanks to everyone for the help.
I haven't updated my Xiaomi Mi 9T yet to MIUI 11. And I don't have any problem with the battery on MIUI 10. Should I wait until this bug is patched to get the update ?
Hussein912 said:
I haven't updated my Xiaomi Mi 9T yet to MIUI 11. And I don't have any problem with the battery on MIUI 10. Should I wait until this bug is patched to get the update ?
Click to expand...
Click to collapse
It's hardly a bug you just have to manually configure the apps that you want to autostart in background.
Hussein912 said:
I haven't updated my Xiaomi Mi 9T yet to MIUI 11. And I don't have any problem with the battery on MIUI 10. Should I wait until this bug is patched to get the update ?
Click to expand...
Click to collapse
I would definately wait. Since MIUI 11 both my wifes and my own phone have massive drain issues. They work fine for days and all of a sudden they fully drain within a few hours without noticing any app really doing anything.
Mine is more or less fully debloated and my wifes is not but has only a few apps.
I think there is really something wrong with the update.
hwandroid said:
It's hardly a bug you just have to manually configure the apps that you want to autostart in background.
Click to expand...
Click to collapse
You know nothing. Is a major bug. Was present in miui 10 and is worse in miui 11.
So is debloat necessary again after updating to MIUI 11 (I disabled the apps, didn't remove them)?
Same finding here
(And maybe an ongoing solution)
hwandroid said:
It's hardly a bug you just have to manually configure the apps that you want to autostart in background.
Click to expand...
Click to collapse
How do I know which apps need to be autostart and which not? Example, I have sharing of my location set up with someone. How do I know if google maps needs to be autostarted, or it's handeled by some api?
It's a huge problem for me. It keeps happening and reappearing every few days.
d.a.v.o.r said:
How do I know which apps need to be autostart and which not? Example, I have sharing of my location set up with someone. How do I know if google maps needs to be autostarted, or it's handeled by some api?
It's a huge problem for me. It keeps happening and reappearing every few days.
Click to expand...
Click to collapse
Turn all off, its the same, wont break anything.
Any solutions? Happened for the first time for me too.