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 !
Related
I'm developing a player app.
For this reason, it uses a foreground service to handle the playback.
Until recently the service was bound to my activities.
This is not the case anymore.
Since then, some specific devices (mostly Pixel 1/2/3) have been killing my app 1 minute after the screen has been turned off
The service is a foreground service not bound to anything.
Why would the device kill it?
As soon as the app is excluded from the device-optimized apps list the issue is solved
I'm not providing code, because I'm just trying to understand if this situation makes sense and if so what should I do to prevent this
BTW the app is using a receiver to act on Screen_ON/OFF messages. That's how I can see in the logs that the player service onDestroy() method gets killed exactly 1 minute after the screen has been turned off
what should I do to prevent this?
The key point here to keep the service alive is as said in official documentation :
While an app is in the foreground, it can create and run both
foreground and background services freely.
so, we can conclude that keeping the work in foreground and visible to the user has very minimal chances of being killed. And to do so we need to know that how android gets the idea that this process is in foreground ?
Here are the criteria's at which a process is said to be in foreground:
It has a visible activity, whether the activity is started or
paused.
It has a foreground service.
Another foreground app is connected to the app, either by binding to
one of its services or by making use of one of its content
providers. For example, the app is in the foreground if another app
binds to its:
-IME Wallpaper service
-Notification listener
-Voice or text service
If none of those conditions is true, the app is considered to be in
the background.
If none of the above criteria is fulfilled by your app process then thats the reason of your service being killed.
You can read more on this topic here :
Foreground service being killed by Android
I have been facing issues with Android service and their restart behavior. At present i have a Service (SERVICE 1) and a thread which is used to move files from one folder to the other. This works great.
But when I am in my app and start the moving service, and i swipe the app away from recent tasks(systemui.RecentTasks) screen the service is stopped with a log "Scheduling restart of crashed service". This service is a foreground service with an active notification.
I do have another service (SERVICE 2) which is also a foreground service with notification. This service also creates a thread to run a background operation. But when I swipe the app this service is not killed and there is not log from ActivityManager.
The final scenario is when the SERVICE 1 stopped frequently from recent tasks within small intervals , again and again, the SERVICE 2 is also stopped now with the same log. I can understand this, as the system detects frequent crash from this app, it tries give less priority to it even if it has foreground service.
My question is why this strange behavior. Both are running in foreground and with an active notification. why does the SERVICE 1 Is stopped and SERVICE 2 is not? I don't find enough resources of service restart behavior when it is crashed. Also i don't find information as how the android system manages to schedule a restart. FYI SERVICE 1 returns START_REDELIVER_INTENT and SERVICE 2 returns START_STICKY.
Kindly help me with this issue. Please. Thanks
I am working on a app that during boot time starts an activity that logs in to my server (needs an activity to log in through facebook) using a service (initiated with startService). This service establishes XMPP listeners and does nothing after that, just waits for connection. I want this service to run all the time the device is up.
The problem is that the activity stops after a while and my service is also stopped. The service returns START_STICKY so I was expecting it to hang around. Also the service doesn't do anything except wait for connection.
The activity has the properties:
android:excludeFromRecents="true"
android:noHistory="true"
android:launchMode="singleInstance"
so that it does not show up in the task list (when user long presses the home button).
The activity is stopped when the user long presses the home button and the service also ends. I am thinking its possible that the application exited, that's why the service also ends. I could not find any way to keep the activity from not stopping. Maybe its stopping because of the above properties.
So what can I do to keep the service running all the time. How can I keep the application from being removed. I read somewhere that if I keep a while loop running in the service then START_STICKY can keep the service around??
I can use AlarmManager to start the service but I don't want it to stop easily and then have to restart it every time.
I don't want to run a foreground service. I can not run the service in a different process since I am using existing code that does not do IPC. Any help will be appreciated. Thanks.
There are two things to keep running a service indefinitely; create the service using startService() and return START_STICKY from onStartCommand(). You seem to be doing this both. With these two steps, the service may be shut down by the system but it should restart almost immediately.
The only suggestion I have is to create a separate thread in the service. This is because by default, started services run in the application main thread. If the service is constantly doing certain task, it may block the main thread and kill the application. Google doc has an example of implementing this:
http://developer.android.com/guide/components/services.html#ExtendingService
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???
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.