I believe you all are already familiar with "background service limitations" imposed on Android 8.0 and up (https://developer.android.com/about/versions/oreo/background.html#services).
I'm having a very particular problem right now. My application is meant for a very specific use case. App checks for certain data on the server every minute and in case of some wrong value, user is being alerted immediately. Obviously so far application was running in a form of background service and my customers never cared about (obvious) battery consumption coming from complex calculations that are being performed every minute.
Now, whole idea is that app needs to stay alive, working and in background (even with permanent notification, i don't have anything to hide) regardless of anything! If phone is in a deepest possible sleep state - service needs to keep running. If there's 2% battery left - service needs to keep running. So far, i managed to achieve that using alarms and "guardian services" which prevented any way of stopping the background service while app is installed. But now, with Android "0" - what's the way to go? Is there a JobScheduler that will guarantee execution at given rate (every minute) regardless of anything?
How SMS / Phone, WhatsApp and similar apps achieve that "awake no matter what" state?
That's what Google tells us.
A process is not forever.
If you feel you need your foreground service to stay alive
permanently, then this is an indicator that a foreground service is
not the right answer.
Effective foreground services on Android
I think you could use repetitive tasks with WorkManager or change the architecture and use FCM. In any case, Google will not let us work as it did before.
Related
I am building a ride-hailing app and I need a real-time driver location update even when the app is closed or in background, according to the new android os versions I can't use background services even if I could use it the os might kill it so my best option is to use foreground service with a noticeable notification, my question is, is it possible to use an ongoing foreground service for realtime location updates without being killed?
A foreground service can still be killed, its just less likely to be so. If the user was to open up a couple of memory hogging apps that meant it really needed your apps memory, it can still be killed. There's a priority to what stays in memory, having a foreground service just makes it higher priority than an app with a background service using the same resources. That said, a foreground service is your best bet for short duration updates like that.
Note that there's a difference between "closed" and backgrounded. If the app is backgrounded, a foreground service will continue. If the user terminates the app by swiping it away from recents or force stopping it, the foreground service will also be killed. But the foreground service would allow him to move to another app (like Waze or something) without killing your app unless the phone goes really low on memory.
i have a problem look like you . i am searching a lot and i test
foregroundservice , alarmManager , Worker and ...
none of them isnt working well and suddenly service stoped ! .
in the end i find 1 ways :
1- handle service in server in backened with pushNotificaiton .
In my app I want to show notification on exact time when the app is working in background or even it is closed. I used AlarmManager and service with BroadcastReceiver to show notification. The latest versions of android doesn't allow to run service in background after app closed and foreground service is consuming battery, slowing down the device etc.. I wonder if I could use something else can work even app is closed and show the notifications. I've heard of WorkManager and JobScheduler for that kind of operations but can they do the work even if app is closed?
Foreground services is not consuming more battery and not slowing down device, just notification is shown.
And the answer is basically it is not possible to make continuous background service on new android API's. You only can schedule tasks with tools like WorkManager, JobScheduler and so on.
These days I think WorkManager is the answer because Android team is focused on it this year.
Also even continuous foreground services gets killed after some time.... To avoid that 2 things has to be done:
Native battery optimization for app should be disabled.
Phone manufacturer (another battery optimization) has to be also disabled for specific app.....
I know it is worst user experience, and they throwing away half smart things that phone can do, but life is life :)
I'm writing my first independent Android app. It will sit in the background and respond to a few events generated by the OS, somewhere between a few times a day to a few times a week depending on the user.
Coming from a PC programming background, I thought I might need a service, but Android Developers > Service says:
What is a Service?
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
The app should not need to consume any resources unless one of the events it's listening for happens. The user should also not need to actively use the app after it's been set up, only if they want to change its settings.
I have games that seem to do something similar to what I want. They sit in the background and can receive messages (e.g. it's now my turn), and when I click on the notification it loads the game into memory, which takes a few seconds longer than if it was already in memory.
If the user hasn't used the app's interface for a month, I want it to still be in operation (even if the device has been power-cycled) and respond to events but not to appear in the list of recent apps (assuming a month is long enough to push it off the end). Ideally, I want it to respond to the events within one second; it doesn't have to be near-instant. What's the normal way this is done?
An app (occasionally used) and a separate "service" process/thread (persistent)
A combined app and "service" (persistent)
A combined app and "service" (loaded into memory by events)
Not enough reputation to comment, but just to tell you that nothing prevent Android to kill your service, To restart your service after the user reboot its phone you can add a broadcast receiver and listen to
https://developer.android.com/guide/components/broadcasts
.Also, if you don't want to display a notification while your service is running you will have to use a background service instead of foreground one. Hope this help.
Since threads persist past the lifetime of the activity that spawn them, I can just put whatever background work I need to do on HandlerThreads for example, no need for a service. Also they will keep running when the app in in the background bypassing the new Oreo restrictions.
Am I missing something here?
Also, ever since the introduction of Doze mode and the addition of even more restrictions on background work starting Oreo, when exactly should I use a service to do background work? Apart from
scheduling tasks for future conditions, such as WIFI connection, or charging I would then use a JobScheduler. But even that can be handled through a BroadcastReceiver...
Also they will keep running when the app in in the background bypassing the new Oreo restrictions.
That isn't quite right. It's true that background threads will continue to execute for as long as your app is alive. The problem is, your app might not be alive for very long! A Service is used to indicate to the operating system, "I don't want to get torn down; I still have useful work I have to do".
From the docs:
...[A Service represents] either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.
and
It is not a means itself to do work off of the main thread
Ultimately, when Android is deciding whether or not to keep your App around, it doesn't care about the number of threads you have running, the number of CountDownTimers that haven't finished yet, how many Runnables you have waiting in the queue, etc. It cares about whether or not you have any active application components. Is an Activity visible? Great, stick around. Is a Service started? Also great. None of the above? Maybe it's time to terminate the app.
So this also answers the question, "when exactly should I use a service to do background work?" As mentioned, a Service won't do the work for you, it'll just help you stay alive. You can try to kick off a thread in a BroadcastReceiver (note that most implicit broadcasts no longer work post-Oreo), but as soon as you return from onReceive(), your app is likely to be killed -- unless you have a Service going, too.
ADDITIONAL POST-OREO CAVEATS
Note that a Service is likely only going to help your app stay alive for "several minutes" after the app leaves the foreground (docs). The only way I am aware of to get around this is to get back into the foreground by making your Service a "foreground service."
Additionally, if you need to ensure the device remains awake until your work is completed, you'll need a component in the foreground. That is, you can still do that work in the "background" (in the sense of being "off-screen"), but you'd need a "foreground Service" (icon in the action bar). Otherwise, Doze will apply, and that tends to inhibit any WakeLocks your app is using.
I am using AlarmManager for repeated background process. My app repeatedly requests data from server in 5 sec interval. But after some long time, when I open my app it crashes. I can't figure out why.
How should I execute a background process repeatedly? Should I use AlarmManager,Timer` or something else?
My background process should run always even when the app does not have focus or isn't active.
My app repeatedly request server for data 5 sec interval.
Users with mobile devices, like phones and tablets, will not appreciate your behavior. They will not appreciate your consumption of battery life and your consumption of bandwidth. Device manufacturers and Google are continuing to take aggressive steps to prevent applications like yours from behaving this way, both automatically and by giving users the tools to find ill-behaving apps like yours and get rid of them.
But After some long time when i open my app its crash
Most likely, you have a bug in your app. You will need to fix the bug. Since you have provided no details of your crash, such as source code and a stack trace, nobody can really help you with that.
Which is the best for repeated background process, AlarmManager, Timer or something else?
Switch to a user-configurable and less-crazy polling period (e.g., every 15 minutes by default), then use AlarmManager in conjunction with an IntentService, so that your process can cleanly go away
Or, switch to having the server send messages to the device when the data of interest changes, such as via Google Cloud Messaging. This will allow you to drop the polling period to something infrequent (e.g., every hour by default), as a fallback mechanism in case you miss a push message for some reason.
My background process should run always though the app is not on focus or active
Your users will disagree with you. They do not want apps running all of the time, tying up system RAM. They really do not want apps that consume battery and bandwidth the way that you are proposing. The users will get rid of your background process, either by:
swiping your app off the recent-tasks list
using a third-party task manager
force-stopping your app via its entry in the application list in Settings
uninstalling your app