Database Info

[Q] Suspend vs sleep (WTR AlarmManager) on Tegra 2

Hi, I'm a Vega owner but we don't have kernel source and given that the Gtab is pretty similar hardware I like to ask a question of you:
Does AlarmManager work while your device is sleeping?
The Android AlarmManager is used by most services but the most obvious and observable is the clock alarm. On any android phone I've used, if the device is sleeping then the AlarmManager will wake it up to perform the task at hand (E.G. switch on the screen and play an alarm, grab some RSS, pull tweets, etc) but from what I've seen the Vega goes straight into a kind of suspend where _nothing_ happens until you press the power button at which point the alarm fires even if it's well overdue. I'm wondering if this is correctable once we get kernel source.
So does having an alarm fire wake up your GTab device? If not are the any custom kernels that have fixed this for you?

Moved to general

SilentMobius said:
Hi, I'm a Vega owner but we don't have kernel source and given that the Gtab is pretty similar hardware I like to ask a question of you:
Does AlarmManager work while your device is sleeping?
The Android AlarmManager is used by most services but the most obvious and observable is the clock alarm. On any android phone I've used, if the device is sleeping then the AlarmManager will wake it up to perform the task at hand (E.G. switch on the screen and play an alarm, grab some RSS, pull tweets, etc) but from what I've seen the Vega goes straight into a kind of suspend where _nothing_ happens until you press the power button at which point the alarm fires even if it's well overdue. I'm wondering if this is correctable once we get kernel source.
So does having an alarm fire wake up your GTab device? If not are the any custom kernels that have fixed this for you?
Click to expand...
Click to collapse
I haven't really noticed in particular, but I can tell you that the G Tablet does plenty of resume/re-suspending when it's suspended, switching between L0/L1/L2 suspend modes, and so on. You can see all that activity from the dmesg output after an extended suspend. I've never tried the clock alarm, so not sure specifically if that can interrupt suspend state, but I wouldn't be shocked.
There is a ton of stuff in the Tegra2 kernel code regarding suspend/resume, so it's definitely possible that when you get the source code for the Vega kernel you can polish up the way it handles suspend/resume. We've had good luck merging up more recent changes from NVidia's mainline to fix some of the original kernel bugs regarding suspend/resume behavior (specifically low voltage states sticking the CPU at low clock speed after prolonged suspend).

Thanks rcgabriel, my worry is that people are currently blaming the lack of wifi during sleep on the failure of things like twitter/rss/etc not updating while the screen is off when in actual fact the AlarmManager events aren't even waking up the unit at all.
Could someone with a Gtab perhaps test if the alarm wakes up their device while it's asleep when they have a spare moment?

SilentMobius said:
Thanks rcgabriel, my worry is that people are currently blaming the lack of wifi during sleep on the failure of things like twitter/rss/etc not updating while the screen is off when in actual fact the AlarmManager events aren't even waking up the unit at all.
Could someone with a Gtab perhaps test if the alarm wakes up their device while it's asleep when they have a spare moment?
Click to expand...
Click to collapse
Hi,
I didn't know you could even do that (no Android phone here) .
My Gtab is stock TNT 3452, and I:
- Set an alarm for 11:25AM (it was 11:21AM)
- Pressed power
- Selected Sleep
- Screen went black
- At 11:25AM, the tablet started buzzing - Screen came on with the time and two buttons, Snooze and Dismiss.
Pretty cool!
I haven't tried the above just letting the tablet go to sleep on its own though.
Also, I can set the alarm to sound, but how do you do those other things like checking RSS, etc.? Is that dependent on an app to do that?
Jim

I have tried Juice Defender to accomplish this. Juice allows me to set the interval at which the tablet should wake, turn on the wifi, allow things like email to be polled then return to sleep. So far I cannot say if it is working or not working.
Before Juice my phone would buzz to say I had email at say 3 am, but the Gtab wouldnt get it until I woke it up hours later. My assumption was that the wifi was turned off when the tablet entered sleep and didnt turn on until I pushed the power button.
Well, after fixing my wifi at home I can say that Juice will allow email polling after the tablet has gone to sleep. this morning when I woke my tab up there were a three emails that arrived at 3 to 5 am in the inbox.

bboyle said:
I have tried Juice Defender to accomplish this. Juice allows me to set the interval at which the tablet should wake, turn on the wifi, allow things like email to be polled then return to sleep. So far I cannot say if it is working or not working.
Before Juice my phone would buzz to say I had email at say 3 am, but the Gtab wouldnt get it until I woke it up hours later. My assumption was that the wifi was turned off when the tablet entered sleep and didnt turn on until I pushed the power button.
Well, after fixing my wifi at home I can say that Juice will allow email polling after the tablet has gone to sleep. this morning when I woke my tab up there were a three emails that arrived at 3 to 5 am in the inbox.
Click to expand...
Click to collapse
i have juice defender but it seems it still cannot prevent wifi going to sleep even though i trigger on certain application and data transmission

Double post, Please ignore [Q] Need app for keeping cpu active despite sleep

Double post, Please ignore ​
hi, guys.
"wake my android pro" is an app that turns on the screen for 500ms every T period, where T is user defined. Problem is i am worried about screen wearing too soon, with all those fire ups.
Next choice is never turning the screen off. That's another component spending its life. I would rather avoid it.
"Regpon" is another app. It keeps wifi working with a wifi wakelock, less than a partial wakelock it seems. Then, anything nit concerning wifi is beyond it. I have tried it but it doesn't sarisfy my need
There is another app, whose name isn't coming to me right now. wakelockcontrol, maybe. It supposedly employs a wake lock. The user would be able to pick the depth of the wakelock. Unfotunately, it achieves even less than regpon in my device.
Finally, if you can point me to a standalone screen on switch, I'll work with that. In other words, a simple app that I can execute programatically with llama or automateit and which only turns the screen on with one tap
ty.

Resume - Suspend app

I have posted an idea for an app on my website which xda says must remain anonymous. Its intent is to prevent distracted driving. It automatically suspends cellphone activity while driving and automatically instates it when you stop driving.
I have no experience with Android. I wondered if it has the necessary API hooks to pull this off. Anyone is free to implement the idea.

Battery Drain and Kernel Wakelocks

I've had this phone for a few days now and I notice some mean battery drain that happens from time to time. I dumped a Bug Report via developer options, and used Google's Battery Historian after leaving my phone unplugged and idle overnight after a full charge and reboot. The tool seems to show that the following kernel wakeup reason seems to be the problem and holding the phone awake for over 1.5 hours:
Code:
Ranking Name Duration/Hr Count/Hr Total Duration Total Count
0 Abort:Wakeup IRQ -1111803216 (null) pending 10m8s737ms 779.87 1h34m13.62s 7243
The only thing that looks remotely relevant is that on the tool WiFi signal strength became weaker when the above wakeup events started.
Has anyone else had similar issues with random battery drains like this and/or happen to know any workarounds?

Mine seems like it is always awake. Android OS has been keeping it awake for 8-9 while I'm at work.

I tried setting wifi to stay on when sleeping when plugged in, after a full idle overnight, I used my phone in the morning and the same issue came up. The ID above was different, but generally the same problem (IRQ with no description pending). Again, it looks to be wifi related based on the battery stats in Historian. I've rebooted, charged up and turned off wifi to see if the problem goes away.

ru_ready said:
Mine seems like it is always awake. Android OS has been keeping it awake for 8-9 while I'm at work.
Click to expand...
Click to collapse
You might want to try enabling developer options and getting a bugreport generated (which has battery stats), and then visualizing it in Google's Battery Historian to see if it is the same problem. Kind of convoluted, I know, but without root, I don't know of any better way to analyze kernel wakelocks (it isn't a partial wakelock issue on my device).

Last night I left my phone idle with wifi off and WLAN Scanning and Bluetooth Scanning off under Location Settings. The battery ran down only 2% over 9 hours and the Wakeup IRQ pending problem did not keep the phone awake!
I am going to try turning wifi back on today but keep the scanning off and see if that keeps this problem at bay. If not, I may use Tasker to force wifi off when the screen is not on and not plugged in.

The wakelocks seem to happen randomly no matter what my wifi settings are. Though I do think it is related to location settings trying to use wifi scanning.
I give up, there is no reason why a phone I just bought should be like this.

Maybe there are some apk wake up the system
@kumodog Maybe there are some apk wake up the system, you can reboot the system and kill all of application programs when you test it in night with wifi on.
After test, you can also use : "adb dumpsys alarm" in command line to find Top Alarms. it will tell you which alarm make system wakeup.

Phone(s) still hot when turned off. Also, wicked power draw.

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?