Given the limitations that are being imposed on background services in later versions of Android, how do you accomplish the following:
The application's JAVA background service and the native C++ threads which are started by the JAVA background service via JNI continue to run regardless of the phone's state (screen on or off) and regardless of the application's state (activity life cycle). If an activity has been destroyed, the background service must continue to run.
If the user clears the application from the task list (menu button), the background service continues to run and so does the C++ threads.
If the user presses the menu back button, the background service continues to run and so does the C++ threads.
If the user navigates to the OS settings (applications) and selects FORCE CLOSE/STOP for the application, then the application AND the background service is stopped/destroyed.
One of the native threads is responsible for listening and processing UDP data via a socket that listens for multicast data. It is critical that this continues to work regardless of phone/app state (unless the app is forcefully closed).
Not sure if I get your problem right, but all these points you mention, one can accomplish by using the Android Service Component like describede here: https://developer.android.com/guide/components/services.html
I worked with this some time ago and it did just these points you require.
Please correct me if I'm wrong.
Related
When I used foreground service then when I kill the application then foreground service is automatically killed but I want to alive foreground service when the application is killed. this issue appeared in android 10 and android 11. how to solve this issue.
You can't do that as you should not be able to keep alive a foreground service after the application is killed.
You should only use a foreground service when your app needs to perform a task that is noticeable by the user even when they're not directly interacting with the app. If the action is of low enough importance that you want to use a minimum-priority notification, create a background task instead.
If you what to have some background service working, that will be possible.
You can find some useful information here :
https://developer.android.com/guide/components/foreground-services
https://developer.android.com/training/run-background-service/create-service
It should not get killed. When starting foreground service you need to create notification too. You have done that, right?
If you done everything right there is possibility that you have xiaomi phone. Xiaomi deletes everything when app killed. You need to add specific intent protection...
I have been reading Android docs and I feel I am bit lost and confused.
What is the type of service I need to use in Android, so that I can keep running my code even when the app is paused or minimized for prolonged period.
I am not interested in running the service if the app is closed. I want to run small piece of code that will run when app is in foreground or background, but not killed.
You can use a bound Service. The Service will stop after all the bound clients disconnect. Your Activity binds to the Service and when your Activity is killed or finished, you unbind and the Service stops. If Android kills off the Activity, the bound connection is also shut down and your Service will stop.
I need to persist a socket connection when my android app goes to background.
Currently, the socket is started, read and written from its own thread. I also store a reference to this thread in a static instance of a class which means i have access to the thread's reference when my app is resumed.
I also don't need this socket to be persisted if the app is destroyed.
Now coming to my question, "Do i need to start a service to maintain this thread or can i just continue with my current design which is to store all such instances that i require when the app resumes in a static container class?"
The only advantage i found so far of using a Service is that the app might be one of the last few to be destroyed during low memory or similar scenarios by the OS (considering the service and the app reside in the same process).
Once your Activity is destroyed, your process becomes a candidate for being shutdown. Most likely, it will linger around a while and not get killed. But on a lower end device, with less memory, all bets are off. Go to Developer Options on your device and check "Don't keep activities ...". Exit the activity and see the outcome.
The workaround is to keep a Service active. Preferably with a notification icon so the user knows it's still running. That's exactly what I did with my music app to allow the audio stream to keep going even when the user switched apps.
On the flip side, a dedicated socket connection is going to use more battery and more of the user's data plan. If your socket is going to be idle most of the time, a better approach might be have the socket connection connect to the server only when notified via a push notification that there is data available.
I have a pool of AsyncTasks which pass state data back to the service that executed them, but they keep being killed by Android.
I can't use an IntentService because the Service is keeping track of State used by UI and AsyncTasks.
How do I:
1) keep the service from being killed
2) Replace either service or AsyncTask with something better for this use case?
You should use foreground service. Android OS can kill service if it is running short on resources, but it will always spare foreground service.
The Android system will force-stop a service only when memory is low
and it must recover system resources for the activity that has user
focus. If the service is bound to an activity that has user focus,
then it's less likely to be killed, and if the service is declared to
run in the foreground (discussed later), then it will almost never be
killed.
Note: Another thing you should also consider
Caution: A service runs in the main thread of its hosting process—the
service does not create its own thread and does not run in a separate
process (unless you specify otherwise). This means that, if your
service is going to do any CPU intensive work or blocking operations
(such as MP3 playback or networking), you should create a new thread
within the service to do that work. By using a separate thread, you
will reduce the risk of Application Not Responding (ANR) errors and
the application's main thread can remain dedicated to user interaction
with your activities.
I have seen apps like Lookout, JuiceDefender, and MagicJack run in the background indefinitely, unless force closed by a user directly through the task manager. (And even then, in Gingerbread, it wouldn't close unless you browsed to the application that was running under "Downloaded Apps" in the settings and force closed it once you were at the menu where you have options to manage the app like "Clear Memory" and "Force Close".
I am wondering how this is accomplished? I need to do something similar for an app of mine but I don't know how to avoid the Android OS's automatic task killing.. And don't say it's not possible because if that were true, JuiceDefender, MagicJack, and Lookout would not work.
What you can have is a service that stays alive indefinitely. You achieve that returning Service.START_STICKY on your Service's onStartCommand method.
Whenever the os needs resources and chooses to kill your app, your service will be respawned as soon as the resources are available again.
Bear in mind that having an application that is continuously alive will result in consuming the phone's battery. You should (at least) notify the user with a notification that your app is still alive in the background.
On top of that, you can register a broadcast receiver for the BOOT_COMPLETED event in order to restart your service while the device gets restarted. Yet, bear in mind that this could result in eating the phone's battery and so be careful on what you are doing in the service.
I believe these apps are launching a Service when their Activity get started (i.e when onCreate() is called).
A Service keeps running when the application get paused. When the Service is launched, you may return START_STICKY in your onStartCommand.
Also, to prevent a Service from being killed by Android's memory killer, you can specify that your Service is important to the user by calling startForeground(). Android Developers website states that :
A foreground service is a service that's considered to be something
the user is actively aware of and thus not a candidate for the system
to kill when low on memory.
I am creating an app and I have to use one or more of the following super functions inside OnCreate():
onDestroy()
onPause()
onResume()
onSaveInstanceState()
to close an app completely from the memory. And also do not use Activity.finish() method. Usually Android does a pretty good job in closing the app when memory is needed, called pop out of stack and not recommended to forcefully stay in memory, unless there is a very very good reason to. Hope it helps.
You can also check the Android DOC website for more information and examples to your request.
You need to start a service. Services runs in background and is useful to push alerts.
This some links about it:
http://developer.android.com/guide/components/services.html
http://www.vogella.com/articles/AndroidServices/article.html
In the service onStartCommand method return "START_STICKY".
http://developer.android.com/guide/components/services.html
/Thomas