yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] ithehappy:
I completely agree with you on this. I tested with some UV settings with SetCPU and I can confirm that there is NO difference at all it makes by changing the Governor state. I don't know about other models but I9100's CPU is more than enough to change it's state when needed. Absolutely no need of any kind of application additionally to do that.

Some people are going crazy with these apps. Just a matter of time when they will realize they ran behind nothing and wasted their time.

Regards.
[BetterBatteryStats] donatinho:
My lowest battery usage in idle is 30mha. I tried different roms, and many kernels.... Which value should i consider "normal"?
[BetterBatteryStats] nobnut:
2-5 mAh is good. Up to 10 is OK if you have lots installed on your phone. Above that, there is room for improvement :)

Post some details or screenshots and we'll suggest some things for you to try.

Sent from me to you using stuff
[BetterBatteryStats] amandureja:
Hey everyone,

By using BetterBatteryStats to try to narrow down the source of my battery drain, I have found that 2 processes (wakelocks) are causing the bad battery life.

These processes are: "suspend", and "events/0". They are preventing the phone from going to deep-sleep, and are sometimes running for minutes/hours!

How can I prevent these processes from running and draining my battery?

Thanks!
[BetterBatteryStats] ejstubbs:
Guys, I'm going to get all pedantic here - and I know you're not the only offenders - but the current drain is in milliamps (mA) not milliamp hours (mAh). Milliamp hours is the

capacity

of the battery: for example, if it outputs 30mA for 24 hours from full to flat, the capacity is 720mAh.

The ampere, more commonly called the amp, is the SI unit of current and is named after André-Marie Ampère (1775–1836), French mathematician and physicist, considered the father of electrodynamics (according to Wikipedia). It is defined as one coulomb per second. That makes one coulomb equal to one amp second - so 1mAh is actually 3.6 coulombs. You may ask why battery capacities are quoted in mAh. They just are, OK? I don't know, you people with your questions...

Anyway...the lowest current drain I see on my Defy at idle is around 25mA. The stock battery is rated at 1500mAh. That would give 2.5 days standby time, which I think is not unrealistic. Of course, actually

using

the thing reduces that. I get a bit over 24 hours out of the battery at my typical usage. I've no idea how to even approach 10mA, let alone 2mA. Even 10mA would mean a standby time of nearly a week, which personally I doubt is actually feasible.

The question in my mind at the moment, however, is what happened at 05:25 this morning?

I do see these sudden peaks in battery drain every so often when the phone is supposed to be idling. I have no idea what causes them.
[BetterBatteryStats] nobnut:
I knew that thank you. That was a typo.

I've never had a problem getting 2mA. Maybe your issue is hardware related, possibly just a less 'fuel' efficient phone?
[BetterBatteryStats] donatinho:
It seems the process which causes most partial wakelocks is alamr manager. Another was Beautiful Widgets, which I already trashed.

I attach a drocap screenshot,and a file log, hope it helps.

I a
[BetterBatteryStats] nobnut:
Hi,

Your partial wakelocks aren't too bad at all. Nothing there that should cause too much drain.

Wakelocks
=========
*backup* (Sistema Android): 22 s (22 s) Count:113 0,6%
ActivityManager-Launch (Sistema Android): 17 s (17 s) Count:71 0,5%
RILJ (Composiz.): 10 s (10 s) Count:95 0,3%
SCREEN_FROZEN (Sistema Android): 6 s (6 s) Count:31 0,2%
NetworkLocationLocator (com.google.android.apps.maps.Maps): 4 s (4 s) Count:1 0,1%
AlarmManager (Sistema Android): 4 s (4 s) Count:248 0,1%
GTALK_ASYNC_CONN (Servizi Google): 4 s (4 s) Count:3 0,1%
sleep_broadcast (Sistema Android): 3 s (3 s) Count:27 0,1%
*sync* (com.cooliris.media.Galleria): 2 s (2 s) Count:2 0,1%

You can turn off Android Backup in settings if you don't want it. To reduce AlarmManager activity, you can remove calendar reminder notificatrions from within the calendar app (note this will not totally remove AlarmManager related wake). If you don't want or need Latitude running, you can sign out of it if you haven't already.

What you can also do, which will probably have much more effect on standby drain than partial wakelocks is to decide which apps and processes you do not need running all of the time and stop them from autostarting. Some contenders are listed below. There is no need to have these running all of the time (unless of course you want them for some reason):

drocap2

Maps

FileTransfer Service

If you are interested in preventing apps from autostarting, have a look at this.
[BetterBatteryStats] chamonix:
those are processes. Switch to the 'partial wakelock' view and look for the apps rssponsbile for the wakelocks. Feel free to post your finding here if you need help.
[BetterBatteryStats] ejstubbs:
Apologies, the comment wasn't aimed at you specifically - hence why I also quoted donatinho's original question. It's just that I've seen the error a number of times on this thread and given that we're discussing battery life I felt that I couldn't let it go any longer! As I say, I'm a bit of a pedant at heart...

I think that is probably the case. I don't seem to be getting spectacularly worse battery life than other Defy owners, judging by the Defy forums on XDA. Also, Motorola have just announced the Defy+ which informed opinion says is the same hardware as the Defy (despite the marketing blurb suggesting otherwise) but with Gingerbread and a 1700mAh battery instead of the Defy's 1500mAh battery. That suggests to me that they know the Defy is fairly hard on its battery.

I've just taken delivery of a "2200mAh" battery from China. That capacity is probably a crock but at £10 it's cheaper than a genuine Motorola battery and will hopefully at least be an acceptable spare. If it's demonstrably nothing like as good as the stock battery I'll just chalk it up to experience/experiment.
[BetterBatteryStats] nobnut:
No apology necessary :)

Be careful with those 'dicky' batteries. I put one of those in a Desire HD and it swelled up during use (because of the heat generated) and broke the phone! Literally cracked the case.

The issue was that it wasn't my phone, it belonged to work. I had to replace it.

Oh well, such is life.
[BetterBatteryStats] MPKO:
My understanding has been that millivoltage, milliamps, battery % and % of used applications reported by the Android os are based on the Energy model what was created by the Android OS developers. My understanding has been that detailed energy measurements can't be done with any application due to reason that our phones don't have any hardware available to measure it in practice. Due to this reason, only way to measure the actual energy consumption is to use external measurement device. My question is, do you know if this is still the case nowadays ?

Then another thing. I saw that some people were wondering their energy consumption in idle state. in my case the BatteryMonitorWidget is reporting 25-30mA consumption in idle state at day time. First I was wondering why it is so high, because it should be something like 5-6mA if everything is fine. Then I notice that the snapshot of statistic collected by the BatteryMonitorwidget history was taken every 5min which explains my high idle state result quite well.

Cheers!
[BetterBatteryStats] nobnut:
Chamonix posted over the wekend that these stats are a collection od data gathered from many parts of the system. His inference was that they should not necessarily be taken as absokute truth. I liked the quote about statistics he gave. Have a look back for his post.

No, you have misunderstood the statistic. The 5mA is a 'live' statistic. It has nothing to do with time. It is not the case that you multiply 5mA by 5 (minutes) to give 25mA. 25 mA is 25mA. Ejstubbs' earlier post explains this well, I won't repeat what he said.

Basically it means that your phone is drawing 25-30mA... it might well be possible to get this lower.
[BetterBatteryStats] MPKO:
I know that "5mA" is a "live" statistic and I know the difference between mA and mAh. If I measure the consumption of my phone by using an external tool my constant idle drain is 5-6mA. Why the BatteryWidget is reporting 25mA every 5min ?
[BetterBatteryStats] nobnut:
I misundertood you.

In that case you have two options. One of these is incorrect:

1. Your external tool

2. Battery Monitor Widget

Take your pick.

EDIT: I do know that BMW doesn't auto-detect all devices' battery cpacities. For example it doesn't auto-detect the Samsung Galaxy SII. You have to manually enter the correct mAh figure. Is your correct mAh figure being detected by BMW? If not, it is possible that your figures are being miscalulated. That is a masive margin of error in your case though.

Maybe you should ask the Dev, or post in the BMW thread.
[BetterBatteryStats] sowen222:
Just out of interest, have you tried setting BMW to do samples every 60 seconds, to see if the readings change?
[BetterBatteryStats] MPKO:
Thanks! I actually have a SGS2 and battery capacities were non detected. I'll try again.

Cheers!
[BetterBatteryStats] ejstubbs:
I think the only candidate I can see on my phone is BBC iPlayer. It seems to have the same annoying habit that it does on my Mac of starting at boot. I'll have a go at getting it to behave better using Gemini.

EDIT: Hmm, Gemini says the only autorun setting for BBC iPlayer is "On Connectivity Change". I've disabled it anyway.

As a matter of interest, what's the best way to find out what apps are running at a particular moment? I've been using System Tuner Pro but the information I get from that doesn't seem to match well against, for example, OS Monitor, Toolkit orTask Manager. The "Running" tab of Manage Applications lists stuff that I have frozen using Titanium Backup, which also doesn't seem right. Gemini has an "Is Running" filter which lists vastly more than System Tuner Pro does. Colour me confused...
[BetterBatteryStats] nobnut:
Have a look at the autostart permissions iPlayer has. You'll laugh. Yes, you can turn them all off and it still works fine. That is what I've done.

Weird, freezing them should make them 'vanish' from the system. You shouldn't see them as installed in the apps drawer and you certainly shouldn't see them running!

The only place you should see them is under 'Manage Applications' in Settings > Applications. I would check yor TB settings, maybe there is something not quite right there.

As for seeing what is running, as you say. I normally just use Gemini. The first screen after opening Gemini shows what is running and to mess with the autostart permissions, press menu and select 'Expert Mode'. Then click on the app concerned and choose 'Config "Autorun" (root)'.

Some apps will not function if you kill all of the autostart permissions. An example is Market. For some apps you can stop them all, for other apps, you have to play 'chase' with different settings until you get it right.
[BetterBatteryStats] hristopelov:
I tried absolute stock 2.3.6 without any Titanium Backup or Gemini for a day, and still had a lot ot "Event Log Service"

Upgraded to 4.0.4 Stock 2 days ago, NONE of it, same carrier, same apps that i use...

It makes me think is Carrier/ROM related...

Migh make another idle overningh test soon to prove it, but yeah, i dont have it on 4.0.4
[BetterBatteryStats] jaydoubleyou:
I've been having the event log service issue since i was using darkside ics which makes me unsure if it's really rom related. i checked my brother's wakelocks and he doesn't have any issues running the same rom/kernel
[BetterBatteryStats] hristopelov:
Every ROM is diferend, i didn say ICS vs GB, my Stock 4.0.4 on T-Mobile is diferend than the Stock 4.0.4 on AT&T, and especialy Stock ROMs vs Custom build ROMs as you say your using one.

That is my point, it appears in some ROMs, i think is not app related, is more ROM related as i tested 2 Stock ROMs and i had it on one and dont have it on another.
[BetterBatteryStats] Lebenita:
Implausible screen on times on Xperia Go w/ ICS 4.0.4

Since I've switched to 4.0.4 from 2.3.7 on my Xperia Go, I'm consistently seeing screen on times that are way too high (often higher than wake time, which is obviously impossible). This is either a bug in Sony's new OS version or in BBS v1.11.

I have switched to debug mode in BBS and I have attached a dump and a logcat that illustrates the problem. I hope this allows you to identify the problem, Sven. I hope it is down to BBS (because then you can fix it), but of course it can be either a bug or an incompatibility (out of many) in Sony's firmware.

Another problem I'm seeing is that references are not properly reset (at least in my understanding):

On boot, both unplugged and customer reference are reset as they should be.

However, on plug/unplug, the boot reference and the custom reference are not reset. But they should be, no? After all, they are not meaningful any more (in fact they are misleading) if the device was plugged in in the meantime.

Thanks,

Lebenita
[BetterBatteryStats] Maxxon2k:
Please help with putting things together

I own an Xperia S with ICS. My story started with the stock battery overview in settings showing that Android System took the most juice right after the display. So i installed BBS. Now i have an issue putting the readings together.

First off all, according to BBS, i loose 0,8% juice per hour when having the phone doing nothing siting on my night desk. I would be fine with this, but readings dont correlate and i am simply curious now:

Of 8 hours night time (where the phone has WLAN and bluetooth turned off, but data connection and sync allowed because i want to find out what the phone does in it's day idle times), i have

approx 7 hours 50 minutes deep sleep

approx 10 minutes awake,

but i have:

approx 5 minutes PowerManagerService

approx 45 minutes AlarmManager

and i have a 200~300 wakeups by AlarmManager but in the Alarms list are only shown like 50 ones.

The stock battery overview in settings still identifies "Android System" as being the main juice eater at nights, with 2 minutes CPU but the 45 minutes awake time i see for the AlaramManager. But how can this correlate with the deep sleep times? Which statistic is correct? Where did the missing Wakeups the AlaramManger shows go, but which are not in the Alaram overview? And last why uses AlarmManager more time than PowerManagerService (of which i read that it's the kernel representation of AlarmManager)?

Many thanks if anyone could clarify this or give me a hint where to read things about it. Its impossible to find anything in this thread :(

P.S.: The other strange thing is, that i can't reproduce the high wake up time for AlarmManager at daytimes. For example while googleing and writing this text i had the phone again 1,5 hours doing nothing. But now i have only 2 minutes of AlarmManager (which would not give me the same numbers for the 8h night times) - with WLAN on though. But the described night behaviour is reproducable.
[BetterBatteryStats] Karpfenhai:
Here you go that's post number 3.

Should answer your questions :)

Hint, wakeups are not the same as wakelocks.

Happy reading.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Maxxon2k:
Thanks your your reply. I have indeed seen that post, but didnt find an answer in it why the numbers dont match up. Especially how the time spend for AlarmManager can be higher than the phone actually being awake, because the online help of BBS also says that the times in PartialWakelocks are calculated against the Awake Time. I read in another post, that it may be simply a counting problem.
[BetterBatteryStats] indigold:
Please help interpret this

http://db.tt/MOSJv35G
[BetterBatteryStats] chamonix:
Please post a logcat with full debug as well as a dumpfile. I don't understand the examples you post: PowerManagerService is a kernel wakelock, Alarm Manager is a partial wakelock, you don't mention screen on and total times...

AlarmManager sums up all the activities related to alarms and that is not only wakeups (e.g. creating/deleteting/updating alarms, alarms not related to wakeups). The Alarms stats show wakeups. You can read more about that here: http://developer.android.com/reference/android/app/AlarmManager.html
[BetterBatteryStats] chamonix:
There is nothing to interpret:

Since 0 s

Please red the first posts of ths thread in order to understand how to take a reading and how to read it, and provide a new post if you need some help
[BetterBatteryStats] indigold:
Am sorry, I posted d wrong stats, i meant to post this http://db.tt/gdQR5GAV

Please help me interpret
[BetterBatteryStats] chamonix:
The dumpfile was taken with "since custom" and you mentioned that the custom ref did not get deleted. Was there a boot between the tme of saving the ref and the time of reading?

What puzzles me is this:

D/Misc (29393): Substracting Awake 5 h 20 m 31 s (19231 s) in 21 h 47 m (78420 s) Ratio: 24.5% from Awake 5 h 21 m 49 s (19309 s) in 22 h 13 m 50 s (80030 s) Ratio: 24.1%
D/StatsProvider(29393): Result value: Awake 1 m 17 s (77 s) Ratio: 4.8%

5:21:49 - 5:20:31 = 0:01:17 (with a little rounding)

But:

D/StatsProvider(29393): Current value: [B]Screen On[/B] 2 h 39 s (7239 s) Ratio: 9.0%
D/Misc (29393): Substracting Screen On 1 h 59 m 17 s (7157 s) in 21 h 47 m (78420 s) Ratio: 9.1% from Screen On 2 h 39 s (7239 s) in 22 h 13 m 50 s (80030 s) Ratio: 9.0%
D/StatsProvider(29393): Result value: [B]Screen On[/B] 1 m 22 s (82 s) Ratio: 5.1%

2:00:39 - 1:59:17 = 00:01:22

Now you have really low awake/screen on times (22 hours total) and I would be interested in knowning if after a reboot it looks the same.

About your refs not being deleted:

- please post a logcat at boot time

- please make sure that you haven't removed the boot receiver from BBS

- please make sure you have not move BBS to SD with any tools
[BetterBatteryStats] Maxxon2k:
Total time was 8h. Screen On was more or less the same than active time. But i'll simply make a log this night.

My Info about PowerManagerService was based on this guide-thread http://xdaforums.com/showthread.php?t=1827676 which states

So because of the catch-all i thought this should be >= PWL.

ty
[BetterBatteryStats] Lebenita:
Just to avoid misunderstandings: Like I wrote above, the refs (custom + unplugged) are correctly cleared on boot. What does not get cleared is custom + boot refs on unplugging the device. Could you please confirm if this is a bug or by design?

If in the light of this, a boot logcat is still needed, I'll be happy to post one. I can also post one when unplugging the device.

---------- Post added at 12:01 PM ---------- Previous post was at 11:26 AM ----------

The time spent in different CPU states doesn't add up to the total time. I originally reported this here and later confirmed here that it happens not only with "Since custom ref", but also with other references like "Since boot" and "Since unplugged". I have now noticed that the problem persists in v1.11 (and on another phone), see below.

===================

General Information

===================

BetterBatteryStats version: 1.11.0.0

Statistic Type: (6) Since Boot

Since 3 h 15 m 4 s

===========

Other Usage

===========

Wifi On (): 3 h 15 m 4 s (11704 s) Ratio: 100.0%

Wifi Running (): 3 h 15 m 4 s (11704 s) Ratio: 100.0%

No Data Connection (): 3 h 15 m 4 s (11704 s) Ratio: 100.0%

No or Unknown Signal (): 3 h 15 m 4 s (11704 s) Ratio: 100.0%

Deep Sleep (): 3 h 3 m 22 s (11002 s) Ratio: 93.9%

Screen On (): 13 m 18 s (798 s) Ratio: 6.8%

Awake (): 11 m 42 s (702 s) Ratio: 6.0%

Phone On (): 1 m 12 s (72 s) Ratio: 0.6%

==========

CPU States

==========

200 MHz (): 22 m 31 s 10.8%

400 MHz (): 12 s 0.1%

800 MHz (): 15 s 0.1%

1 GHz (): 2 m 47 s 1.3%

Deep Sleep (): 3 h 3 m 22 s 87.7%

The time in the 5 CPU states adds up to 12547 seconds as opposed to the total time reported which is 11704 seconds. Consequently, the deep sleep ratio reported in "CPU states" is significantly different from the one reported in "Other". What could be the reason?

BTW, the quote illustrates again the problem of screen on times that are higher than wake times. I'll reboot and test again to see if it has anything to do with the device being plugged in since boot.
[BetterBatteryStats] chamonix:
Sorry I misread. Reds not being deleted at unplug is a feature: the counters do not get reset at unplug. Of course those refs make more or less sense if you have been loading in between but I leave that up the the user as data will still be consistent.

The logcat at boot is not required as that is sorted out now.

What I'd like to understand is if the total time has an effect. In the previous post we had a difference of 4 seconds with a runtime of 20 hours so that would be an error of about 0.005%. I'd have to check the precision of the internal clock but this looks like something than can be explained. Now if the error is linear I'd say this may be normal as we talk about stats based on counters here. If the same error happens in 1 hour that would be a more alarming 0.1% error.
[BetterBatteryStats] Lebenita:
Noted, thanks.

Not sure if you refer to the CPU times add-up error or the excessive screen-on time error. The time add-up error may be related to counter precision, particularly given the presumably high number of transitions between CPU states. However, the error is high enough (5% in the example below) to warrant bughunting and correction.

The screen-on error is not linear and sometimes so outrageously high that no amount of rounding can explain it. Instead we're talking about either a bug in BBS or a bug (or API incompatibility) in Sony's OS.

As an example, here's a dump taken 6 minutes after a reboot:

BetterBatteryStats version: 1.11.0.0

Statistic Type: (6) Since Boot

Since 6 m 6 s

===========

Other Usage

===========

Wifi On (): 6 m 6 s (366 s) Ratio: 100.0%

Wifi Running (): 6 m 6 s (366 s) Ratio: 100.0%

No Data Connection (): 6 m 6 s (366 s) Ratio: 100.0%

No or Unknown Signal (): 6 m 6 s (366 s) Ratio: 100.0%

Deep Sleep (): 5 m 21 s (321 s) Ratio: 87.7%

Awake (): 44 s (44 s) Ratio: 12.0%

Screen On (): 1 m 31 s (91 s) Ratio: 24.9%

==========

CPU States

==========

200 MHz (): 42 s 11.0%

400 MHz (): 1 s 0.3%

800 MHz (): 2 s 0.5%

1 GHz (): 18 s 4.7%

Deep Sleep (): 5 m 21 s 83.5%

(adds up to 384 s as opposed to 366 s "total time")

The screen-on time here is overstated by more than 100%. The actual screen on time was definitely less than the awake time (only as much as required to enter pin + pattern lock, and then at the end store the dump from BBS). I have attached a logcat in case it helps.
[BetterBatteryStats] chamonix:
The first thing I seee in this log is:

W/ActivityManager( 1783): Timeout executing service: ServiceRecord{41826648 com.asksven.betterbatterystats_xdaedition/com.asksven.betterbatterystats.services.WriteBootReferenceService}

so there is something wrong with that reference so it's not worth looking at the figures based on that reference.

I also noticed

W/PackageManager( 1783): Not granting permission android.permission.DEVICE_POWER to package com.asksven.betterbatterystats_xdaedition (protectionLevel=2 flags=0x8be46)

meaning BBS is not granted the right to process plug/unplug events.

I suggest that you revisit your setup
[BetterBatteryStats] Maxxon2k:
Hello,

i have already a log for you. In particular:

how can the AlarmManager keep the phone awake for 25 minutes, when it was Awake only 1,30 minutes according to other stats? The Settings->Battery Applet is telling by the bar graphs that the phone was active half of the whole hour i did the test.