FORUMS
Remove All Ads from XDA

[HELP CENTER] [Guide] How to prevent, handle wakelocks , and save battery life

6,585 posts
Thanks Meter: 4,976
 
By AndroidSlave, Senior Member on 25th August 2012, 07:40 PM
Thread Closed Email Thread
[HELP CENTER] How to prevent § handle wakelocks § save battery life[GUIDE] [β]



Thread Purpose:
Information, help and support for those, who experiencing battery drain.


Some of the material was taken from respective BetterBatteryStats thread - Check it out, for the sake of information and correct explanation. I take no credit for this info and grateful for it's existance.

References and credits: @ahalford for all his hard work
& : Chasmodo - you know, who you are!

For the info & software: BetterBatteryStats creator & team

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.

How can we eliminate it, if we found such?

The purpose of this thread - is support per situation, if solution has not been
found after reading FAQ & Tips section. You should provide BetterBatteryStats dump file, data about rom/kernel, (possibly) list of installed apps and describe your situation.

How to provide dump file:

Code:
- Install the app and grant it root access.
- Plug/unplug the charger
- "Menu" - "More" - "Set Custom Ref." - creates a reference point
- Leave the phone with screen off for some time, 4 to 6 hours - this must be   done so we can have uncluttered data as a basis for valid analysis
- Ensure you have the same wakelocks, that you've been about to report.
- Save a dump file - "Menu" - "More" - "Dump to file"
- It will look like - sdcard/BetterBatteryStats-2012-09-10_191252250.txt, for example
- Check that the chapters "Kernel wakelocks", "wakelocks" & "alarms"are populated.
I'm not posting the app FAQ on purpose - those, who can't handle it, can just provide a dump file. Those, who can understand or learn fast - don't need it

But. Brief explanation, about where to look at the wakelocks:

1.Set your reference as "Since unplugged" in the second line.
2. Then, in the first line: "Other" - look at the "Awake" vs "Screen on". If it differs a lot, continue with a drill-down.
3. First line - check under "Partial Wakelocks" and "Kernel wakelocks".
4. "Menu" - "More" - "Raw kernel wakelocks"
5. For more help: "Menu" - "Help" - "Getting started" or "How to".
6. Same web links:
Help:
http://asksven.github.com/BetterBatt...Base/help.html
How to:
http://asksven.github.com/BetterBatt...ase/howto.html

App Screenshots:











[/FONT]

Want to install Cyanogen or AOKP rom and have questions? Get here.
The Following 6 Users Say Thank You to AndroidSlave For This Useful Post: [ View ] Gift AndroidSlave Ad-Free
 
 
31st August 2012, 02:33 AM |#2  
AndroidSlave's Avatar
OP Senior Member
Thanks Meter: 4,976
 
More
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.


Wakelocks - XDA Wiki - take a look at it, may be very useful.
The Following 3 Users Say Thank You to AndroidSlave For This Useful Post: [ View ] Gift AndroidSlave Ad-Free
31st August 2012, 02:33 AM |#3  
AndroidSlave's Avatar
OP Senior Member
Thanks Meter: 4,976
 
More
AlarmManager

Author(s): sven, credits to andy2na @xda-dev
Ranking: n/a
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".
Here is a comprehensive guide to analyse Alarms: In order to find those Intents run the command dumpsys alarm.
This will dump all the alarm events so you can see what is invoking AlarmManager as a wakelock. From there you can find the culprits that have a lot of wakeups. In some instances, you cant do anything about it (Android System), but in others, you can uninstall or disable notifications. Hope this helps in solving your excessive AlarmManager problems.
Scroll to the " Alarm Stats" near the bottom, it should look like this:
com.levelup.beautifulwidgets
246776ms running, 10 wakeups
10 alarms: act=com.levelup.beautifulwidgets.ACTION_UPDATEWEAT HER flg=0x4
1583 alarms: act=com.levelup.beautifulwidgets.ACTION_UPDATECLOC K flg=0x4
com.motorola.blur.datamanager.app
22ms running, 0 wakeups
1 alarms: act=com.motorola.blur.datamanager.app.checkin.time out flg=0x4 cmp=com.motorola.blur.datamanager.app/.DataManagerCheckinService
ccc71.bmw
130743ms running, 1585 wakeups
1585 alarms: flg=0x4
com.motorola.kpilogger
2156ms running, 0 wakeups
13 alarms: act=com.motorola.kpilogger.START_LOG flg=0x4
com.gau.go.launcherex
528ms running, 10 wakeups
6 alarms: act=com.jiubang.intent.action.AUTO_CHECK_UPDATE flg=0x4
4 alarms: act=com.jiubang.intent.action.SCAN_APPS flg=0x4
As you can see, in my case, the services that have invoked AlarmManager seem to be BeautifulWidgets (to update the clock everytime the minute changes - 1583 alarms: act=com.levelup.beautifulwidgets.ACTION_UPDATECLOC K flg=0x4)
Battery Monitor Widget (obviously to pull the mW of the battery) - 130743ms running, 1585 wakeups
You could also reduce the amount of AlarmManager events by simply turning off Wireless location, Signing out of Google Talk, and turning off notifications or updates in apps you dont really use.
TLDR: 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.
Known conditions of occurence:
Related wakelocks:
References:
http://forum.xda-developers.com/show...&postcount=861
http://developer.android.com/referen...rmManager.html


AudioOut_1

Author(s): xda
Ranking: n/a
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.


AudioOut_3



ConnectivityService

Author(s): sven
Ranking: n/a
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.
Known conditions of occurence:
Related wakelocks:
References:http://grepcode.com/file/repository....ctivityService


deleted_wake_locks

Author(s): sven, credits to Tritonio_GR @xda-dev
Ranking: n/a
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.
Related wakelocks:
References: http://forum.xda-developers.com/show...postcount=5644 http://forum.xda-developers.com/show...postcount=6671 http://www.netmite.com/android/mydro...wer_Management


GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservi ce.AndroidEndpoint

Author(s): credits to lmihaila @xda-dev
Ranking: n/a
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
Related wakelocks: Other GTALK_ASYNC_CONN partial wakelocks
References: http://forum.xda-developers.com/show...postcount=3416


network-location

Author(s): sven
Ranking: n/a
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
References:
http://developer.android.com/guide/t...-location.html
http://developer.android.com/referen...onManager.html


PowerManagerService

Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
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

Author(s): sven, credits to Tungstwenty @xda-dev
Ranking: n/a
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.
Know actions:
Known conditions of occurence:
In relation with Chrome: http://forum.xda-developers.com/show...8&postcount=24 In relation with Wifi turning on/off when the screen goes on/off
Related wakelocks:
References:
http://forum.xda-developers.com/show...postcount=6603


svnet

Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: svnet
Rationale: basic radio management (Galaxy S/S II specific)
Know actions: No direct actions known, may be conditioned by using a different radio/modem


svnet dormancy

Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: svnet-dormancy / multipdp (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
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

Author(s): sven
Ranking: n/a
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: http://code.google.com/p/android/issues/detail?id=9307


SyncLoopWakeLock

Author(s): sven
Ranking: n/a
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
References: https://github.com/asksven/BetterBat...Base/wiki/sync
Sources: New implementation:http://grepcode.com/file/repository....SyncManagerOld implementation (sync):http://grepcode.com/file/repository....SYNC_WAKE_LOCK


vbus_present

Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: vbus_present
Rationale: vbus_present is a kernel wakelock that is held when the charger is connected.
Know actions: No action required.
Known conditions of occurence:
When plugged in to charger / charging USB port


wlan_rx

Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: wlan_rx
Rationale: Wifi chip received a packet from somewhere - On a Galaxy S II, lots of these combined with the fact that the device takes 650 msec to resume from suspend and 150 to go back to sleep means that occasional wifi packets coming in will skyrocket Android OS usage. As an extreme example, run the following from a Linux box when wifi sleep policy is "never" and watch your deep sleep percentages plummet, your battery drain, and Android OS skyrocket: ping -i 5 <wifi IP address of phone>
Know actions: Use a sniffer to determine the cause of the traffic.
Known conditions of occurence:
Related wakelocks: wlan_wake References:


wlan_wake

Author(s): sven, credits to Entropy512 @xda-dev
Ranking: n/a
Speaking Name: wlan_wake
Rationale: wifi chip woke the CPU (Usually this fires and leads to a wlan_rx wakelock).
Know actions: Use a sniffer to determine the cause of the traffic.
Known conditions of occurence:
Related wakelocks: wlan_rx References:


***NEW***L2_HSIC:

HISC is the interface that connected the main Soc processor ( Also called Applciation Processor AP) to the modem ( 3G or 4G if there are two modems separately )

HSIC is uses the standard USB core library. And it is standard given by usb.org. The HSIC by itself consumes very less power and is one of the very power efficient and space efficient ways of interconnecting chips. Currently common to Qualcomm and Sammy Exynos architectures.

The reason seeing too many HSIC wake lock and other wake ups is due to the fact that the HSIC interface is waken up by modem (resulting modem scenarios are also so many) .

Also one important reason is EFS sync.
A concept : that the new modem architectures doesn't support a flash storage.(Saves lot of cost to manufacturer) .So every time modem needs to store something , it wakes up hisc interface and ask the AP (Main processor) to store it for him in his flash.

So this CP storing via AP is a fairy frequent activity even during suspend/deep sleep mode. Remember modem is periodically awake to do "Cell Update message" all the time.

I see the concern over this L2_hsic wake lock. I can say at this point that it is quite natural activity. and a necessary evil for smooth working of your modem( network 2g,3g,4g ) subsystem.

Every company including Sammy have some kind of power optimization done in the HSIC. So they taking care of this we considering fairy high battery drainer issue. .

If it is too high, modem/network can be blamed , if too many frequent network ( too many cell re-selection activity due to low RF reception) changes force the modem to do more activity, thus waking AP to do the work of storing its data over HSIC.

The Following 3 Users Say Thank You to AndroidSlave For This Useful Post: [ View ] Gift AndroidSlave Ad-Free
31st August 2012, 02:33 AM |#4  
AndroidSlave's Avatar
OP Senior Member
Thanks Meter: 4,976
 
More
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.

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:
1. You probably have some corrupted files, on which it stuck. Backup, start to restore to the step it was OK, to find the culprit
2. 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.
3. I/O scheduler - CFQ sometimes being reported as taking longer time to media scan to complete. Try NOOP.
4.And, of course, sometimes it won't work without formatting emmc and starting over.

- Google apps/services:
(in edit)
- 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.
The Following 2 Users Say Thank You to AndroidSlave For This Useful Post: [ View ] Gift AndroidSlave Ad-Free
31st August 2012, 02:33 AM |#5  
AndroidSlave's Avatar
OP Senior Member
Thanks Meter: 4,976
 
More
...
9th September 2012, 11:12 PM |#6  
jeetu1981's Avatar
Senior Member
Flag New Delhi
Thanks Meter: 731
 
More
Amazing!! will save lot of threads/questions about battery drain.

It will be great if you can look at frequent questions about battery drain in Q&A and can include in Q&A of your thread.
The Following User Says Thank You to jeetu1981 For This Useful Post: [ View ] Gift jeetu1981 Ad-Free
9th September 2012, 11:37 PM |#7  
ahalford's Avatar
Senior Member
Flag עץ החיים
Thanks Meter: 2,110
 
Donate to Me
More
Thanks, hopefully we'll build our database on the current and upcoming requests.
The Following 2 Users Say Thank You to ahalford For This Useful Post: [ View ] Gift ahalford Ad-Free
10th September 2012, 12:00 AM |#8  
cheryanne's Avatar
Senior Member
Flag Canberra
Thanks Meter: 171
 
More
This should be a sticky.

Sent from my gnote as always Rooted & Deodexed Stock 4.0.4 XXLRQ HydraCore v4 STD
10th September 2012, 01:12 AM |#9  
chasmodo's Avatar
Senior Member
Flag Novi Sad
Thanks Meter: 41,591
 
More
Well and comprehensively written, ahalford. Now let's wait for the first customers.
The Following User Says Thank You to chasmodo For This Useful Post: [ View ] Gift chasmodo Ad-Free
10th September 2012, 01:46 AM |#10  
ahalford's Avatar
Senior Member
Flag עץ החיים
Thanks Meter: 2,110
 
Donate to Me
More
Well, I actually expected you to sleep, sir
Thanks, and I'm continuing with edit. Like I said, many things to be added later, as it always happens.
10th September 2012, 06:49 AM |#11  
ahalford's Avatar
Senior Member
Flag עץ החיים
Thanks Meter: 2,110
 
Donate to Me
More
Thumbs up
So, we started to collect our suspicious apps in post #4.
Please, don't hesitate to share your knowledge regarding such mVsuckers.
The Following User Says Thank You to ahalford For This Useful Post: [ View ] Gift ahalford Ad-Free
Thread Closed Subscribe to Thread

Tags
battery drain, betterbatterystats, cm10, cyanogen, gt-n7000
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes