I am making an Android application where I schedule alarms in AlarmManager that trigger notifications to the user and need to go off at rigid specific times.
When a user uses a task killing program (usually from a chinese phone and ROM), the alarms are killed as well.
This is troublesome, because after this happens, no more notifications are launched untill I re-open the app or restart the phone. This is not trivial to the target user that is a layman.
These alarms are supposed to work offline, so using GCM to re-up the alarms through a network listener is not an option. I actually need some "unkillable" service on the phone that checks if the alarms still exist and reschedule them if they don't. Is this possible?
I found this post here, but the last answer was in 2012: Keep android alarms alive, even after process killed by a task manager
Is there currently a solution to this?
Related
My app has a background service running that gets users current location and update it to a server every five minutes. To run this location update process continuously, I use alarm manager to set its next execution time from the service itself. However, when I install the app in my Nokia 6 running Android 8.1 it works for some time and if I keep the phone idle for some time, my service will get killed with the next alarms by the application also being cleared from system alarm manager. My guess was that the idle time makes the phone enter doze mode. However, I don't understand why the alarm managers got cleared. To my understanding, the doze mode should open up maintenance windows periodically to execute any pending tasks.
To mitigate this issue, I tried to apply a JobScheduler service on top of AlarmManager, which runs every 15 minutes. Purpose of this jobscheduler was to re-start the service which has the alarmmanager in it, so even if it gets killed and the alarm is cleared, jobscheduler would re-up the service.
After I tested this patch and keeping it for some time to go into idle mode, it resulted in getting both JobScheduler Service and Service which has the alarm in it killed with the scheduled jobs and alarms getting cleared from the system.
It is said in the Android documentation that we can use JobScheduler to mitigate its background execution limitations. And to test this out I forced killed the two services when I tested the app, but the already scheduled job did not get cleared, and it made the service with the alarm run again successfully. I don't understand the reason for this behavior, although the Evernote guys give an explanation that could match this scenario in here Android Job by Evernote
Any ideas for this abnormal behavior?
Test Environment Details
Device : Nokia 6 (TA-1021)
OS : Android 8.1.0
You would not be able to run background services long running in Oreo as there are behaviour changes, now Oreo to optimise system memory, battery etc, it kills background service, to solve your issue you should use foreground service.
Have a look at Background execution limits https://developer.android.com/about/versions/oreo/android-8.0-changes
A suggestion from me, if you can use FCM then go for it, becasue apps like WeChat, Facebook uses it, to deliver notifications and they don't face any problem...
Hope this helps in understanding the issue....
In Doze more, the alarms do not get reset, but get deferred to a later time. You have two mainstream options here:
Use either setAndAllowWhileIdle() or setExactAndAllowWhileIdle(). However, these too can fire at the maximum frequency of 1 time per 9 minutes. So you'll have to decrease the frequency at which you get location in your app.
Use a foreground service by way of showing a foreground notification. Everyone does that (apps like Uber, Google Maps etc). That way, your service won't get killed, and be treated as though you have an app open.
I'm currently facing the same issue and doing the same workaraound like you do. That is, setting the Jobscheduler to a periodic job to launch my Foreground Service every 15 min in case it is getting killed for whatever reasons like a killed task. This works like a charm on pre Oreo Versions.
For Oreo the only solution I am awared of at the moment is, to allow the app to autostart in the settings. Under installed apps that is. Then it should work like pre Oreo again.
What Ive heard but not tested yet, is to set the setPersisted(true) option in the Job Scheduler.
Let me know if that helps
I assumed currently DOZE mode not allowed to background service so you need to find a way that DOZE mode will not affect on your app.To solve your issue you should use foreground service. or make some battery setting. Any way my better option is you should go with Firebase Cloud Messaging
I am developing an app that connects to and modifies data in a database by executing php files.
If I need to make changes to the database or php files, this may cause old versions of the app to behave unexpectedly and crash. For this reason, I want to force users to update the app when such changes are made.
Right now, I have a method that connects to the database and compares the apps version to the databases version. This works fine but I call it every time I access the database (very often) which significantly slows down the usage of the app. Is there a better way to do this? I have read that I could use an AlarmManager or BroadcastReceiver to check for updates every X amount of hours. But what if the user closes and doesn't use the app for a few days. Will these timers get called as soon as the user starts the app and thus be able to force an update?
The Android AlarmManager is an API that let you communicate and program alarm with the Android Alarm Service. Think of it as similar to a Linux Cron job. As soon as the alarm is programmed, then it'll be triggered even if your app isn't running, because the alarm is triggered by the alarm service and not by your app. For instance, the only thing you need to do is to program your alarm. It's important to note that when you restart your device then your alarms are cleared, so you need to reprogram then in every reboot. You can do this by capturing the BOOT_COMPLETED broadcast, so you can reprogram your alarm every time the device boots up. Check out the definition of the Android AlarmManager. A common pattern to do what you want is to program an alarm that sends a broadcast or starts a service, then in that service you can query your server. You need to consider that when the device is sleeping then the alarms couldn't be sent, so you need to work with wakelocks. This class will help you with that, check it out.
I've developed an app to schedule multiple local notifications to remind users to do something. Every month in the current year there should an notification be raised.
These local notifications are scheduled using an "AlarmManager". A notification is created and raised in the OnRetrieve of a "BroadcastReceiver".
It works all fine until the app is terminated (by user) or the device is rebooted.
After some research I found the solution to reschedule the alarm / local notifications if the device is rebooted => using a BroadcastReceiver with "ActionBootCompleted" as intent filter and then reschedule the notifications in the "OnReceive".
Unfortunately I can't find a decent solution to reschedule the alarm / local notifications if the app is terminated.
What is the best approach for this case?
Try to run this as a background service. When the user opens up the app for the first time, call the service OnCreate(). Make sure the service is START_STICKY so it cannot be stopped unless you explicitly tell it to. Then place your AlarmManagers inside the service.
I am making an app that needs to execute a function each hour even the app is closed.
First of all, I thought to create a service, but during my tests, I realise that android sometimes kills my service. So I was looking for another solution and I found AlarmManager. I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)
Another question, it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread?
I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)
It will run until:
the device is rebooted, as you noted, or
the user uninstalls your app, or
you cancel the events yourself, or
the user goes into Settings, finds your app in the list of installed apps, taps on that entry, and clicks the Force Stop button
It's possible that alarms will need to be scheduled again after your app is upgraded (I forget...).
it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread??
Unless the work you are going to do will take only a couple of milliseconds, you will want a background thread for it. That leads to two possible patterns:
If you are not using a _WAKEUP-style alarm, use a getService() PendingIntent to send control to an IntentService every hour
If you are using a _WAKEUP-style alarm, you will need to use a getBroadcast() PendingIntent, and have it either invoke your subclass of my WakefulIntentService, or you will need to manage a WakeLock yourself to keep the device awake while you do your bit of work
No, Android won't kill scheduled alarms and they got executed as planned unless app is replaced or device is rebooted. Use broadcast receivers for these events to reschedule Alarms. There's no way to prevent Force Stop as it kills all of your app components and threads totally.
That depends on what Alarm Manager do. If it sends a broadcast, the receiver limit is 10 second.
If it starts an Activity, Service or Intent Service, there is no limit. For Activity and Services you must finish or stop it and for Intent Services until the process is finished. Be aware that you can't have another thread inside Intent Service and you'r limited to code inside the OnHandleIntent.
Also you must consider device state. If it's sleep and you are using Wake Up flag receivers won't need a wake lock, but others do. It won't take long for device to go back to sleep.
Don't waste system resources with a service because Alarm Manager do what you want.
So I've been writing an app that uses an alarm to open a service ever few hours or so. My Galaxy S2 Skyrocket has a built in Task Manager that allows me to "Exit" recently opened applications. After I set the alarm if I go into the Task Manager and "Exit" my app its killing my alarm. Is there a way to prevent this?!
It is understandable because you are forcing the system to get rid of the application in Task Manager and therefore the services it is running.
If you observe DDMS in Eclipse, you will recognize that whenever your service starts running, you will see the name of your application appearing under the list. Thus, by asking your alarmmanager to continue running even when you are forcibly closing the application, you are imagining about a virus-like application and a user would not want that.
If your application being terminated by Task Manager is a high possibility, then an alternative could be creating another back-up application that monitors if your service is running on time and fire an intent to start it if not. This would lead to an infinite loop of applications monitoring each other though and I am not sure how practical it could be.