This only happens on Android Oreo. I'm using Play Services 11.4.2.
I'm registering geofences using the GeofencingClient and the addGeofences method with a pendingIntent to an IntentService that is handling geofence transitions.
It looks like the intent sent by the play services is blocked by the OS in certain conditions.
The system logs the following:
Background start not allowed: service Intent { cmp=my.app.id/my.package.struct.GeofenceTransIntentService (has extras) } to my.app.id/my.package.struct.GeofenceTransIntentService from pid=-1 uid=10154 pkg=my.app.id
as soon as I add a geofence in the following situations:
when I add it after the device boots
when I add it after the app was swiped
In both occasions the app is actually already running in the background (since I'm able to run the code that adds the geofence) because I listen to the PROVIDERS_CHANGED, BOOT_COMPLETED.
This is caused by the new Android Oreo background service limitations.
You have to change the PendingIntent from using a Service to using a BroadcastReceiver.
See this CodeLab for further information and example code.
In addition to switching to a BroadcastReceiver as mentioned in the accepted answer, I'd like to point out that although you will still receive BOOT_COMPLETED, you will not be able to receive PROVIDERS_CHANGED any longer.
PROVIDERS_CHANGED is an implicit broadcast and is not in the list of broadcast exceptions.
BOOT_COMPLETED is in the list of broadcast exceptions which is why you'll still receive it.
If you want to learn about an alternative approach to get the hook when location services is toggled, please see my answer to a related question for more details.
Related
With the transition to android 8 I encountered an issue that geofences in app are not working anymore when app is killed.
I implemented geofences as per android developers guide, so no reason to show any code snipplets.
With some small modifications and explicit broadcast receiver I was able to receive geofence notification when app was running and when app was in background.
Still no luck with case when app is killed. If anyone had made transition to android 8 and has working geofences please share your experience.
You will have to change the PendingIntent that the geofence triggers to a BroadcastReceiver instead of a Service. The system will no longer let a Service start when your app is in the background.
Also noted in this answer.
I am using geofence service in my app and using exactly the same sample as given in the google documentation.
Doing some research i found that the Intent service is killed when the app is killed. I want to receive the geofence notifications even when the app is not running. How can i do that.?
I have looked for the examples using broadcast receivers but they are old and use classes which are deprecated.
I'm testing Activity Recognition API in 2 apps : Google sample code and implementation of this code in my app.
The problem is both apps keeps getting activity recognition fine but after a few hours the intent service stops and i'm not getting any activity recognition from both of them.
Any idea why the intent service stops even though i've tested geofencing api with intent service and it's working forever without stopping?
Your IntentService might "stop", I would say "fall asleep" because of:
To conserve battery, activity reporting may stop when the device is
'STILL' for an extended period of time. It will resume once the device
moves again. This only happens on devices that support the
Sensor.TYPE_SIGNIFICANT_MOTION hardware.
Basically it should be the case for most of the devices with API >= 20.
Please find more here.
Unfortunately, you can only request activity updates and it is impossible to force ActivityRecognitionApi to continuously give current activity even if it is "still" for some mysterious "extended period of time".
In my opinion, it would much more convenient if this feature of ActivityRecognitionApi was configurable.
Even registering broadcast receiver in Manifest file,you need to register in dynamically in Oreo+ otherwise it will not work. Try this.Add this code in main activity or in startCommand in Service.It worked for me.I have tested this code on Android 10 too..worked perfectly.You need not to register broadcast receiver in Manifest file.
#Override
protected void onStart() {
super.onStart();
IntentFilter intentFilter=new IntentFilter(Constants.BROADCAST_DETECTED_ACTIVITY);
intentFilter.addCategory(Intent.CATEGORY_DEFAULT);
registerReceiver(broadcastReceiver,intentFilter);
}
I am having a broadcast receiver that starts a service in ICS. I have not activity associated with the code. The issue that I am facing is that I am unable to receive the BOOT COMPLETED broadcast in my receiver. Is there a round about solution for this?
In newer versions of Android, an application must have been manually started by the user at least once before any background stuff can be run, so you're going to need an Activity.
I want to know the difference between services and broadcast receivers, can anyone point out an example that can be observed on android mobile devices.
Thanks
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method.
Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Here is good article : Service and BroadcastReceiver
Service is used when you want to do something in background, any long running process can be done using Service in Background. For example, you want to play music when your application gets close. In that case service will be running in background with music.
Example of Service
BroadcastReceiver is used when you want to fire some stuff or code during some event. For example, event can be on Boot of Device. If you want to perform something when device Boots, date and time changed etc...
Example of BroadcastReceiver
I think of it possibly a different way. A Service receives intents that were sent specifically to your application, just like an Activity. A Broadcast Receiver receives intents that were broadcast system-wide to all apps installed on the device.
(The reason I say a Service is a bit like an Activity is that: You wouldn't broadcast a message saying "start Activity MyActivity" across all apps installed on the device. It is only for your specific app.)
Of course, as others mentioned, a Service can continue running in the background, whereas a Broadcast Receiver should finish quickly (e.g. if it is running for more than 5 seconds it may be killed by the OS). The Broadcast Receiver can still run in the background (when app is closed) under certain circumstances. For this, it's worth mentioning that there are actually two types of Broadcast Receivers - Manifest-declared, and Context-registered. They have different lifespans and restrictions - the former can receive broadcasts in the background with certain restrictions, while the latter cannot receive broadcasts in the background (app must be running and active) but has no restrictions on the types of intents that can be received.
Both services and broadcast receivers must be specifically invoked (via an intent), but for services this is usually a specific call (e.g. when your app is started or when the user clicks some button) whereas for broadcast receivers they don't need to be explicitly started as they will start anyway when a relevant broadcast is made.
Here's how I would think of it:
Type
Displays UI?
Can continue running for a long time when app is closed?
Can receive intents when app is closed?
Intents must specifically target your app?
Restricted list of intents that can be specified?
Activity
Yes
No
Yes
Yes
No
Service
No
Yes
Yes
Yes
No
Manifest-declared Broadcast Receiver
No
No
Yes
No
Yes1
Context-registered Broadcast Receiver
No
No
No
No
No
1: Only if you target Android 8.0 or above. The restrictions are not applied if the intent specifically targets your app. The restricted list of intents can be found here.