I'm write an auto-speaker app which has a service inside, and listen to the phone state change.
I expect that the service should be exist all the time and can't be killed.
However, I found that if I use some task killer to kill my app, there will be few seconds my listener won't work.
Although my app seems to be restart automatically in few seconds later and work again.
Why the service could still be killed by task killer??
Is a service just like an activity, just with no UI, and able to restart automatically?
Thanks for your answer.
You cannot exempt your service from being ended by the user or automatically by the OS when resources are needed for that matter.
The best you could do is attempt to write code to compensate for restarts but certainly don't write as if your service will run forever without exception.
EDIT
Android Developer documentation Managing the Lifecycle of a Service has useful information on recovering from stops and when the callback hooks get called and not.
Add this trick to your service onCreate:
startForeground(R.string.app_name, new Notification());
It will prevent service from closing on low memory, task killing etc..
Because taking away the ability of the user to end a process when he/she wants to is just wrong. Instead try to write a work-around so in the event of of the service shutting down, XXXXXX takes place.
Related
I need to create a service that runs alongside the android app,irrespective of which screen of the app the user is on.
The app is a chat application so when the device is offline the service should queue up all the messages that are being sent offline and when the device is connected it should sync all messages.
I have written code for the job scheduler to sync data automatically when the device is online but while the app is active i would like to handle this manually.
Creating a Long Running service.
Operating system still can terminate the service in low memory and possibly other situations. There are 2 ways to overcome this:
If you are implementing the service, override onStartCommand() and return START_STICKY as the result. It will tell the system that even if it will want to kill your service due to low memory, it should re-create it as soon as memory will be back to normal.
AlarmManager .A system service, which will execute actions periodically. That will ensure that if your service will be terminated, or even the whole process will die(for example with force close) - it will be 100% restarted by AlarmManager.
Thank you.
You can do this by simple following steps:
Create Simple Service and after first launch of app just start at splash screen.
In Service after getting one data you can call another request.
After that you can create one broadcast action globally which will always call every network changed.
At background you can sync again data and saved it to shared preferences or as per your your requirement.
For interval you can also using AlarManager.
A part from this you can simply create Service using JobSheduler in this you can assign job and time as well.
Refer link :
https://developer.android.com/reference/android/app/job/JobScheduler.html
Hopefully this logic will helps you.
You have to use a intent service with sticky instead of service for this which will be executed in a queue and do your work. And since it is a intent service it will be started automatically after sometime, when system kills the service process.
I have started a service from my application and from that service a worker thread is started .I want my service to run even application goes background and until the user kills/exits the application.
But some cases my service got killed due to low memory ,then used sticky service or making the app to foreground to restart the service.
My issue is I dont want to lose the data between service ending and restarting time ,so is it possible to start another thread from service ondestroy method, but in this case how we can control that thread.
Please let me know is it the right approach ,and is this usecase achievable
I want my service to run even application goes background and until the user kills/exits the application.
This is not possible. The user can always get rid of your app, via Force Close in Settings, or via some device's version of the recent-tasks list.
But some cases my service got killed due to low memory
No, your process is terminated for low memory.
My issue is I dont want to lose the data between service ending and restarting time ,so is it possible to start another thread from service ondestroy method
No, because your process is being terminated.
Please let me know is it the right approach
Probably not. Very few apps need a service that runs constantly, which is why Android, and its users, go to great lengths to control such services. I would recommend that you try to find some solution to whatever your problem is that does not need a service running constantly.
I am making an android app which will have two services that will keep sending data about the usage of the phone by the user every 24 hours.
The user should execute the app, toggle the buttons to enable the logging of the usage of the phone and then the user should be able to do a normal life with his phone, until he starts again the app and disables the toggle button to stop the logging of the info.
What considerations should I take about the life cycle of the services?
What about the interaction of the user with the phone while the services should be sending the data?
All info is very much appreciated, as I my mind is getting a little bit overwhelmed with all this!
Thanks a lot in advance everybody!
The service can be cut at any time through the settings menu. It can also be killed at any time by Android if it decides it needs the resources for the currently running activity. onDestroy() will be called regardless so use that to store anything needed.
The service runs in the background but through the main UI thread. Thus, it is possible to block operation of the phone through a service. It looks like the phone locked up when it's really a service trying to do something. Any blocking procedure should be used in a thread such as Java timer, Java thread, or AsyncTask.
There can only be one running version of the service at any given time. However, calling startService(myService) if "myService" is already running will essentially override the current running service and onStartCommand() will be called again. However, one call to stopService(myService) is needed to stop it no matter how many times startService(myService) was called.
stopService(myService) will not stop a service if the service is bound to anything. It will wait until all bindings are removed before the service stops.
My situation:
I have created an Android service, which is started when the app is started. The service consists of a simple Thread that waits for 5 seconds, writes a log message and waits again.
After closing the application (using the back button), Android chooses to restart my service , because I am returning START_STICKY in OnStartCommand.
When debugging the application, I can actually use DDMS to kill the process. Android again chooses to restart the service. This is expected as per the manual.
I also installed a task manager, and used that to "kill" the instance. Funky thing, is that now my service is no longer restarted.
The funky thing is this: in either case, no destroy code of my classes is called. No InterruptedException is raised on my waiting threads. There seems to be no way for my application to know it's being destroyed.
My question:
How can I get around this, and respond to kill requests? I already noticed that the DVM lacks sun.misc.Signal and sun.misc.SignalHandler for proper signal handling (if that's even being used by task killers).
I kind of need to know wether my app is being destroyed, so I can properly close file handles, database connections and the likes.
Many thanks for any assistance.
How can I get around this, and respond to kill requests?
You don't. OTOH, this task killer behavior should have been eliminated in Android 2.2, so it eventually will not be a problem.
My app runs a geolocalisation service that the user can active or disactive by a toggleButton. To check the status of the service, I write a boolean in the Shared Preferences. I listen the beginning of the service and the end of it thanks to the onDestroy() of my service.
My problem is that: When the user kill the service with the "advanced task killer", I can't know that the service is killed, the onDestroy is not called !
How can I deal with that?
Thanks for your help.
Florent
When a process is killed (using ATK or android's own force stop button, or the function here), it is immediately purged from memory (if the kernel allows it). This means there's no chance for any additional code to run, meaning there is no way to really deal with a "force kill" sent to your application.
If you want to handle this, you have 2 options (that I can think of):
Publish a disclaimer telling users to add your app to the "ignore" list of ATK.
Find some way to maintain functionality without relying on the onDestroy() method.
EDIT:
If you want to check for your process from a list of currently-running processes, look into getRunningAppProcesses().
onDestroy()
If you want to restart the service, you can restart in onDestroy().