I have a service that has started by startService and binded with BIND_AutoCreate , I want my service runs automatically when android kill it for low memory , how can I implant that ?
thanks'
If the service is created because of the BIND_AUTO_CREATE binding, it will be stopped if it does not have any activities bound to it.
According to the docs (service lifecycle), you can both start explicitly a service and then bind with the autocreate flag enabled.
If you start explicitly the service as STICKY (returning START_STICKY in its * onStartCommand* method, it will be automatically restarted back whenever the system has more resources.
You have to register broadcast receiver for the ACTION_DEVICE_STORAGE_OK which indicates low memory condition on the device no longer exists. In the onReceive() method check your service if it is stopped, start it.
The DEVICE_STORAGE_OK action is broadcast when the device has recovered from a low memory state(internal memory). I think this is a perfect event for you to check if your service was killed during memory recovery by the system, and start it if was killed.
Please read documentation here.
Related
I was using a service which will update my application whenever new update is available in server. So my service run and it always check with server for version update and if i get new version update it will install.
My issues whenever i closed my application form taskmanager my service is getting killed. I used START_STICKY in onstartcommand() also even though it is not working. Is their is any chance to restart my service once it is stopped by taskmanager.
You can use AlarmManager to periodically wake up your application (i.e. activity or a service). This way you won't need to run service in the background all the time.
Just set AlarmManager to wake your app/service every day/week, check for an update, and then close the service. Check out this tutorial on how to use AlarmManager.
This approach will be better than running your own service, because it'd use no memory or battery power. Your users will thank you for that!
If your application is designed to run on API level 21 or newer (which means Android 5.0 Lollipop), you can also take advantage of JobScheduler. It might be useful, i.e. it could schedule update check to run when device is plugged in, to further save power.
From the docs:
Notice that the onStartCommand() method must return an integer. The integer is a value that describes how the system should continue the service in the event that the system kills it (as discussed above, the default implementation for IntentService handles this for you, though you are able to modify it). The return value from onStartCommand() must be one of the following constants:
START_NOT_STICKY
If the system kills the service after onStartCommand() returns, do not recreate the service, unless there are pending intents to deliver. This is the safest option to avoid running your service when not necessary and when your application can simply restart any unfinished jobs.
START_STICKY
If the system kills the service after onStartCommand() returns, recreate the service and call onStartCommand(), but do not redeliver the last intent. Instead, the system calls onStartCommand() with a null intent, unless there were pending intents to start the service, in which case, those intents are delivered. This is suitable for media players (or similar services) that are not executing commands, but running indefinitely and waiting for a job.
START_REDELIVER_INTENT
If the system kills the service after onStartCommand() returns, recreate the service and call onStartCommand() with the last intent that was delivered to the service. Any pending intents are delivered in turn. This is suitable for services that are actively performing a job that should be immediately resumed, such as downloading a file.
Have you tried to return the onStartCommand() with START_REDELIVER_INTENT ?
You can owerride this method onTaskRemoved to start service again via BroadcastReceiver.
I have a Service running in the foreground, and an Activity that interacts with it. If the Activity crashes, Android kills the entire process, including the foreground Service and its associated Threads.
However, the ongoing notification provided by the Service does not go away, and upon closer inspection, Android's task manager reveals that the Service itself is still running.
How can I kill the foreground Service in this circumstance?
Have you override onStartCommand method of the Service? What value is it returning? If not, try to override it and return START_NOT_STICKY from it.
START_STICKY: If this service's process is killed while it is started, then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service.
START_NOT_STICKY: If this service's process is killed while it is started, and there are no new start intents to deliver to it, then take the service out of the started state and don't recreate.
Not sure, as I have never worked on foreground services, but this might be the reason.
Are you sure the service is not running it its own process...
Also can you confirm whether the service is getting restarted..If its getting restarted-it is because you are returning START_STICKY from onStartCommand()
I want to run a service to collect the accelerometer sensor information and it shouldn't stop when the phone is sleep or the activity (for starting the service) is not running.
I have to send start and stop commands to the service from the menu activity.
currently I am using a bundled service in the same process of the activity but the problem is that it gets closed as soon as activity is closed (return key pressed).
I am wondering if I use a separate process it will resume even if there is no bundled activity (when activity is closed).
If not, which service model should I choose?
You are probably looking for startService instead of bindService.
http://developer.android.com/reference/android/content/Context.html#startService%28android.content.Intent%29
However, even with startService, there are no guarantees the service will remain running "forever" and "always".
WARNING, the options below will consume a lot of battery.
You can increase the chances the service will not be stopped by changing the priority to startforeground (requires a notification).
While the screen is off, the only way to keep the service "alive all the time" is to use Alarm Manager with an RTC_WAKEUP or ELAPSED_REALTIME_WAKEUP schedules.
Less battery...
Practically speaking, however, without startForeground and just using normal RTC or ELAPSED_REALTIME alarm schedules, your service will run most of the time.
You can create a service in the same process with your application, even if your activities all closed, the app still work because your service still alive until you call stopservice (the system will restart your service automatically when it is killed by system). if your service perform complicated communication with activities , i think you should use remote messenger service. During running of service you can bind to service to send and receive data between service and activities.
For more information of service and communicate to service, you can refer here
I have built an application which implements a number of broadcast receivers and registers them within a service based on user settings. The service is bound to an activity which calls some of its methods.
When a broadcast receiver is called it starts the service (or calls onstart of the service if it is already running) and passes it a string telling the service what to do. My problem is when the activity is destroyed (back button) the service is also destroyed which in turn kills the broadcast receivers.
I know I can register the receivers in the manifest which would mean doing a check when they are called to see if the user has selected that option. However one of the receivers critical to the application is 'android.intent.action.HEADSET_PLUG' which can only be registered programatically.
So I guess my question is, is there a way to keep this broadcast receiver active when the service is destroyed?
If not can anyone see a workaround for this issue?
Thanks,
Rob
My problem is when the activity is killed the service is killed which in turn kills the broadcast receivers.
If by "killed" you mean the user terminated your app with a task killer or "Force Stop" in the Settings app, then "killed" is the appropriate verb. However, your whole process is "killed" -- it does not follow the chain of events that you describe here.
If by "killed" you mean the user exited your activity via the BACK button, that is because you elected to bind to the service, rather than start it. If you want the service to continue executing past the lifetime of the activity, you must use startService(), and ensure that there is some path by which the user can indicate that they no longer want this service, so you know when to call stopService().
So I guess my question is, is there a way to keep this broadcast receiver active when the service is killed?
No.
If not can anyone see a workaround for this issue?
Start your service, instead of (or possibly in addition to) binding to the service.
I am building an application where I need a service which will never stop like android system services. I can make my service restarted by system using start_not_sticky but there is no guarantee that my service will never stop. So my idea is if there is any way to broadcase receive when my service will be goes off I can restarted the service. Is there any way to receive that?
The documentation explains it best :
Use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory . (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)
Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it