Hey guys,
I experienced very weird battery behavior tonight.
Before I went to sleep I listend to an audiobook for a bit, played some towerdefense and the battery went down to 88% before I set it to Airplane mode, activated my alarm for the morning and put it on my nightstand.
Usually the battery will drop by less than 5% until morning, which would be expected.
But today when I woke up, battery stats read 35%.
You can imagine that I was quite surprised.
Images are attached.
One thing I also changed (I just remembered) before I went to sleep:
I got rid of the Poweramp widget and put the regular HTC Music widget on my screen, listened to 2 songs to see if it sounded alright, then stopped playback and put it down.
So the only thing that I can imagine right now is the regular Music widget keeping the phone active although no music is playing.
ROM is ARHD 6.2.1 - is this ROM specific?
Help appreciated.
I could be wrong but it looks like something is preventing your phone from sleeping. Go to terminal and type the following 2 lines. You can also run it from adb shell too. Toward the bottom will show some wakelock lines.
su
dumpsys power
Here is a sample from my phone when it had a wakelock issue.
PARTIAL_WAKE_LOCK 'MediaScannerService' activated (minState=0, uid=10014, pid=4932)
Code:
Power Manager State:
mIsPowered=true mPowerState=0 mScreenOffTime=263861 ms
mPartialCount=0
mWakeLockState=
mUserState=
mPowerState=
mLocks.gather=
mNextTimeout=294581118 now=294852985 -271s from now
mDimScreen=true mStayOnConditions=0 mPreparingForScreenOn=false mSkippedScreen
On=false
mScreenOffReason=3 mUserState=0
mBroadcastQueue={-1,-1,-1}
mBroadcastWhy={0,0,0}
mPokey=0 mPokeAwakeonSet=false
mKeyboardVisible=false mUserActivityAllowed=false
mKeylightDelay=6000 mDimDelay=32000 mScreenOffDelay=7000
mPreventScreenOn=false mScreenBrightnessOverride=-1 mButtonBrightnessOverrid
e=-1
mScreenOffTimeoutSetting=45000 mMaximumScreenOffTimeout=2147483647
mLastScreenOnTime=0
mBroadcastWakeLock=UnsynchronizedWakeLock(mFlags=0x1 mCount=0 mHeld=false)
mStayOnWhilePluggedInScreenDimLock=UnsynchronizedWakeLock(mFlags=0x6 mCount=0
mHeld=false)
mStayOnWhilePluggedInPartialLock=UnsynchronizedWakeLock(mFlags=0x1 mCount=0 mH
eld=false)
mPreventScreenOnPartialLock=UnsynchronizedWakeLock(mFlags=0x1 mCount=0 mHeld=f
alse)
mProximityPartialLock=UnsynchronizedWakeLock(mFlags=0x1 mCount=0 mHeld=false)
mProximityWakeLockCount=0
mProximitySensorEnabled=false
mProximitySensorActive=false
mProximityPendingValue=-1
mLastProximityEventTime=143525904
mLightSensorEnabled=false
mLightSensorValue=-1.0 mLightSensorPendingValue=320.0
mLightSensorPendingDecrease=false mLightSensorPendingIncrease=false
mLightSensorScreenBrightness=142 mLightSensorButtonBrightness=0 mLightSensorKe
yboardBrightness=0
mUseSoftwareAutoBrightness=true
mAutoBrightessEnabled=false
mScreenBrightness: animating=false targetValue=-1 curValue=104.0 delta=0.0
mLocks.size=0:
mPokeLocks.size=0:
That's what the shell command gives me.
The important line is toward the bottom. mlocks.size = 0 just means there is no current process that has a wakelock state. What this means is a process was running at some point, enabled a wakelock, and the process exited without removing the lock. Figuring out which process is a problem since there isn't much to go on. The only thing I might try is run the command below in terminal and monitor the wake_count column. The output is a little messy but excel formats everything into nice columns.
cat /proc/wakelocks
Since the only thing that I've done differently than well... ever, was using the original HTC Music player.
I guess there's a bug with the ARHD ROM and the stock player that keeps it active even though nothing is playing.
I'll just stay away from it and use Poweramp instead.
I don't know if this has been mentioned before in this forum.
Like a lot of people with the Shield Tablet, mine was getting very laggy and slow. It was at it's worse when it had been sitting idle for a while (and when not on a charger). I press the on button and it would take 2-3 minutes to become responsive. Since the "doze" function in Marshmallow sucks, I suspected that the slow down was a result of the tablet not executing the "doze" function correctly.
So I rooted the table and with the adb command of "adb shell dumpsys deviceidle disable" was able to disable doze.
Ta-da! No more issues with an unresponsive tablet since doing this. Of course, I'll have to execute this command after each reboot, but I don't care. It's a huge improvement.
Why not just uninstall doze?
Greenify may be the better option.
Used to have the same problem... laggines all over the place. After uninstalling Facebook and the messenger, it feels like a whole new tablet.
Sent from my SHIELD Tablet using Tapatalk
G'day,
I've had some odd issues with two consecutive Xiaomi phones, and I'm hoping someone here can shed some light on it for me.
With both my Mi Note 2, and now my current Mi Mix 3, after less than a year of owning each one (respectively), out of nowhere, the battery life drops through the floor, the phone gets really hot, and most oddly, I got wicked battery drop while the phone is off (e.g. I turned the phone completely off at 77%, and about an hour later, I turn the phone back on and it's at 43%).
On both phones, I've tried a factory reset, but it didn't work. It was, for all intents and purposes, fecked. At the moment, I'm waiting for the 15 day countdown for my Mi Mix 3 bootloader to be unlocked so I can try flashing the EU MiUI ROM and see if that helps, but that's still a hell of a long time to wait with a phone that idles at 50+° C and has a battery life of about 3 hours with minimal SoT.
I've installed BetterBatteryStats (using ADB to provide permissions), CPU-Z, CPU Monitor and Ampere to see if I could get some more information. I found a few things:
1. Somehow, with mobile data and WiFi enabled, the system was drawing SO MUCH power (reported by Ampere) that it literally wouldn't charge while plugged into a 2A wall port. It was drawing like 1300mA when it wasn't plugged in, and when it was, it was STILL drawing about 130mA, meaning no matter what, while the phone was on, I was losing battery.
2. BBS reported the biggest battery killer was under the 'Alarms' tab, caused by Android, which were "Intent: *job.delay*" and "Intent: *job.deadline*". I have literally no idea what these are, what's causing them, or how to stop it triggering.
3. I've done a full factory reset. The first hint that something was wrong was when I noticed that the phone wasn't charging when it was plugged in and turned on. I did the full factory reset, didn't help.
I'm currently running Global MiUI 11.0.4.0, Android 9.
Does anyone have any ideas? I haven't manually updated anything, I'm not particularly rough with the phone, but for two phones in a row, this has come straight out of nowhere. It's a shame, because the Mi Mix 3 has spoiled me with it's 100% screen real estate (no hole-punch, no teardrop for front camera), but I think my next phone is gonna go with something else.
Cheers.
Update: I've taken a squizz at the Google Battery Historian and basically, I have no feckin' idea.
The best I can get out of it is "Yep, something in the labyrinthine generic 'Android' system is causing it, but good luck narrowing it down or stopping it."
That being said, I've found that this Partial Wakelock is triggered fairly often (1-6 times per minute, give or take): IntentOp:.common.broadcast.BackgroundBroadcastReceiverSupport$GmsReceiverIntentOperation
I have no idea what the hell it is or does, and the only information I can find about it is from developers asking questions where it just happens to be part of their codebase, or a breakdown of how the WakeBlock app works.
It's getting woken up about every minute or so (usually more than once a minute). However, the wakelocks appear to be part of the core Google/Android systems that can't be individually disabled.
I'm still feckin' confused.
Overloke said:
Update: I've taken a squizz at the Google Battery Historian and basically, I have no feckin' idea.
The best I can get out of it is "Yep, something in the labyrinthine generic 'Android' system is causing it, but good luck narrowing it down or stopping it."
That being said, I've found that this Partial Wakelock is triggered fairly often (1-6 times per minute, give or take): IntentOp:.common.broadcast.BackgroundBroadcastReceiverSupport$GmsReceiverIntentOperation
I have no idea what the hell it is or does, and the only information I can find about it is from developers asking questions where it just happens to be part of their codebase, or a breakdown of how the WakeBlock app works.
It's getting woken up about every minute or so (usually more than once a minute). However, the wakelocks appear to be part of the core Google/Android systems that can't be individually disabled.
I'm still feckin' confused.
Click to expand...
Click to collapse
I think it's an issue with your network operator
XDRdaniel said:
I think it's an issue with your network operator
Click to expand...
Click to collapse
Any ideas as to how I'd further troubleshoot? I've gone into *#*#4636#*#* and changed the sort of signal it looks for, but it doesn't appear to have fixed anything.
In case anyone is interested, I've attached on of my Bugreports (from running adb bugreport), which can be viewed through Google Battery Historian.
I'm not saying there's a cash prize for anyone who can tell me what is happening and why, but I'm also not saying that there isn't.
So, I think we have our culprit (maybe).
I have attached several screenshots from a Battery Historian I took after having my phone on all day. The total phone on time was about 4-5 hours with, no joke, maybe 10 seconds of screen on time. Let's go through this absolute bullshittery together, shall we?
Battery - Full Time: The full length of time captured by the Battery Historian/bugreport command. It's in Zulu Time (GMT+0) and I'm in Australia (GMT+10), so the line starts going up at 5PM last night, which is more or less when I plugged it in to charge. You can see, while 'off', it took 16 hours to charge to 100%, and this was from a 'cold boot' (phone is completely dead), so it didn't have any information about what had been running, etc.
Battery - Discharge: The five or so hours time in which the entire battery discharged, starting from when I woke up in the morning and got ready for work. In the Screen row, you can see the small, three-to-four second windows throughout the day that I turned the phone on to check the battery. For almost the entirety of the time, the screen was off. You can see where the line next to Phone State goes from black to navy blue. This indicates that the phone has been put into Airplane Mode - you can see this is also where everything relating to network connectivity or mobile strength completely disappears. You can also see that App Processor Wakeup completely dies here - that means that actual installed apps (including GOOGLE_SERVICES and Xiaomi's preinstalled Facebook app stop sending commands to wake the CPU.
Battery - Cause: At least once a minute, usually more, two things fire that keep the CPU running - Abort:Wakeup IRQ detected during suspend: 999 msoc-delta and Abort:Wakeup IRQ detected during suspend: 663 qpnp_rtc_alarm. I have no feckin' idea what either of those are, and Googling results in either developer guides or threads that lead nowhere. If anyone knows what they are, for the love of God let me know.
Battery - Foreground Processes: While the phone was off, with every app closed, in Airplane Mode, we can see that there are still four apps that are somehow in the foreground: com.miui.mishare.connectivity (odd, since there's no connection), com.miui.securitycenter (which I tried disabling through ADB last night, and it stopped my phone from booting. Oops), com.miui.notification, and com.android.providers.contacts (which disappeared shortly after entering Airplane Mode).
Battery - Video: You can see here, for the ENTIRETY of the time that the phone was turned on, this odd Video row was enabled. There is no other information about it - what causes it, where it's coming from, what 'Video' means, anything.
Battery - 7 Second Slice: This is just a close-up of a seven-second period of time, wherein the above 999 msoc-delta and 663 qpnp_rtc_alarm kept the CPU running six times within 7 seconds. Not a lot on its own, perhaps, but over the course of hours, it clearly causes issues.
I've also attached the latest bugreport where I took these screenshots from if anyone wants to try and make sense of it.
--
This looks to me like an hardware issue more than anything, what is the idle state of the cpu?
Overloke said:
So, I think we have our culprit (maybe).
I have attached several screenshots from a Battery Historian I took after having my phone on all day. The total phone on time was about 4-5 hours with, no joke, maybe 10 seconds of screen on time. Let's go through this absolute bullshittery together, shall we?
Battery - Full Time: The full length of time captured by the Battery Historian/bugreport command. It's in Zulu Time (GMT+0) and I'm in Australia (GMT+10), so the line starts going up at 5PM last night, which is more or less when I plugged it in to charge. You can see, while 'off', it took 16 hours to charge to 100%, and this was from a 'cold boot' (phone is completely dead), so it didn't have any information about what had been running, etc.
Battery - Discharge: The five or so hours time in which the entire battery discharged, starting from when I woke up in the morning and got ready for work. In the Screen row, you can see the small, three-to-four second windows throughout the day that I turned the phone on to check the battery. For almost the entirety of the time, the screen was off. You can see where the line next to Phone State goes from black to navy blue. This indicates that the phone has been put into Airplane Mode - you can see this is also where everything relating to network connectivity or mobile strength completely disappears. You can also see that App Processor Wakeup completely dies here - that means that actual installed apps (including GOOGLE_SERVICES and Xiaomi's preinstalled Facebook app stop sending commands to wake the CPU.
Battery - Cause: At least once a minute, usually more, two things fire that keep the CPU running - Abort:Wakeup IRQ detected during suspend: 999 msoc-delta and Abort:Wakeup IRQ detected during suspend: 663 qpnp_rtc_alarm. I have no feckin' idea what either of those are, and Googling results in either developer guides or threads that lead nowhere. If anyone knows what they are, for the love of God let me know.
Battery - Foreground Processes: While the phone was off, with every app closed, in Airplane Mode, we can see that there are still four apps that are somehow in the foreground: com.miui.mishare.connectivity (odd, since there's no connection), com.miui.securitycenter (which I tried disabling through ADB last night, and it stopped my phone from booting. Oops), com.miui.notification, and com.android.providers.contacts (which disappeared shortly after entering Airplane Mode).
Battery - Video: You can see here, for the ENTIRETY of the time that the phone was turned on, this odd Video row was enabled. There is no other information about it - what causes it, where it's coming from, what 'Video' means, anything.
Battery - 7 Second Slice: This is just a close-up of a seven-second period of time, wherein the above 999 msoc-delta and 663 qpnp_rtc_alarm kept the CPU running six times within 7 seconds. Not a lot on its own, perhaps, but over the course of hours, it clearly causes issues.
I've also attached the latest bugreport where I took these screenshots from if anyone wants to try and make sense of it.
Click to expand...
Click to collapse
Same problem. Any solution?
Hi all,
I wrote a program which runs in Terminal on my phone (Android 9), this program makes some computations and writes the result in a file. No input, no app.
I have realized that after a few minutes I suspend the display the execution is frozen and resumes when I switch it on again, very annoying since my goal is to take advantage of the CPU during day and night.
Is there any way to avoid this? Note the phone is not rooted
Thanks a lot to whomever will reply
S
The terminal's output device is phone's screen. It should be obvious that terminal app interupts working when you suspend the screen and resumes working when you turn on screen again.
No, should not be, in the options of Terminal there is something like Activate Wakelock which should make so that the processing continues even in suspension, But does not seem to work
Hi,
I have a question about runnig my old Samsung (XCover 3 - SM-G388F) without battery.
I have connected wires (usb cable connected to charger) dierctly to pins under cover and it works fine. The problem is that system counts the battery load percentage down and when it reaches 0% the phone is shutting down. When I boot it up system shows again 100% and counts down.
Is there a way to bypass this (phone is rooted if it helps)? I need it runnig 24/7.
ok, my mistake
I was trying to serach an answear before I posted and didn't find anything.
But when I posted this question I got "suggested" thread with answear
"Here's how to fix the battery percentage going down:
-You have to be rooted
-Use the terminal emulator app
-Type SU (switches from $ to #)
-Type this command to keep the phone at 100%
dumpsys battery set level 100
-Type this command to tell the phone that the charger is plugged in
dumpsys battery set usb 1
Everytime you reboot it reverts to stock settings. So I use a tasker script that runs the above commands on every boot."
I leave it here for other
Chears
wouldnt it be possible to keep the battery in and just prevent it from charging ?
I tried that with an app called "Battery Charge Limit" but from time to time the phone was shutting down.