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.
Related
I am creating an application that should show some Screen on incoming message.
I think I need some background job/service that's running permanently while phone is on. That job will handle for the incoming message and run the Application with some parameters, so based on these parameters the application will show corresponding Screen.
Is it possible to reach the goal this way? Or is there any other ways?
(I am creating the app using react-native, so if there's react-native solution, it would be even better, but native Java-Android solutions are welcome too)
This approach is very bad to battery life because it doesn't allow CPU to sleep. There is no guarantee that system will keep your background service alive. For deeper understanding I can suggest you to learn about services and doze mode.
Consider using Push notifications or at least job scheduling mecanism.
I tried to find if there's a way to run foreground service (one which would hopefully never be killed) without any ui. (Ok I guess notification is necessary but other than that)
This is a very specific use-case since the device being used is a custom one (not a phone), where we need one 'server' app, and might be couple 'client' apps. Clients app will have all necessary ui, but server app should behave in a way like a web server.
I understand this is not a intention of foreground services, but it is justified in the use-case we have.
Bonus question: Is there a 'best' way to achieve an android process/service absolutely constantly running and never being killed by platform for cleaning the memory, since this service will be de facto critical part of the system. Like a phone/dial app on phones for example
Sorry, I can't write comments so I have to post an answer.
It's not exactly what you are looking for, but maybe this google codelab can help you
start with something:
https://codelabs.developers.google.com/codelabs/while-in-use-location/#0
The code in the sample project starts a foreground service whenever the app leaves foreground, allowing the service to "survive" even if the application it's destroyed. Basically the system will not stop the service because tied to his notification.
Plus the service can be stopped from the notification itself.
Maybe with a foreground service started from a device boot broadcast you can have an "always running service"
My main app supports different hardware attachments. It ranges from RFID readers to stepper motors controllers.
Because the app is quite independent and the scenarios where attachments are used is rare, I have decided to remove all the code from the main app and move it to services which are installed on specific devices.
The services used to communicate using the Intents.
Recently the devices running the app were upgraded to Android 8 and I can no longer use a background service as I used to because it's killed after a few moments.
I went through the docs in here: https://developer.android.com/guide/background
It seems I should use the Foreground Service, however when searching for more info about foreground services I have found that it is not a suitable solution for long-running processes (the RFID reading process runs from boot to shutdown).
When developing the first solution a while back I have decided not to use the Bound services as they are far less convenient than just waiting for the incoming intents.
I don't mind at all the notification icon, I actually like it as it will allow us to easily see what's running and what's not when interacting with a device.
I just don't want to invest time in rebuilding the app and then ending up with something that does not work.
What should I do to make sure that the service will run indefinitely and will not be killed? I will not be able to monitor it from my main app and restart when needed.
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.
I made an android application with a runnable that checks something ever minute.
But the problem is the application goes [DEAD] after a couple hours without an error messages or anything.
Anybody have any idea what the problem could be?
That is not a problem, that is actually expected behaviour.
The lifecycle of all apps is managed by the Android OS. It decides whether to terminate an app in order to free resources and keep the system responsive. Apps that are currently is use have priority over paused and background ones. I think in your case the OS just decides to shut down the app because it thinks it's not needed anymore.
There are ways to get around this, but it all depends on what your app actually does. I don't know your implementation details, but may want to look into sticky Services or the JobScheduler in order to achieve what you want. Keep in mind that there is no such thing as a perpetually running background task that comes out of the box in Android (not should there be one) and usually implementations have certain limitations.
It could be the Android OS itself closing the app. If the OS requires more memory it will start to kill of other processes that have not been used for a long time (i.e. interacted with). You haven't stated how the check happens but it shouldn't be done directly within the app, but it sounds like it is something that a background service should be doing the work which would likely prevent this from happening.
You should NOT use Runnables for background processes, as they get suspended/killed by the OS as soon as your app goes off-screen.
If you want to let some processes run regularly, you have to stick with AlarmManager / BroadcastReceiver combination