yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] alireza_simkesh:
No, I have Samsung S8 running Android 7.0.

I have about 1000 wakeups for job.delay and 800 wakeups for job.deadline, so if i can eliminate these wakeups i will be able to increase my battery life by almost 100%!

---------- Post added at 06:58 PM ---------- Previous post was at 06:56 PM ----------

I see that you also had the same problem, were you able to find out about the root of the problem?

I am thinking of getting help from another app called Wakelock Detector to find an answer for these wakelocks.
[BetterBatteryStats] DB126:
Err...more likely WL requests which do not actually wake the device nor keep it from sleeping. Depends whether a receiver is 'listening' and if so, what actions (if any) are taken.
[BetterBatteryStats] 93fuelslut:
How do you post/create a log? I read the OP and didn't see it mentioned, or an option from the playstore app version

Not sure if this will work, but I made a Dropbox link to the logs and texts dump file https://www.dropbox.com/sh/g31sqijzkl42v7q/AACqMoTIe1O_8ktjKt41p6hca?dl=0
[BetterBatteryStats] 93fuelslut:
Screenshot
[BetterBatteryStats] TNSMANI:
If you had searched the thread, you would have found it. A sample: https://xdaforums.com/showpost.php?p=73750994&postcount=32778

The dumps you posted all have more than 45 minutes screen on time. It has to be less than one minute.
[BetterBatteryStats] alireza_simkesh:
Thanks, is there an app that could tell me whether or not the receiver is listening?

That way I can further investigate it.
[BetterBatteryStats] DB126:
Not really. The evidence comes from observing app run times and identifying 'bad actors' that contribute to excessive (operative word) idle drain. A high number of wakelock 'requests' is suggestive if a potential problem but is in no way conclusive nor standalone blocking/limiting. The latter is just asking for trouble in the form of undesirable side effects that can actually lead to worse performance and/or battery life.

A problem that isn't a problem doesn't need fixing.
[BetterBatteryStats] borisboing:
[MENTION=5656100]tnsmani[/MENTION] ／ [MENTION=5488402]Davey126[/MENTION]

Thanks, I'd already tried pretty much every combination other than a clean flash - which I've now done.

With any LineageOS 14 based ROM (the three current nightly release of LineageOS for MicroG, the three current nightly release of LineageOS official, and the last version of ResurrectionRemix); using either of the, included kernel, squid2's kernel, or the somefreak kernel all cause this device to lose 3-4% battery an hour because of not dozing.

After flashing latest stock marshmallow it dozes as you would expect and loses around 2-3% battery overnight. Next step is to try one of the TWRP flashable stock nougat ROMs to see if it is a problem with nougat or a problem with the kernel used by Lineage--everything is pointing at it being a kernel problem, weird that no real mention of it in the LOS thread for this device.

Amplify, Greenify, BBS, and WakelockDetector were just installed to help me identify the cause of the battery drain during screen-off. I have little use for either amplify or greenify-I'm going to be keeping only apps I want to be active on this device-so there is no question of me installing any of them other than BBS once I'm sorted. :>
[BetterBatteryStats] natri23:
My battery drained horribly while sleeping, losing 4% in 6h. Can you help me read the dump?
[BetterBatteryStats] 93fuelslut:
Thanks for providing the link. I did search for "how to post a log". A member mentioned about using the share function in the BBS app. But the options are Gmail, or telegram. Which is useless for sharing on xda.

---------- Post added at 12:55 AM ---------- Previous post was at 12:54 AM ----------

How did you post your dump/log
[BetterBatteryStats] SteveYoungs:
Ya know, looking at this in a glass is half-full kinda way, that equates to 150 hours before your battery is empty. That's less than a day short of a week. :)

Yeah, yeah, I know, Doze is supposed to be better than that. :)
[BetterBatteryStats] natri23:
I know, but using a Pixel XL, it should be around 1%. I only get close to 4h screen on time during the day so it's not something I used to

---------- Post added at 01:27 AM ---------- Previous post was at 01:23 AM ----------

Press Share then press Save. A dump should be on your internal storage
[BetterBatteryStats] Lughnasadh:
Your idle drain was .7%/h. Seems perfectly acceptable to me.
[BetterBatteryStats] natri23:
In deep sleep? Nah, it supposed to be 0%/h. At least with a Pixel XL
[BetterBatteryStats] Lughnasadh:
Well, first of all, you weren't in deep sleep 100% of the time. And even in deep sleep phones still do stuff in the background. If you are aiming for 0% idle drain then the only thing you can really do is shut off your phone.
[BetterBatteryStats] natri23:
I know you are trying to help. But if you cant read my dump then you cant really help me. There is something wrong with my phone and I know it.
[BetterBatteryStats] 93fuelslut:
Yes it is on my internal storage. But I'm asking how did you post it on Xda
[BetterBatteryStats] githyanki:
Facebook, nanohub, and speed test were your top drains. They were not significant, but if you want to reduce your idle drain, start by removing apps that run in the background.

Getting to 0 drain is is a great goal, but will require some extreme sacrifices, even on a pixel 2. The best way to achieve that will be to not use gapps.
[BetterBatteryStats] natri23:
What is nanohub? Is that a system app I can disable?
[BetterBatteryStats] githyanki:
I don't know, it showed up on your dump and i didn't recognize it, so i thought it was an app you installed.
[BetterBatteryStats] DB126:
Not surprised the abnormal idle drain received little attention in the Harpia LOS thread. That community seems more focused on performance (and when Oreo will be available) than efficiency.

I doubt core Nougat is the problem but rather how these custom Harpia ROMs are spun up. Likely a generic component driver issue. Lenovo is now pushing out their own Android 7.1.1 build for this device. Be shocked if it exhibited the same behavior.

---------- Post added at 05:47 AM ---------- Previous post was at 05:42 AM ----------

Ultimately you many want to retain Greenify to rein in 'bad actors'...or to quickly verify whether an app is contributing to excess drain. It is particularly effective when used in combination with Xposed Framework. Food for thought ...

---------- Post added at 06:20 AM ---------- Previous post was at 05:47 AM ----------

Well I can certainly read "your dump" and can say with confidence the battery did not drain "horribly" while the device was "sleeping" (0.75%/hr loss is within norms for a Pixel XL). Nor is there anything "wrong" with your phone. Is there room for improvement w.r.t app selection/behavior? Clearly yes as advised by another poster. Can you achieve "0%/hr" idle drain without shutting off the device? Nope, even with Micro G and other concessions. Anything below 0.5%/hr is quite good; approaching 0.2-0.3% will take considerable effort and is probably not sustainable. Setting realistic, obtainable goals is one of the first steps in achieving power/performance zen.

Listen to the folks in this thread; most know what they are talking about and are happy to present helpful guidance to willing recipients.
[BetterBatteryStats] timytimy:
almost 8 hours screen-off 0% drain :eek:

wow finally found a custom rom*mokee* for my lenovo P2..
[BetterBatteryStats] DB126:
While the few metrics presented appear favorable the "0% drain" is a statistical anomaly likely related to sampling interval. Power was consumed; it just didn't register on the fuel gauge.
[BetterBatteryStats] Khotu:
Yep I have the same issue :/ and system is the highest alarm and battery drainer:(
[BetterBatteryStats] tojnk:
Battery drain on Samsung Galaxy S6

Suffering from high battery drain during the day on my Samsung Galaxy S6.

Two logs:

During the night (attachtment _night.txt) the Level lost is [0,8%/h], which is perfectly acceptable to me. Log is recorded respecting the rules in the first post.

But somehow during the day (attachtment _day.txt) it goes to [3,4%/h], which is not acceptable to me, because it sometimes is not enough for 1 day of usage without recharging in between.

Now this second log is not respecting all rules in the first post, because I have to use my phone from time to time during the day. But I hope I can get some help nonetheless. I notice the following things:

Awake (Screen Off) is 6 h 29 m 36 s 27,4%, this seems very high to me, because Screen On is only 1 h 3 m 14 s 4,4%

Dropbox seems to be very busy, but I set it to upload only when connected to charger: *job*/com.dropbox.android/.camerauploads.CameraUploadsScanAndUploadJobService (com.dropbox.android.Dropbox): 3 h 1 m 47 s Count:46 12,8%

ssp_wake_lock (*api*): 2 h 5 m 26 s Cnt:(c/wc/ec)4195/0/0 8,8% Getting a lot of ssp_wake_lock, what is causing this?

Hope someone has some useful insights in how to reduce the battery drain.
[BetterBatteryStats] alireza_simkesh:
Exactly, system is on the top on the alarm list and inside that, job.delay is the highest intent with 1000 alarms.
[BetterBatteryStats] DB126:
- night log looks fine; typical behavior/drain for device type

- day log is largely unusable due to high screen-on time; simply too much noise to accurately pinpoint potential offenders

- that said dropbox is a problem; always busy identifying potential sync candidates it is not allowed up upload/download

- best path forward is to systematically disable apps (preferably one at a time) until you find the culprit(s)

- alternatively, use a tool like Greenify to temporarily hibernate suspected offenders while you observe behavior

- don't get drawn into arguments suggesting nlp (location services) and/or wacklock management is the answer

- ssp_wake_lock appears to be a Samsung thing...or at lease is observed most often on Galaxy series handsets

- suspect when you mitage other potential drainers (looking at you dropbox) ssp_wake_lock frequency will decline

Good luck!
[BetterBatteryStats] chamonix:
New release went up on gplay beta earlier than hockeyapp because hockeyapp is currently doing some maintenance. Sorry for the inconvenience, the release will be published to testers once the maintenance is over.

Release content: a few more fixes of ANRs, we are getting closer to final release :)

Update: 2.3-202 is up now!
[BetterBatteryStats] 93fuelslut:
So my WiFi is off but it's still killing my battery. I'm lost on that too. Has anyone had the issue and what did you do to address it
[BetterBatteryStats] Many40:
I had something similar and in my case disabling "WIFI scannng" option helped (located in Settings>Location>Improve accuracy).
[BetterBatteryStats] DB126:
So why do you claim WiFi is "killing my battery"? The screenshot you included simply shows WiFi was available for 8+ hours - not the amount of power that was consumed. WiFi radios often idle efficiently when not in use. That said, WiFi scanning can be a power suck; you will want to check and disable that if power conservation is your top priority.
[BetterBatteryStats] chamonix:
settings - network ... - wi-fi - wi-fi preferences: is your wi-fi really off?
[BetterBatteryStats] 93fuelslut:
Yes my WiFi was really off. That's why it was weird

---------- Post added at 01:34 AM ---------- Previous post was at 01:30 AM ----------

I disagree. It says "running" for 8hours.

---------- Post added at 01:34 AM ---------- Previous post was at 01:34 AM ----------

I disagree. It says "running" for 8hours.
[BetterBatteryStats] nahoku:
Tried searching in the thread but couldn't find what I was looking for.

The problem I'm having is with a NON-rooted VZW Note 4 on KK 4.4.4. When I run the adb commands, I'm getting an error on the last command. This is the error I see...

Operation not allowed: java.lang.SecurityException: Package com.asksven.betterba

tterystats has not requested permission android.permission.PACKAGE_USAGE_STATS

The other two commands create no errors and appear to go as expected, but without this last one, BBS won't work.

Is this a KK problem? Do I need to change something? Could I be blocking something with Debloater that won't allow the adb command to go through?

Note that on my work phone, NON-rooted ATT Note 4 on Marshmallow, all adb commands went in with no errors and BBS works great!

Thanks for any help!
[BetterBatteryStats] DB126:
As you wish. Read a lot of logs; seen a lot of BBS stats across a wide variety of devices. Let's just say that metric by itself is not immediately concerning from a drain perspective.

While the ROM may claim WiFi is 'off' and likely won't permit communications via that path it doesn't necessarily mean the kernel complied and/or the radio is powered down. That may be by design or represent a bug/error.

WiFi components idle efficiently on newer hardware. Suggest submitting a BBS log for analysis if you feel your device drain is excessive. Most likely one or more apps are the culprit vs the WiFi radio itself.
[BetterBatteryStats] Many40:
Did you read my post?

If yes, did you try what I sugested?

If yes, it wouldn't be necessarily a culprit for your "huge battery drain" (as Davey126 explain to you) but at least might help you to eliminate WIFI scanning on the background for location services and to stop increasing "WIFI Running" at you main BBS section.
[BetterBatteryStats] j1gga84:
Isn't it possible anymore to run BBS beta in system mode? Or is it not necessary for working correctly?

regards
[BetterBatteryStats] 93fuelslut:
Yeah I read your post and it actually helped. My battery drain was just acute after that. I could've sworn I replied to your post to. This xda labs app freezes up at times on replying.
[BetterBatteryStats] 93fuelslut:
Thanks for helping me in this situation. I believe all your claims, I just thought it was odd for wifi to be calculated. I'm just trying to figure out what's causing the rapid drain every other day. I'm a UPs driver so my days are basically the same routine over and over. Same area too. My phone just sits in my pocket and stream Spotify via BT. My SOT might differ 20-30 min. But Android system will be 21% one day and 7% next day. That's a huge gap. Spotify will do the same as well as BT.
[BetterBatteryStats] DB126:
A portion of it may be due to environmental conditions. While travelling your route the mobile radio will ramp power levels up and (hopefully!) down based on signal strength and which tower the phone communicating with (not always the closest). In contrast, WiFi radio consumption should remain fairly steady provided scanning is disabled as there are (presumably) no defined APs within range. Buzz by that Starbucks you have defined and the device will try to connect and keep radio power levels elevated for several minutes after driving away. Still, probably not a big contributor.

BTW - the WiFi radio will likely powered up if BT is on and vise versa as both typically share the same hunk of silicone. Doesn't mean it's active, just powered.

Easy things to try:

- disable location services if not being used for navigation (tough ask)

- configure the Play Store for manual updates

- use an app/tool to explicitly put your device to sleep vs relying on the screen off trigger which sometimes doesn't happen promptly

- if running Marshmallow (Android 6.x) your device may need help maintaining doze while in motion; Greenify can help with this (believe root is required)

If none of the above helps you'll need to do some deeper analysis to figure out what apps/events are triggering screen-off activity. Depends how much effort you want to put into it.
[BetterBatteryStats] 93fuelslut:
Yeah I knew abt signal strength playing a role in battery drain but I didn't know about what you said in your 2nd paragraph. I do greenify as you mentioned above and has helped. But today was a repeat of my original problem that I just have to research further. I finished the day 15 min later than yesterday, same neighborhoods same business in the same order as yesterday. Even did a pickup at the same time as yesterday. Only used Spotify and BT. But here it is- Android system was 14% today instead of 24% yesterday. BT was alot lower and so was Spotify.
[BetterBatteryStats] tojnk:
I disabled dropbox, fitbit and samsung health, but the ssp_wake_locks are still there. Could it be that the ssp_wake_locks are not caused by an app that I installed?

I'm thinking about moving to a different ROM or kernel to see if that solves the problems...
[BetterBatteryStats] DB126:
Yes it's possible. Not everyone experiences (or reports) these wakelocks. Also keep in mind wakelocks themselves are NOT evil and do not necessarily wake the device or keep it from entering a low power state. All depends if a receiver is listening and what actions, if any, are taken. The vast majority of 'spamming' wakelocks are benign.

As for migrating to a custom ROM or kernel:

- is there really a "problem"?

- if so, is the solution worth the time/effort?

- are there other benefits to be gained (features/functionality)?

- you'll likely trade one set of issues for another

Android devices and accompanying firmware/software/apps are not precision instruments that repeatability execute the same code; day-to-day variability is to be expected. Trying to 'perfect' your device is often akin to drinking from the supposed fountain of youth. Lots of skeletons litter the watering hole yet folks continue climbing over the bones it search of an elusive elixir.

In general prefer using my imperfect gizmos vs managing them. Good luck.
[BetterBatteryStats] Osid:
BetterBatteryStats xda edition 2.3-202 (90)

LineageOS 14.1 (based on AOSP 7.1.2)

Logcat main buffer shows lots of:

E StatsProvider: A batteryinfo error occured while retrieving BT data
E StatsProvider: A batteryinfo error occured while retrieving doze mode data

[MENTION=1330150]chamonix[/MENTION] in com/asksven/android/common/privateapiproxies/BatteryStatsProxy.java you're using, through reflection, internal methods removed from AOSP 6.0 release (see https://github.com/aosp-mirror/plat...2cd7eb4#diff-d6d7a7c340a94b0f80e21d7074a140b9), so BT and Doze times aren't retrieved.
[BetterBatteryStats] Keive:
Same problem here on a non-rooted Pixel 2 XL.
[BetterBatteryStats] vasujahagirdar:
Download manager issue

Hi all,i followed the guide in op to prevent wakelocks( I use greenify, force doze & my Android tools) , but now when I try to download some thing on wifi , download messenger pause when screen is off!! How to prevent it & to get continue download even when screen is off?
[BetterBatteryStats] chamonix:
I am not sure that I get your conclusion but am happy to look into the problem closer but I need some more info.

Here is the code that retrieves the BT stats:

if (sharedPrefs.getBoolean("show_other_bt", true) && !bWidget)
{
try
{
if (Build.VERSION.SDK_INT >= 21)
{
timeBluetoothIdle	= mStats.getBluetoothInStateTime(BatteryStatsTypes.CONTROLLER_IDLE_TIME, statsType) / 1000;
timeBluetoothRx	= mStats.getBluetoothInStateTime(BatteryStatsTypes.CONTROLLER_RX_TIME, statsType) / 1000;
timeBluetoothTx	= mStats.getBluetoothInStateTime(BatteryStatsTypes.CONTROLLER_TX_TIME, statsType) / 1000;
timeBluetoothEnergy	= mStats.getBluetoothInStateTime(BatteryStatsTypes.CONTROLLER_ENERGY, statsType) / 1000;
}
else
{
timeBluetoothOn = mStats.getBluetoothOnTime(batteryRealtime, statsType) / 1000;
}
}
catch (BatteryInfoUnavailableException e)
{
timeBluetoothOn = 0;
Log.e(TAG,
"A batteryinfo error occured while retrieving BT data");
}

}

as you can see from SDK21 another method is used to retrieve BT stats: getBluetoothControllerActivity

try
{
//Parameters Types
@SuppressWarnings("rawtypes")
Class[] paramTypes= new Class[2];
paramTypes[0]= int.class;
paramTypes[1]= int.class;

@SuppressWarnings("unchecked")
Method method = m_ClassDefinition.getMethod("getBluetoothControllerActivity", paramTypes);

//Parameters
Object[] params= new Object[2];
params[0]= new Integer(state);
params[1]= new Integer(iStatsType);

ret= (Long) method.invoke(m_Instance, params);

}

Now looking at the diff you linked this method is not there and that is what puzzles me because - looking at the release branches:

- Lolipop has getBluetoothOnTime: https://android.googlesource.com/pl...elease/core/java/android/os/BatteryStats.java

- Marshmallow and on has getBluetoothControllerActivity:

- https://android.googlesource.com/pl...elease/core/java/android/os/BatteryStats.java

- https://android.googlesource.com/pl...elease/core/java/android/os/BatteryStats.java

- https://android.googlesource.com/pl...elease/core/java/android/os/BatteryStats.java

- https://android.googlesource.com/pl...elease/core/java/android/os/BatteryStats.java

Can you refer me to the branches that you diffed?
[BetterBatteryStats] chamonix:
Ok I guess the doc has created some confusion and I have fixed it:

1. you are on BBS version >= 2.3-150 because for any older BBS builds this permission is not required so that would result in the message "....has not requested permission...."

2. this permission was introduced in SDK21 (Lolipop) so on any previous android version the app would not get it granted even if requested in the manifest; this would result in the same error
[BetterBatteryStats] nahoku:
The version I'm running is from Playstore and it says V2.2.2.0... not sure what version 2.3-150 is.

So just to be clear, (cause I'm still confused), BBS can't run on Kitkat unrooted?

By the way, now the first permission "adb -d shell pm grant com.asksven.betterbatterystats_xdaedition android.permission.BATTERY_STATS" is giving me the same error. Not sure what's going on with that. I have since uninstalled the app from my phone. Should I try it again?... (unless it can't run on KK). Do I need to undo any of the adb commands... I've read somewhere trying to figure this all out that the commands are saved on the phone somewhere. Perhaps thats why the error on the first command now? Don't know.

Thanks for your help!
[BetterBatteryStats] chamonix:
You are confusing a few things:

1. when you run the gplay version the adb grant should be for the package com.asksven.betterbatterystats not com.asksven.betterbatterystats_xdaedition (_xdaedition is another version of the same app, distributed by other means)

2. 2.3-XXX is a build of the current development version: you can get it on gplay by applying for the beta programme

3. If your device is not rooted I highly recommend switching to the beta on gplay or to the _xdaedition version (see first posts of this thread)

Hope this helps
[BetterBatteryStats] Osid:
My fault in code review. Looked at the wrong method.

That's correct. But...

From SDK24+ there isn't long getBluetoothControllerActivity(int,int) but only getBluetoothControllerActivity(void) that returns a ControllerActivityCounter object. Which causes on actual code a NoSuchMethodException, catched by your code in BatteryStatsProxy (generic catch(Exception e)) and raising your BatteryInfoUnavailableException.

In order to get times you could use:

/* ... */
BatteryStats.ControllerActivityCounter counter;
final long idleTimeMs = counter.getIdleTimeCounter().getCountLocked(statsType);
final long txTimeMs = counter.getTxTimeCounters()[0].getCountLocked(statsType);
final long rxTimeMs = counter.getRxTimeCounter().getCountLocked(statsType);
final long totalTimeMs = idleTimeMs + txTimeMs + rxTimeMs;

Snippet taken from http://androidxref.com/7.1.2_r36/xr.../internal/os/BluetoothPowerCalculator.java#67.

Similar reason for error message

A batteryinfo error occured while retrieving doze mode data

In this case is a NoSuchMethodException for getDeviceIdleModeEnabledTime missing from SDK24+.

In SDK24+, due to new Doze on the Go, you could use getDeviceIdleModeTime, taking into account maybe Doze Light and Deep, in order to have more detailed infos.

Also getDeviceIdlingTime is changed in SDK24+.

Hope it helps. Do you prefer a post here or an issued opened on Github for the future? Could be helpful a pull request with fixes if you don't have spare time?