Hi

hello, Mike!

how can I help you today?

hello Mark

Could you please help me clarify something

I need to write an app which tracks device location in background

I'm using Fused Location API

I know getting device location continuously drains the battery

But the requirement is, when user does specific actions in the app, the app should start monitoring the location

it has to do this even on reboot if the app's custom state requires it

my question is

I've been reading that I need to keep a Wake Lock and a foreground service

I am not certain if that is necessary with the fused location API, but I have not tried using that from a background app

per my understand Wake Lock keeps CPU awake (although with Android 6, we have Doze mode and App Standby)

correct

and Foreground service is to keep process alive

correct, which you may not need, if you are using the PendingIntent version of the fused location API methods

right

Im having trouble understanding the role of wakelake vs foreground service when in regards with keeping service alive

wakelock*

a WakeLock does not keep a process alive

it just keeps the CPU powered on

right

a foreground service helps keep the process alive

so foreground service is to tell Android not to apply its optimization mechanism related to priotization

wakelock is strictly an optimization for CPU

both need to be applied, correct?

a foreground service raises the importance of its process to be on par with the foreground UI

possibly neither need to be applied

:)

it depends on what your app does and how the fused location API behaves

how come

correct

in my case, my pending intent used when initiating tracking location, does not need a foreground service

it shouldn't need a foreground service, as the PendingIntent (when invoked) will trigger the creation of a fresh process for you, if needed

the bigger question is the WakeLock

right

my hope would be that if you have a LocationRequest tied to a PendingIntent, that power management is Google's problem, not yours

and so you would skip both the WakeLock and the foreground service, and get location updates as requested

however, I have not tried this

so, as the saying goes, YMMV

but if the pendingintent is runing a long task, it might be subject to kill. correct?

that's why a wake lock woudl be needed I think

ah, I see

yes, while you are doing work related to an incoming location update, you may want a WakeLock

actually it's a IntentService

and, if that work will take a substantial period of time, you may want a foreground service

so the pending intent actually will start an intentservice

however, ideally, you only need those things while processing an individual location update, not 24x7

right

correct

ummm... I would have the PendingIntent start a WakefulBroadcastReceiver, which starts the IntentService

right

or, use my WakefulIntentService and a regular BroadcastReceiver

and intentservice need to keep a wakelock and set itself as foreground?

if you use WakefulBroadcastReceiver, it handles the WakeLock

similarly, if you use my WakefulIntentService, it handles the WakeLock

the idea is that those components wrap up the WakeLock management, so you do not need to worry about it

whether you need a foreground service would depend on how long the work might take

I don't know how much it takes

it needs to send GPS locations to server

if the work should be done in a matter of seconds, a foreground service should not be necessary

if the work might take minutes or hours, a foreground service is a good idea

the app writes location in database and also tries to send all pending in database to backend

another thing:

when connecting to google play services

IMHO, the work to be done when receiving the location update is only to write the location to the database (or Tape queue or something)

then, use JobScheduler, AlarmManager, SyncAdapter, or something for the periodic uploads

ok

by the way, I find scheduling tasks so tricky ...

it is definitely a pain

with all the changes with doze mode

my app has to run on ANdroid 4.4+

I am looking to (finally) cover SyncAdapter in an upcoming book update

nice! looking forward for it

one more question

the code which connects to google play services

and then calls requestLocationUpdates on the location manager

im not sure if it needs to be in a service which has stay alive

I mean

once you called requestLocationUpdates

the process which called this

does it have to stay running

?

if you are using the PendingIntent version of the method, it should not need to stay running

if you are using the LocationCallback version of the method, it does need to stay running

Im using the pending intent which needs to start that service to write locations to DB and also send them

the reason I am asking is becasue

I dont know how to stop receiving the updates which was initiated with pendinginent

requestLocationUpdates returns a PendingResult

call removeLocationUpdates() with an equivalent PendingIntent

oh

hmm

because PendingIntent stays in OS

?

becauyse that's how it actually works

I would phrase it more as "a PendingIntent represents an OS-managed token that survives process termination"

right

Google's Play Services process needs to stay running, as you cannot persist a PendingIntent

but your process should not need to stay running

and, when you want to stop the location updates, call removeLocationUpdates() with "The PendingIntent that was used in requestLocationUpdates(GoogleApiClient, LocationRequest, PendingIntent) or is equal as defined by equals(Object)."

(quoting the docs)

I read about really edgy situations when Google PLay Services gets updated, but I don't even want to think about that situation, it really hurts

right! that phrase " or is equal as defined by equals(Object)." is key

yes, there will be corner cases that you cannot really address

oh man

thank you so much

I have nobody I can talk to :)

I am happy to be useful!

btw,

I've never quite seen a good explanation in one phrase about the difference between wakelock and foreground service

I think many people tend not to understand it

they use it because they read about it

but I think some don't really understand

well, that is akin to expecting to see a phrase about the difference between a banana and a knife

they are related, in that you might use a knife with a banana

scary thing

but they are not so tightly coupled that you would equate a knife with a banana

you are saying "another". I'm having a hard time finding another article on your blog about doze

yes, I had forgotten about that case

doze issues

is there another scenario I need to keep i mind?

there, I meant "another" with respect to other Doze-related challenges

such as the documented ones

I see

one more thing

testing getting location updates is really really a pain

the other day I tried everything I could to see how getting location is NOT working

i wanted to see how it's not working when I dont have a wakelock AND it's not a foregrounded

it kept running

even with screen off

it kept running

I didn't understand why

well, as I wrote, that'

oh

wait a minute

that's ideally how it should work

it was firing off my service

right, based on the PendingIntent

so GPS wakes up the CPU?

im having trouble understanding this

when does the device really in sleep mode

i was testing on ANdroid 4.4 and Android 5

Play Services is managing the power

whether it is using a continuous WakeLock or something else is up to them, plus the specifics of your LocationRequest

GPS itself should not wake up the CPU, AFAIK

so you're saying it's not guaranteed to get GPS location update with the pendingintent?

note im not talking about Doze mode

at least IM trying to understadn how it works on Android 4.4 and Android 5

in your LocationRequest, you indicate the priority for the location updates

PRIORITY_HIGH_ACCURACY, PRIORITY_LOW_POWER, etc.

right, and power scheme I want to target I think

that helps Play Services determine what location technologies to use and what else to do (e.g., WakeLock)

oh I see

under the hood they are using wakelocks too I guess

same tools

exactly what Play Services does is up to Google, probably varies by Play Services release, is undocumented, etc.

presumably it uses WakeLocks

however, I cannot rule out that they have special hooks to make WakeLocks do more than what we have in the SDK

make sense

in theory, Play Services is "just another app"

OK

thank you very much again

you're welcome!

you're usually online here only in the hours I see in the Office Hours calendar, correct?

yes

I close the chat room after the office hours ends

thank you again, have a great day \ evening

you too!

sorry Mark, I can't see all the discussion. Scrolling up shows me part of the discussion :(

only after 4:15 PM

is it possible to see all of it?

probably not right now

I will be posting the entire transcript to https://commonsware.com/office-hours/ once the chat ends

ok thanks

so, if you can wait ~15 minutes, you will have access to it all then

that's the end of today's chat

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

thank you

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

have a pleasant day!