I want to conserve on battery so I am trying to decide if I should leave LocationClient connected, or connect / disconnect in onStart / onStop like in the official examples. I want to be location aware in my entire app, which means I could potentially connect / disconnect a lot.
bothLocationClient continues to get location updates if:
1) is connected
2) updates are requested
If those 2 are true, then it will receive updates in background as well
Is your location client declared in an Activity or Service? My experience shows that if it is in an Activity, the location updates will not be received because your Activity is in sleep when not in foreground (i.e. user not using it).
To continuously receive updates, you need a Service in Android.
This thread shows you exactly how to do that.
Related
Is it possible to get location updates in android app after force stopping the app. In IOS it is possible to get the location update if we force stop the app, in similar manner is there any service which can provide location updates to killed app in android.
No, this isn't possible because the app's process has been killed and the registered locations listener has been removed. The system doesn't know who it should deliver the Location updates too. It the user force stops and app, by all means that means the app should stop what ever it's doing. But if the app is killed because of low memory pressures, then this is where using a STICKY service would come in handy. Simply register for location udpates inside of your Location Service and then inside of onStartCommmand return the START_STICKY constant to indicate to the system that if the service is killed (not force stopped), then the system should restart the service when memory pressure drops.
Yes, app could restart itself if you had some Geofence registered using BroadcastReceiver. Whenever device enter/leaves the Geofence app would receive the callback via BroadcastReceiver and in this callback you can reschedule location update listener.
But without Geofences location updates are not given to forced closed app.
Here you can know the basics about how to monitor geofences.
I'm trying to make an optimized application that runs background 100% of the time.
It receives location updates and post them to a server.
I'd like to know if im doing things the way i should.
At this moment my app has a service that requestLocationUpdates using LocationServices API.
It accumulate locations and try to send them to the server.
This services is self terminated if no more locations are pending left.
Also i have an alarm to wake up this service every while.
So next time the service wake up, start a new session of GooglePlayServices and receive locations again.
I understand that using pendingIntents is better for unmanaged location tracking, but i still think that need the background service to upload locations in a timely manner.
- Should i stop using alarm raised services?
- Is there any way to start requesting location updates without user intervention / activity?
- Is a broadcastReceiver capable of managing heavy work like network posting?
Got this from google locationServices doc:
public abstract PendingResult<Status> requestLocationUpdates
(GoogleApiClient client, LocationRequest request, PendingIntent
callbackIntent)
Requests location updates with a callback on the specified
PendingIntent.
This method is suited for the background use cases, more specifically
for receiving location updates, even when the app has been killed by
the system. In order to do so, use a PendingIntent for a started
service. For foreground use cases, the LocationListener version of the
method is recommended, see requestLocationUpdates(GoogleApiClient,
LocationRequest, LocationListener).
Thanks in advance
Is there any way to start requesting location updates without user intervention / activity?
Yes, you can create nice scenarios setting up alarm with specified frequency. Even the app is not working, your alarm wakes up device, receives location and then sends to server. After it's work done, device sleeps again. Please check this project, here super scenario from commonsguy.
Is a broadcastReceiver capable of managing heavy work like network posting?
Yes, it does, You'll probably send location to server.
Should i stop using alarm raised services?
Depends on your tracking style.. Consider examples
Receiving location and sending to server at every 10 minutes (or more)
Receiving location and sending to server at every 5 seconds (like realtime tracking)
Probably, for the first example, you will set repeating alarm and then wake up device, receive and send location, and finally allow device's sleep (10 minutes). In this case, you must stop everything about tracking (location services, network operations)
But in the second example, you cant set alarm with lower frequency like 5 seconds. You should have not-stop background service (theoretically) and make location request with 5 seconds interval. In this case, you shouldn't stop resources like (awake device, location requests, network operations). And finally user uninstalls the app :-)
Bottom line, follow commonsguy's project
I have registered a location listener, which will receive location updates using NETWORK_PROVIDER. The listener receives location updates if the activity is in foreground. If I leave the app, after some time it stops receiving location updates. Which is a bit weird... isn't it supposed to receive location update even if none of the activity is on the stack? The listener starts receiving location updates again if I go back to my app.
Or am I doing something wrong? What programming model is suggested to receive location updates even if none of my activity is not active (neither on foreground, nor on stack)?
There are some other way to receive location updates (using pending intent), but those do not trigger if I do not turn on GPS.
The activity in the background will be eventually destroyed, you don't have any guarantee that once stopped it will continue receiving location updates. Activities in Android are not supposed to be used like this.
You can use a service with a wake lock as suggested, but keeping the device awake will quickly drain your battery.
I recommend you this talk by Reto Meier (IO 2011), where he talks about different strategies to have a fresh location. Here is the code.
Like many others, I want to have an exit button that will turn off the GPS when the user leaves the app to conserve battery life. Many discussions are posted basically saying this cannot be done but I have an application that does it so continue to try and find a way. The developer of that application told me that he runs the internal GPS in a service that he wrote and that his exit key kills that service and vola, the GPS indicator goes off instantly.
My app is very time sensitive and I would like to use the equivalent of onLocationChanged that I use now when using the LocationListener part of the system service but have the system service inside a service I write so that I can kill it.
My question then is can I put the system GPS service inside a local service without adding any significant delay, without me having to poll the local service for updates. Any help on how I can do this would be appreciates as this is my first Android app and although I have written tons of C and PHP code, this is new territory and a bit strange.
Like many others, I want to have an exit button that will turn off the GPS
You cannot "turn off the GPS". You can tell Android that your app no longer needs GPS (e.g., you no longer need GPS updates). Android will then determine whether or not to power down the GPS radio, depending on what else might be trying to use GPS at the moment.
when the user leaves the app to conserve battery life.
You do not need a button for this. Simple apps, where only one activity needs GPS access, can simply request location updates in onResume() and remove them in onPause(). More complex apps might request location updates on the first onResume() that needs them, then remove those updates in onUserLeaveHint(), or do a reference-count of resume/pause operations to determine when to remove updates.
There may be scenarios where you really do want the user to have to explicitly say "stop using GPS" by clicking a button, but if you can avoid it, please do so.
The developer of that application told me that he runs the internal GPS in a service that he wrote and that his exit key kills that service and vola, the GPS indicator goes off instantly.
Somehow the developer needs to determine when to start and stop this service. Rather than starting and stopping the service, they could request and remove the location updates, and have the same effect, while consuming less heap space and making it less likely that the user will attack you with task killers and the Force Stop button.
IMHO, the only reason to use a service with location updates is because you specifically want to consume location information in the background with no activities around.
The app is handling location updates and sending the location back to a server. The app does not turn the location updates off. This is for devices permanently plugged into power, so battery is not an issue.
By design, will the location updates continue indefinitely, or will Android stop sending them at some point, for example if the app is pushed out of RAM?
If the location updates do stop, how do I request them in such a way that they will continue indefinitely?
Yes, if phone is not asleep, then user processes will run.
Register a LocationListener in a Service so that it's triggered when location changes. Even if your service is not running, system will start it and execute the registered method.
You should definitelly read the Deep Dive into Location blog for all angles of location handling in Android.
It depends on how you are running the app. As long as the app maintains focus, unless something catastrophic happens, it will continue to send updates. If the app loses focus, then you might run into issues, depending on how you implement the location updating. Either way, be sure to
Create an ASyncTask[docs] to handle the actual sending of updates, otherwise your app will be killed
If the app can lose focus, you can create a Service, and detach it from your application to keep it running in the background.