I have been reading Android docs and I feel I am bit lost and confused.
What is the type of service I need to use in Android, so that I can keep running my code even when the app is paused or minimized for prolonged period.
I am not interested in running the service if the app is closed. I want to run small piece of code that will run when app is in foreground or background, but not killed.
You can use a bound Service. The Service will stop after all the bound clients disconnect. Your Activity binds to the Service and when your Activity is killed or finished, you unbind and the Service stops. If Android kills off the Activity, the bound connection is also shut down and your Service will stop.
I am developing an application in which a background service is created to collect sensor data. I am starting the service from my activity:
startService(new Intent(this, MyService.class));
I created the service so if the application is destroyed, the background service still continues to collect data. I tried this, and it worked to a certain extent. My problem is that when I kill the application, the service seems to restart because the onCreate() service and the onStart() methods are invoked. Is there any way with which the service isn't restarted please?
UPDATE:
As suggested in an answer below, I added the following method in the service but no luck.
#Override
public int onStartCommand(Intent intent, int flags, int startId) {
return START_NOT_STICKY;
}
It depends on the value returned in onStartCommand.
You must return START_NOT_STICKY
According to the documentation:
For started services, there are two additional major modes of operation they can decide to run in, depending on the value they return from onStartCommand(): START_STICKY is used for services that are explicitly started and stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are used for services that should only remain running while processing any commands sent to them
In short:
If you return START_STICKY the service gets recreated whenever the resources are available. If you return START_NOT_STICKY you have to re-activate the service sending a new intent.
Since all of this triggered my curiosity, I made a sample app to test this. You can find the zip with all the sources here
There are a startService button and a stopService button that do what you would expect from them.
The service returns START_NOT_STICKY in onStartCommand.
I placed toasts in onCreate, onStartCommand and onDestroy.
Here what happens:
If I press start, onCreate and onStart are called
If I press stop, onDestroy is triggered
If I press start twice, onCreate is called once and onStartCommand twice
So it behaves as one would expect.
If I start the service and kill the app as you described, onDestroy does not get called but neither onCreate or onStart.
If I get back to the app and I press start again, onCreate gets called which means that, as I wrote before, START_NOT_STICKY prevents the service to getting restarted automatically.
I guess you have something else in your app that starts the service again (maybe a pending intent).
The app and the service live on the same process, which means when the app is killed so is your service. Changing the return value of onStartCommand doesn't affect this process. It simply tells the Service to either start/stop when you tell it or when it's finished doing what it needs to. As mentioned in your comment to your original post, setting it as a foreground process worked, but that's really just forcing the service to have a high priority, not solving the problem.
To change the Service so that it's killed separately and assuming it's a started service rather than a bound service due to the use of onStartCommand, specify a process name in the manifest for that Service.
From the Process and Threads Developer Guide:
The manifest entry for each type of component element— <activity>, <service>, <receiver>, and <provider>—
supports an android:process attribute that can specify a
process in which that component should run. You can set
this
attribute so that each component runs in its own process or so
that some components share a process while
others do not. You can also set android:process so that
components of different applications run in the same
process—provided that the applications share the same
Linux user ID and are signed with the same certificates.
Android might decide to shut down a process at some
point, when memory is low and required by other
processes that are more immediately serving the user.
Application components running in the process that's
killed are consequently destroyed. A process is started
again for those components when there's again work for them to do.
From <service> in Manifest File:
android:process
The name of the process where the service is to run.
Normally, all components of an application run in the default process
created for the application. It has the same name as the application
package. The element's process attribute can set a
different default for all components. But component can override the
default with its own process attribute, allowing you to spread your
application across multiple processes.
If the name assigned to this
attribute begins with a colon (':'), a new process, private to the
application, is created when it's needed and the service runs in that
process. If the process name begins with a lowercase character, the
service will run in a global process of that name, provided that it
has permission to do so. This allows components in different
applications to share a process, reducing resource usage.
Not sure why the other answer that mentioned this was down voted. I've used this method in the past and, today, created a simple one Activity app with a Service on a different process just to make sure I wasn't crazy. I used Android Device Monitor to kill the app's process. You can see both, separate processes in ADM and can see that when the app's process is killed, the Service's is not.
Start not sticky doesn't work above kitkat, and the other onTaskRemoved not working above Marshmellow.
onTaskRemoved could be used by handled some exceptions. Did not worked on that. But try that one.
If you are using an IntentService, it has an
onHandleIntent()
method where you should place the code that needs to be executed. It is executed in a separate thread (not a UI thread where your application runs) therefore your app shouldn't affect it. When the code has finished executing, the thread is terminated and the service is stopped automatically.
I ran into the same problem and was able to resolve it by making the service run in a global process. You do this by adding the following to the manifest tag:
process="com.myapp.ProcessName"
(Make up whatever name.)
When I did this I found that my service wasn't killed (and restarted) when the app is swiped off the list. Presumably this is because the app process is killed when you swipe it off, but global service processes are not.
The disadvantage of this is that communication between your app and service now has to be via the IBinder interface; you can't directly call functions in the application or service from the other one, because they're running in different processes.
I know its much late to answer this question, but may be it can be helpful to others. This really helped me for my Music Player App.
If there are services which can be disruptive or can affect the user experience like music etc , then in that case you have to use Notification and when service is started successfully, then create the Notification and use the function
startForeground(int Notification_id,Notification);
This will run your service in background without restarting and reinvoking its methods
https://developer.android.com/reference/android/app/Service.html
I've developed an android application with a service that runs in the background
the service is called like that
startService(new Intent(getApplicationContext(),myService.class));
but when I remove the app from the recent apps, the service stops and it crashes if I test it..
is there a way to prevent the service from being destroyed when swiping the app from the recent apps?
thank you
You can register a service to run on a repeating cycle using AlarmManager
http://developer.android.com/reference/android/app/AlarmManager.html
The service will run even if the application is not running.
I have an Android app published on Google Play. When the app is launched for the first time (it is done by storing and checking boolean flag "FirstLaunch" in SharedPreferences), it launches a Service which will be launched once a day (=every 24 hours using AlarmManager).
For the sake of simplicity let's say that this service just shows a Toast with "Hello World!" when the time comes.
Let's assume that there is a user who downloaded and installed my app from Google Play.Let's also assume that I have changed some code in that service (e.g. changed the Toast from "Hello World" to "Hello Universe!") and updated the app on Google Play.
If that user updates my app, will the service start showing new Toast text ("Hello Universe") once a day, or will it still show the old version ("Hello World")?
Generally speaking, if I am changing the code of a running service, do I need to relaunch it programmatically in my app, or will Android itselft change/switch its code to the new version?
Android services runs as part of your application process, when the process is terminated your services will be terminated as well (it will be restarted if its start mode is sticky which will restart the whole process), so when the user updates your app a new process will be started with your new code
If Android updates an app (through the PlayStore of course),which you are currently using, it gets terminated. Services get terminated as well. So if users of your app receive their update, their service gets terminated and restarted, if thestartmodeof your service issticky or it gets restarted by your app.
Hello im triying to run a service in background that it doesn't stop when app is destroyed by task manager. The idea of the service is verify every "x" min if there a new insert in a database that i got in a server.
The service is running great even if i close the app but when i use the task manager to destroy my app all the threads are closed too.
So i want to know if its possible to run a thread that ask in background forever unless user cancel it in the app itself, that ignore the destroy caused by task manager so in the future i can use notification bar to tell the user that a new insert happened in the database.
Tryed:
public int onStartCommand(Intent intent, int flags, int startId) {
// TODO Auto-generated method stub
askServer(); // i made a timertask that ask every "x" minute
return START_STICKY;
}
As i read START_STICKY should run again the service if it get killed for some reason and i know that this can be done since some app get closed by taskmanager and still get notifications from it as whatsapp,bbms and others. Please tell me if im wrong in anything and thank you for reading!.
UPDATE: Im not trying to break any law or security rule from Android and im not trying to ignore the stoping services option from an app in settings. I want that the service that listen for new incoming "events " inserts in my case keep running after user used the interface that appear when you press home for a while :
UPDATE : sorry for talking to much about this app but is the one that i can use as an example. In whatsapp when i close the app by the interface that i showed above the process and services are killed but after a couple of second they relaunch, this is exactly what i want to do to keep user informed about database events. From setting you still can stop the service without problem or even i can put the option in the app itself to stop notifiying.
Is a bad implementation call in OnDestroy() method an instance of the service so it relaunch after destroy?
UPDATE : welp looks like my service is still running on background after i close the app. I will just have to work on my service design to not waste battery life and resources. Also i was using the log.i() to check if service was running, looks like when main process closes i can't use log or toast just notifications ( still not implemented) because the service is there running just won't show in log .
UPDATE : now is working using using startForeground(0, null). In future i will send a notification to show when a event on database happen building it and calling startForeground(1, notification).
For services, look at Settings -> Applications -> Services. and see if it is running.
However, poorly designed services may run more often or perform syncing operations. So yes it is possible.
I had a problem similar to this when developing my first android game; force-stop was the only way to kill it.
START_NOT_STICKY will kill the background service when you swipe the app away from the task manager. START_STICKY is, as the name implies, "sticky", Meaning it sticks to the android system even when the app is gone.
That's from my experience, anyway.