Am using Network Change listener (in manifest) in android app, here i can observe once the app received any broadcast app process continues running even after completion of broadcastreceiver execution. I observed this behavior in debug build while connected to studio, is this is the behavior in the real-time also ?
Yes, this is expected. By triggering the BroadcastListener, Android system started the process of your app. It will then keep this process until it needs to kill it for resources.
This does not mean that any user-relevant components of your app (like Activities, Services etc.) are running in the background. Just the process, which is a "box" which houses all that :-)
Related
I am using the WorkManager API that is supposed to be able to run even while the app isn't started or is killed(?) Then I wonder, if app isn't started or is killed, which process does the work actually execute in? Some system process? Or is it actually (by default) always running in a designated thread in the app process if nothing else is specified? I am confused. If it is running in the app process, does it start the app process without actually starting anything else in it, then?
I am curious to whether I can access my app's data from within the work while it is executing. I mean I am not supposed to be able to access for instance a singleton app member in case it is running in a completely separate process.
I have read many posts state that doze mode killed a running service at a particular moment e.x link or that they want to execute a long running thread.
I can't understand why you should use a service to do a background job that you know that in some point it will stop eventually.
For instance:
You could use a simple Thread:
new Thread(new Runnable).start()
and do some work in it. Using this:
In combination with a wake lock, device wont sleep and thread will keep running.
No doze mode restriction (except network but lets say we do local stuff)
So you can do background work with no restriction whatsoever. Although you should use services for these reasons link.
Is this another way (not better of course but a way nonetheless) of doing a background work? Am I wrong?
There are a lot of ways to do a background job aside of services check this link it may help you pick the best option for your work :
Job Scheduler vs Background Service
And services as #TheWanderer said will continue to work event after the app is closed for a period of time unlike a simple thread that will end immediately when the app is closed.
Read this part in the link that you linked
Services are given higher priority than other Background processes and
hence it’s less likely that Android will terminate it. Although it can
be configured to restart once there is ample resources available
again. You should go through the different processes and their
priority/important level in the documentation on processes and
threads. Assigning them the same priority as foreground activities is
definitely possible in which case it’ll need to have a visible
notification active (generally used for Services playing music).
If you are running a background thread that you start from an Activity, Android does not know that you are doing background work in the OS Process that is hosting your Activity. Android can kill the OS Process hosting your Activity at pretty much any time. If the user presses the HOME button or takes a phone call or opens a notification and goes to another application, Android can kill off the OS Process at any time. When the user returns to your application, Android will create a new OS Process and recreate all the relevant activities, but your background thread is hopelessly lost. This is the reason that Android has services.
If you start a Service to perform your background processing, the Service will also start background threads, but these are controlled. Your Service tells Android what to do if it kills the Service while it is processing an Intent. Your Service can therefore be informed and restart (or continue) the background processing as necessary. You can also run the Service in a different OS Process from the OS Process running your activities. This will prevent Android from killing the Service if the user removes your app from the list of recent tasks.
With newer Android SDKs there are other mechanisms you can use, like JobScheduler.
I have obtained images from the camera and want to save it to a directory after some processing which takes about 10 seconds. I tried the following methods :
1) Asynctask(Problem : if the user closes(swipes) the app, the asyncTask is killed)
2) Intent Service(Problem : same as Asynctask)
3) Foreground Service(Problem : Hangs the UI of the application)
4) Running on UI Thread(Problem : Hangs the application).
So my question is what should I use to save my images(with some processing) such that all tasks are done even if app is closed and the UI does not hang(freeze).
Any help would be appreciated.
You cannot prevent Android from killing your process. If the user wants it killed (for example, using "force stop"), it will get killed. There is nothing you can do to prevent that.
When the user swipes the task from the recent tasks list, the behaviour is different in different versions of Android (and also different manufacturers have different behavour). However, in most cases, the OS Process hosting your app (including any services) is simply killed. If the app had a running Service that wants to be restarted, Android will create a new OS Process and reinstantiate the Service and restart it.
You can mitigate this a bit by putting your Service in a separate OS process. To do this, add android:process=":remote" to the <service> declaration. On some versions of Android, swiping the task from the recent tasks list will then kill the OS process hosting your activities, but NOT kill the OS process hosting your Service.
In any case you need to make your app robust so that it can handle being killed and restarted.
Thanks everyone for suggestions. How I finally was able to achieve this was using a foreground service which itself created and asynctask to perform the work in the background. I am a novice so don't exactly know how it's working, but it doesn't cause any app freezing/lag and does the work even if the app is swiped from the recent tasks list. (tested in Android L(5.1.1) and M)
How does the apps like Swiftkey, Locker Master manages to keep process alive even after it has been removed from back stack?
They also don't use sticky notification.
Update:-
I need to keep my process alive. But in my case service is active but process gets killed.
They all have one or more unbound background service.
To kill those services you can go into Settings -> Apps -> Running.
However the services may be restarted at any time by other apps or system by sending a system wide message (intent). In most cases it is restarted by
Time events
Boot complete
Other apps
Other intents
In the Swiftkey case, it will be started by Android OS when it needs to show a keyboard.
EDIT: you can specify that a service runs in a remote process by adding this to the service definition in AndroidManifest
android:process="process_name_here"
However there is no such thing as a service that cannot be killed and can run forever. Android OS may start killing your service if it is running low on resources or the service is running for a long period of time. To overcome this, you can make a forground running service, but it needs to show a notification. It can also be killed by task managers, like you mentioned. You should instead start focusing on how to save it's state so you are able to restart it later.
I created an Android app and need to make it difficult for users to stop the main service that the app spawns during its startup process. This is for a rooted Jelly Bean 4.1.2 device. Here are some steps I've taken so far:
Installed as System App
Uses the Device Admin APIs
android:allowClearUserData="false" is included in the AndroidManifest.
The steps I've taken so far takes care of most normal ways a user would stop/disable an app/process; however, when you check the running apps list in Settings -> Application manager -> Running, users can still hit the 'Stop' button on the long-running service that was started by the app (see picture below):
Is there any way to prevent users from stopping the service here? Or what's the best way to restart a service when a user hits this stop button? I tried putting some code in the service's onDisable() function, but that function does not seem to be called in this case.
Any help would be appreciated!
As explained above does not have this option unless it is executed as root, but you can create an AlarmManager when starting your service that runs from time to time, the system will run if the service is not running, it will be created again.
Is there any way to prevent users from stopping the service here?
Having your app be a device administrator probably blocks this. It definitely blocks the "Force Stop" option.
I tried putting some code in the service's onDisable() function, but that function does not seem to be called in this case.
Since there is no onDisable() on a Service, this is not surprising.
This is a security app for an enterprise, so its expected to be continuously running.
There is nothing intrinsic to "a security app for an enterprise" that would require it "to be continuously running".