hello, Bryan!

how can I help you today?

Hi Mark

The app that I work on recently started having unexpected issues with Doze

I am trying to determine the best approach to deal with this.

Here is an example of the use case:

My app has a feature to use geofencing as a trigger for home IoT devices - when you leave/arrive home, the app will get the trigger, and make a MQTT connection to connect to the cloud and check the state of devices/turn devices on/off

Just recently some of the users with Pixel phones running Android 7.1.1 reported issues where the app would not be able to connect during these transitions (the phone is likely locked/in their pocket while driving)

And after doing some research it seems that Doze would likely be preventing the app from access the network when the device is in this state

I don't know what you are using for geofencing, and I don't know how geofencing itself behaves when Dozing

Adding the app to the battery optimization whitelist appears to fix the issue, but I would rather not involve that much user intervention

that would further suggest that you are correct in your Doze analysis

OK - initially we were using Play Services, but recently switched that backend to PathSense

what we can see from the logs is that the geofence triggers accurately still, but the connection the app attempts to make after the geofence trigger will fail

We have an IntentService that is started from the geofence trigger, which then starts another service to connect

that feels like one more service than you might need, but, otherwise, I'm in general agreement with your analysis

Thanks :)

though I'm surprised/impressed that PathSense is able to trigger your code in this situation

but, my knowledge of PathSense is limited to two pages of their Web site, read in the past few minutes

what versions of Android does your app support?

Yes - I will likely reach out to them to confirm they have tested specifically for Doze

4.1+

So as for solutions, I am confused on what the best option would be

what you might need to do is to switch to using a JobService on Android 6.0+, though it would be an option for you on Android 5.0+

but I am leaning towards a foreground servbice

when the geofence trigger comes in, set up a job to do the communications, set to be invoked quickly, but only if there is an Internet connection

then, you'll get control when you get a window of connectivity

if you want to try to force the issue, and ensure that you always have connectivity, AFAIK the battery optimization whitelist is your only full answer

a foreground service will help with partial Doze on Android 7.0+ but not full Doze on Android 6.0+

Interestingly we have never seen any issues with Android 6 users

and that fits with your "while driving" tehory

er, theory

Because 6 wont enter Doze in that case?

as while driving, full Doze will not get triggered, since the device is moving

right

Yeesh

7 won't go into full Doze either, but it will go into partial Doze

For a JobService, what would the timing on that look like for when the job runs?

Could it be queued for more than 10+ minutes?

it would be when you get network access again, either because of entering a "maintenance window", or because the user turned on the screen or something

yes, it could be longer than 10 minutes

at least for full Doze mode

I'm not clear as to how frequently maintenance windows occur in "Doze on the Go"/"partial Doze" mode

Hmm, that is not quite ideal, especially for the "I just came home" use case

agreed

What if we made the service a foreground service?

IIRC, that will suffice to allow you to retain network access during partial Doze mode

And showed a notification with a little progress spinner like "Checking your home..." while it connected

it's with an eye towards streaming media players and the like

however, you would need to be a foreground service *before* the device enters partial Doze mode, AFAIK

which, in effect, would make you a foreground service all the time, since you probably cannot predict when partial Doze might become an issue

OK - also not ideal

("nobody expects the dozing Spanish Inquisition!")

If only we were using FCM

but alas we are not, and that doesnt seem practical

that's certainly Google's preferred way to punch through Doze

I'm sure that there are some developers who send out high-priority FCM messages periodically, just to avoid a foreground service for this sort of scenario

where the messages are merely to give you a chance to use the network, not so much for actually delivering data of relevance in the message itself

that's about right

Is there any other option missing from that list?

4) FCM (would need heavy system redesign)

actually, the FCM hack I proposed shouldn't affect your design a ton

but, it's a hack

and I haven't tried the hack, so YMMV

but, other than those four things, I got nuthin'

Can you point be towards the hack?

not really, as it's theoretical, and I can't point you to an implementation

but, if FCM high-priority messages give your app a window of control with Internet access, it stands to reason that you can use FCM as a quasi-cron job

Ah - OK

have your app do the whole FCM registration thing with your server (which might be a major system redesign)

your server sends FCM high-priority messages periodically, just to give your app control

when a geofence is triggered, if you cannot connect, make note to connect on the next FCM message

and, since you control the FCM message frequency, you control the max latency for when you can get connectivity

other than standard no-connectivity scenarios (airplane mode, parking garage, etc.)

it's a nasty hack, which means I'm sure that people are using it :-)

OK. Would certainly prefer to steer clear of that!

or are at least trying it -- while I cannot see any reason it wouldn't work, again, I haven't tried it personally

How about using an Alarm?

setExactAndAllowWhileIdle() gives you control but AFAIK there is no guarantee of Internet connectivity

you're welcome to run experiments, but I expect that the environment is akin to when you get the geofence trigger

that's why I pointed to JobScheduler, as it has the notion of checking for connectivity

it's just not deterministic *when* you will get connectivity

it would be nice if Doze mode had a "designated network" exception, where the user could say "don't Doze when I'm home"

Im surprised this isnt a thing on iOS already

well, iOS started from a totally locked-down setup

originally, background stuff was impossible

they slowly "opened the kimono" on background work

I'm not an iOS dev, but I would assume that they did so with an eye towards these sorts of battery scenarios

Agreed. The app I work on has an iOS version as well, and the design is similar

but this never came up ;)

Do you know of any APIs to check if Doze is active?

try isPowerSaveMode() on PowerManager

Does that correspond to "Battery saver"?

I don't really know

I haven't tried logging it to see what it does for partial Doze, full Doze, etc.

but, "Returns true if the device is currently in power save mode" sounds promising

There is also isDeviceIdleMode

ah, yes

that's probably a closer match

Fortunately I have some friends with Pixels that told me about the issue - I think experiments will be necessary

my apologies for missing that

np

in theory, any 7.0+ device should exhibit the same behavior

I don't think partial Doze mode is tied to specific hardware

in case you happen to have something else that got upgraded to 7.0 there in your lab

At this point I am learning towards showing a specific notification if this happens to users where it wont connect due to idle mode, and if so, launch to an activity that explains it and guides them through the whitelist

that should be fine, though be careful about running afoul of the Google Play Police, if you're shipping via the Play Store

We are, but it seemed like we fall into the accepted criteria

I agree, you should be fine

however, "should", like "beauty", lies in the eye of the beholder :-)

Haha

I wonder if we can specify that somewhere to avoid any surprises

specify what?

Specify the use case for why we use the whitelist to the play store policers

trying to find language for that, where it makes sense to users/prospective users and to the Play Police, might get tricky

Im surprised that Google didnt decide to use the normal permissions system for this

I don't know and right now I'll decline to speculate

Well thank you for your time! Will let you know if we come up with anything interesting

Hi, sorry, lost Internet connectivity

sorry, still struggling with Internet

any quick final questions?

OK, that's a wrap for the chat, then

the transcript will go up on https://commonsware.com/office-hours/ shortly

the next chat is Thursday at 7:30pm US Eastern

have a pleasant day!