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.
Related
I have a downloader application on Android.
It shows a notification(in-progress, not dismissable) during the download
and it also catches a wakelock.
I even asks the user to disable Doze for my app.
However, battery-saving feature from various vendors seem to ignore it and kill it randomly.
Is there a way to mark my app process "busy",
so that it has a higher priority in the not-to-kill list?
Note that I'm not using a service in my app.
Regular activity spawns up a thread and download is handled from there.
Note that I'm not using a service in my app
That would be the lion's share of your problem.
Regular activity spawns up a thread and download is handled from there.
That means that Android has no idea that you are doing anything that the user would value, when you're not in the foreground. Android will happily terminate your process to free up system RAM for other processes.
Use a service, perhaps an IntentService (since it already has a background thread for you, and it automatically shuts down once your work is complete). Convert your Notification into one for startForeground() on the service.
If you are keeping a wakelock for a longish time then it is better to let the user know about it, use a foreground service as CommonsWare pointed out.
However, if your use case does not warrant any foreground behavior then I would recommend you use framework JobScheduler that plays very well with doze and app standby as well.
For earlier than API 21 you may use JobDispatcher API.
You can read the more details here.
Documentation for AlarmManager startes that
Note: The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. For normal timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler.
However, once my application is closed (force close from task manager) my alarm does not work and the OnReceive method is never called inside the broadcast receiver.
I am targeting 4.x.
What's happening?
What #Shrikant says is pretty much the answer.
The longer verison is that it is assumed by Android that something is amiss with the app if the user had to force close it manually. Therefore all activities (BroadcastReceiver's, alarms, etc) related to the app will not be initiated until the app is run manually by the user at least once. For example, app's boot BroadcastReceiver will not be called when device is turned off and on in this state until the user runs the app, then the next device boot event will be delivered to the app's BroadcastReceiver.
This behavior is confirmed as by design by Android framework devs: https://groups.google.com/forum/?fromgroups=#!topic/android-developers/anUoem0qrxU
*edited for grammar & added an example behavior
I would like to notify my users of new content available in the latest version of my android game without using an external service like Push Notifications.
What I would like to do as a first step to achieve this is to just create a standard notification on application update.
This brings me to my question: is it possible to start a service the first time a user launches the game and then just keep it running indefinitely? I want to even keep it running after an update completes. Since it is possible that the code for the service may have changed between versions, would I need to stop the old version of the service manually and start the new version? Is it possible to even do something like this where the event that drives initiation of the service is the completion of an app upate?
My plan is to have this service check some persisted data about the last time the user was notified about new content and based on this I will be able to determine if a notification should be created for them after they update.
It's important that they are not required to go back into the game after update in order for the notification to be created. This is the problem that I am having now. Auto-updates occur and they don't know and hence also don't know that there are new stages, etc, available so they never go back into the game if they were already done with the previously available content.
It seems that games like Family Guy have got this approach working, but I am not sure if they implemented it in this way. Even after I update it, I will still get notifications even if I have not actually executed the app since update.
Services are mostly killed when other process needs the resources. Therefore use
startForground(...)
for running Services indefintly on background.
See here: http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)
What you can do is use the AlarmManager in your service that notifies you at certain time. Start the service, do the task and set again an alarm to notify you. In this way, you'll be able to run your service infinitely at periodic time.
I started redacting this answer on GameDev Stack Exchange before you
deleted the question. Unlike the guy who told you to delete, i thought it was an interesting question even for game dev stack exchange.
What you describe is a bad practice on android. I don't believe any game do that. What's more, android require "service" app to run as ForegroundService (This force you to display you app icon in the notification bar, so that users are always aware of running services) It can also be randomly be killed when the system lacks memory. However it can be implemented nicely using Alarms and AlarmManager.
Services and Notifications :
You can however schedule intents when the app is running, with AlarmManager, this is the good practice. Let's take a simple exemple : Candy Crush.
In Candy Crush, when you lose your last life, every 30 minutes you regain one, and have a limit of 5 lives. You want to notify the user when all his lives are back. How to do that ?
Exemple 1 :
When the user lose his last life or quit the game, schedule an intent with AlarmManager in (5-number_of_life)*30 minutes that will fire a local notification.
Exemple 2 :
Schedule an intent with AlarmManager every 30 minutes to check the number of lives, and fire a notification when the user have 5 lives again.
Using a Boot receiver may also allow you to schedule things as soon as the device boot.
However, users expects to be able to disable this kind of features.
Updates :
If you want your app to notify users when an update is available, you'll need to somehow check on the internet with a request on your server. You may schedule an intent again with alarm manager to check regularly if the update is available. If the user is ingame, you can also check it more regularly.
A lot of "online" games do that, and simply force the user to download the new update from the Play Store, before they can play again.
I have a Phonegap app that functions as a communication service for a specific group of people. Using the local notification plugin found on the phonegap-plugins GitHub page, I have implemented notifications into the app, so that whenever someone receives a new message, a notification will appear if the app is in the background.
After about an hour, though, no more notifications will occur, and it appears the process was killed. When I go back into the app, it starts completely over instead of resuming from where I last left off. I'm assuming that after a certain amount of time, Android stopped running the app in the background.
Does anyone know how to keep the app running in the background until it is told by the user to stop, and prevent Android from killing the process?
As CommonsWare suggests, you could write a dummy service to keep your app alive, but also as he rightly suggests, if you're going to go to the effort of writing a native dummy service, you may as well write the actual service natively and have done with it.
As a bit of a quick and dirty solution, you could maybe use a partial wakelock (see here) to keep the CPU running your app while it's in the background.
I successfully used this approach to keep my Phonegap-based walk navigation apps alive in the background so they can continue to receive and process position updates.
In your case, staying alive to receive notifications isn't exactly what a partial wakelock was intended for and so I'm unsure whether android will kill your app anyway after a while since it's not doing anything (unlike mine which is constantly receiving and processing position updates) but it might do the job without needing to write a service, so may be worth a try.
Have a look at my answer to this question which contains my code for an updated version of the PowerManagement plugin for Android. I updated the plugin for use with Cordova 2.8.0 but also extended it to be able to acquire a partial wakelock.
I need to keep service running to monitor changes through content observer.
I also need to know , Can my alarms set for periodic intervals can be erased ?
If yes then When ?
Can task killers erase Alarms for version onwards 2.2 ?
If you want to keep a service running, use Service.startForeground. Then the Android system won't kill it, except under the most extreme circumstances.
You need to supply a notification which is continuously shown to the user so that they know they have a service running which is potentially using resources. This seems to be a deliberate (and sensible) design decision.
So long as you do that, and so long as your ContentObserver actually works, there should be no need at all for you to wake up your activity or service code using AlarmManager. Your service should just continuously run and your code should be called whenever the content changes.