My goal
Get user location updates for quite long time (e.g. 8 hours) with quite high frequency (e.g. every 30 seconds) even when the application is not running in foreground (meaning the activity where the location tracking was started might be destroyed).
Issue
I've found many articles regarding location tracking in Android apps.
The newer ones usually explain how to use Google Play Services' location APIs.
The problem is that in most cases, they demonstrate getting location updates in co-operation with Activity and LocationListener. For example in Google's tutorial. It's obvious this is not what I need. The only approach for long-running background location updates was based on periodical starting (via AlarmManager) of a service that run until it got accurate enough location update. However, this approach doesn't seem right for the frequency I need.
So, I ended up with custom idea how to solve the topic, but your critique would be welcomed. Here it is:
Idea of a possible solution
MainActivity - used just for starting/stopping the tracking by starting/stopping the MonitoringService
MonitoringService - a foreground service, where the whole connecting to LocationServices from Google Play services happens. Also, once connected a requestLocationUpdates method is called, but its variant with PendingIntent object. The pending intent contains intent invoking MyWakefulBroadcastReceiver class. Also, the service holds a partial wake_lock to prevent the device going to sleep and interrupting receiving of the location updates. Here, I'm not sure if holding the wake lock really helps.
MyWakefulBroadcastReceiver - extends WakefulBroadcastReceiver, just starts LocationProcessingIntentService via the startWakefulService
LocationProcessingIntentService - processes the location update passed via intent to it. Network communication performed here. Therefore, it is done in separate service and not directly in the MonitoringService
Currently, I have the solution described above implemented without acquiring the partial wake lock in the MonitoringService. When connected to debugger in Android Studio, I see the processing of the location updates work. However, I'm not sure what it will do after e.g. 4 hours of running without being connected to laptop (like it is for the debugging purposes)
Questions
Is this approach OK from architecture/performance/battery life point of view?
Should I use the wake lock for being sure the device won't go to sleep?
If answer to 2. is yes, do I still need to use WakefulBroadcastReceiver for starting the IntentService processing the location updates?
Any other recommendations?
What you have is mostly fine. You don't need the MonitoringService. The PendingIntent will wake your BroadcastReceiver, regardless of the state of your app. You don't need a permanent wake-lock. Just use the PendingIntent in your setup Activity to requestLocationUpdates.
Remember that the location services are already running in the background (as long as the user has enabled location services), so you don't need to run your permanent wake-lock service also (you can wake-lock after BroadcastReceiver#onReceive(), but don't forget to release the wake-lock after processing).
The only time you might have to worry about the PendingIntent not waking your BroadcastReceiver is if the user force-stops your app. In that case, you could choose to respect the user's decision. You can also explore using intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES); which should wake your BroadcastReceiver from the stopped state, but I haven't tested this flag in this scenario.
Related
I am implementing a solution to track location updates in my Application,both in foreground and background, and perform some task when location is updated.
As per the Google recommendations in https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#requestLocationUpdates(com.google.android.gms.location.LocationRequest,%20android.app.PendingIntent), I used PendingIntent variant of requestLocationUpdates API.
What is the best way to perform a task when location is changed ?
As per the Google sample https://github.com/googlesamples/android-play-location/tree/master/LocationUpdatesPendingIntent, task to be performed when location changes, is done in the onReceive() of broadcast receiver. This approach doesn't deal with wakelocks and the device background restrictions.
As per my understanding after going through various stackoverflow answers and different blogs, I have to use JobIntentService.
Is using JobIntentService is the correct approach for my requirement
Do Application needs to acquire wakelock to perform a task when location changes, when device is in sleep mode(I am aware that JobIntentService automatically handles wakelocks).
When the system callbacks like onlocationChanged(),onReceive() of BroadcastReceiver() are invoked, is CPU awaked automatically when device is in sleepmode. If waked, how much time it will be active ? Does it wait for callback to be finished.
Found some useful info in Android source code comments
"When location callbacks are invoked, the system will hold a wakelock
on your application's behalf for some period of time, but not
indefinitely. If your application requires a long running wakelock
within the location callback, you should acquire it yourself."
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/location/java/android/location/LocationManager.java
Is using JobIntentService is the correct approach for my requirement
Using JobIntentService would be the correct approach,
1. It can handle wakelocks,
2. As there are background limitaions on Android "O" and above versions, it can work in Maitainance window of doze mode.
Do Application needs to acquire wakelock to perform a task when location changes, when device is in sleep mode(I am aware that JobIntentService automatically handles wakelocks).
Location change callbacks come with wakelocks acquired and loose if callback is returned. For any lengthy task in callbacks, Service has to be started in callback with wakelocks(JobIntentService would help here).
When the system callbacks like onlocationChanged(),onReceive() of BroadcastReceiver() are invoked, is CPU awaked automatically when device is in sleepmode. If waked, how much time it will be active ? Does it wait for callback to be finished.
System callbacks often come with wakelocks acquired, and release when callback is returned. As they run in UI main thread, any task to be done has to be offloaded to service. For services to run even in device sleep usecase, wakelocks have to be acquired, and again JonIntentService helps here.
JobIntentservice also deals with doze mode in a best possible manner.
Note: Because of the background location restrictions, to get the continuous location updates, App has to start the foreground service.
I'm making an app that tracks user activity in the background using ActivityRecognition API, and if the user remains in the same place for specified period of time(e.g. 1 hour), then system pushes notification telling user to take a walk. I have implemented activity recognition, but only for the cases when the app is opened. Obviously, the Google API Client needs to keep connected in order to send activity updates. My questions is - for activity tracking in background, what would be a better solution:
1) To implement AlarmManager in the main activity (or separate activity) that once in 30 seconds wakes the activity, connects Google API Client to Play Services, then sends PendingIntent to IntentService for activity analysis
2) Create a separate Service (not IntentService) to continuously run on background (separate thread), that will keep API Client connected, and send activity updates to IntentService. Hence, the system would have 2 services: 1) Service to keep API client connected to Play Services and send regular activity updates to IntentService for analysis; 2) IntentService for receiving activity updates form Service, and analyse the data.
3) Some other solution (offered by you guys)
Comments: My tutor suggested me to use AlarmManager, but you usually use it for things like network updates, hence the interval is generally more than 10 minutes whereas I need 30 sec - 1 min. So I am hesitant to use it.
I also have seen many similar questions on here before, but I haven't found any clear answer.
Actually, a connected GoogleApiClient is only required for requesting and removing activity updates - you do not need a connected GoogleApiClient to receive activity updates.
The requestActivityUpdates() documentation actually specifically mentions working in the background:
A common use case is that an application wants to monitor activities in the background and perform an action when a specific activity is detected. To do this without needing a service that is always on in the background consuming resources, detected activities are delivered via an intent. The application specifies a PendingIntent callback (typically an IntentService) which will be called with an intent when activities are detected. The intent recipient can extract the ActivityRecognitionResult using extractResult(android.content.Intent). See the documentation of PendingIntent for more details.
I would recommend a different approach. The problem with the Google Activity recognition API is that you cannot be confident about it reporting a certain event until its confidence level is >75. To have a confidence level of >75, you need to increase the detection level, which in turn can consume a lot of battery. I’d recommend trying some free SDKs like Atooma, tranql or Neura (you can find them online). These give you much better insights about your users and, in some cases, consume only around 1% of your battery life
I just finished the tutorial for geofencing on Android (http://developer.android.com/training/location/geofencing.html) and I wonder why the 'callback' for geofences are done via pending intents and not a simple callback interface.
If implemented in an activity, one would usually disconnect the location client in onPause() anyway, so previously added geofences would not be tracked either after the application paused/was destroyed, so why a pending intent? Or am I mistaken here?
I wonder why the 'callback' for geofences are done via pending intents and not a simple callback interface.
Mostly because geofences are designed to work even without your application running.
If implemented in an activity, one would usually disconnect the location client in onPause() anyway, so previously added geofences would not be tracked either after the application paused/was destroyed, so why a pending intent? Or am I mistaken here?
I believe that you are mistaken here. In fact, geofences specifically are not designed for directly triggering UI, as is discussed in the documentation:
The Intent sent from Location Services can trigger various actions in your app, but you should not have it start an activity or fragment, because components should only become visible in response to a user action.
Now, you might elect to say that you want to only use geofences while you have your activity in the foreground. However, you would have to remove those geofences in onPause(). A geofence will remain registered until its expiration time or manually removed, AFAICT.
This answer can be outdated - accuracy and realiability of google play services has changed a lot from it's initial release.
Some of my experiences with geofencing below.
First of all - the main advantage of this technology is VERY low battery usage. In the fact, I can't notice any changes in battery life. It's really impressive.
Service seems to use only Wi-Fi and network location. I didn't notice GPS running at all. I can't say if it's only hidden location icon or really not using GPS.
Accuracy - it's terrible. 20 circle areas are not detected at all, except range of my home ap. It looks like whole position circle, including error must be inside of fenced area. 1000m areas are detected sometimes and with huge latency. Those experiments where made in open area with very low number of Wi-Fi ap around. I'm still trying to find really reliable settings foot this service. After getting intents I want to turn on GPS location and make final approach in my own code.
My application requests for updates in a service on background when a boolean flag is set to true. If flag is set to true, then i acquire a PARTIAL_WAKE_LOCK to let my background service run.
My questions are:
Since I requested for updates from location manager ( i don't manually request updates but subscribed for locationManager.requestLocationUpdates )... does the locationManager keep working as normal/usual even if device goes to sleep with PARTIAL_WAKE_LOCK ?
I've read there is a WifiLock -> WIFI_MODE_SCAN_ONLY that I'm not acquiring. Since location manager uses wifi scans to detect location through wifi hotspots, should I acquire this as well ?
What about gps location updates when device goes to sleep ?
no, it does not. More (very good) info here, including possible solutions/ hacks.
regarding 1, I would have to make an educated guess and say it wouldn't make a difference
from what I can gather, it doesn't make a difference which provider you are using for the updates, LocationManager.NETWORK_PROVIDER or LocationManager.GPS_PROVIDER.
in danger of going a bit OQ, I am a bit curious which kind of application would need to aquire a wake lock to keep a service running at all. As far as I know, having a wake lock doesn't ensure your Service keeps running. The only thing which ensures a Service keeps running is to have it in the foreground (Service.startForeground()). Otherwise the system still might kill the service, regardless if it aquired a wake lock or not.
That being said, if it is running, it can do it's work with a Handler or something.
If you are using this approach, and I think you are based on the scenario, I would advise against it. Basically you are creating a service, have it run in the foreground (guess) AND you are aquiring a wake lock just to request for location updates when the screen is off. This seems a bit overkill.
There's a more efficient way, which has the benefit it has by far more accurate timing then the dreaded timing of Handler.postAtTime or Handler.postDelayed: AlarmManager.setRepeating(). Set type to ELAPSED_REALTIME_WAKEUP or RTC_WAKEUP so it will run if the device sleeps, then when the alarm event is fired and received by a BroadcastReceiver you will have to create, you could request for updates and handle other events.
If you're not using a Handler, but are merely requesting location updates, this approach still probably would be better, because it doesn't require you to have a running Service or to acquire a wake lock.
And it seems LocationManager.addProximityAlert() is the way to go here. Which is flawed as well (see 1)
Similar question here by the way: Android: GPS location updates when the cellphone is in sleep?
I've spent days trying to get WiFi and cell-based locations with locked screen with Android 6.0 on Nexus 6. And looks like the native android location service simple does not allow to do it. Once device got locked it still collects location update events for 10-15 minutes then stops to providing any of location updates.
In my case the solution was to switch from native Android location service to Google Play Services wrapper called com.google.android.gms.location: https://developers.google.com/android/reference/com/google/android/gms/location/package-summary
Yes, I know that some of Android devices lack of GMS, but for my application this is the only solution to perform.
It does not stop sending location updates even when in the background and device screen is locked.
Me personally prefer RxJava library to wrap this service into a stream (examples included): https://github.com/mcharmas/Android-ReactiveLocation
I am new to Android, and I need some advices for start up.
I want to build an application, which will show up, when the user gets into some hot situation.
By hot situation I mean:
the GPS/cell coordinates are in known zone;
known Bluetooth device detected;
known Wi-Fi network detected;
weather info has change;
I see something running in background and when one of the clauses hit, it will trigger and open the app.
How to get started?
How do I make sure my app won't be shut down?
As I read somewhere that Android OS will terminate apps if memory out occurs or consumes too much, and my app would consume a lot, making repeated measures/checks to see if situation changed.
Regards,
Pentium10
You need to use a Service for the part of your application that runs in the background.
You might find the Application Fundamentals document in the Android Developer Documentation helpful. It says this about Services:
A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it.
In you case you might find the LocationManager Service helpful. It is a system Service which will you can use to notify your application based on GPS position.
However, I think you'll have to write your own Services to monitor Wi-fi, Bluetooth and weather.
You can use the AlarmManager Service to get your Service to perform particular tasks at certain intervals.
It depends on how & where you want to deploy your application. In my experience it boils down to
you create an application for a specific use case where battery drain matters less than accurate results (showcase situations, prototyping, ...)
you want to distribute the application to users.
In case 1) just create one service that aggressively polls the sensors / web services. Use the AlarmManager to send a REFRESH intent (AlarmService.setRepeating(...) ).
That REFRESH intent will restart the synchronization service everytime, even if it was killed by the system. onStart() will be called everytime the REFRESH intent is emitted. You can do heavyweight setup logic in onCreate() as this will be called everytime the service is created after it was destroyed. WARNING: This will possibly drain the battery very quickly.
In case 2) I would create several services and let the user configure different polling intervals for each service to limit battery drain. I can see for example that bluetooth should be polled more regulary than GPS as it is more likely that a bluetooth device suddenly appears than a user moving extremely fast.
Weather sounds extremely expensive (network lookup, possibly triggering a network connection!)
Please do not try to be too persistent with your app in case 2). It usually makes a lot of sense for a phone to kill memory / power draining services.