I have found the reference to "*alarm*:*job.heartbeat*" in JobSchedulerService.java and it appears that as the name of file suggests, "*alarm*:*job.heartbeat*"is related to scheduling of jobs and when I took the log of dumpsys batterystats, I found out that every 30 minutes, the phone come out of doze by this "*alarm*:*job.heartbeat*". What is the role of "*alarm*:*job.heartbeat*" and can we configure the interval? (I'm rooted)
I think it is related to the android standby bucket. and maybe android 9 adaptive battery. and it is deeply integrated into the system. so it is not as simple as a system app uninstall. and the process is responsible for it is (system_server) .and if you delete it you will have to re-flash your ROM. and using Battery Historian *alarm*:*job.heartbeat* is waking the device every 1 hour and half (90 minutes) but in my case, it does not wake the device out of
Doze. see the image below if the doze is off there will be a gap. and there is a gap because I turned my screen on. my theory that the android system Schedule it to work to check for any change in the bucket and behave accordingly to it
Related
I have an app which runs a background service overnight. It's triggered to run by an alarm clock app.
The app spends the night uploading data off the phone's external SD card onto Dropbox. It worked seamlessly on previous versions of Android but is not working on Pie. The background service is killed after running for about two hours every night. Interestingly, however, I've noticed that if I make a tiny change to my code, e.g. editing a string, and then run a debug, the app runs perfectly the next night but then on subsequent nights, goes back to being killed after two hours.
I've tried the following:
Using a foreground service with a persistent notification
Opening and closing an Activity after the app is opened so it's in the recent apps list
Making the app a device administrator
Disabling battery optimisations for the app
CPU and Wifi wakelocks
Running a thread with an infinite loop that uses root privileges to adjust the app's minfree values every five seconds
Disabling Pie's adaptive battery manager feature during the night
Despite all of these mechanisms, the app still gets killed. My theory is that there's some kind of artificial intelligent battery manager/performance optimiser on the phone that picks up that the app runs all night and decides to kill it in the future but then gets reset when I re-install the app.
I've tried everything and I still can't seem to find a solution. Can someone please point me in the right direction? I'm sure there's some root/reflection thing that I can do to fix this but I just don't know what it is!
I found the problem! Turns out my phone had a service called G3 which was killing the app to "save power". Apparently, this service is useless so I uninstalled it and the problem was solved instantly!
I used the following command:
adb shell pm uninstall --user 0 com.evenwell.powersaving.g3
adb shell pm uninstall --user 0 com.evenwell.powersaving.g3.overlay.base.s600ww
Pretty annoyed that this service took to killing an app that had root, administrator privileges and permission to avoid battery optimisations - how obvious do I have to make it that I want the app to stay alive?!
try job schedular
https://developer.android.com/reference/android/app/job/JobScheduler.html
https://developer.android.com/topic/performance/scheduling.html
use Alarm manager
https://developer.android.com/reference/android/app/AlarmManager.html
As one of the changes that Android 8.0 (API level 26) introduces to improve battery life, when your app enters the cached state, with no active components, the system releases any wakelocks that the app holds.
In addition, to improve device performance, the system limits certain behaviors by apps that are not running in the foreground. Specifically:
Apps that are running in the background now have limits on how freely they can access background services.
Apps cannot use their manifests to register for most implicit broadcasts (that is, broadcasts that are not targeted specifically at the app).
By default, these restrictions only apply to apps that target O. However, users can enable these restrictions for any app from the Settings screen, even if the app has not targetted O.
Nothing will work like job schedular or Alarm manager
Your problem will be only resolved by using WorkManager
With Android 9 battery optimization has been pushed further and apps are classified into standby buckets depending on how much the user has recently interacted with the app (see Android documentation). The system limits the device resources available to each app based on which bucket the app is in.
How can I keep my app in the "working set" bucket, even if the user does not interact with it? (I do not find any permission or similar that allows to override this power management feature.)
More specifically, I have a PeriodicWorkRequest that must run once every 30 minutes with a flexibility of 10 minutes. However, if I understand the table of imposed power restrictions such a work request could be deferred up to 24 hours, if my app is put into the "rare" bucket. (Under the hood, the Work library uses the job scheduler.)
Further Details on the Scenario
The app is safety critical and not intended for public use but only meaningful to a restricted set of users. However, if anyone else uses this app nothing bad happens, but the app does not serve any purpose for him/her.
More precisely, the app is connected to the central fire alarm station of a specific building. All employees are asked to install the app on their smartphone. If the central fire alarm station of that building detects an event, it sends a push notification (via FCM) to all registered smartphones and the app plays an alarm sound. This implies nothing happens for (hopefully) a long time and the user has no intention to interact with the app in any way. The app itself does not provide any interaction, it only illustrates the current state (which is either a green "OK" sign or a red "ALERT" sign) and waits in the background for the rest of the time.
As the app is safety critical, the fault condition that the app looses the connection to the server must be detected. To this end, the server actually sends messages in the background periodically, i.e. a sequence idle, idle, idle, idle, alarm, alarm, alarm, alarm, idle, idle, idle, ... Normally, messages are broadcasted with low FCM-priority every 5 minutes. If the state changes, an additional message is immediately sent with high FCM-priority (cp. bold letters).
The app implements a watchdog using PeriodicWorkRequest as mentioned in the question above. This watchdog does twofold: Wake up the device and make the device receive all (low priority) FCM-messages that have been postponed and then check if the most recent message is not older than 1.5*5min. If this fails, the app tries to re-register itself with the server and waits if state messages start to come in again. If this fails too, the app presents a warning to the user.
Everything works fine so far. The only problem is the new kind of battery optimization which slows down the watchdog at some point of time. Of course, I could hand out a standing regulation that forces all employees to open the app once in a while and simply look at it, but that is a little bit silly.
I could re-phrase the question above: I totally understand why Android is pushing battery optimization to an edge. There are a lot of (insane) apps that have misused periodic tasks for purposes that should have been solved differently. And the web is still full of "idiotic" programming advises, like checking a specific webpage for modifications every 5secs. However, how am I expected to write safety critical apps that require a watchdog for legitimated purposes if battery optimization becomes more and more an obstacle. Google's thumb of rule "if the user does not use your app, it is obviously unimportant to him/her" does not apply here.
How can I keep my app in the "working set" bucket, even if the user does not interact with it?
You can't and you shouldn't. That same documentation says:
Do not try to manipulate the system into putting your app into one bucket or another. The system's bucketing methods can change, and every device manufacturer could choose to write their own bucketing app with its own algorithm. Instead, make sure your app behaves appropriately no matter which bucket it's in.
Even whitelisting won't work in your case because:
the whitelisted app’s jobs and syncs are deferred
There's this too:
Note: Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected.
If your app is site-specific and not distributed from the play store, you can ask your users to disable battery optimization for your app. That will exempt your app from the standby app bucketing system. Obviously it's not a great user experience to have to go through a bunch of menus to disable some obscure feature, but given that you are considering forcing users to open the app manually, disabling battery optimization would be preferable.
I have an open source gps tracking application that has been around for many years. Recently, I have been getting complaints that in android nougat, instead of getting updates once a minute, people are getting updates from the phone once every five minutes when the phone is unplugged.
There is something going on with the power saver mode even though we tried turning it off.
Is there a way to force a phone to get gps updates at a specified time when unplugged?
Here is the code if anyone wants to see it but I don't think it's a problem with the code. It has been very stable for years.
https://github.com/nickfox/GpsTracker/blob/master/phoneClients/android/app/src/main/java/com/websmithing/gpstracker/LocationService.java
thanks.
One change in Android 7/Nougat was that the Doze is now "more aggressive". In Android 6/Marshmallow the doze mode kicked in when the screen was off, the device was running on battery and it was stationary.
(This is documented in Optimizing for Doze and App Standby)
Now in Android 7 the conditions are just screen off and running on battery.
(This is documented in Android 7.0 Behavior Changes)
Apps can be white-listed to be exempt of the restrictions if they break the core functionalility of it. In your case they do as the GPS tracker needs to record coordinates in real time.
There's a list of Acceptable Use Cases for Whitelisting
This includes:
Task automation app | App's core function is scheduling automated
actions, such as for instant messaging, voice calling, new photo
management, or location actions.
Users can white list an app manually on their own in the device settings or whitelisting can be requested by the app and approved or rejected by the user.
This is covered in Support for Other Use Cases
Quoting:
An app can fire the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent
to take the user directly to the Battery Optimization, where they can
add the app.
An app holding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission can
trigger a system dialog to let the user add the app to the whitelist
directly, without going to settings. The app fires a
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intent to trigger the
dialog.
The user can manually remove apps from the whitelist as needed.
The last point is important of course, but luckily the whitelisting status can be checked programmatically:
An app can check whether it is currently on the exemption whitelist by
calling isIgnoringBatteryOptimizations().
So, dealing with the Doze mode is one thing to study at least.
Another issue is keeping the Service running in general. But the Service getting killed by the system might result in more random time intervals. There are of course the classic things like using START_STICKY or running as a foreground service.
How to opt-out my app from android M DOZE mode ?
Is there a standard way to include and exclude apps from DOZE and auto standby selectively at run time ?
How to opt-out my app from android M DOZE mode ?
You can't by any known mechanism.
Is there a standard way to include and exclude apps from DOZE and auto standby selectively at run time ?
In theory, the user can toggle an "Ignore optimizations" option in Settings, to put the app on a whitelist of apps that should not go into app standby mode. This will not affect doze mode.
Quoting somebody who I believe is Dianne Hackborn:
While the device is dozing, syncs and jobs are turned off globally, putting an app on the whitelist does not change the behavior for them. This is the intended behavior, as is the lack of free use of the alarm manager. (One of the key aspects of all of these is that they are ways to cause the device to wake up, and anything that causes it to wake up will have a significant impact on battery life in the durations we want to last while dozing, so it is simply not allowed.)
While dozing, the AndAllowWhileIdle APIs allow you to wake up the device at most once every 15 minutes; when not dozing this is raise to once every minute. When the device is in idle maintenance mode, all of the doze restrictions are removed (so AllowWhileIdle can happen once a minute).
Note that "idle maintenance mode" is presently undocumented. My guess is that this refers to a device that is idle but is charging.
i have coded my 2nd android application that switches audio profiles based on a certain schedule (date and time only as of now)....the code is working without any issues if i run the code using the emulator via eclipse...however i recently exported the apk and installed it on my At&t Samsung Galaxy S2 and added the same profile schedule as the emulator, but for some odd reason the timertask is not executing after the 1st time...
For Example:
Here is the Profile Schedule from my phone as well as the emulator:
8AM - 5:30PM -- Work
5:30PM - 10PM -- Home
10PM - 8AM -- Sleep
once the above is scheduled and i press the activate button on the main activity..a background service runs switching from one profile to the next until it is de-activated...
the only difference i have noticed between the emulator and my phone is that, the emulator screen never shuts off...so im guessing that the emulator doesnt ever go on sleep? whereas, my phone's screen turns off after about 30 seconds of inactivity, in addition to the lock screen...furthermore, i turned on USB debugging on the phone and plugged it directly into the computer and from what it seemed like, the code was executing, switching one profile to the next, on my phone without any issues...(Note that, when i was doing this testing, i used smaller time intervals in the profile schedules)...Additional details: i have also added startForeground() in my service code and ensured that the service is not getting terminated...
does anyone have any idea on what im missing, or what i can do to get around this bizarre problem?...i did do some research before posting this, and found out few posts that recommended using: Android's PowerManager...
Thanks for your input
Nothing weird about this: if the phone is asleep, the CPU is off and you cannot execute code. Don't use TimerTask on Android, use AlarmManager to schedule recurring tasks. It's implemented in the kernel and can wake up the phone if necessary (that might have a negative impact on battery life, so use with caution). Also look into WakeLock's.
http://developer.android.com/reference/android/app/AlarmManager.html