Hi, Mark!

hello, Steve!

how can I help you on this fine Saturday?

I have a couple of quick questions today.

I have a service with some inner classes. The inner classes should outlive the service only very briefly, if at all. Should the inner classes be static?

ideally, yes

ok

if you're real sure about that lifetime, you're probably OK with them being non-static

but, if it's easy to make 'em static, make 'em static

Ok. So if they were coded correctly they could be non-static, but to be safe it would be better to make them static?

The next question is about LeakCanary. Can I use LeakCanary to look for memory leaks in a service?

well, the class can be coded correctly and still be leaking memory, if you are incorrect about the lifespan of those objects

ok

and, while you might be correct today about the lifespan, code changes tomorrow might change that

so, all else being equal, static is the better answer

ok. I will see about making that change

in terms of LeakCanary, it will not automatically track leaks of services, though you can set that up AFAIK

do you know what I would need to do to set that up, or can you direct me to a place to look for that information?

I was just checking the LeakCanary docs, and they seem to have reorganized them

it should be tied into the RefWatcher, teaching it to watch your service reference

ok. i've used that before. i will try that

great - thank you

no more questions today

very helpful as always!

that was easy

thank you so much, Mark!

you're welcome!

have a great rest of the day!

you too!

hello, Tej!

Hi Mark.

how can I help you today?

I was wondering whether you could provide some insight into starting an application from the background in Android O

by "starting an application", do you mean starting an activity?

Specifically, what modes are there ? Background, idle. etc. how to simulate testing for those modes ( possibly throught ADB commands) -- similar to forcing doze and app standby on previous versions of Android.

um, the modes are foreground and background

So, as an example : I'm suppose I was to create a pending intent using getService, getActivity, getBroadcast. and then use the alarm manager. For how long would it work ?

for how long would what work?

Would getService ever throw an exception say 1 hour after the device is left untouched and the app went into background mode ?

I don't think so

and time has no impact here

your app is in the foreground, or it is not

Ok. So if the app goes background, how long is my service allowed to run before it is stopped ?

there is a small window (~1 minute) where your app still behaves "foreground-ish" after it moves to the background

Is there a way to measure this ?

a started, non-foreground service will be stopped after a minute, based on my testing

the documentation says "several minutes"

now, AlarmManager is not cited as one of the things that gives you a fresh window of time for background work, though AFAIK it is

I see, and once I'm in background mode, and an alarm fires with a pending Intent that starts a service, should I have any problems ( apart from the fact the service will be stopped in a minute unless promoted to foreground) ?

none tied to )

er, none tied to O

Doze mode still applies, and I am not aware of any changes in that behavior on O

Thanks. Yes. So testing behavior by forcing doze and app standby through ADB should suffice ?

since I do not know the details of what you are testing, I cannot really answer that

the testing you did for 7.0/7.1 should be fine for O, so long as you are sure that your service will run for under a minute

or, consider switching to JobIntentService, once the v26 support libraries are released in final form

So I recently moved all my service code to jobs using the FirebaseJobDispatcher library. What exactly are the advantages of the JobIntentService over this library ?

JobIntentService is not really related to that library

JobIntentService is a replacement, of sorts, for IntentService

on Android 7.1 and below, it *is* an IntentService

but on Android 8.0+, it actually uses JobScheduler

it schedules the job to run more or less immediately, though the system might delay it a bit

a JobScheduler job can run for ~10 minutes before Android starts getting irritated

and, while I have not tried it, it seems like it should be easy to move an IntentService to a JobIntentService

FirebaseJobDispatcher is a separate thing, designed to be a replacement for JobScheduler with backwards compatibility

I have not used it, as it requires Play Services, and I avoid things that require Play Services where I can

I see. I just looked at the docs for the JobIntentService. Thanks, this is useful.

*extremely useful.

bear in mind that JobIntentService is still part of the v26 support library beta

So as pertains "waking up the app" I'm looking for things like say, the awareness api -- that can bring my app to the foreground when certain conditions are met ( eg. headphones plugged in) . So what I'd really like to understand is what all can cause the app to come to the foreground, do geofences trigger this ? Do I continue to receive activity updates if my app is in background ( if so, for how long) etc.

that's all outside the scope of my expertise, sorry

I have not used Play Services' geofences, nor Play Services' awareness API

No worries. Is there any light you can shed on the activity updates and how they're affected by backgrounding the app ?

I do not know what you mean by "activity updates" here

Things like IN_VEHICLE,

I have not used that API either

if it is from Play Services, odds are very good that I have never touched it

Ah yes, it's activity recognition.

and, that's a wrap for today's chat

Sorry for incoherence, this is the first time I'm doing a QA chat.

Thanks a ton for the help!

no worries

the transcript will be posted to https://commonsware.com/office-hours/ shortly

the next chat is Tuesday, 4pm US Eastern

Thanks!

have a pleasant day!