I'm working on an app with GEOfencing API. I have created a geofence and whenever a user leaves already specified geofence, broadcast receiver is triggered and I can successfully display a log message. However when my application is in the background, onReceive method of Broadcast Receiver is not triggered, even though Geofencing is working, my onReceive method will be triggered only when I open the app in foreground. How can this be achieved in the background?
You can use WorkManager to schedule tasks.
WorkManager is an API that makes it easy to schedule deferrable, asynchronous tasks that are expected to run even if the app exits or the device restarts. The WorkManager API is a suitable and recommended replacement for all previous Android background scheduling APIs, including FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler.
The broadcast listener can also be triggered when the app is in background.
Check out the link for implementation of WorkManager with AlarmManager, you will get a rough idea of how the whole thing works.
Click here
I figured it out.
The problem with was with Android Emulator. I didn't receive a Log message from my Broadcast receiver when I triggered the geofence (When my app was in background), because there is a BUG in Android Emulator. You need to have Google Maps Application opened to receive a trigger from geofence from your app in the background.
It's a strange bug, and it took me few days of debugging to figure it out.
Related
I am working on an Android application that most it logic is done in background and basically analyzing the user activities (walking, running, in_vehicle etc)..
The ui has only 2 screens for basic setup and for giving permissions.
In the Application class onCreate (not Activity) the app register to ActivityRecognition api and gets the ActivityDetected events in a broadcast receiver which process the DetectedActivity and so on.
The app has also a boot complete receiver, after device boot, the receiver onReceive invoked.. This, causing the Application class to start, onCreate is invoke, the ActivityRecognition begins as described. This works perfectly!
So actually, the process starts in boot complete and nothing stops it..
Additionally, in the Application onCreate I send a firebase analytics Event (like AppStarted)
Also, when ActivityRecognition registration done I send another event (like ActivityDetectSuccsesfullySrarted)
Now here is the thing, in firebase I see that these events are sent about 20 times a day!!
Is there explanation for this?
This means that something, kills and recreate the process? Why?
Android terminates unused processes to free up system memory.
If you want a process to run for a long time on an off-the-shelf Android device, you will need to use a foreground service. If you are working with your own custom firmware, you could take other steps to try to keep your process around.
We need to add functionality in Android app (Api 26+) that every X hours (doesn't have to be precise) will fire some task which will read local database and then display Notification (by click on Notification some Activity should be shown).
Problem is, this should happen no matter if app is in background or not. I've been reading about Android lifecycle and limitations put on recent android versions and I was wondering what would be best solution, using WorkManager or AlarmManager then scheduling job?
Is it even possible to run Activity on Notification tap, when app has been killed or is in background and not whitelisted?
First Question:
WorkManager is the best solution for this. Behind the scene, workmanager is also using job scheduler ,job dispatchers, GCM Network Manager,Alarm Manager and Broadcast receivers, depending upon the operating system with handling of backward compatibilities.
It has alot of functions which will make its implementation clean and easy.Also we don't need to restart it after device reboot like service, it will start itself.
Second Question:
Yes, we can open application by taping on notification even if app is killed.
You can check this.
I have a scenario where I need to notify the server whenever the device language changes. I need to call an API (even if the app is not running)
and update the current language with the server. I have implemented this with the help of a BroadCastReceiver for
<action android:name="android.intent.action.LOCALE_CHANGED" />
As soon as the broadcast triggered, I'm launching a service and calling the API. But, Since Android Oreo and above has background execution limits,
I have to launch a ForegroundService.
Here, during the background API call, a notification is visible in the Notification panel. So,
The user can still go to App settings and Force Stop the App, then the API call will be interrupted. But I need a guaranteed execution of this API. Is there any way to execute it in the background
other than foreground service? Can it be done with the help of WorkManager or Job Scheduler? What is the best way to handle this use case? Hope my question is clear. Thanks in advance!
The user can always kill your app so this should not be unexpected. But if you do not like foreground service, then queue this information (with timestamp) in DB and send to your API next time your app is running. If you must send immediately then do queue it too and then send immediately. If the user kills your app in mid-operation then you still will be able to resend it from queue next time. WorkManager is a good choice:
Guarantees task execution, even if the app or device restarts
I have a question about BroadcastReceivers. I have an app that needs to receive constantly the ACTION_TIME_TICK intent to refresh the clock widgets. I implemented a foreground service which contains a BroadcastReceiver that listens to that action. But on android oreo the only way to start a service is starting it as foreground service which implies to show a persistent notification to the user which notify that the app is working in background.
I don't want to show to the user that notification. I tried to implement BroadcastReceiver inside the Application class. But this is not working proprely. Somethimes the BroadcastReceiver doesn't work and somethimes works well. Even when it works well, if the app is removed from the recent tasks, the BroadcastReceiver stops to work. Is there a way to use a BroadcastReceiver that works indefinitely without the use of a service?
Is there a way to use a BroadcastReceiver that works indefinitely without the use of a service?
In the case of ACTION_TIME_TICK: No, since you cannot use a manifest-declared BroadcastReceiver.
Since you're not willing to use a foreground service, you may want to look into START_STICKY. In this situation, that's the only way to maximize your Service's run-time: Allow the system to re-start it, capriciously, after it's been stopped for lack of resources. Of course, this means your clock could stop updating for arbitrarily long periods of time.
Note that your problem is not limited to Oreo (Oreo does not require you to be a foreground service, but it does impose certain limits on what you're allowed to do if you're NOT in the foreground). Even on earlier OSs, if you're not foreground, the system considers you a prime candidate for elimination.
I want to create Event Reminder App, I search and found that I need to use a service and broadcast receiver.
But it is not clear for me what is the role of each components ?
As I understand-but I am not sure- that the App needs an Activity that when starts, it runs the service ( which check the current time with times are stored persistently , for example in database !). when the two times match , the service create a broadcast, and our broadcast receiver receives it and create Alert.
My questions are:
Does this inception is correct ?
How to make the service running and always check the time ( do we need some infinite loop?!!)
thanks in advance,
Activities and Services can be killed off without notice anytime system decides it's low on resources. There is no guarantee that your Service would run all the time. Also, if phone is in sleep mode, your code stops executing.
So:
The premise is wrong, for the reasons stated above.
You cant guarantee that Service would be running all the time.
For your purpose you should be using AlarmManager. It is garanteed to call your code when alarm is triggered. Also important - AlarmManager survives device restarts.