0

I'm developing an app that requires the user's movements to be tracked continuously - using a foreground service. The app should work even when it's in background and screen is off.

I don't really need to track it in real time, so, to avoid draining battery, my first solution was a scheduled thread that would fire every 1 minute, fire a location listener, get a location and then turn it off.

This works well. But of course I eventually found out that after Doze mode kicks in, it would defer that task to many minutes - sometimes hours - ahead. Which kind of kills the purpose of my app.

After some research and trials I found that I could use the AlarmManager for that by calling setExactAndAllowWhileIdle, which does a better job but still suffers from the same issue.

Then I found that setAlarmClock circumvents Doze mode consistently (at least on my test device: a Pixel 3a). One thing that it does differently, though, is that it adds a "clock" icon to the status bar indicating that there's an alarm set up.

Now, I can see why Doze mode exists (abuse) and why setAlarmClock works around it (we need alarm apps to be reliable). And for that reason, I'm not sure if I should proceed with using it and if it's even something that could get my app blacklisted or if it's a bad practice overall - using alarms to retrieve location definitely looks wrong, but documentation on the matter is pretty incomplete at the moment.

I can say this method drains VERY little battery - as little as 1% for 24h usage. And it's probably the best solution for my use case.

So, is it ok to keep using this method? Any chances this could backfire somehow?

arvere
  • 727
  • 1
  • 7
  • 21
  • Here is the documentation provided by Google. Seems like you are on the right track, and I don't see why it should have your app blacklisted for this particular reasons: https://developer.android.com/training/monitoring-device-state/doze-standby#doze-checklist This is what you should decide based on what your use case is: https://developer.android.com/guide/background/#choosing_the_right_solution_for_your_work – omz1990 Feb 09 '20 at 11:36
  • "I can say this method drains VERY little battery - as little as 1% for 24h usage" -- first, whatever you are using for this figure is very likely to be a rough estimate. Outside of specialized hardware, per-process battery figures are mostly guesswork. Second, you appear to be concerned only about the battery drain directly attributable to your app. Your users will care about the overall battery effects, and waking the device up every minute may trigger work to be done by other apps on the device. So the overall battery impact will depend a lot on the user and their mix of apps. – CommonsWare Feb 09 '20 at 12:19
  • @omz1990 for reasons like the one posted right after you hehe – arvere Feb 09 '20 at 12:22
  • @CommonsWare that's very good to know, it's one thing that I wasn't considering. do you know if there's another solution that I can explore? I've seen people mentioning FCM, but I wanted to make my app as play-services-agnostic as possible – arvere Feb 09 '20 at 12:25
  • Doing anything once per minute has a chance of being dreadful. For some users, you will never let the device power down, because you do not get a location within a minute, as GPS is not necessarily fast or reliable depending on situation (e.g., phone is in a large building). "I can see why Doze mode exists (abuse)" -- you feel you are not abusing the device; your users may disagree. There is no good answer for a reason: Google does not want you doing what you are trying to do, based on lots of user feedback. – CommonsWare Feb 09 '20 at 12:33
  • while I agree with you, I don't feel it's abuse if that behaviour is stated clearly in the app. In my case, I'm developing an "idle-geolocation" hybrid sort of game, so the users should be expecting background operations - even if I didn't state that myself, they are asked for "background location permissions" at launch. Similarly to when one decides to play a battery draining online FPS shooter vs a lightweight Solitaire game - they should know what they are getting into. In any case, thanks for the nice replies, maybe you'd want to post as an answer so I can accept it? – arvere Feb 10 '20 at 08:33

0 Answers0