I've got a running service. But when taskmanager kill the Activivty that starts the service the service get killed to.
Why do my service get killed when the taskmanager kill the activity not the service?
There is no "taskmanager" in Android, at least by that name.
If you are running Android 2.1 or older, third party applications that describe themselves as "task managers" or "task killers" can terminate your entire process, and more besides, which will get rid of your service.
If you are running Android 2.2 or newer, while "task managers" have a somewhat reduced role, the Settings application in the OS allows users to force-stop any application or individual service.
IOW, what you are seeing is perfectly normal and something you need to take into account. Users do not like services running for long stretches of time, unless they perceive value from those services being there. So, for example, a user who kills the service that is playing back music quickly learns not to do that anymore. But, if the user does not know what value your service is adding, and your service is running a lot, expect it to be shut down by the user.
As a result, savvy developers architect their applications to avoid long-running services. For example, if you are checking the Internet for something (e.g., new email) every 15 minutes, rather than have a service running all of the time, use AlarmManager to start up your service every 15 minutes, and have that service stop itself once the Internet check is complete. This gives you the same functionality, but you stay out of memory most of the time.
Complementing CommonsWare: if the only reason for your Service to exist was that it was bound to the activity, when that activity is killed there is no longer a reason for the service to exist, hence it could be killed.
(I thinking in bound services in here! http://developer.android.com/guide/topics/fundamentals/services.html)
Update
Based on your comment, I see that you are using a "Started" service. In that case I recommend you to implemente the service in a separate class, not as an inner class within the Activity class. This could be what was causing your problem.
Related
I am building a ride-hailing app and I need a real-time driver location update even when the app is closed or in background, according to the new android os versions I can't use background services even if I could use it the os might kill it so my best option is to use foreground service with a noticeable notification, my question is, is it possible to use an ongoing foreground service for realtime location updates without being killed?
A foreground service can still be killed, its just less likely to be so. If the user was to open up a couple of memory hogging apps that meant it really needed your apps memory, it can still be killed. There's a priority to what stays in memory, having a foreground service just makes it higher priority than an app with a background service using the same resources. That said, a foreground service is your best bet for short duration updates like that.
Note that there's a difference between "closed" and backgrounded. If the app is backgrounded, a foreground service will continue. If the user terminates the app by swiping it away from recents or force stopping it, the foreground service will also be killed. But the foreground service would allow him to move to another app (like Waze or something) without killing your app unless the phone goes really low on memory.
i have a problem look like you . i am searching a lot and i test
foregroundservice , alarmManager , Worker and ...
none of them isnt working well and suddenly service stoped ! .
in the end i find 1 ways :
1- handle service in server in backened with pushNotificaiton .
I'm fighting with the Android desire of killing everything which isn't active on the screen. My problem in few words:
I have a microcontroller which communicates with a processor on which Android runs;
the processor must keep active a watchdog on the microcontroller, resetting periodically (every one second) one of its registers; an application, say App B, accomplishes this duty;
on the processor I can be sure about the persistent existence of another application, say App A (or, however, if App A dies App B can die too because the system is compromised) which for now does nothing, in the future will accomplish other duties.
Which is the best way to implement App B?
I tried the following solution: App B contains a Bound Service, say Service A, to which App A can bind on; Service A starts a thread, say Thread A, which periodically resets the microcontroller watchdog. Thread A is launched when app A sends a command to Service A (e.g. START_WATCHDOG).
In my idea, Service A lives until App A lives (thanks to the binding), and so the process to which Service A belongs lives, and so also Thread A.
Unfortunately, from tests I see that sometimes (in a sporadic manner), after some time (sporadic time, too), with almost no work running on the system (except for App A, Service A and Thread A) the system kills Service A process, and so Thread A stops and the watchdog elapses.
When Service A dies, it is restarted (because it is a Bound Service and App A is still running) but, for now, I don't save the current state of Service (which simply consists on the START_WATCHDOG command arrival or not) and this is the reason for which the watchdog elapses.
So, I've got several questions about my solution:
is it ok and I simply need to save the current state of Service A in order to restore it when restarted?
should I discover better the reasons for which Service A, or better its process, is killed?
is there a better solution for my problem?
Thank you very much to everyone who will spend some time to help me.
Being not sure about periods in which your service runs you can try these:
Use foreground service. However, you might need to acquire a wakelock within your service start point if you need cpu in long time. Plus, a notification needs to be shown on phone status bar.
Use WorkManager-new api part of jetpack simplifying the use of alarm managers and jobschedulers- to schedule your tasks periodically. However if your frequency is higher than 1 per 5-10minute then you will need to take care of doze mode. If phone gets into doze, your tasks might be delayed till maintenance periods. A trick to apply here might be starting a foreground service when you catch activation of doze mode and return back to Workmanager logic in deactivation(if you don't want user to see the foreground service's notification). Do whatever you want in the foreground service like.
Use Firebase Cloud Messaging to push notification from your server to your users periodically for you to have a small amount of time to do work in background. When notification comes, OS grants you an interval to run a task.
Use Work manager it is easy to implement.
I know that I can register a service by adding Code A in AndroidManifest.xml.
Will the service resident in mobile phone system until I uninstall the App?
Will the service may cost system resource when it stays in system?
Code A
<service android:name="bll.CleanupService">
</service>
There are a lot of stuff available on internet related to service and it's usage, But still, I will try to answer as much as possible.
Service: It is android component where it runs on background and foreground of the system.
A foreground service performs some operation that is noticeable to the
user. For example, an audio app would use a foreground service to play
an audio track. Foreground services must display a Notification.
Foreground services continue running even when the user isn't
interacting with the app.
Android - implementing startForeground for a service?
A background service performs an operation that is not noticeable to
the user, It can be downloading any file. We can use this for long
running operation.
Coming back to your question, will try to answer one by one.
Will the service resident in mobile phone system until I uninstall the App ?
Yes, It will reside on your phone until you not uninstall application. But it will not run infinite, As your job finished it will be stop.
Will the service cost may system resource when it stay in system?
It may cause, If you are not using it properly, If you are running background service we should know when to stop it, unless it will run continuously. It may also cause you memory related issue.
If you start the service and the task not complete till then the service will be there in the system. In case of low system resources, the system can kill your service. But you can add options like START_STICKY to start the service again automatically after the system is out of low resources.
You can check this link for further understanding
https://developer.android.com/reference/android/app/Service#ServiceLifecycle
A Service is an application component that can perform long-running
operations in the background, and it doesn't provide a user interface.
Another application component can start a service, and it continues to
run in the background even if the user switches to another
application.
There are two reasons that a service can be run by the system. If someone calls Context.startService() then the system will retrieve the service (creating it and calling its onCreate() method if needed) and then call its onStartCommand(Intent, int, int) method with the arguments supplied by the client. The service will at this point continue running until Context.stopService() or stopSelf() is called.
Will the service resident in mobile phone system until I uninstall the
App ?
Yes. According to Service Lifecycle it can perform long-running operations in the background (i.e Unitil Install Application) until Context.stopService() or stopSelf() is called.
Will the service cost may system resource when it stay in system?
NOTE
Services should be used with caution.To allow running processes, Android sets a hard limit on the heap size alloted for each app. The exact heap size limit varies between devices based on how much RAM the device has available overall. If your app has reached the heap capacity and tries to allocate more memory, the system throws an OutOfMemoryError.
GOOD APPROACH
Developer’s responsibility to make sure that stopService() or stopSelf() is being called after work is done.
Will the service resident in mobile phone system until I uninstall the App ?
[ANS] : Yes,it will reside in mobile phone until you uninstall the app.
Will the service cost may system resource when it stay in system?
[ANS] : If you start the service and it does not stop (if you haven't called stopSelf()) when it's job is over,then it may cost system resources until you uninstall the app.
Will the service resident in mobile phone system until I uninstall the
App?
Yes, the service does reside in mobile phone until the app is uninstalled.
Will the service cost may system resource when it stay in system?
There are different types of services, if the service is STICKY and the operation is not yet fully performed, the service will stay awake and will consume system resources.
I am working on an Android project and I need the app to work even when the device is locked.
The idea is to open the app that will start the (Intent)Service, the service processes the data all the time. The device can be locked/put away and after some time when the app is opened the service is manually stopped. The service should be running all the time in the background.
I have found information online, but I am not sure what to use and in which way..
I have found that the IntentService can be used. Also the service should run in a new thread. I need to process the data from gps all the time, should I use WakefulBroadcastReceiver?
Thank you.
IntentService is not necessarily what you want to use. It will automatically spawn a new thread just to handle an incoming Intent. Once all incoming Intents have been handled it will stop the Service. To have a long running Service, you would need to derive from Service and when it is started return START_STICKY from the onStartCommand() method, plus spawn your own thread to handle your background work.
If you need to monitor GPS, you'll have to manage that along with keeping the device awake using a WakeLock. Note that in Marshmallow, this gets more complicated because of the new Doze mode where even wakelocks are ignored.
Also, note that the way Android is architected there is still a chance that your application running the background Service may be killed. Android uses a unique process management technique based on memory pressure and user perceived priority to determine how long a process should stick around. I recommend reading up on the Service lifecycle in the documentation.
In android their is no fool proof way to ensure that your service runs forever because the LMK(low memory killer) when the system needs resources (based on a certain memory threshold) , kills the service then if it can restarts it. If you handle the restart properly the service will continue to run.
Services that are given foreground priority are significantly less likely to be killed off, so this might be your best bet. However their will be a notification of your service running the in the background on the menu bar up top. Foreground Service
What happens to a service started by BOOT_COMPLETE after system kills it for memory?
Will it ever be restarted without rebooting the phone? Is it possible to restart it somehow?
What is the best practice to avoid as much as possible an important service from being killed?
Will it ever be restarted without rebooting the phone?
Possibly. If it truly was because "system kills it for memory", and you return an appropriate value from onStartCommand() (e.g., START_STICKY), it should be restarted at some point in the future. If the service was killed due to user action (e.g., Force Stop in the Manage Services screen in Settings), it will not be restarted.
What is the best practice to avoid as much as possible an important service from being killed?
First, design your application to not rely on an everlasting service like this. 99.44% of Android applications do not need a service that runs continuously, let alone one that starts doing so at boot time. Android device users hate developers who think that their apps are sooooooooooooo important that they have services running all the time -- that's why we have task killers, Force Stop, and Android killing services due to old age. For example, if you are checking for new email every 15 minutes, use AlarmManager and an IntentService, not a service that runs forever.
If you can demonstrate -- to me and to your users -- that yours is among the 0.56% of applications that really do need a service that starts at boot time and runs forever, you can use startForeground(). This will indicate to the OS that your service is part of the foreground user experience. You will have to display a Notification, ideally to allow the user to shut down your service cleanly if and when the user no longer feels that it is justified.
If you need to restart the service then you should use AlarmManager to check up on the service in a separate BroadcastReceiver, but nominally when a service is killed by the system for memory it will not get automatically restarted.
You may want to take a look at START_STICKY
Use the AlarmManager to periodically send an Intent-- receive the intent and make sure your service is running.