I've noticed something strange which seems to drain my battery faster when it happens.
Some apps that use sensors seem to leave the sensor active after closing the app itself (even with force close from app manager).
I've first noticed this problem with the app "GPS Essentials", then "GPS Status" the next day, they left the "Magnetic Field" sensor active after manually force closing them.
After a few hours, in Badass Battery Monitor, I could see that the Apps were eating about 75% of the battery, and when looking at the details, "GPS Essentials" was using about 45%, more than the kernel and android system), and it said that it had been using the "Magnetic Field" sensor for more than 5 hours, although the app was manually force closed about 20 minutes after I've started it.
That was in the stock ROM.
Since then, I've installed a custom ROM (CheckROM V2, so it's still based on Samsung's base ROM), and the problem is appearing again.
This time, I've had the same problem with Sygic that left the "Orientation" sensor active, and continued using it according to Badass Battery Monitor, even after force closing Sygic.
Did anyone else notice that or is it a problem with my phone?
Is there a solution besides rebooting every time after using any of these apps?
Thanks!
I've found a similar problem, and explanations on why it's happening, but it says that it appeared in Gingerbread but has been corrected in Honeycomb and ICS.
It does seem like the exact same problem with the same symptoms though, so I wonder if it really is gone...
Here is the page where I found the info :
http://fivasim.pcriot.com/androsensor.html
And here is a quote from that page :
Update: After many months of testing and debugging I haven't found a way to fix the battery issue for good. Perhaps I shouldn't... It's not really my issue but a general android problem (just google for "gingerbread battery drain"). And it happens with EVERY app that makes use of the sensors that are the root of the problem.
The battery leakage comes from android sensors that are not well supported by the kernel or the android OS. Most usually the accelerometer sensor causes the issue but sometimes the light sensor and the proximity sensor can cause this issue as well. Other sensors seem to have nothing to do with battery drain.
However I have found what's causing it and ways to `patch` over it (unfortunately, no way to permanently fix it).
Trying to invoke a sensor with such a problem, will cause the sensor to stay open even after the app is stoped and disposed of memory.
Another common issue is a conflict. Two apps register the same sensor, then one app unregisters but fails because the sensor is in use by the other app. The sensor stays in use by one of the two apps and this will remain even after both apps are killed.
In most cases there is a way to fix this:
- In the first case, you may just find which sensor is misbehaving (strange readings, very slow response or 'Failed to start' error etc.). Go to AndroSensor's settings and disable that sensor. Then reboot, run AndroSensor once and wait to see if the problem persists. Most usually the light and the proximity sensors are to blame for this issue. Sometimes the issue is caused only if both light and proximity are enabled, but disappears after disabling any of the two.
- If you don't have a misbehaving sensor then there is probably some conflict. Conflicts can be caused (usually in Gingerbread) when having auto-rotate (accelerometer use) or auto-brightness on.
Solution: Go to your device's display settings and disable auto-brightness and auto-rotation. Then reboot, run AndroSensor once and wait to see if the battery drain continues. If the problem persists then there is probably a conflict with some hidden/system service. Most usual is the conflict with SGS and SGS2 secret menu ( by dialling "*#0*#" on the dialer ). I have found no way to bypass this and it can only be solved by disabling the accelerometer and orientation sensors in AndroSensor, then reboot (orientation sensor makes seemless use of the accelerometer).
The only good thing about this, is that in HoneyComb and ICS the issue seems to have disappeared for good!
Am I really the only one with the problem?
Mithrandir007 said:
I've noticed something strange which seems to drain my battery faster when it happens.
Some apps that use sensors seem to leave the sensor active after closing the app itself (even with force close from app manager).
I've first noticed this problem with the app "GPS Essentials", then "GPS Status" the next day, they left the "Magnetic Field" sensor active after manually force closing them.
After a few hours, in Badass Battery Monitor, I could see that the Apps were eating about 75% of the battery, and when looking at the details, "GPS Essentials" was using about 45%, more than the kernel and android system), and it said that it had been using the "Magnetic Field" sensor for more than 5 hours, although the app was manually force closed about 20 minutes after I've started it.
That was in the stock ROM.
Since then, I've installed a custom ROM (CheckROM V2, so it's still based on Samsung's base ROM), and the problem is appearing again.
This time, I've had the same problem with Sygic that left the "Orientation" sensor active, and continued using it according to Badass Battery Monitor, even after force closing Sygic.
Did anyone else notice that or is it a problem with my phone?
Is there a solution besides rebooting every time after using any of these apps?
Thanks!
Click to expand...
Click to collapse
Does CPU Spy confirm that problem, showing awake instead of deep sleep?
chamonix said:
Does CPU Spy confirm that problem, showing awake instead of deep sleep?
Click to expand...
Click to collapse
It does seem to go to deep sleep, but I still see a big difference in battery life between when it happens (around 7-10%/hour), and after I reboot (~ 1%/hour).
Before I start applications using those sensors, the battery life is normal as well, so I don't think it's something else.
I've just made a few screenshots to show what's happening.
Last night, before going to bed, I've rebooted the phone, then started Sygic and AndroSensor, exited the apps, then manually force closed them to make sure.
Then I left the phone charging for the night.
This morning, I remove the phone from the charger, and Badass Battery Monitor starts from that point to calculate the battery drain from everything (so I'm sure neither Sygic nor AndroSensor have been running at all since I unplugged the phone).
Since then, a bit less than 2 hours have passed (I've barely used my phone during that period since I was getting ready then driving to work).
There was a 5% discharge (which is strangely not as much as I had yesterday, but still more than the usual 1%/hour when in standby) and we can clearly see what's eating the battery the most in Badass Battery Monitor.
The "Orientation", "Pressure", "Magnetic Field" and "Accelerometer" sensors have been running the whole time since it was unplugged.
What do you think, is this normal behavior?
I've now installed another custom ROM (Omega 8, with the new samsung firmware update), and the problem seems to remain..
If I'm the only one with the problem, I'm starting to think it might be something hardware (or an app I've installed every time maybe), since I've had the problem with every ROM I've installed...
Switching to another kernel didn't seem to help either.. I'm really starting to wonder if this is something I can fix.
Does no one else have the problem?
I think I've found the reason but now I wonder why no one else seems to have the problem (or maybe I'm the only one who actually cares ).
It looks like it's a battery usage reporting bug in the Samsung firmwares, not an actual drain.
Whenever you run an app which uses sensors (like GPS Status, AndroSensors, Sygic, ...), there is a good chance that when quitting the app, Android will not register the sensors as "stopped", even though they are not running anymore.
This means that the current battery life calculation takes those sensors into account as if they were still running, and the battery % drops faster than it should.
Here's a post from the creator of GPS Status, explaining the problem :
http://forum.xda-developers.com/showpost.php?p=23106668&postcount=491
There is also a small explanation from the author on the Google Play page for GPS Status, I'll quote :
"KNOWN FIRMWARE ISSUES (please do not report them):
- Samsung phones: Because of a firmware bug those phones may report extreme battery consumption for GPS Status (and for other programs using sensors) even if it is not running. This is harmless and no power is consumed! Just ignore it and let's hope that a future firmware upgrade will fix this."
So I'm still wondering if this is something we can fix, or if we have to wait for Samsung to correct that bug?
Mithrandir007 said:
I think I've found the reason but now I wonder why no one else seems to have the problem (or maybe I'm the only one who actually cares ).
Click to expand...
Click to collapse
Yes I care. Thanks very much for posting this. I've noticed exactly the same thing and it's been driving me crazy. Good to know it's just a false alarm. With ICS 4.0.4 coming to the Galaxy S2 soon, maybe it will be fix there.
Mithrandir007 said:
I think I've found the reason but now I wonder why no one else seems to have the problem (or maybe I'm the only one who actually cares ).
It looks like it's a battery usage reporting bug in the Samsung firmwares, not an actual drain.
Whenever you run an app which uses sensors (like GPS Status, AndroSensors, Sygic, ...), there is a good chance that when quitting the app, Android will not register the sensors as "stopped", even though they are not running anymore.
This means that the current battery life calculation takes those sensors into account as if they were still running, and the battery % drops faster than it should.
Here's a post from the creator of GPS Status, explaining the problem :
http://forum.xda-developers.com/showpost.php?p=23106668&postcount=491
There is also a small explanation from the author on the Google Play page for GPS Status, I'll quote :
"KNOWN FIRMWARE ISSUES (please do not report them):
- Samsung phones: Because of a firmware bug those phones may report extreme battery consumption for GPS Status (and for other programs using sensors) even if it is not running. This is harmless and no power is consumed! Just ignore it and let's hope that a future firmware upgrade will fix this."
So I'm still wondering if this is something we can fix, or if we have to wait for Samsung to correct that bug?
Click to expand...
Click to collapse
If this is really the problem that would be an deep in Android or between the hardware and android as it is the 'batteryinfo' service reporting sensors data.
Indeed, I don't think there is an easy fix for this one, unless someone has already worked on that part ((un)registration of sensors from the battery measurement service).
Hopefully it'll be fixed in a future version of the firmware, or in Jelly Bean.
XDA-Usr : maybe it'll be fixed in that version, indeed..
It is just a false alarm, although it still leads to inaccuracy of the battery level.
Mithrandir007 said:
I think I've found the reason but now I wonder why no one else seems to have the problem (or maybe I'm the only one who actually cares ).
It looks like it's a battery usage reporting bug in the Samsung firmwares, not an actual drain.
Whenever you run an app which uses sensors (like GPS Status, AndroSensors, Sygic, ...), there is a good chance that when quitting the app, Android will not register the sensors as "stopped", even though they are not running anymore.
This means that the current battery life calculation takes those sensors into account as if they were still running, and the battery % drops faster than it should.
Here's a post from the creator of GPS Status, explaining the problem :
http://forum.xda-developers.com/showpost.php?p=23106668&postcount=491
There is also a small explanation from the author on the Google Play page for GPS Status, I'll quote :
"KNOWN FIRMWARE ISSUES (please do not report them):
- Samsung phones: Because of a firmware bug those phones may report extreme battery consumption for GPS Status (and for other programs using sensors) even if it is not running. This is harmless and no power is consumed! Just ignore it and let's hope that a future firmware upgrade will fix this."
So I'm still wondering if this is something we can fix, or if we have to wait for Samsung to correct that bug?
Click to expand...
Click to collapse
Now 1 year has past since your original post. I'm still experiencing the same problem on my Galaxy Note 2. :silly:
luzok said:
Now 1 year has past since your original post. I'm still experiencing the same problem on my Galaxy Note 2. :silly:
Click to expand...
Click to collapse
On my Galaxy S4, the problem seems to be gone, so hopefully it'll be gone on your device as well once Samsung releases the 4.2.2 update.
Sent from my GT-I9500 using xda app-developers app
Hi, I'm running CM7.2 nightlies on an LG P999 (Canadian version of the G2x). Over the past few weeks, I've had issues where the screen will dim as it approaches the display timeout, but never turn off completely. This is intermittent, and I have yet to notice a consistent pattern. I've been searching to try to find a cause but with no luck so far. I am familiar with using BetterBatteryStats and thelike to track down issues with wakelocks and not going to sleep, but i don't know what to use/look for in this instance (ie how to identify apps that might block the screen from shutting down). Any suggestions?
Tv
tvisforme said:
Hi, I'm running CM7.2 nightlies on an LG P999 (Canadian version of the G2x). Over the past few weeks, I've had issues where the screen will dim as it approaches the display timeout, but never turn off completely. This is intermittent, and I have yet to notice a consistent pattern. I've been searching to try to find a cause but with no luck so far. I am familiar with using BetterBatteryStats and thelike to track down issues with wakelocks and not going to sleep, but i don't know what to use/look for in this instance (ie how to identify apps that might block the screen from shutting down). Any suggestions?
Tv
Click to expand...
Click to collapse
I would recommend using a logcat app to try and narrow down your problems, the recently featured | AIOlog - All in One Android Logger v0.3 is an excellent tool for this job, and if you would prefer to use an app for your phone try CatLog - Logcat Reader. Now as far as what to look for look for things in the logcat that refer to package's (I.E com.android.phone) and wake-locks or changes in power states. For example if you see that a package when in use is causing a wake-lock or keeps changing the power state (It may for example be preventing the display from completely shutting off because it thinks your still using the app and thus should keep the screen on), you know that may be the culprit. If you can narrow down a list of suspected apps carefully disable or uninstall them one at a time (Be very careful if it's a system app, make a backup first), and see if this fixes your problem. Let me know if you need any help troubleshooting !
Hi all,
I experience problems with kernel wakelock, named "s5p-ehci". In random moment it's getting seized my phone and the phone stops sleeping. It looks like:
all other kernel wakelocks and partial wakelocks take less than 1 min of activity, whereas s5p-ehci is active during hours. So, for instance, if s5p-ehci is active at night - I am loosing about 4% of charge per hour (phone deep sleep time is 0%).
Temporary solution is to reboot the device: so s5p-ehci's activity time is between seconds and minute, later it gets crazy again and is active constantly. I did not succeed to find some relation between it and applications or system processes.
I am not an Android developer, but since there is no other kernel for my device (Meizu MX2) I'm eager to TURN OFF this damned s5p-ehci... Please, tell me, how to do it:
either via build.prop or via linux command or changing some configs.
I have tried to use other firmware, wiped my phone and tried to work without my apps, but all in vain: so I still don't know, WHY this s5p-ehci is on Earth getting so active so long all of the sudden. It has nothing to do with USB, because my phone is not plugged with cable when it happens
Nafiganado said:
Hi all,
I experience problems with kernel wakelock, named "s5p-ehci". In random moment it's getting seized my phone and the phone stops sleeping. It looks like:
all other kernel wakelocks and partial wakelocks take less than 1 min of activity, whereas s5p-ehci is active during hours. So, for instance, if s5p-ehci is active at night - I am loosing about 4% of charge per hour (phone deep sleep time is 0%).
Temporary solution is to reboot the device: so s5p-ehci's activity time is between seconds and minute, later it gets crazy again and is active constantly. I did not succeed to find some relation between it and applications or system processes.
I am not an Android developer, but since there is no other kernel for my device (Meizu MX2) I'm eager to TURN OFF this damned s5p-ehci... Please, tell me, how to do it:
either via build.prop or via linux command or changing some configs.
I have tried to use other firmware, wiped my phone and tried to work without my apps, but all in vain: so I still don't know, WHY this s5p-ehci is on Earth getting so active so long all of the sudden. It has nothing to do with USB, because my phone is not plugged with cable when it happens
Click to expand...
Click to collapse
Since it persistent across different versions of the software, I'm wondering if it is not hardware related, like the USB is shorting out or messed up (yes, I read that it wasn't plugged in during the main issue, but doesn't mean it is not the root cause). Have you tried using https://play.google.com/store/apps/details?id=com.uzumapps.wakelockdetector to see if maybe it can narrow down the source of your issues?
es0tericcha0s said:
Since it persistent across different versions of the software, I'm wondering if it is not hardware related, like the USB is shorting out or messed up (yes, I read that it wasn't plugged in during the main issue, but doesn't mean it is not the root cause). Have you tried using https://play.google.com/store/apps/details?id=com.uzumapps.wakelockdetector to see if maybe it can narrow down the source of your issues?
Click to expand...
Click to collapse
Hi,
yes, i've used Wakelock detector app as well as its advanced colleague - BetterBatteryStats. So that's how I've found out about "s5p-ehci" wakelock. And I can see there is no other reason of phone insomnia, besides s5p-ehci.
All other apps and processes consume CPU moderately. When s5p-ehci activity is moderate - phone sleeps well. When it gets berserk and is active during several hours - phone does not sleep at all during whole this time (deep sleep is 0%), instead works on minimal frequency (300MHz), however, it's about 40% of battery draining per night.
If it's a hardware issue - I wonder who can help me with that investigation. Services do not deal with such cases, since there is no permanent problem signs. In my case the process can behave properly during a day. Then, all of a sudden, it's getting active and some its activity lasts hours! Then it's getting back to normal again. I've looked at kernel log and system log. There is a lot of various events happening there: something is going on, then device sent to sleep, then again something is going on, then wakeup, in various cases wakeup reasons are different, I was unable to find some relevant info... I would send this log to anyone who could help me to find source of the problem.
I've rolled back to Android 4.1 firmware and installed custom kernel.
Here situation is better, but what I have discovered:
phone seems not to detect when it's being plugged off from charger - no matter, USB cable from computer or wall socket wire. s5p-ehci does not go away and sucks off my battery. What only helps is manually resetting EHCI power: setting 0 in ehci_power file. As a result, something is reset, ehci power is on again, but this sucker goes away and after that everything is fine until next charge. But I need to find a root of the problem!
Going on investigation - too view info in Internet...