3

I'm creating an app to connect with BT device to collect heath data (i.e.: body temperature).

The sensor sleeps for periodic time and wakes up only for limited window of time to connect.

I've tried to create AlarmManager which fires Foreground Service with setExactAndAllowWhileIdle() and it is working as expected for periods higher than 9 minutes,

but below 9 minutes it goes to doze mode and do not fire AlarmManager BroadcastReceiver.

From documentation I do not understand if adding app to battery optimalization whitelist will allow AlarmManager to trigger more offen https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases

For example, the whitelisted app’s jobs and syncs are deferred (on API level 23 and below), and its regular AlarmManager alarms do not fire

What are the regular alarms? is setExactAndAllowWhileIdle() regular?

Any clarification will be appreciated

EDIT:

I understand that setExactAndAllowWhileIdle() will trigger event in doze mode for periods longer than 9 minutes, question is does adding app to whitelist will allow it to trigger more often

wojciech_maciejewski
  • 1,277
  • 1
  • 12
  • 28
  • Nope! setExactAndAllowWhileIdle is the extreme flag when you need to fire the alarm no matter what happens but it is restricted for the smallest interval of 9 minutes. – Tarun Kumar Jul 18 '18 at 10:17
  • Doze is a system wide concept. Adding an app to the so called white list does not prevent doze. That statement is saying that regular alarms like set() and the so called setExact() won't fire during doze, but the idle methods like setExactAndAllowWhileIdle will fire during doze maintenance windows. – Elletlar Jul 18 '18 at 10:22
  • Hey, thanks for comments, I understand concept of doze, and firing alarms, question is does adding to whitelist will allow me to trigger alarms often than 9 minutes – wojciech_maciejewski Jul 18 '18 at 10:29
  • 1
    No whitelisting will not do that, but setAlarmClock can fire that frequently. – Elletlar Jul 18 '18 at 10:30
  • alarmClock or run foreground service during whole time, not only measure times – wojciech_maciejewski Jul 18 '18 at 10:31
  • 1
    Yes except on some Android 6 devices where foreground services get dozed unless they are in a separate process. – Elletlar Jul 18 '18 at 10:34
  • @Elletlar so, you say setAlarmClock is more reliable than setExactAndAllowWhileIdle? – Mitulát báti Apr 13 '20 at 17:56
  • 1
    @Mitulátbáti The AlarmManager APIs are notorious for having different behaviours on different versions of Android. The AlarmClock API used to be exempt from 'doze', but the current documentation hints that this is no longer the case. You would be wasting your time trying to find specific guidance because Google are intentionally vague regarding 'doze'. But to answer, I do not believe there is any AlarmManger API that is documented to fire more often than setAlarmClock. – Elletlar Apr 15 '20 at 17:39
  • Present Docs for setAlarmClock: these alarms will be allowed to trigger even if the system is in a low-power idle (a.k.a. doze) mode. The system may also do some prep-work when it sees that such an alarm coming up, to reduce the amount of background work that could happen if this causes the device to fully wake up -- this is to avoid situations such as a large number of devices having an alarm set at the same time in the morning, all waking up at that time and suddenly swamping the network with pending background work. As such, these types of alarms can be extremely expensive on battery... – Elletlar Apr 15 '20 at 17:40

1 Answers1

3

What are the regular alarms ? is setExactAndAllowWhileIdle() regular ?

No. setExactAndAllowWhileIdle() is not regular. Regular alarm could be AlarmManager alarms set though setExact() and setWindow().

but below 9 minutes it goes to doze mode and do not fire AlarmManager BroadcastReceiver

It has restrictions on how frequently you can set alarm.

Based on the documentation:

To reduce abuse, there are restrictions on how frequently these alarms will go off for a particular application. Under normal system operation, it will not dispatch these alarms more than about every minute (at which point every such pending alarm is dispatched); when in low-power idle modes this duration may be significantly longer, such as 15 minutes.

You can refer to Doze restrictions which says:

Standard AlarmManager alarms (including setExact() and setWindow()) are deferred to the next maintenance window.

  • If you need to set alarms that fire while in Doze, use setAndAllowWhileIdle() or setExactAndAllowWhileIdle().
  • Alarms set with setAlarmClock() continue to fire normally — the system exits Doze shortly before those alarms fire

For Whitelist:

Apps available in whitelist are partially exempt from Doze and App Standby optimizations. This doesn't mean they have full access to and could perform tasks during doze mode. An app that is whitelisted can use the network and hold partial wake locks during Doze and App Standby. However, other restrictions like jobs being differed, standard alarm trigger are still imposed

Note: You should check acceptable usecases for whitelisting an app.

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.

Sagar
  • 23,903
  • 4
  • 62
  • 62
  • Nice answer. One more thing that might be good to include, what is the full benefit of having a user whitelist the app? – Elletlar Jul 18 '18 at 10:27
  • probably will create all the time running foreground service, and just trigger BT connection on periods triggered from AlarmManager – wojciech_maciejewski Jul 18 '18 at 11:08
  • @wojciech_maciejewski I have done some testing on Pixel. I found that after 4 hours the foreground service was terminated. Seems they optimize for CPU intensive work. Remember to test this case if its so crucial – Sagar Jul 18 '18 at 11:09
  • hmm that is not a good info for me, I can always prompt user to hold device under power :P Thanks for tip – wojciech_maciejewski Jul 18 '18 at 13:14