Related
There has been so much speculation on battery performance on the Sprint version that I wrote this logging program. This is the first stable Beta Version, Please PM me with bug reports (and as usual use at your own risk).
I know that it works for the CDMA version if someone wants to try it on the GSM version that would be great. Also Using the nuePower Battery driver for the Diamond give better resolution on the battery level.
What it logs:
1. a. Date and Time
b. Is AC Charger Attached
c. Battery Voltage
d. Battery Current (Discharge)
e. Battery Temperature
f. Battery level (%)
g. Pertinent System events:
a. Active Application
b. Speaker Phone Activity
c. Phone Radio Off/On
d. Phone Active Data Call (EVDO/1xRTT Activity)
e. No Phone Service
f. Phone Searching For Service
g. Bluetooth Power State On/off
h. Bluetooth Hands Free Audio in use (BT Headphones)
i. Bluetooth Hands Free Control in use (BT HF Headset)
j. WiFi Power On
k. WiFi Connected
l. Bluetooth Connections Count
m. Bluetooth Connections Descriptions
n. Cellular Connections Count
o. Cellular Connections Descriptions
p. Phone Call (Talking)
I have been unable to locate where HTC has hidden the charging current so if anyone could let me know that I would appreciate it.
Also, It dumps the data into a CSV file that you can pull into excel if you like. Please PM me with Bug Reports. There is a read.me version of the manual in the cab with a caution about logging to a storage card, please be aware of that if you plan on dumping your log to the storage card.
Version 0.2.3.130
New Features:
Support for Windows Mobile 5
Native QVGA Support (Properly Scales the Graph)
Can toggle between F and C for the Battery Temperature
Bug Fixes:
Properly deletes the downloaded file in the Benchmark test
Some additional Exception handling added
VERSION 0.2.1.105+ REQUIRES .NETCF 3.5!
I have uploaded a new version of the utility 0.1.1.58.
Includes the following Bug Fixes:
1) Now throws an update for every event. Previous Logic would drop events if another event occurred prior to the timed update.
2) Now allows the system to drop into Power mode D3 (sleep)
love the idea. will be reporting soon.
I have uploaded a new version with some reported bug fixes...
The following bug fixes are in place:
1) If multiple events occur while saving the log, a file in use exception would be thrown. It is now properly handled.
2) Visibility of the plots is now properly implemented.
After slugging through several long days of debugging and testing I have uploaded ver 0.2.1 of the battery log/diagnostics program.
What's new:
added mAH consumption counters for Data and Phone calls
Added a Battery Benchmark Module
Fixed a few miscellaneous bugs.
Benchmark Module details:
This module places the phone in a standard state (screen and backlight on, data connection active and Bluetooth radio on and discoverable). Then performs a 5 minute continuous data download, followed by a 20 minute telephone call. And saves a final report detailing power usage and AC adapter and charging times.
maybe my comments are silly but after those long discussions about battery draining in Raphael and diamond devices i find curious that nobody has said anything about this tool.
correct me if i'm wrong but this tool seems the best tool i've seen until know to check what the hell is draining our devices when in standby or calling or Data downloading or whatever.
i don't know too much about how it runs but i expect to learn it after some tests i will do.
I think that this tool will let me discover which running process is draining my battery, of course this tool won't tell it to me but after some testsenabling and disabling processes i will be able to see which one/s is/are the guilties.
I guess that the "ma" value that changes over time is per hour right? maybe PalladiumTD, could you explain me how to use this tool as if i would be a dummy, ( you can take out the "as if" if you want...
i don't understand the difference between "average current (ma)" and total usage (mah). The display doesn't change its contents when i switch between these options.
BTW it seems to run in my GSM device with unprotected Proven ROM 1.502. of course i can't install Nuepower driver.
is this tool trustable and accurate?
it doesn't seem to instantly react depending of what is running in the phone. it reacts after a while. ( of course i have it set to one second update)
and apparently it jumps from -78ma to -145ma and to -215ma without doing anything special. The Phone is just flashed with only battlog installed and running and it jumps between these values for no apparently reason.
Also i don't see any difference between having HDSP enabled or disabled (GPRS).
if i turn on Wifi, i see a big difference.
The benchmark test doesn't seem to run. it does not call and it does not download anything. (with wifi turned on)
fourcc said:
maybe my comments are silly but after those long discussions about battery draining in Raphael and diamond devices i find curious that nobody has said anything about this tool.
correct me if i'm wrong but this tool seems the best tool i've seen until know to check what the hell is draining our devices when in standby or calling or Data downloading or whatever.
i don't know too much about how it runs but i expect to learn it after some tests i will do.
I think that this tool will let me discover which running process is draining my battery, of course this tool won't tell it to me but after some testsenabling and disabling processes i will be able to see which one/s is/are the guilties.
I guess that the "ma" value that changes over time is per hour right? maybe PalladiumTD, could you explain me how to use this tool as if i would be a dummy, ( you can take out the "as if" if you want...
i don't understand the difference between "average current (ma)" and total usage (mah). The display doesn't change its contents when i switch between these options.
BTW it seems to run in my GSM device with unprotected Proven ROM 1.502. of course i can't install Nuepower driver.
is this tool trustable and accurate?
it doesn't seem to instantly react depending of what is running in the phone. it reacts after a while. ( of course i have it set to one second update)
and apparently it jumps from -78ma to -145ma and to -215ma without doing anything special. The Phone is just flashed with only battlog installed and running and it jumps between these values for no apparently reason.
Also i don't see any difference between having HDSP enabled or disabled (GPRS).
if i turn on Wifi, i see a big difference.
The benchmark test doesn't seem to run. it does not call and it does not download anything. (with wifi turned on)
Click to expand...
Click to collapse
I guess I really ought to write a manual?? Anyway the top for windows are live readings REPORTED by windows they are (left to right/top to bottom) Battery level, Battery Voltage, Battery Temperature, Current being drawn from the battery. These are realtime numbers.
The display average current and total Usage options on the update log menu apply to the Phone Current and Data Current boxes. (just below the 4 realtime boxes. These all total the current drawn during a voice or data call and allow you to see the average current drawn from the battery and the total power drawn from the battery (in mAH i.e. milliamp hours).
The fluctations in power draw may be real, I see them on the CDMA version when I am in a low signal area. the -78ma is close to what I have seen with the backlight off, the -120 - 150 ma when the backlight is on at 50%, the -215 may be an intermittent radio transmission (just speculation...)
With HDSP or GPRS enabled, you should only see a current draw when the radio is transmitting or receiving (i.e. when you are transfering data).
As far as accuracy, these numbers will be only as accurate as what the phone hardware is reporting. To keep it as generic as possible, I pull the values through the WinMo SystemStatus interface which makes it a bit sluggish in updating if other applications are running.
To run the test you must have .net Compact framework 3.5 loaded, it will not run without it. With that loaded, the benchmark should run (as it call only native WinMo functions). If you have .netCF3.5 loaded PM me and I'll see if we can troubleshoot..
One difference between the CDMA and GSM versions is that the CDMA hardware only reports current draw (as a positive number) I am guessing that The GSM phones report net current draw in the standard WinMo manner ,( i.e. negative for discharge, positive for charging and the number reported is the sum of the discharge and charging currents).
If there is interest (and someone could provide me with a log file from a GSM Phone while not connected to the charger, then when connected to the charger) I will make a GSM flavor of this utility, but will need some willing beta testers as I don't have a GSM Raphael...
Found via freewarepocketpc.net
Your Battlog utility is described on freewarepocketpc.net here: http://www.freewarepocketpc.net/ppc-download-battlog.html
Unfortunately, the download link points to Batti (another good utility) rather than Battlog.
I downloaded Battlog from your link here, and when trying to run Battlog the first time, I got the following error: BattLog.exe MissingMethodException Method not found: get_CellularSystemConnectedEvdo Microsoft.WindowsMobile.Status.SystemState. at System.Windows.Forms.Form.OnLoad(EventArgs e) at System.Windows.Forms.Form._SetVisibleNotify(Boolean fVis) at System.Windows.Forms.Control.set_Visible(Boolean value) at System.Windows.Forms.Application.Run(Form fm) at BatteryStatus.Program.Main() At the time when I ran this, my phone (PPC-6700 running WM5, .Net CF 2.0 & 3.5 installed) was connected to my computer via ActiveSync, the battery was fully charged, and the WiFi was turned on (and connected, I believe). the 1xRTT connection was not connected, as far as I know (no evdo on Cellular South in our area yet).
I'm no programmer (my expertise is in IT: remote access support, hardware, networking, etc.), but I hope this helps you. This looks like a worthwhile utility that has a lot of promise.
*edit*
I verified that I receive the same error if disconnected from ActiveSync, and after a soft reset. I also receive the error if WiFi is turned off and the 1xRTT connection is established.
Maybe I'm digging too deep; is this WM5 compatible, or WM6 only?
Sorry, I guess this could be a "bug report" and should have been PM'd to you. I didn't see that part until after I'd posted this.
*/edit*
TekServer said:
Your Battlog utility is described on freewarepocketpc.net here: http://www.freewarepocketpc.net/ppc-download-battlog.html
Unfortunately, the download link points to Batti (another good utility) rather than Battlog.
I downloaded Battlog from your link here, and when trying to run Battlog the first time, I got the following error: BattLog.exe MissingMethodException Method not found: get_CellularSystemConnectedEvdo Microsoft.WindowsMobile.Status.SystemState. at System.Windows.Forms.Form.OnLoad(EventArgs e) at System.Windows.Forms.Form._SetVisibleNotify(Boolean fVis) at System.Windows.Forms.Control.set_Visible(Boolean value) at System.Windows.Forms.Application.Run(Form fm) at BatteryStatus.Program.Main() At the time when I ran this, my phone (PPC-6700 running WM5, .Net CF 2.0 & 3.5 installed) was connected to my computer via ActiveSync, the battery was fully charged, and the WiFi was turned on (and connected, I believe). the 1xRTT connection was not connected, as far as I know (no evdo on Cellular South in our area yet).
I'm no programmer (my expertise is in IT: remote access support, hardware, networking, etc.), but I hope this helps you. This looks like a worthwhile utility that has a lot of promise.
Click to expand...
Click to collapse
Unfortunately, the many of the systemstate Classes that I use to detect the usage of the cellular radios aren't directly accessible from managed code in WM5. I will have see if I can code around it or remove some of the functionality when run on WM5. Thanks for the Info BTW.
You're welcome!
I know that I'm in a rapidly dwindling minority of WM5 users, but I love my PPC-6700, batter hog though it is, and I'm getting as much use as I can out of it before I choose a replacement from Cellular South's somewhat limited selection. (And I must admit, I am holding out hope that Google Android powered phones live up to their hype.)
Thank you for looking at this, and I'll be watching for a WM5 version!
Palladium, have you taken a look at the HTC-written TBattery app here?
http://forum.xda-developers.com/showthread.php?t=451646
It might help in your further development. Appreciate your work!
Da_G said:
Palladium, have you taken a look at the HTC-written TBattery app here?
http://forum.xda-developers.com/showthread.php?t=451646
It might help in your further development. Appreciate your work!
Click to expand...
Click to collapse
I will take a look at it (in detail that is) on the 7501A chipset it only reads battery level, temp and current. What is interesting is the from what I have read both the 75xx and 72xx chipsets use the PM7500 power management chip which is where those numbers should be coming from anyway. I'll see what I can learn from it... THANKS!!!
TekServer said:
You're welcome!
I know that I'm in a rapidly dwindling minority of WM5 users, but I love my PPC-6700, batter hog though it is, and I'm getting as much use as I can out of it before I choose a replacement from Cellular South's somewhat limited selection. (And I must admit, I am holding out hope that Google Android powered phones live up to their hype.)
Thank you for looking at this, and I'll be watching for a WM5 version!
Click to expand...
Click to collapse
I have just uploaded a new version. This version supports WinMo 5 as well as improved support for QVGA screens. there are a few other bug fixes and the ability to switch between deg F and C for the temperature display.
It works! Nice job; looks good.
A couple of points of constructive criticism (intended in the most positive and complimentary context!):
- I don't think the temperature is reporting correctly, at least on my Apache. It was reporting in C as 8.82 degrees, then when I switched to F it reported 16.94 degrees. As my phone is not currently in a freezer, I'm fairly certain this is off by a bit.
- The readme in the zip file is from the previous version.
I already love this program, and I've only scratched the surface. I've just started it logging and left it running; hopefully this will help me figure out which of the many apps I have is sucking my battery dry.
Thanks again!
TekServer said:
It works! Nice job; looks good.
A couple of points of constructive criticism (intended in the most positive and complimentary context!):
- I don't think the temperature is reporting correctly, at least on my Apache. It was reporting in C as 8.82 degrees, then when I switched to F it reported 16.94 degrees. As my phone is not currently in a freezer, I'm fairly certain this is off by a bit.
- The readme in the zip file is from the previous version.
I already love this program, and I've only scratched the surface. I've just started it logging and left it running; hopefully this will help me figure out which of the many apps I have is sucking my battery dry.
Thanks again!
Click to expand...
Click to collapse
Unfortunately this is a known bug, that has been low on my priority list. Basically the Standard WM Battery Dll report in degrees C*10, However, the Driver provided with the CDMA Touch Pro, reports in degrees C * 100. I just haven't gotten around to having the program check which platform it is running on and adjusting the calculation accordingly. So in the meantime your real temperature is the reported value * 10
on the readme, I'll re-upload with the updated Readme this afternoon.
Multiply by 10, got it. I can do that.
Thanks!
Thanks for this handy little program. I am used to the HTC WinMo battery drain devices but always like to see what might be aiding in the drainage.
HI Palladium,
Thumbs up for nice work.
However I'm not able to run the 0.2.3.130 release on my O2-Graphite w. WM 6. I get: "This app. requires a newer ver. of the microsoft.NET Compact Framework"
Hope this information is of any use to you
Regards
Steen
Sorry, My original post wasn't clear on this point, all versions from 2.1.105 forward require .NET CF 3.5. If you download it here Everything should work fine after you install that.
Palladium TD.....
Thanks to a post on another thread, I found your very nicely done program. I have some 'funny' out of the blue battery drains that your program may help me isolate.
I have v0.2.3.130 beta installed on my US ROM1.93 GSM Diamond. It installed fine, tracks current use and temp (/10) and logs the data. Very easy to pull into excel for analysis. I've only used it for a day now and do note the following issues (which may be me not executing correctly or the beta)
Voltage and temp graphs track exactly together and without a scale value
No response from the two Icons on the left (one looks like a help?)
I don't see any response to the "Display Total Usage mAh
Very excellent work, and if I can support, let me know.
Thanks
Hey peeps, well I've jsut got my phone replaced and got it back to how I like it working and loving every minute again lol
So my and swmbo have decided that we'd like to do a little walking\hiking and I was wondering if anyone is running any gps software for hillwalking?
Early days to pick one but would appreciate anyones advice.
have you tried this.. gps software
hi..i do a lot of running and have tried "sportypal " which is a free software for running, cycling, blading, walking, skiing or other workouts involving similar activities...it works for me.......just google ....for it...or try www.freewarepocketpc.net ....works fine on my hd
There's GPSed, which lets you record your route and attach photos at the points you took them (based on the time they were taken, so you can use a camera that doesn't geotag the pics if you want).
http://gpsed.com/
The basic version is free, but the pro version isn't.
Memory Map Pocket Navigator runs on the HD (main program installs on your PC and self-installs Pocket Nav to the phone, with the PC app syncing maps, overlays and routes to the device as required via USB). National maps (OSGB,USGS, etc.) and elevation data sold for most places and you can scan in your own maps. It's far from free, but kinda good.
http://www.memory-map.com/
The only issue on the HD is the footer menu bar icons are a strange color, but they're legible and work fine. As with most GPS apps you need to make sure you've got A-GPS turned off on the HD settings menu (quickGPS can stay on for updates, but A-GPS interferes with the NMEA data and the app continually drops out of lock).
I think you can also give Garmin a shot. If I remember you can get different map types.
I use GPS Cycle Computer v3 when I go hiking in the lakes, it has very good options for saving battery life. It was designed for the Diamond but works perfectly on the HD. Creates GPX & KLM files for importing into Google earth etc.
http://forum.xda-developers.com/showthread.php?t=424423
...and the winner is...
All these recommendations are sub-standard if compared to RunGPS (portable trainer): it is not cheap (you get what you pay for), but it does everything, including taking you back where you left, if you get so much into running or other outdoor activities, and you get lost. All this via voice guidance. Furthermore, the application constantly monitors your parameters as you run and reads these aloud to you, including total distance and burned calories! If you have a supported-heart-beat monitor device, this can be attached, too! Simply the best! You also have online-map support.
Sorry, I am not affiliated to this company, but this application is cool. No offence to other suggestions!
www.rungps.net
For the simplest GPS tracking program, I use NoniPlot. Fairly good for mapless gps tracking.
carola said:
All these recommendations are sub-standard if compared to RunGPS (portable trainer): it is not cheap (you get what you pay for), but it does everything, including taking you back where you left, if you get so much into running or other outdoor activities, and you get lost. All this via voice guidance. Furthermore, the application constantly monitors your parameters as you run and reads these aloud to you, including total distance and burned calories! If you have a supported-heart-beat monitor device, this can be attached, too! Simply the best! You also have online-map support.
Sorry, I am not affiliated to this company, but this application is cool. No offence to other suggestions!
www.rungps.net
Click to expand...
Click to collapse
i agree 100% . if you try rungps you'll never want to use any other software!
well I disagree with statements about rungps.. I found run unstable and overpriced, but each to their own..
I much prefer memory map, gps cycle computer and my favourite gpsvp.
I teach DofE award (and bel) in the UK, and memory map works exactlly as needed (for winding up lost pupils, by showing them exactly where they've just walked compared to where they should be walking). The Desktop version is great for showing what contours they are likely to come across and gives a great visual lesson in map interpretation.
GpsVp works great when I'm cycling overseas where OS maps aren't available, and gps cycle computer for generally logging my rides with the minimum of fuss.
fards said:
well I disagree with statements about rungps.. I found run unstable and overpriced, but each to their own..
I much prefer memory map, gps cycle computer and my favourite gpsvp.
I teach DofE award (and bel) in the UK, and memory map works exactlly as needed (for winding up lost pupils, by showing them exactly where they've just walked compared to where they should be walking). The Desktop version is great for showing what contours they are likely to come across and gives a great visual lesson in map interpretation.
GpsVp works great when I'm cycling overseas where OS maps aren't available, and gps cycle computer for generally logging my rides with the minimum of fuss.
Click to expand...
Click to collapse
I am sorry, but even looking at the interface (website), I feel as if installing this piece of software would result in my HD (OS) stating that this software was written for an earrlier version of the operating system.
I have both RunGPS and SportyPal (http://www.sportypal.com/) on my X1. Both are great. RunGPS has a few more features... but SportyPal is free.
how is the SportyPal in case of battery consumption? for example, if I want to use it fore 7 hours of recording my skiing or a long bike trip or a whole day hiking...
thanks
I've tried many apps like that but they either don't do what I want or are too complex and I cannot make them do what I want. I'm looking for an app which would:
- display tracks in gpx or kmz format
- let me choose a certain area and download maps for all/selected zoom levels (at least google maps, ideally ordnance survey) for offline use.
I can normally use google maps app which displays kmz (or kml, cannot remember) tracks and obviously lets you see maps, but it works only when I have signal and 9 times out of 10 I do hillwalking where there's no signal whatsoever.
Does anybody know an app which would have at least these 2 features?
paw3lk said:
I've tried many apps like that but they either don't do what I want or are too complex and I cannot make them do what I want. I'm looking for an app which would:
- display tracks in gpx or kmz format
- let me choose a certain area and download maps for all/selected zoom levels (at least google maps, ideally ordnance survey) for offline use.
I can normally use google maps app which displays kmz (or kml, cannot remember) tracks and obviously lets you see maps, but it works only when I have signal and 9 times out of 10 I do hillwalking where there's no signal whatsoever.
Does anybody know an app which would have at least these 2 features?
Click to expand...
Click to collapse
I haven't tried all the above mentioned gps software but with rungps you can do both.
you can create your own maps and place them in rungps folder for offline use
OK let me be a bit more specific - I want to be able to cache maps from the phone itself, so without a need to use a PC. If this software is able to do this please let me know how, because I've downloaded the trial of rungps and I cannot do any of these things.
Thanks
hm hm hm. i am testing sportypal right now. everything seems ok, but...have do I manage, that recording of my route does not stops everytime when the device turns into sleeping mode (which is automatic). is there any chance to have the device sleep (that helps battery) and still have active recording?
I was today on a 40 km bike trip and what I have found is point A (my home) and point B (place where I stopped the recording) and just a air line between them :-(
I have just one positive recording - when i used car charger and recorded some driving (the device did´t converted into sleep mode).
any advice?
I don't thing is possible to still record your rout while the device is in sleeping mode. It will lose the GPS signal.
During my holiday in spain, i used at the same time rungps and garmin:
- Garmin mobiel XT for its topo map
- rungps for tracking, and for hiking statistics (distance, average speed, ...)
RunGPS is more stable than garmin for reliable tracking.
Full charged battery of the HD (in airplane more) can reach around 5 hours. For bigger duration hikings, i had an external 3000mAh usb battery. During a 8 hours hiking, i plugged the battery after 4 hours (25%) and 4 hours later, my HD was fully charger and the external battery was not empty yet.
Why not give geocaching a go? they have a cool app that works well on the HD called GCzII.
Careful Geocachig is catching, the HD is ideal for it too!!
Is there a "Smart Protect" or similar available for the GalaxyS?. I do have the sim swap security enabled but would like to track the phone if it's lost or stolen. I have SP on my Omnia and it's been brilliant.
i use 'lookout mobile security' there is a free version and a paid version (or 30day free trial) and i think its awesome..... i can quickly go to the website mylookout.com if my phone is lost or stolen. i can switch gps on,,, track it down ,,, do a complete wipe of the phone,,, block the phone and loads more.. all from my pc..
and it doesnt drain my battery either (i keep mine active 24/7) cause i never know when im gunna get jumped by a load of chavs when im walking my doggie lol
Thanks ADazzle I installed lookout and it works well but...............
GPS needs to be turned on all the time (cell locate too inaccurate). GPS uses google maps so consumes data all day ? GPS consumes battery all day? or am I missing something
well i never have gps activated on my phone. but when i activated it thru mylookout.com it turned gps on and tracked it down quite well... there are a few 'gps fixes' out there that could improve the accuracy.... just put it in the search bar...
ive never looked this up as im happy with my gps accuracy
OK, thanks, maybe I was confusing GPS enabled with turned on.........you are correct......from Lookout FAQ
"Yes! Lookout makes use of the Android phone’s GPS receiver as efficiently as possible. When a locate is requested for an Android device, Lookout can remotely turn on the GPS while the locate is running and then turn it back off again (locates can run for a few minutes to get the best location results). This helps to conserve your phone’s battery life. Lookout only uses the GPS to get your location when you explicitly request it.
It should also be noted that if your GPS is enabled, that only means apps have the ability to use it. It does not mean it is being used continuously or that your location is constantly being tracked"
Where in the world are you? For some countries the built in security does just this plus remote lock/wipe.
Tehpriest, I'm in South Africa. I think I misunderstood 'Remote Tracker' as being activated only by a sim swap. Probably because of the way the description is written. Having read carefully once again as a result of your post, it appears it's a full function tracker.
I'll follow up and test it. 'Lookout' is working well and has back-up and a virus scanner too.
Tried it and web responds......."for legal reasons this service is not in service in some countries"
Checked with service provider and they confirm RT not enabled in RSA
I use Prey, it works by sim swap or activation text, never had reason to use it yet, but you can use it for multiple devices so have it on my iMac and my kids phone as well.
Please be patient with me guys this thread is work in progress...Many thanks to ahalford and with reading and learning from our great kernel devs here i will build this thread up as we go along
Right first up this thread is work in progress. Most of the info is from ahalford. He has been kind enough for me to use the information on his thread and share it here with you guys. Now to start with i will be sharing his info here and then i will be adding my own information as i go along with this thread as i am still learning and i feel i can add my own input here to...So enough of this and lets get going with the thread
What is wakelock and why it may cause battery drain:
Wakelocks or to be more precise partial wakelocks is a pattern (in fact a class) than helps devs to make sure that important pieces of their code do not get interrupted.
Basically the phone has (simplified, kernel devs don't shoot) three states:
1. awake with screen on
2. awake
3. sleeping (that's you phone favorite state)
The transitions are from (1) to (2) and finally from (2) to (3). Now as long as you use your phone it's in (1) and does not leave that state as long as you keep using it interactively. If you stop using it the phone is aiming to go to (3) as fast as possible.
And here's where wakelocks are important: as our phones as smartphones they tend to do background processing. Some of this processing is important like e.g. making a phone call, listening to music or synchronizing your contacts.
As the phone wants to go from (2) to (3) and on the other hand you don't want to hang up while you are in a call the app keeps hold of a wakelock to prevent that transition. When you hang up the partial wakelock gets release and here we go (the phone goes to sleep).
So partial wakelocks is a tool and it's not something that we should forbid for obvious reasons. Now there are cases when the design on an app is not real life proven (conditions of poor of no coverage) and the wakelocks have negative effects because they are held unnecessarily or for too long.
How can we identify it?
BetterBatteryStats app identifies these wakelocks and using your expertise or the once from our users here you can understand what happens and find a strategy to change that for the better.
Link for BetterBatteryStats:
XDA Thread
Playstore Link
New app as well other than BBS is Wakelock Detector..
Link: WakeLock Detector - XDA thread
With this app you can detect applications which are consuming much battery by checking wakelock history.
It simplifies BetterBatteryStats by concentrating more on wakelocks.
No any background services or system bootup events for gathering data.
Brief explanation, about where to look at the wakelocks:
Set your reference as "Since unplugged" in the second line.
Then, in the first line: "Other" - look at the "Awake" vs "Screen on". If it differs a lot, continue with a drill-down.
First line - check under "Partial Wakelocks" and "Kernel wakelocks".
"Menu" - "More" - "Raw kernel wakelocks"
For more help: "Menu" - "Help" - "Getting started" or "How to".
Brief History Lesson
The relationship between embedded system developers and the kernel community is known for being rough, at best. Kernel developers complain about low-quality work and a lack of contributions from the embedded side; the embedded developers, when they say anything at all, express frustrations that the kernel development process does not really keep their needs in mind. A current discussion involving developers from the Android project gives some insight into where this disconnect comes from.
Android, of course, is Google's platform for mobile telephones. The initial Android stack was developed behind closed doors; the code only made it out into the world when the first deployments were already in the works. The Android developers have done a lot of kernel work, but very little code has made made the journey into the mainline. The code which has been merged all went into the staging tree without a whole lot of initiative from the Android side. Now, though, Android developer Arve Hjønnevåg is making an effort to merge a piece of that project's infrastructure through the normal process. It is not proving to be an easy ride.
The most controversial bit of code is a feature known as "wakelocks." In Android-speak, a "wakelock" is a mechanism which can prevent the system from going into a low-power state. In brief, kernel code can set up a wakelock with something like this:
Code:
#include <linux/wakelock.h>
wake_lock_init(struct wakelock *lock, int type, const char *name);
The type value describes what kind of wakelock this is; name gives it a name which can be seen in /proc/wakelocks. There are two possibilities for the type: WAKE_LOCK_SUSPEND prevents the system from suspending, while WAKE_LOCK_IDLE prevents going into a low-power idle state which may increase response times. The API for acquiring and releasing these locks is:
Code:
void wake_lock(struct wake_lock *lock);
void wake_lock_timeout(struct wake_lock *lock, long timeout);
void wake_unlock(struct wake_lock *lock);
There is also a user-space interface. Writing a name to /sys/power/wake_lock establishes a lock with that name, which can then be written to /sys/power/wake_unlock to release the lock. The current patch set only allows suspend locks to be taken from user space.
This submission has not been received particularly well. It has, instead, drawn comments like this from Ben Herrenschmidt:
looks to me like some people hacked up some ad-hoc trick for their own local need without instead trying to figure out how to fit things with the existing infrastructure (or possibly propose changes to the existing infrastructure to fit their needs).
or this one from Pavel Machek:
Ok, I think that this wakelock stuff is in "can't be used properly" area on Rusty's scale of nasty interfaces.
There's no end of reasons to dislike this interface. Much of it duplicates the existing pm_qos (quality of service) API; it seems that pm_qos does not meet Android's needs, but it also seems that no effort was made to fix the problems. The scheme seems over-engineered when all that is really needed is a "do not suspend" flag - or, at most, a counter. The patches disable the existing /sys/power/state interface, which does not play well with wakelocks. There is no way to recover if a user-space process exits while holding a wakelock. The default behavior for the system is to suspend, even if a process is running; keeping a system awake may involve a chain of wakelocks obtained by various software components. And so on.
The end result is that this code will not make it into the mainline kernel. But it has been shipped on large numbers of G1 phones, with many more yet to go. So users of all those phones will be using out-of-tree code which will not be merged, at least not in anything like its current form. Any applications which depend on the wakelock sysfs interface will break if that interface is brought up to proper standards. It's a bit of a mess, but it is a very typical mess for the embedded systems community. Embedded developers operate under a set of constraints which makes proper kernel development hard. For example:
One of the core rules of kernel development is "post early and often." Code which is developed behind closed doors gets no feedback from the development community, so it can easily follow a blind path for a long time. But embedded system vendors rarely want to let the world know about what they are doing before the product is ready to ship; they hope, instead, to keep their competitors in the dark for as long as possible. So posting early is rarely seen as an option.
Another fundamental rule is "upstream first": code goes into the mainline before being shipped to customers. Once again, even if an embedded vendor wants to send code into the mainline, they rarely want to begin that process before the product ships. So embedded kernels are shipped containing out-of-tree code which almost certainly has a number of problems, unsupportable APIs, and more.
Kernel developers are expected to work with the goal of improving the kernel for everybody. Embedded developers, instead, are generally solving a highly-specific problem under tight time constraints. So they do not think about, for example, extending the existing quality-of-service API to meet their needs; instead, they bash out something which is quick, dirty, and not subject to upstream review.
One could argue that Google has the time, resources, and in-house kernel development knowledge to avoid all of these problems and do things right. Instead, we have been treated to a fairly classic example of how things can go wrong.
The good news is that Google developers are now engaging with the community and trying to get their code into the mainline. This process could well be long, and require a fair amount of adjustment on the Android side. Even if the idea of wakelocks as a way to prevent the system from suspending is accepted - which is far from certain - the interface will require significant changes. The associated "early suspend" API - essentially a notification mechanism for system state changes - will need to be generalized beyond the specific needs of the G1 phone. It could well be a lot of work.
But if that work gets done, the kernel will be much better placed to handle the power-management needs of handheld devices. That, in turn, can only benefit anybody else working on embedded Linux deployments. And, crucially, it will help the Android developers as they port their code to other devices with differing needs. As the number of Android-based phones grows, the cost of carrying out-of-tree code to support each of them will also grow. It would be far better to generalize that support and get it into the mainline, where it can be maintained and improved by the community.
Most embedded systems vendors, it seems, would be unwilling to do that work; they are too busy trying to put together their next product. So this sort of code tends to languish out of the mainline, and the quality of embedded Linux suffers accordingly. Perhaps this case will be different, though; maybe Google will put the resources into getting its specialized code into shape and merged into the mainline. That effort could help to establish Android as a solid, well-supported platform for mobile use, and that should be good for business. Your editor, ever the optimist, hopes that things will work out this way; it would be a good demonstration of how embedded community can work better with the kernel community, getting a better kernel in return.
Many thanks firstly to the following:
ahalford: for his awesome thread and his awesome work and a great guy for allowing me to share his work here...please click the thanks for him for all this
chamonix and his team: for his awesome must have app BBS and for all the work they put in it...without that app we would be lost..
Entropy512: guy is a human wikipedia...
To all the kernel devs and those who explained in detail regarding the wakelocks definitions and everything else..
Like i said above i merely put all the info together from ahalford...he is the genius behind this thread and please click here to check his thread out and thank him...I will be adding my own info here as well and make this thread in the long term as my thread to be proud of..
TYPICAL REASONS FOR WAKELOCKS & APP SUCKERS, KNOWN ISSUES:
*Any kind of messengers, social clients – like Skype, Facebook, Twitter, etc. Any of those, who want to be online, receive a push messages, sync every while. If it’s must to have them, disable it in accounts sync settings, and disable notifications in each app’s setting.
*“Energy savers” – Green Power, Timeriffic, etc. They mess with the system power policy, if you choose to enable/disable wi-fi, gps, data, Bluetooth, etc. Especially, Samsung’s one is known as problematic.
*“Soft-buttons”, so called “power button savers” – like ScreenOff & Lock and such. Related to previous group. Let the hardware do the job.
*Task killers - If it kills some services in the middle of their action, it will cause’em start all over again or even stuck, and eat your precious battery resources. If you have to use it (like in case with JB 4.1 memory leak issue, do it manually).
*Your sound settings – screen vibro & sounds on tap, haptic feedback – disable it.
*Media Scan – process, that will run after each fresh install & reboot. Typically takes about 10-15 minutes, runs on high CPU frequency. If stuck more than this, causes no Deep Sleep (can be seen in CPU Spy app) – you have an issue with Media Scan. It can stuck on large files directory – nothing to do here, unless you can reduce files number. Another case – problematic memory cluster, and there is only solution to back your data, format your storages, and start over.
*Startup - Check it – do you really need this entire long startup list? Throw some; it will only make the system act better.
*Accounts sync – again: Minimize your list. Drill down every account setting, Google especially: Picasa, Google Disc, G+, etc.
*App settings – always drill down your app settings – it may be some nasty hidden setting, that enables your app to be in constant action. No concrete advise, treat each app individually.
TIPS:
Always perform clean install! Backup your stuff – App2zip (free on market) app, Titanium, whatever – spend some time for formats and setting up your settings, you will only have profit on this.
Don’t judge your battery consumption right after new rom/kernel install. Especially in the first hour, while Media Scan is busy with scanning your storage. System needs some time to settle.
It is highly suggested, after you installed all apps and made your configurations, to reboot recovery and clean your cache & dalvick.
If you’re installing custom kernel and any .zip flashable files, don’t do it in the same time with rom flashing. Flash the rom, reboot system, let it settle, then reboot recovery again, flash your kernel/mods, let it settle again.
WI-FI sleep policy: leave it on “Always”. Note’s wi-fi chip consumes nearly zero energy, and it would be much healthier to leave it on.
WI-FI home network: if you’re on dynamic IP, set to maximum your DHCP lease time in router setting, and bind your device to the MAC address. Also, fix your WI-FI channel and frequency both on device and router.
Don’t mess with Fast Dormancy app, if you don’t have dormancy related wakelocks, or if you don’t know your cell operator dormancy setting! And, on JB 4.1 it’s sometimes more preferable to leave it on, than to deal with some weird wakelocks, that may appear. Another case – if your operator setting for dormancy is “off”, app won’t discover it, and, actually, you may enable it instead of disabling it.
PWL Bloodsucking apps that drain the battery due to constant wakelocks. (thanks to T.J.Bender)
A note when uninstalling Google built-ins: Google built-ins are often system packages, and deleting them can have unpredictable results. I highly recommend freezing them in Titanium Backup for several days to see how the phone runs before uninstalling them through there as well. Deleting system processes is inherently risky, and I assume no responsibility for your own decisions.
Facebook: Any social networking app will want to sync as often as it can, but you can overrule that by setting notification intervals. Thing is, Facebook doesn't respect those intervals, and wakes up the device for data exchanges pretty constantly (even though your news feed may only update every hour or so when you want it to). This app is no better than bloat, and should be treated as such when you clean house.
Alternative App: Friendcaster. It's as good a third-party Facebook client as you'll find on Android, and it only wakes up when you tell it to.
Gmail: A running theme here will be that if there's a non-Google equivalent to a Google app, you should probably kill the Google and download the alternative. Gmail is an alarm fiend, and one of the main offenders if you have an excessive SyncLoopWakeLock problem.
Alternative App: How many email clients are out there? I've had the best luck with the stock Email app, but K-9, Kaiten, MailDroid, even Enhanced Email and Touchdown for the power users are all great alternatives. Speaking of which...
Whatever email client you're using: Email clients will always be high up on the list of alarms, and that's by their nature. Keep an eye with raw network stats on how long they're connected for, and don't be afraid to experiment. I tried K-9, Kaiten and MailDroid before settling back on the stock Email app as the one that gave me the best balance of battery life and necessary features.
Alternative Apps: Download and try out different clients until you find the one that works for you. Nothing ventured, nothing gained, right?
Google Latitude: Latitude is a tracking service. As such, it tracks you. Beyond the creepiness aspect of that, it holds your phone awake pretty often while doing so. Kill it. Kill it with fire.
Alternative App: Personally, I'm not into the whole stalking thing, but I've heard that Glympse works quite well.
Google Maps: Colossal waste of space and battery. You can do better. An important note on Google Maps: this app will still wake your device up even after being frozen in Titanium Backup. I don't know how it happens, but it does. To truly solve the alarms from Google Maps, you have no choice but to uninstall it. Do so at your own risk.
Alternative Apps: I'm a fan of Waze for navigation and MapQuest for a Google Maps-ish browseable interface. OSMAnd is also a great alternative, but it uses a ton of internal memory because of its offline nature.
Google Play Music & Movies: Updates itself constantly and wakelocks. Even if you freeze it, it still somehow manages to tell you that there's an update available. It's the Google zombie.
Alternative App: There are literally 100+ music and/or movie players out there. I'm sure you can find one that works for you. I'm a big fan of RocketPlayer for music, and I just use the stock video app more often than not.
JuiceDefender: What's that you say? JD sets off tons of alarms and holds the device awake for more time than I'd care to discuss, largely because of its data control settings. More harm than good, in my opinion.
Alternative Apps: JuiceDefender's main goal in life is to minimize the amount of time your device is held awake. Therefore, if you've just gone through all this to clear out wakelocks, do you really need another wakelock-prone app to do what you've already done?
Skype: Occasionally, after a call, Skype will wakelock. This is not designed to happen, and is more a glitch in the app than a forced sync. Force-stopping the app and clearing its cache have solved it for me on the rare occasion that I've seen the wakelock occur.
Alternative Apps: No idea. I don't personally consider this a "replace" situation.
World Weather Clock Widget: Do you have this on your phone? Get rid of it. I installed it as an alternative to SiMi Clock Widget, and while it certainly looks pretty, it ignored my "Update every 3 hours" and tried to update 275 times in that 3 hour window. This drove AlarmManager, GSYNC_ACONN, and NetworkStats off the deep end, and left me at 82% deep sleep with 6% of my battery gone in 3 hours. Kill it. Kill it with flaming nuclear waste.
Alternative Apps: I liked SiMi Clock and wanted to try something new, basically. I'm back to SiMi, but there are literally hundreds of clock widgets out there.
Wakelocks - XDA Developers Wiki - Worth the read trust me
Wakelocks Definition
AlarmManager:
Speaking Name: Alarm Manager
Rationale: AlarmManager provides access to the system alarm services. These allow you to schedule an application to be run at some point in the future. When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running. Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted. The Alarm Manager holds a CPU wake lock as long as the alarm receiver's onReceive() method is executing. This guarantees that the phone will not sleep until you have finished handling the broadcast. Once onReceive() returns, the Alarm Manager releases this wake lock. This means that the phone will in some cases sleep as soon as your onReceive() method completes.
Know actions: AlarmManager itself is not generating partial wakelocks but the applications (intents) that were set to be called when an alarm goes off do. Alarms can be listed through the menu "Actions - Alarms".
AlarmManager is a universal process that MANY apps use to update time, push you notifications, etc. In most cases, it is a necessity; in other cases, you should really check it out and disable/uninstall things that have invoked it too much.
AudioOut_1
Speaking Name: AudioOut_1
Rationale: AudioOut is used to play notification and system sounds.
Know actions: From the home screen... Menu -> Sounds -> uncheck "Touch Sounds", uncheck "Screen lock Sounds"
Known conditions of occurence: Each time the screen is touched or locked.
Definition: "AudioOut_1" is a Wakelock that is basically a kernel process that funnels data from audio apps to the audio hardware. It's what processes audio from say, Pandora or Slacker Radio, and passes it to the phone's audio hardware.
AudioOut_3
User Experience
But for those of you that have lockscreen sounds on, touch screen sounds on and dialpad touch tones on then you will have massive wakelock. I had this same problem with my S2.
Only way to beat this. Settings - Sound - system and untick the first 3 options. Reboot and charge your phone and then check the difference. You will see that the wakelock is not as high as it use to be.
More info regarding this you can find here
ConnectivityService
Speaking Name: ConnectivityService
Rationale: Service responsible for tracking data connection / apn, establish and maintain connections. This wakelock is held during transition between data connections.
Know actions: May be conditioned by using a different radio/modem or bad coverage, may be reduced by forcing 2G.
deleted_wake_locks
Speaking Name: deleted_wake_locks
Rationale: In the API available to android drivers it is advised to call wake_lock_destroy before freeing the memory of the wakelock struct that they created. This is done above all on shutdown, but also in a few situations where a driver is unloaded dynamically from the kernel. Whenever it happens, the destroyed wakelocks disappear from the list but their stats are added up to this pseudo-wakelock to the deleted_wake_locks. This allows knowing that a set of old wakelocks had a combined set of stats that this entry shows. The stats of this entry do not increase unless additional real wakelocks that have non-zero stats are destroyed.
Know actions: Since this is merely an entry that combines the activity of all the kernel wake locks that no longer exist, there's nothing that can be directly done to reduce this entry. The best course of action is to identify the wake locks that generate activity and that are later deleted, before that happens and they end up showing in a combined way on this entry.
Known conditions of occurence:
The Wifi driver is one known source for kernel wakelocks that are destroyed whenever the driver is unloaded (when Wifi is disabled manually or as part of the turn-off policy). Wakelocks such as wlan_rx_wake and wlan_wake, when the driver is unloaded, will no longer show up in the list and their stats be added to the deleted_wake_lock previous values.
GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservi ce.AndroidEndpoint
Speaking Name: AndroidEndpoint
Rationale: This wakelock has been found to occur under certain non reproducible conditions, showing high wakelock counts and in certain cases high wake times. As the reasons are not exactly known there is no garanty that this wakelock does not occur for other yet unknown reasons.
Know actions: In one case (see ref) this wakelock was successfully removed by changing the proxy / re-creating an APN definition and leaving the proxy blank for that APN. The "faulty" proxy was predefined for the provider Orange but it is not excluded that proxies from other providers show the same effect.
Known conditions of occurence:
Conditions are unclear, to be confirmed
network-location
Speaking Name: Network Location
Rationale: The network location service is responsible for providing coarse grained location information to requesting applications.
The frequency of updates (and of wakelocks) is related to the precision requested by the application (max. time between updates, precision in meters).
Examples of app requesting coarse grained location: weather widgets, latitude, most social tools, google+
Know actions: Actions to reduce wakelocks:
• Find the responsible app: look for all network-location wakelocks and check for the responsible apps on the second line of the list
• Check the settings of the app to see if the precision can be changed
• Use the benefits of Wifi based location (stable location minimizing the update frequencies)
• Look for alternative apps with a better design
Known conditions of occurence: Poorly designed apps with too high requirements on precision will drive the Network Location Service up.
Unstable network conditions (frequent handovers between towers) may trigger location updates.
In some cases updating the radio/modem has effect on the network location: the location is based on the tower information delivered by the RIL.
Related wakelocks: LocationManagerService, NetworkLocationLocator, WifiService, GpsLocationProvider, network-location-cell-update
PowerManagerService
Speaking Name: PowerManagerService
Rationale: This kernel wakelock is a placeholder for all partial wakelocks being held in userland.
Know actions: Use "Partial Wakelocks" to drill down the applications / services causing wakelocks.
Known conditions of occurence: Some devices show userland wakelocks as a total named PowerManagerService
suspend_backoff
Speaking Name: suspend_backoff
Rationale: suspend_backoff is triggered whenever there's a rapid succession of sleep-wakeup-sleep transitions in a short period of time (10 occurrences within x ms IIRC). When that happens, SB makes sure the device is continuously awake for a bit instead of alternating a lot. The KWL count indicator could give a hint about the source of those continuous wakes, but not a definite answer because it doesn't show their time distribution.
Known conditions of occurence: Read here on how to tackle this wakelock and read here to
svnet
Speaking Name: svnet-dormancy / multipdp from the man himself(those are synonyms, depending on android version)
Rationale: svnet-dormancy is a kernel wakelock related to cell data transfers - Fast dormancy or not, you get a 6 second wakelock any time the radio transfers data..In other words, the phone stays awake for 6 seconds for every incoming data packet which effectively prevents it from sleeping.
Know actions: Change the duration of the wakelock (use at your own risk). Reduce the wakelock by reducing the amount / number of data traffic requests
Known conditions of occurence: Caused by data traffic
Sync:
Speaking Name: Account Sync Service
Rationale: The sync service is responsible for syncing all the accounts from "Settings" - "accounts and sync". A wakelock is held while the sync process is running.
The more items are getting synced and the more often the sync occurs the higher the wakelock time will be.
Potentially the wakelock time is prone to raise in case of bad data connectivity.
Examples of accounts are: twitter, google+, linkedin, google mail
Know actions: Actions to reduce wakelocks:
• Remove any unwanted accounts
• Check the settings and remove any unwated options (contact sync)
• Check the frequency of the sync and see if you really need it as defined
Known conditions of occurence: Under bad data connectivity conditions, with poorly designed Sync providers
Related wakelocks: none
References: A known bug related to gmail:Email app wakelock
SyncLoopWakeLock
Speaking Name: SyncLoopWakeLock (Account Sync)
Rationale: SyncLoopWakeLock is the wakelock used by the Android SyncManager (android.content.SyncManager) and was introduced starting in 4.01. The sync service is responsible for syncing all the accounts from "Settings" - "accounts and sync". A wakelock is held while the sync process is running.
The more items are getting synced and the more often the sync occurs the higher the wakelock time will be.
Potentially the wakelock time is prone to raise in case of bad data connectivity.
Examples of accounts are: twitter, google+, linkedin, google mail
Know actions: Actions to reduce wakelocks:
Remove any unwanted accounts
Check the settings and remove any unwated options (contact sync)
Check the frequency of the sync and see if you really need it as defined
Known conditions of occurence: This wakelock is held by the SyncManager while handling sync actions (method handle()). Previously this wakelock was known as sync. Under bad data connectivity conditions, with poorly designed Sync providers this wakelock is held longer.
Related wakelocks: sync https://github.com/asksven/BetterBatteryStats-Knowledge-Base/wiki/sync
Which stated as above both similar and can cause same drainage if not tackled properly.
com.android.phone(under alarms,BBS)
Way to beat it:
1. Choose SETTINGS - WIRELESS CONTROLS - MOBILE NETWORKS -
2. uncheck everything unnecesary ie. "Data Roaming" and "Enable always-on mobile" -
3. Change setting on "Use only 2G networks", wait 10 seconds, then change it back.
4. Now try NETWORK OPERATORS. Here you will get a network error (Not the "com.android.phone" error)
Just continue and you'll get your wanted network.
The reason for this behavior is that android uses a new type of network and supports old ones.
Some countries dosen't use this new network.
When your android phone makes a handshake in these countries it'll accept without error, but when it returns to the new type it won't connect.
This must be a bug and you can solve / workaround this by doing the above
Remember: there is no app, that behaves in same way on different system. While it can drain on CM, it can be rock solid on the TW, and vice-versa. So, don't take those examples too serious and don't run to uninstall your apps just for preventive maintenance. Act per need. Anyways..I already mentioned a few things in the above posts but here is a few more added to what i said above and few new ones..
So, as listed above, our Top Chart leader is Media Scan:
- Media Scan – process, that will run after each fresh install & reboot. Typically takes about 10-15 minutes, runs on high CPU frequency. If stuck more than this, causes no Deep Sleep (can be seen in CPU Spy app) – you have an issue with Media Scan. It can stuck on large files directory – nothing to do here, unless you can reduce files number. Another case – problematic memory cluster, and there is only solution to back up your data, format your storages, and start over.
Stopping the process won't help much, as on next reboot it will resume. Suggestion - charge the battery to 100% before Media Scan starts to rebel, and let it finish.
Another case - stopping any download (browser, market) in the middle. Media scan can possibly stuck until next reboot.
- Media Scan stuck:
You probably have some corrupted files, on which it stuck. Backup, start to restore to the step it was OK, to find the culprit
Folder with many files - likely to stuck or to spend a lots of time to scan it. Do the math. If you have to have this folder (likely to be a cache folder) - disable your media scan.
I/O scheduler - CFQ sometimes being reported as taking longer time to media scan to complete. Try NOOP.
And, of course, sometimes it won't work without formatting emmc and starting over.
- Google apps/services:
- Google Plus - there were cases, when this app, with auto-sync left, was just hanging in the memory and caused drain.
- Google Currents - depends on system, but there were also cases, when the service left active on CPU resource after it was even completely killed in task manager.
- Google Location service - if you choose to update your location by GPS only, expect wakelock, when GPS can't lock on a stellite. Second case - if location being updated from internet, and your mobile data is in bad state (poor signal, etc.). And, of course, it depends on apps, who require location update, and there are a lot of such. Whenever you don't need it - disable your locations service in Settings.
- Google Maps - brightest example of wakelock, caused by requiring your location. If you want to run Google Maps, disable the Location services, and disable Maps in start-up.
- "The Holy Trinity" - Skype, Facebook, WhatsApp. Just be sure to kill the app and & services, when you don't need it.
- Same applies for a clients of a kind: Viber, Twitter, etc.
- “Energy savers” – Green Power, Timeriffic, etc. They mess with the system power policy, if you choose to enable/disable wi-fi, gps, data, Bluetooth, etc. Especially, Samsung’s one (power policy) is known as problematic.
- “Soft-buttons”, so called “power button savers” – like ScreenOff & Lock and such. Related to previous group. Let the hardware do the job.
- Task killers - If it kills some services in the middle of their action, it will cause’em start all over again or even stuck, and eat your precious battery resources. If you have to use it (like in case with JB 4.1 memory leak issue, do it manually).
-Sopcast - very likely to stuck in memory, and to cause multi_pdp wakelock. Worse, it may keep consuming your precious data. Suggestion: reboot right after you ended using Sopcast.
- *new* - Weak network signal. Pretty understable, but still - weak network signal can cause some weird wakelocks. Especially, when you're on autosync on with mobile data, and the signal is weak, you will get "*sync*com.google.android.apps...." wakleock, "genie.widget" is you're syncing "new&weather" thing, RILJ is very likely, etc.
LOL ! Nice one Goku
Mr Hofs said:
LOL ! Nice one Goku
Click to expand...
Click to collapse
thanks Hoff more to come mate:good:
Nice thread kakaroth , this should prevent alot of questions about wakelocks :good:
Shan89 said:
Nice thread kakaroth , this should prevent alot of questions about wakelocks :good:
Click to expand...
Click to collapse
More to come.
Sent from my HTC One X using xda premium
How about the AudioOut_4 wakelock(?
Sent from something that's BETTER THAN YOURS
XxVcVxX said:
How about the AudioOut_4 wakelock(?
Sent from something that's BETTER THAN YOURS
Click to expand...
Click to collapse
same as audioout_1 and audioout_3
EDIT:added a bit more info regarding those 2 wakelocks and provided another link as well if anyone needs to do more reading
http://forum.xda-developers.com/showthread.php?t=1629346
Goku80 said:
same as audioout_1 and audioout_3
EDIT:added a bit more info regarding those 2 wakelocks and provided another link as well if anyone needs to do more reading
http://forum.xda-developers.com/showthread.php?t=1629346
Click to expand...
Click to collapse
AudioOut_4 seems to be different. At least on my phone, it occurs when I leave a game, say NFSMW without actually killing it then turning the screen off.
Sent from something that's BETTER THAN YOURS
XxVcVxX said:
AudioOut_4 seems to be different. At least on my phone, it occurs when I leave a game, say NFSMW without actually killing it then turning the screen off.
Sent from something that's BETTER THAN YOURS
Click to expand...
Click to collapse
So just kill he game before you turn the screen off. Give me time and will add more.
Sent from my HTC One X using xda premium
XxVcVxX said:
AudioOut_4 seems to be different. At least on my phone, it occurs when I leave a game, say NFSMW without actually killing it then turning the screen off.
Sent from something that's BETTER THAN YOURS
Click to expand...
Click to collapse
Right been diving into more regarding this audioout_4 wakelock thing and from reading around the forums here and from searching google it is exactly as i stated from the start..
audio related as it states from its name and you talking about the game..now when you are turning the screen off the game is still running in the background...so of course that will drain your battery and will cause you the massive wakelock..
similar to one that i had...i was watching a video in the browser....i just pressed the home button and left the phone and screen was off..woke up the next day and the battery was flat..why? because in the background the video on the website i was checking out was still running...hence why the massive drain in battery..that is similar to your situation...
solution: always disable or kill what you are playing or watching or listening to on your phone
EDIT: check post 4 for more info
You deserve all my thanks for today
Sent from my HTC One X using xda premium
drali500 said:
You deserve all my thanks for today
Sent from my HTC One X using xda premium
Click to expand...
Click to collapse
Thanks but why
Sent from my HTC One X using xda premium
Goku80 said:
Thanks but why
Sent from my HTC One X using xda premium
Click to expand...
Click to collapse
It very good thread I searched for something like this many times and more you manged to sum it all for us... Thanks again
Sent from my HTC One X using xda premium
powerManagerService
Suspend_backoff
Added to post 3. plus added a bit more info as well in few of the wakelocks..more to come
guys if you want to post here your wakelocks and need help feel free to do so...will try my best to help out and see what is the problem..that way i can learn more and help you guys out in the process
Hey Goku80,
Very, very nice work man!
I do have a wakelock for your list, it's the st_wake_lock, like in this screenshot:
{
"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"
}
I already googled it, but couldn't find any useful information.
Could be it's only the name for a set of wakelocks together, I don't know really.
What can you tel me about it, and how to avoid it?
Love your thread man, very good work! :thumbup::beer:
PS: partial wakelocks look like this:
rkuijpers said:
Hey Goku80,
Very, very nice work man!
I do have a wakelock for your list, it's the st_wake_lock, like in this screenshot:
I already googled it, but couldn't find any useful information.
Could be it's only the name for a set of wakelocks together, I don't know really.
What can you tel me about it, and how to avoid it?
Love your thread man, very good work! :thumbup::beer:
PS: partial wakelocks look like this:
Click to expand...
Click to collapse
by any chance do you have volume keys set to wake the phone up?
Anyways to be honest i would not worry about what you have in the kernel wakelocks...mainly be worried what you have the highest in partial wakelocks..and from your second image so far so good....keep me posted when the battery goes to its lowest...
EDIT: just to add. Ignore "Kernel Wackelocks", cause its from the system itself, like connection & other stuff.
Unlike many modern versions of Android, I can find no three-tiered setting for GPS accuracy. I'm looking to set it to "Device Only" but it's either off or on, with a few additional location options but nothing more for GPS.
I'm using lineage 17, the second to last update, on a Samsung Tab 4 and I just want to restrict the device to the system GPS app GPS I've set (but it keeps drifting).
neocortex08 said:
Unlike many modern versions of Android, I can find no three-tiered setting for GPS accuracy. I'm looking to set it to "Device Only" but it's either off or on, with a few additional location options but nothing more for GPS.
I'm using lineage 17, the second to last update, on a Samsung Tab 4 and I just want to restrict the device to the system GPS app GPS I've set (but it keeps drifting).
Click to expand...
Click to collapse
I don't see any android 10 distro with the old settings (high precision/ device only/energy saving)
GApps installed?
kurtn said:
I don't see any android 10 distro with the old settings (high precision/ device only/energy saving)
GApps installed?
Click to expand...
Click to collapse
Yes, Gapps installed and working well (version for Android 10, nano),but I'm not sure google settings would change what would be in the device system settings. I guess I'm just looking for some way to force that missing setting without having to resort to tin foil around the device.
neocortex08 said:
Yes, Gapps installed and working well (version for Android 10, nano),but I'm not sure google settings would change what would be in the device system settings. I guess I'm just looking for some way to force that missing setting without having to reset to tin foil around the device.
Click to expand...
Click to collapse
No matter what settings you change, Google knows your location.
kurtn said:
No matter what settings you change, Google knows your location.
Click to expand...
Click to collapse
I'm not tin-foil-hat-concerned with Google knowing my location; I'm referring to the systemized GPS app I installed to be able to determine the location I set. Which it can currently, and can usually continue to do when I can set the device to take GPS from "device only". In this case it shows me on the map "rubberbanding" between my actual location and the location I've set about 100 feet away. This is because the OS is allowing the device to try and locate its own location.
neocortex08 said:
I'm not tin-foil-hat-concerned with Google knowing my location; I'm referring to the systemized GPS app I installed to be able to determine the location I set. Which it can currently, and can usually continue to do when I can set the device to take GPS from "device only". In this case it shows me on the map "rubberbanding" between my actual location and the location I've set about 100 feet away. This is because the OS is allowing the device to try and locate its own location.
Click to expand...
Click to collapse
Oh, location spoofing
https://f-droid.org/app/com.wesaphzt.privatelocation
GPS drains battery
With previous (before 17) it was possible to set the location service to be switched on, but only use cell data.
When I use the gps device it drains my battery much faster.
Therefore: How can I leave the location service on, but DO NOT USE the gps device in LOS 17 ????
Thanks in advance
Chris
Chris56 said:
How can I leave the location service on, but DO NOT USE the gps device in LOS 17 ????
Click to expand...
Click to collapse
+1
luckysoul777 said:
+1
Click to expand...
Click to collapse
Do you try to spoof your location? And why? What location providers do you have? GApps?
I guess your reply refers to my question.
Maybe I was not clear.
With former LOS versions I was able to explicitly choose whether to use the (battery draining) gps receiver for my location or not.
I have several other sources of location information (gsm cell based and wifi based) usually with less accuracy. But I may prefer theses under certain circumstances because of less power consumption. I Don't use google but microg.
kurtn said:
Do you try to spoof your location? And why? What location providers do you have? GApps?
Click to expand...
Click to collapse
No. I am not trying to spoof anything. I have an automation program called Tasker on my S4. When I was on stock Samsung ROM (5.0.1), I was able to use the "location mode" in Tasker to switch between high accuracy and battery save. If Tasker detected I was running Google Maps, it switched on high accuracy. If not, it switched over to battery save. From what I can tell, high accuracy used GPS + network and battery save used network only.
Now, I'm on LOS 17.1 and battery save would turn on GPS too. It seems the only way to not use GPS is to turn off location mode altogether. This makes me wonder what the differences are between Device Only and Battery Save modes. Since I cannot tell, I am assuming both modes are provided for backward compatibility to Tasker users but the underlining Android 10 doesn't differentiate them.
I am suspecting with Android 10, there are only 3 modes.
* GPS + network
* GPS
* OFF
Thus, if one needs the location service, GPS must be used.
I raised this question elsewhere. Some people actually told me that GPS doesn't consume much power if it's just turned on but not being used, e.g. by Google Maps. I have no way to verify if they are right.
luckysoul777 said:
No. I am not trying to spoof anything. I have an automation program called Tasker on my S4. When I was on stock Samsung ROM (5.0.1), I was able to use the "location mode" in Tasker to switch between high accuracy and battery save. If Tasker detected I was running Google Maps, it switched on high accuracy. If not, it switched over to battery save. From what I can tell, high accuracy used GPS + network and battery save used network only.
Now, I'm on LOS 17.1 and battery save would turn on GPS too. It seems the only way to not use GPS is to turn off location mode altogether. This makes me wonder what the differences are between Device Only and Battery Save modes. Since I cannot tell, I am assuming both modes are provided for backward compatibility to Tasker users but the underlining Android 10 doesn't differentiate them.
I am suspecting with Android 10, there are only 3 modes.
* GPS + network
* GPS
* OFF
Thus, if one needs the location service, GPS must be used.
I raised this question elsewhere. Some people actually told me that GPS doesn't consume much power if it's just turned on but not being used, e.g. by Google Maps. I have no way to verify if they are right.
Click to expand...
Click to collapse
Network location is not part of lineageOS. You can add it with GApps or microG. Have you?
Enabling location does not power the satellite receivers continuously. It really needs battery. The job of your tasker script is done by android 10 automatically. If you suspected apps to drain battery with GPS, disable their location permission!
kurtn said:
Network location is not part of lineageOS. You can add it with GApps or microG. Have you?
!
Click to expand...
Click to collapse
I'm using Gapps, the nano package. Do you know which one comes with network location? I can't tell because this comparison chart doesn't show it for any packages, https://github.com/opengapps/opengapps/wiki/Package-Comparison
kurtn said:
If you suspected apps to drain battery with GPS, disable their location permission!
Click to expand...
Click to collapse
The reason I preferred to keep it on battery save instead of off completely in the old days was that if I ever lost my phone, I wanted to be able to track it. Now with Android 10's mandatory GPS for location service, if I want to disable abusive apps from requesting unnecessary location service, which app should I avoid disabling? Which app is giving out my phone's location if I am tracking it remotely?
Thank you
luckysoul777 said:
I'm using Gapps, the nano package. Do you know which one comes with network location? I can't tell because this comparison chart doesn't show it for any packages, https://github.com/opengapps/opengapps/wiki/Package-Comparison
The reason I preferred to keep it on battery save instead of off completely in the old days was that if I ever lost my phone, I wanted to be able to track it. Now with Android 10's mandatory GPS for location service, if I want to disable abusive apps from requesting unnecessary location service, which app should I avoid disabling? Which app is giving out my phone's location if I am tracking it remotely? Thank you
Click to expand...
Click to collapse
I think the answer to both questions is Google play services. com.google.android.gms It's the mightiest app on your phone. I avoid installing it.
kurtn said:
I think the answer to both questions is Google play services. com.android.google.gms It's the mightiest app on your phone. I avoid installing it.
Click to expand...
Click to collapse
I still see one drawback with very selectively granting apps location service. For example, I do want to grant Chrome location service to facilitate better search. If I'm indoor, wouldn't GPS without a clear view of the sky trying very hard to get a fix and thus burn more power than necessary? With that said, can High Accuracy (GPS + network) actually be more power efficient under Android 10 than Battery Save (GPS only)? This is assuming Chrome would give up on GPS when it can't get a fix and be happy with just network while Battery Save would keep trying to get a fix with GPS. Again, this is just my assumption.