IIUC, there should only be one instance of a given Android service, it is a singleton.
However, my service gets instantiated multiple times, although I
do nothing for it.
When the service crashes (for example when I uninstall the app through adb), it
gets scheduled for restart ("Scheduling restart of crashed service.. "). I
understand this is an effect of the service being sticky.
After that, when my app starts, it calls startService() and bindService(), and
the service gets appropriately started and bound. But the service is then
reinstantiated and onCreate() is called repeatedly, as many times it was
scheduled for restart.
Each instance then wait for clients to bind and register, but onBind() is only
called in the "main" service instance. The additional instances wait a bit for
client to bind, and since that doesn't happen, they call stopSelf().
But stopSelf() has absolutely no effect in these "dead" instances, onDestroy()
is never called.
The "main" service instance does work as expected, and when it decides to call
stopSelf(), onDestroy() is indeed called.
Worse, all these dead instances accumulate, they never gets destroyed.
Therefore, their only possible end is a crash (which happen every time I
launch/install through adb), and thus scheduled restart.
So that in the end I get many of these dead instances, which are restarted
progressively once by minute approximately.
Does anyone know what's going on?
I got similar behavior if I use eclipse to restart an app with a remote service. According to logcat, system consider the killed service had a crash and tried to restart the service. At the same time, the service has been restarted with the restarted app. For some unknown reason, Android system does not realize there is already a running service, and tries to start a new one.
It happens several times on Optimus one, Galaxy tab, and EVO 3D. It is fine with Nexus one.
Because I haven't seen your code, this is just a guess: Maybe you have a memory leak that prevents the service from destroying properly. That's the only reason I could think of to get multiple instances of service. For example, if you service is holding on to some object that also have a reference to your service. It happens a lot with inner classes.
Check out this video from Google I/O to see if this problem applies to your services and how to find it: http://www.youtube.com/watch?v=_CruQY55HOk&feature=player_embedded
if you use the section to be excecuted in onstart() . if ur starting the service by onclick button or like clicking on icon multiple time means ,what it will do is if service is already running means ,it will go to onstart(),so the method is excecuting again and again its not that service is starting multiple times .... ur method is running for multiple time ,This i told accornding to my guess may be exact code will be Explaind properlly
if your app exit on crash or kill the process it belongs to like System.exit(), it will start after your app exit or start if your service is running in the same process with Application.
Because you kill the process, and Android detect your service should not stop, so Android restart it for you after your app exit. And why service start again after app restart, I think it is Android's bug, it reallocate a new process to your app instead of using the process allocate to your service.
So, how to solve this problem?
just set the attribute android:process=":background"(whatever you want here, starts with :) to your service node in AndroidManifest.xml. hope it helps you.
Related
I have an Android Library with a service, which I implemented using AIDL. I want a single instance, cross application to be used with other apps. So I have a base app with the service and I managed to make the library for other apps to use the same instance.
My problem comes when I close all apps using the service, because for every app, the on destroy unbinds from the service, but the service is still running.
Also, I'm only using the service by binding, not by startService().
I checked through android studio that the service is running after closing the apps, and the counter I have on the service for each bind/unbind call is 0!. I increment the counter when there is a call to bind, and decrease for calls to unbind. My only way to make the service stop is by opening the base app, which has the service defined and closing it.
Edit: Also noticed that onBind is being called only once, even for other apps that are binding, but the reference for all those apps is still the same service, they share the same information and only one Service is shown in the android studio.
Edit: I've also observed that if one of the apps using the service is the base app, if I close it, the service dies and another one is started, the other apps don't notice the change, they keep using the service as if nothing happened, which is understandable because it's a remote service.
What is happening and what can I do about it?
For the two points being questioned:
I was able to verify what CommonsWare said that the process in which the service is run is still up, but the service itself is not. At first I had a thread running in the service after every app unbound, but after making sure it wasn't up in the end made the service be destroyed.
The second issue, regarding the service being destroyed while still bound with other activities was solved by seeing this link which describes a bug in android that kills services when it shouldn't. My case was simply solved by making my service run in the foreground, which I didn't know was possible.
After some tests I verified the service is still intact as long as any app is bound with it, and that the service indeed is destroyed correctly after no more app is bound.
I am working on an Android project that requires me to end a service completely and then restart it at some later time. It should end when a user logs out and restart when the user logs in.
I am new to the project and Android, so sorry if this question will have an obvious answer.
The service extends IntentService. I override onDestroy and in this method I call stopSelf() and I also call stopService(intent) where the intent is the intent passed to onStartCommand. The main service has some other services that are bound to it, but I make sure to unbind them (I think I have found all of them) before calling the stop functions.
When the user logs out, it appears that the service is dead. There are no log messages coming out and the app just hangs, as expected. When I log back in, there are two services running. I can tell this because the log messages are printing doubles (triples if I log out again and log back in, quadruples if I do it again, and so on). For example, there's a message that says "Starting service" in the onHandleIntent
What reasons could cause the service to restart in duplicates? Could it be a bound service that I missed?
Thanks.
The issue I was having was that the service was an IntentService. Instead of killing the service and restarting it, I just change parameters while it runs.
I have an IntentService which is used to save [potentially large] files. I initially had a problem where the service would die mid-save if the app was killed. Starting the Service in foreground during a save solved this problem for the most part.
Here is the problem: If the app has been killed while a file is being saved, when I call stopForeground (when the save is complete), the service crashes, indicated in Logcat:
06-23 16:47:25.266: W/ActivityManager(523): Scheduling restart of crashed service...
I have verified that nothing after the call to stopForeground is executed.
It's very possible for me to move my code around a bit, so that this doesn't really cause any problems, but I don't like allowing the service to crash just because there are no consequences...
Because there is no problem at all when the app is still running, my only guess is that it has something to do with the context used to start the service no longer existing. I have tried using both the activity and application contexts, and have also tried running the service in a separate process from the rest of the app. All attempts had the same result.
Am I overlooking something? Thanks!
I am working on three different services and on device bootup, one service starts other two services. Right now its working fine but some times my service crashes and it restarts itself. I know that this behaviour is common with services, if the memory is low then for reclaiming the memory service restarts itself.
I need to track the service info like getting the service crash time. Right now I retrieve the service start time by writing code in onstartCommand() and stop time in onDestroy().
What I observe is stop time in onDestroy() code does not execute when service is crashed. So Is there a way to get the service crash time?
A few thoughts:
If it's crashing, it will leave a trace in the log file, there are some comments on reading it here: Android read error log from handset
If it's being closed by the system in a normal way, it should go through onDestroy.
If it's going through the slightly mysterious "close, restart" effect that has been reported elsewhere, then it doesn't seem to hit the log, but the two events seem to be very close in time, and this effect seems to be stopped by making the services run in separate processed. (Android service onCreate is called multiple times without calling onDestroy and possibly Service being re-Created by AlarmManager).
From a state management perspective, if you store the time the service last did something of note (ie keep a stored time of when it does something of note and update it everytime it does something of note) then you will have a good estimate.
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.