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!
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 have coded a simple app in Android Studio. What it does is not important but it starts a Service with Context.startService(Intent i). Till now everything is allright BUT when I kill all tasks with my Task Manager of my phone the Service is killed, too and with it the notification ist creates! I don't understand why.
By the way: I used return START_STICKY at the end of my Service. And it has been started/sheduled by the Timer class with Timer.scheduleAtFixedRate(TimerTask task, int delay, int period). The Service has been started by my Main Application or by the BroadcastReceiver which received BOOT_COMPLETED. The timer has also not been canceled.
Hope you will pardon my english.
Services that are started with startService does not stop until an explicit call - stopService is done on that particular service. Another case when the service stops is when the phone needs more memory its stops the background services and applications. In your case, you are doing the exact same thing. Clicking on the kill all tasks clears the memory which is the exact thing that happens when phone is out of memory and wants more memory. In that case - services are stopped and sticky services are restarted. Now, how to handle the restart of the service properly, kindly search clearing memory stops services android and you will be shown a bunch of answers on stackoverflow !
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 this wierd Android issue with Services/IntentServices...
I have a Service which starts a manager class which asks for ActivityRecognition updates from Google Play Services (i.e. gets a connection, then calls requestActivityUpdates() on ActivityRecognitionClient passing a PendingIntent).
The PendingIntent references an IntentService with onHandleIntent(Intent) implemented - it just prints the most probable current physical activity to the Log.
So far so good. Everything works fine - the Service is bound, the Manager connects, the IntentService is fired and the users physical activity is written to the Log.
Here's the problem...
I want this to just sit in the background and listen for activity updates, even if my user shuts down the UI activity in the 'recent apps' screen. This technique I already use in my app for location updates - my location service keeps tracking location even if the UI portion of the app is destroyed by the user or the system.
Thing is, since adding this new Activity recognition stuff, when the user kills the UI, the next PendingIntent received by the IntentService kills, the entire rest of the App including all the other services. Everything stops/dies/disappears. But there are no warnings, no exceptions, no log entries, no nothing!
The only thing that keeps on working is the damned IntentService! That keeps going like nothing happened every time a new Intent comes in.
If I comment out the code where I register for activity updates (so the PendingIntent isn't used and the IntentService doesn't get called) everything works just fine.
I have no idea what's possibly causing this meltdown, and no clues to go off in the Log.
I searched and searched Google / SO but I've drawn a blank. I can't find anyone describing similar behaviour.
So is there another type of Android component capable of being triggered by an Intent that I could try instead of IntentService? Is IntentService realy the problem? Can Activity recognition not be done in the background like this? What other things could I try?
Update: Is it possible that when the onHandleIntent() method on the IntentService finishes, the OS kills all threads in my app, not just the one created for the IntentService?
Here's what's in the Log...
--User is shutting down the App UI, but the Services are left running as intended...
19:41:12.146 13679-13679/tripcomputer I/tripcomputer.TripComputer? STOPPED TripComputer Activity: 1107344720
19:41:12.153 1258-4401/? W/ContextImpl? Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1244 android.content.ContextWrapper.sendBroadcast:365 com.motorola.motocare.util.TriggerHelper$TriggerBuilder.send:76 com.motorola.motocare.internal.frameworkevents.PauseResumeTrigger.handleFrameworkEvent:53 com.motorola.motocare.internal.frameworkevents.FwEventMonitor$FrameworkListener.processFrameworkEvent:114
19:41:12.645 13679-13679/tripcomputer I/tripcomputer.TripComputer? DESTROYING TripComputer Activity: 1107344720
19:41:12.646 13679-13679/tripcomputer I/tripcomputer.services.JourneyServiceConnectionManager? Activity 1107344720 is STOPPING the JourneyService...
19:41:12.652 13679-13679/tripcomputer I/tripcomputer.services.JourneyServiceConnectionManager? IGNORING request to STOP the JourneyService - Journey in progress.
19:41:12.655 13679-13679/tripcomputer I/tripcomputer.services.ActivityServiceConnectionManager? Activity 1107344720 is STOPPING the ActivityService...
19:41:12.657 13679-13679/tripcomputer I/tripcomputer.services.ActivityServiceConnectionManager? IGNORING request to STOP the ActivityService - Activity in progress.
19:41:12.659 13679-13679/tripcomputer I/tripcomputer.TripComputer? DESTROYED TripComputer Activity: 1107344720
--The UI has closed down sucessfully.
--The next activity update arrives at the IntentService and gets printed...
19:41:19.703 13679-14095/tripcomputer I/tripcomputer.services.ActivityUpdateIntentService? The most probable user Activity is still (50)
--Then, the system kills the IntentService?
19:41:19.704 969-979/? I/ActivityManager? Killing 13679:tripcomputer/u0a152 (adj 0): remove task
19:41:19.706 1258-4401/? W/ContextImpl? Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1244 android.content.ContextWrapper.sendBroadcast:365 com.motorola.motocare.util.TriggerHelper$TriggerBuilder.send:76 com.motorola.motocare.internal.frameworkevents.ProcessKillTrigger.sendTrigger:147 com.motorola.motocare.internal.frameworkevents.ProcessKillTrigger.handleFrameworkEvent:164
--Boom!, everything else has gone but there's nothing in the Log
--System schedules the Crashed Services for restart
19:41:19.727 969-1273/? W/ActivityManager? Scheduling restart of crashed service tripcomputer/.services.JourneyService in 1000ms
19:41:19.736 969-1273/? W/ActivityManager? Scheduling restart of crashed service tripcomputer/.services.ActivityService in 1000ms
I did eventually find an alternative method that worked...
The problem I experienced above may to be to do with how IntentService threads are handled, although unfortunately I didn't ever track down a more concrete explanation for the total loss of the running app when the intent service's handleIntent method finished.
The workaround was to switch to using a combination of a regular Service to handle the ActivityRecognition PendingIntents (in onStartCommand(Intent...)) along with a custom made Runnable thread to handle the actual work offline from the UI thread. If you do this, the app no longer quits unexpectedly and you get the desired effect.
It's interesting that the documentation and sample code for Google Play Services' Activity Recognition feature only ever mentions working with user activity recognition from an android Activity or a Fragment and never from a Service. Could it be that working with activity recognition using IntentServices can only be done from components running on the UI thread???
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.