yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] cricketAC:
Resize the widget.

Sent from my LG-P999
[BetterBatteryStats] kyub-ie:
I don't have Google Chrome installed. Never have done. :eek:
[BetterBatteryStats] Tungstwenty:
Oh, the irony. Yet again, a battery saver is causing problems with the battery :rolleyes:

I've been away for a couple of days and have caught up on your troubleshooting. Finally, things make sense!

Having some sort of script or app with root privileges messing up with the file permissions on every single boot is really the only logical explanation.

The /sys entries reside in a filesystem of type "sysfs". In practice this means it's similar to a ramdrive - on every boot, it will be "formatted", and files recreated from scratch and with a predefined set of permissions (hard-coded in the kernel logic). Fixing permissions has no effect here whatsoever, it's only for "real" / persistent file systems like /data or /system.

For /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state, the predefined permissions are "r--r--r--" (readable by all), which is the reason why neither chamonix nor the CPU Spy author bothered to read its contents as root.

That rogue app you mention, don't know if intentionally (but why!?) or as some side effect, must be changing the permissions (in particular the final "r--") and make it not readable by everyone and only by root.

It was never a BBS problem, but that was already known as soon as you mentioned CPU Spy was also unable to show the stats. The odd part was the fact you're using the same kernel as many others an nobody saw the same effect.

Remember when I asked you to run "ls -l ..../time_in_state"? It was exactly to see the permissions. You posted your answer here and it showed "r--r--r--". Can you double check if it's indeed like that when you have the bad app running?

Either it isn't (perhaps you ran the command with some other configuration) or the successive parent folders don't all have the "r-xr-xr-x" like they might need to (and should have if no script changes it).
[BetterBatteryStats] It_ler:
Just in addition to my above post here some screenshots of the "small" difference between the Deep sleep ratio in "Other" and "CPU States" view.

Nothing dramatically ... maybe no bug but only a kind of rounding effect?!
[BetterBatteryStats] tigerphil:
I've reconfigured the app (Antutu battery saver) now, it was set to control my cpu frequencies, after unchecking that option, cpu spy and bbs are both running perfectly and the permissions have remained as r--r--r-- :D i decided i'm going to get rid of the battery saver app as the only other 2 benefits of it are, it can change my brightness as the battery runs low and go on auto flight mode at a desired time. Both of these options are also built into my rom so planning on configuring sleep times through the rom but being insomniac my phone is sometimes in use at 4am, soon as i decide on reasonable times just to leave the phone alone i'll be setting everything on the rom :)

1 question i do have, it doesn't involve BBS etc, i had to run the commands through a terminal app, is there any such programme i can install onto a laptop so i can plug my phone via usb and run the commands via the laptop?

As a tattooist my eyes get quite drained during work so looking at the phones terminal can be annoying at times even though hopefully it won't be needed often :)
[BetterBatteryStats] Karpfenhai:
Have you ever heard about adb shell?

should suite tor expectations :D

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Tungstwenty:
Just search the forum for adb and you should find dedicated threads explaining both how to install it (using the full SDK package, or standalone minimal packages with just the required files for adb) and also how to use it. One example: http://xdaforums.com/showthread.php?t=502010

Having it run on a PC with a cable connected to the device (BTW, I think it's also possible to run it through WiFi, just search for it) is much better than having to deal with a virtual keyboard and a small screen :)
[BetterBatteryStats] tft:
the stock Alarm Manager on my Galaxy S3 seems to be constantly waking. i don't even have any alarms set so it must be something else trigger Alarm manager.

how can i tell what is causing alarm manager to wakelock? my device isn't rooted.
[BetterBatteryStats] kevindd992002:
what is the difference of creating an "idle" dump file vs. a dump file alone?
[BetterBatteryStats] Karpfenhai:
Where is your Dump?

Alarm manager is just a collector for userland (partial) Wakelocks, so decrease them and alarm manager should went down too.

@Sven, bad news, the ref issue still persists :mad:

But only after a full charge, a reboot and unplug action fixes the problem, any clue? Normal "replug" w/o reboot does not help. The weird thing, as long as the phone is not fully charged, it works fine!

Reaching 100% soured the figures below:

Yes, I'm on the latest version.
[BetterBatteryStats] chamonix:
AlarmManager has nothing to do with Alarms like calendar reminders. Alarms are a mechanism apps can use to wake up to do something at a specific time. If your phone is rooted you can find the cause in the alarm statt section
[BetterBatteryStats] chamonix:
I will try the full charge cycle. Just in case, could you send me a logcat?
[BetterBatteryStats] chamonix:
Idle refers to leaving you phone alone for 4-5 hours and provide a dump file for that time. It makes it easier in the first step if the usage profile is 'simple', with no user interaction
[BetterBatteryStats] gaspar77:
nice 1 sir :good:
[BetterBatteryStats] kevindd992002:
Great. Thanks for the explanation. By the way, when will the inaccuracy of 1.10.5RC1 be fixed?

Also, in post#1 what do you mean by "make sure that the kernel wakelocks and alarm are populated" ?
[BetterBatteryStats] chamonix:
Current version is 1.5. If with 'inaccurcy' you mean the fact that the since time is not correct this is what I work on for 1.6.

Post #1 is to say that you should check the dump file and make sure all chapters contain data
[BetterBatteryStats] ranova:
Cya later nobnut, Ill let you know when I try out those adb commands
[BetterBatteryStats] chamonix:
you guys rock!
[BetterBatteryStats] carlos67:
App behaviour when network not available when trying to access 3g/H network

This bit is very interesting indeed!

I don't have battery problems, getting ~ 2 days per charge with light to medium usage. However, I am using green power app to turn off my 3g/H connection when screen is off. The app is configured to turn it on for 2 minutes in every 2 hours when screen is off. (Don't use it to manage wifi though).

Here's an interesting question for everyone

Let's say you have an app (facebook, email or whatever), that is set to update hourly. It is scheduled to do it's next update at say 9am. However, Green Power has the data connection turned off at the time of the app requesting it's 9am update. What does the app do then?

Does it.........

a. Continue blindly trying to do it's update (thus causing wakelocks because it keeps timing out and retrying) ?

b. Abandon that update and wait till the next one at 10am ?

c. Wait for Green Power to broadcast that the data network is back on (albeit only for 2 mins) and do it's update then at an unscheduled time?

d. None of the above

If it's answer "d", then what happens with the app eg email with it's sceduled updates. Is the app clever/aware enough of the presence of a data blocking app like Green Power? Surely not?

@Nobnut/Chamonix - your thoughts on this are eagerly anticipated.
[BetterBatteryStats] carlos67:
Disagree! Nobnut, it's the opposite of what you say man. The fact that you are able to test your phone in a very good signal place and also a very bad signal place with FD switched on and off in both places should give some very,very interesting results as far as FD is concerned.

Try it at work with the screen off for say 1~2 hours with FD on and then FD off (preferably with the phone stationary in the same location for consistency both at home and at work). Then do exactly the same at home and report your findings regarding partial wakelocks and battery usage. Maybe reboot the phone also each time just before testing. Also, which carrier are u on?
[BetterBatteryStats] ranova:
Nobnut, I posted in the Q&A section for the atrix asking about FD:

http://xdaforums.com/showthread.php?t=1243577

one user said there is a "Modem Fastdormancy Monitor service" that I can freeze in Titanium backup.

I am going to try that the next day and see if it makes any difference.

Another member found this thread:

http://xdaforums.com/showthread.php?t=1086599

not sure if it applies to the Atrix, but if freezing doesnt work, I may try it out.

I will try that one script out later!
[BetterBatteryStats] chamonix:
Very interesting discussion indeed.

In short you can't tell.

In long here's why (maybe we could start a thread about this); I believe there is no pattern for this but there could be one. I'll try to illustrate with a few patterns / antipatterns.

Let's start with two easy ones:

My app reacts on a location broadcast and updates latitude and it's criticality is low:

- pattern: as the phone is awake (location listener) I don't need a wakelock at all and I just try (once) to upload the location to google latitude and the service does not check for auto-sync being on or off. If it fails I store the location/timestamp and try to update both next time I get a change. If I get interrupted by deep-sleep the location may be lost or not transmitted. Best case is I was able to store it and can do next time worst case it's really lost but who cares (criticality).

- antipattern: For updating I set a wakelock, hold it for three retries fater timeout, do not check auto-sync and if it fails after 3 times I set myself an alarm to try in 5 minutes again, then release the wakelock. At the next wakeup (alarm of location changed again I redo the same procedure.

My app synchronises bookmarks and is scheduled to do a full sync every hour:

- pattern: at the alarm I first check if auto-sync is on, in no I go back to sleep for another hour. If on I set a wakelock, try to connect. If the connect fails I release the wakelock and go back to sleep for one hour. Note that I'm optimal for battery but it could happen that I never sync because I have lost one second checking auto-sync and trying to connect so I will wake up at the same time every time and possibly never meet the connection being on.

- Antipattern: the same but I try multiple times. As it fails I assume JD is preventing me from connection and set an alarm to 5 minutes to try again. I will ginally meet the window of data being on but I will have consumed a hell of battery due to my wakelocks

Questions:

are there patterns for devs?

is there a broadcast when the powersaver turns the data on?

is there a broadcast when auto-sync is turned on?

do all powersavers turn auto-sync on/off?
[BetterBatteryStats] nobnut:
I've just read this back and it sounds like a rant. Honestly, it's not. I find it amusing that folk can diagnose what is going on with my phone from hundreds and sometimes thousands of miles away without even seeing it. Anyway:

I'm on O2 UK. What you describe above is exactly what I did weeks ago. I spent about three days testing under different scenarios. I tested with FD enabled, disabled and with a modified SQL db and poll interval, each in an area of good and then bad reception. I am not saying that FD has no positive benefits as far as battery life is concerned, quite the opposite! I know it has. But there is a BUT... in areas with poor reception, it creates partial wake. Just look at your logcat, it is polling every 30 seconds. Look at your wake time, it is increased. lokk at your battery life, it is lower.

My results were partial wakelocks for FD (average of good and bad reception areas):

Enabed - 10 minutes of related wake per hour and battery drain at 3.5%/hour

Disabled - 0 minutes of related wake per hour and battery drain at 0.8% per hour

(If it's ok with everyone, I think I'll keep it disabled)

I am not on a crusade to get everyone to disable FD... I honestly couldn't care less about who has what on their phone. It's no one's business but their own.

I am saying definitively that for me, FD causes wake and increased battery drain. I don't care how many people say I am wrong, they are entitled to their opinions. As am I.

We are all adults here, we are all capable of making rational and informed decisions about what we like/want/need on our phones. Someone telling me that I really should enable FD on my phone because they know it is best for me is not particularly helpful. I don't go around telling people that they should really stop using a Deodexed ROM because they are wasting uneccessary space in their data partition. Free will, I love it.

I'll just lay this thought out here again. Turning off FD is not like getting a tattoo on your forehead. It can be turned back on with a few clicks of the screen if people want. All I ever try and do is to encourage people to experiment and not be part of the flock. Try something new, learn from it, make mistakes, who cares ;)

Hopefully we'll get somewhere soon, then you can test to see if it cures your wake problem.

Yes, that post you found is exactly what I was referring to above when I mentioned editing the db. I selected a poll interval of 960 seconds (16 minutes) just for your information... didn't have much effect on wake but it did reduce the logcat going mental. For me, just turning the bugger off worked. <disclaimer> I am not saying that this will be the case for anyone else </disclaimer>
[BetterBatteryStats] MPKO:
Thanks for the info. So my conclusion of this FD discussion could be that we should implement a functionality where FD is used only e.q. when Screen is on to avoid "bad behaving UE FD implementation" and unwanted wakelocks in deep sleep. It shouldn't be too difficult to implemet it.

Cheers!
[BetterBatteryStats] nobnut:
Now that sounds like a very good idea! According to my tests, this makes sense for my usage at least. But I guess we would have to test your suggestion in the real world.
[BetterBatteryStats] nobnut:
Hey Andy,

I've Googled and Googled until my eyes started bleeding. Basically, I can't find a secret code to disable FD on the Atrix. I found a couple of scripts that allegeldy turn it on and off but they looked highly suspect to me.

I did come across something however that may well help! But before I cover it, please forgive me if I ask you a dumb question. I am not insinuating that you didn't know this, but checking doesn't hurt, right? When you typed in the *#*#9900#*#*, was that in the stock dialler? If you were using another dialler (e.g. Go contacts), it probably won't work. If it does work for you, you need to rebbot for it to take effect.

Anyway, assuming that you were. Here is something else you could test. Like I said, I was Googling and came across the build.prop for an HTC Sensation. Within it I found this:

[B][COLOR="DarkRed"]ro.ril.fast.dormancy.rule=2[/COLOR][/B]
ro.ril.fast.dormancy.timeout=10
ro.ril.disable.fd.plmn.prefix=23402,23410,23411

I don't have any of these lines in my build.prop on my SGSII. Before you do anything if you don't have a Nandroid to hand, copy your build.prop from the system folder and keep it somewhere safe. Then go to your system/build.prop and add the lines (or edit it to '0' if you do have the lines):

ro.ril.fast.dormancy.rule=[B][COLOR="DarkRed"]0[/COLOR][/B]
ro.ril.fast.dormancy.timeout=10
ro.ril.disable.fd.plmn.prefix=23402,23410,23411

Save, exit and then reboot.

To be honest I have no idea if it will work for you. But you have nothing to lose by trying it and seeing if your partial wakelocks decrease as a result.

If it works you can call me a 'wild man' for a week. If it doesn't you can call me whatever you like, I have a high abuse threshold.

This post was not harmed in the researching of my post.

EDIT: I have just checked the build.prop of my HTC Flyer and it only has the line:

ro.ril.disable.fd.plmn.prefix=23402,23410,23411
[BetterBatteryStats] MPKO:
You can disable it also with this string. U just need to type your own plmn id after 23411,

Cheers!
[BetterBatteryStats] nobnut:
@Andy, if you need to know which yours is > linky linky!
[BetterBatteryStats] flshg:
Is it possible to display which apps currently have a wakelock on, so I know which app to kill if I wish the phone to go into deep sleep? Forgive me if the app already has this feature but I havent spotted it.
[BetterBatteryStats] chamonix:
killing is not a good idea. wakelock are legit and important mechanisms. Learn to read wakelock stats and select your app based on the way they suit your needs
[BetterBatteryStats] nobnut:
It doesn't provide that level of information yet. Sometimes it is pretty obvious which app is causing the problem by the description given. For example you might see

*network-location*

com.anddoes.fancywidgets.Fancy Widgets

In the above case, no prizes for guessing that it is Fancy Widgets that is causing the wake.

Other times however you might see something like

AlarmManager

Android System

In which case you can either search this thread for suggestions and advice, or search Google for clues. If you find any, don't forget to post them back here so that other people can benefit from your new found wisdom ;)

The most common ones have been posted in this thread already. Chamonix is constantly developing BBS and hopefully in time it will have the kind of user friendly information you are asking about.
[BetterBatteryStats] ranova:
Atrix Fast Dormancy and Alarm Manager wakelock update:

http://xdaforums.com/showthread.php?p=17179313#post17179313
[BetterBatteryStats] flshg:
I agree, but there are times when there just seems to be (badly) written apps that have a wakelock on for no apparent reason, probably trying to sync except I have data disabled or blocked using droidwall etc. No matter, I can imagine if that feature was added people (probably me) might well be tempted to kill all apps with a wakelock.
[BetterBatteryStats] ranova:
wow, great find nobnut.

To answer your question, I was using the stock motorola dialer. While the 4636 code worked, the 9900 did now.

I tried looking at the atrix build.prop but nothing comes up when I search dormancy or plmn. :(

I will continue to monitor this FD process disabling thing today and report back results.
[BetterBatteryStats] nobnut:
Whatever works for you.

If Titanium is working, that's great. For the build.prop method, just add the last line I posted into your file. My operator plmn id is 23410, so it is already blocked on my Flyer.

The best bet for you however would be to use *#*#9900#*#*. That way any other features affiliated with fast dormancy that might be of benefit to your phone won't be lost if you freeze the process in Titanium.

Sounds like you've got it sorted anyway. Happy days.
[BetterBatteryStats] ranova:
Yep, now we just need to figure out Alarm manager. It seems that users that flashed cyanogen beta onto their atrix's do not have alarmmanager show up in wakelocks
[BetterBatteryStats] kevindd992002:
Ah. So you don't recommend people to use 1.10.5RC1 as of the moment?

Ok gotcha.
[BetterBatteryStats] Greedyfly:
Guys,

Having some battery drain issues again. I am ok with a negligible amount when running known battery drainers simply for having the app available to me however I think the one's attached below are unacceptable even considering sync/wifi running. Any ideas please.
[BetterBatteryStats] kyub-ie:
Can anyone else check this out for me? It's not Google Chrome I can assure you.
[BetterBatteryStats] m14mclaren:
Lets try that again
[BetterBatteryStats] chantoine:
Hi,

You should cut-off WiFi and provide another dump.
[BetterBatteryStats] Greedyfly:
Will do. That said I've been running WIFI and not had this sort of drain overnight despite my rather aggressive sync schedules.

Can you see anything else that might be causing an issue?
[BetterBatteryStats] chantoine:
I'd say you should :

- cut off Wifi,

- investigate on ("cloudtv.hdwidgets.HD Widgets") this widget, which seems (i can make a mistake) to update regularly while you don't have a good coverage.

(edit) and also cut-off Google location options...
[BetterBatteryStats] s2dh:
Could someone tell me what is using my battery?

Or how I can tell from this file what is wrong?

my phone is at 54% after 3 hours.

also, my phone randomly powers off for no reason?
[BetterBatteryStats] Karpfenhai:
Sorry mate, this dump is useless, read the OP how to produce a better one , yours does not show any data as it was made with charger connected ??
[BetterBatteryStats] shad0vvfax:
To the guy that told me to resize the widget....it does not seem to be resizable. Unless I'm completely missing it somewhere

sent from my HTC EVO 4G LTE using the xda-dev app
[BetterBatteryStats] Karpfenhai:
It depends on the rom / launcher wheter a widget is resizable or not,

But you may uncheck show title from widget settings, this helps too.
[BetterBatteryStats] Cyb0rgz:
Hi, Based on the report, I analyzed the application causing the wakelocks from ALARM and disabled

1. Google Backup from Settings->Privacy

2. Locations/GPS

3. Current widget app.

the application as required.

However, I am not clear on how to analyze the kernel wakelocks and some other parameters used here. Could you please someone explain below points,

1. For Example, Under Process, I could notice many process name and their details:

surfaceflinger (Android System): Uid: 1000 Sys: 9 s (9 s) Us: 8 s (8 s) Starts: 0
com.google.android.gm (com.google.android.gm.Gmail): Uid: 10113 Sys: 1 s (1 s) Us: 8 s (8 s) Starts: 29
com.htc.launcher (UID): Uid: 9999 Sys: 1 s (1 s) Us: 5 s (5 s) Starts: 4

What is

a. UID?

b. Sys?

c. Us?

d. Starts (Main) – What does these counts mean?

2. Under Kernel wake locks, below info are available

"PowerManagerService" (): 16 m 26 s (986 s) Cnt:(c/wc/ec)2212/0/0 3.5%
"alarm_rtc" (): 8 m 15 s (495 s) Cnt:(c/wc/ec)1033/0/169 1.7%
"SMD_DS" (): 7 m 44 s (464 s) Cnt:(c/wc/ec)1947/88/1947 1.6%
"SMD_DATA5" (): 5 m 2 s (302 s) Cnt:(c/wc/ec)683/101/683 1.1%

a. What does (c/wc/ec) indicate?

Any one please review the attached file and

Please help me to analyse all the values by MYSELF. Just trying to learn. Thanks in advance.
[BetterBatteryStats] Tungstwenty:
UID - The linux user id of the app. Each app runs with a separate user (and it can be a member of multiple groups), which allows granular control over which apps can access files and folders. Not really important.

Sys - The amount of time this app was consuming CPU, while running kernel code (on behalf of the application). This would mean things like I/O, perhaps graphics rendering, and other stuff that happens in the kernel.

Us - The amount of time the app was consuming CPU for running "normal" code, i.e., the app's code itself. Calculations, for instance. The sum of User and System time give the total amount of CPU consumed by the app.

Starts - I believe this is the number of times the app was (re)started during this period. It could show 0 if the app was already running when the initial reference started, 1 if it was launched once, or in your example 29 means Gmail was opened and closed multiple times during the elapsed time.

C - count, or number of times this KWL was activated

WC - wake count, or number of times that this KWL was the first one to be activated after the device woke up from deep sleep (could indicate it is somehow related with the reason for waking up, but can also be very misleading as e.g. the battery monitor KWL on SGS2)

EC - expired count. KWLs can be activated with an infinite time (must be explicitly released) or with a certain timeout. If they are activated with a timeout and not released during that period, they are automatically released and this counter increases by 1. As you can see on your list, the SMD_* entries are always released by themselves after some timeout (~440ms for each SMD_DATA5, perhaps?). That's the way that driver was programmed. As for PowerManagerService, it never expires, i.e., the service controlling those locks explicitly requests the aquisition/release of the KWL.