I have created an application in Android. This application should never die (even when sent to the background).
Currently, after a while the Service manager returns "No longer want..." and terminates it.
I've read that one solution whould be to create a service. However my application is way to complicated to be splitted into two functionality sets (one for the service and one for the application).
Is there any "trick" in order to keep my application running at all time?
Could I create a dummy service inside my application that might force the android to keep my application alive?
Is there any other way?
FYI: 1) It's a customized application that will not be released on the Market. 2) Handsets can't be rootted.
Thanks
You must create a Service to have a persistently running app, even after all your Activities have been sent to the background due to user pressing the Back button, answering a call, switching to another app, etc. You should review the Android Process Lifecycle which states that:
Sometimes an Activity may need to do a long-running operation that
exists independently of the activity lifecycle itself. An example may
be a camera application that allows you to upload a picture to a web
site. The upload may take a long time, and the application should
allow the user to leave the application will it is executing. To
accomplish this, your Activity should start a Service in which the
upload takes place. This allows the system to properly prioritize your
process (considering it to be more important than other non-visible
applications) for the duration of the upload, independent of whether
the original activity is paused, stopped, or finished.
Related
I'm writing my first independent Android app. It will sit in the background and respond to a few events generated by the OS, somewhere between a few times a day to a few times a week depending on the user.
Coming from a PC programming background, I thought I might need a service, but Android Developers > Service says:
What is a Service?
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
The app should not need to consume any resources unless one of the events it's listening for happens. The user should also not need to actively use the app after it's been set up, only if they want to change its settings.
I have games that seem to do something similar to what I want. They sit in the background and can receive messages (e.g. it's now my turn), and when I click on the notification it loads the game into memory, which takes a few seconds longer than if it was already in memory.
If the user hasn't used the app's interface for a month, I want it to still be in operation (even if the device has been power-cycled) and respond to events but not to appear in the list of recent apps (assuming a month is long enough to push it off the end). Ideally, I want it to respond to the events within one second; it doesn't have to be near-instant. What's the normal way this is done?
An app (occasionally used) and a separate "service" process/thread (persistent)
A combined app and "service" (persistent)
A combined app and "service" (loaded into memory by events)
Not enough reputation to comment, but just to tell you that nothing prevent Android to kill your service, To restart your service after the user reboot its phone you can add a broadcast receiver and listen to
https://developer.android.com/guide/components/broadcasts
.Also, if you don't want to display a notification while your service is running you will have to use a background service instead of foreground one. Hope this help.
I'm developing a Qt/C++ app for Android, that uses GUI as well as does background work (communicates with server, updating its data). The app is supposed to be always online, as it can receive a call any time and switch on the screen if needed and show GUI.
The app creates a dummy Activity to show GUI and talk to the native part.
Are there any drawbacks aside from battery usage, that may happen if
I use Activity (no Service) with acquiring PARTIAL_WAKE_LOCK?
Will just acquiring the lock be sufficient to run native background tasks and switching on the screen to show GUI when needed?
Is there a difference in terms of App lifecycle between Activity holding a lock and Service holding a lock?
I've read that apps with Activity compared to foreground services (startForeground()) can be killed if they are in background for some time. Is there a way to restart the app in background if Android kills it? I've seen only answers about restarting service-based apps.
I'm not going to use both Activity and Service because of no existing proper integration of them in QT.
Thank you
I have a long running background task that I would like to start when the app launches and shutdown when the application shuts down. I'm already quite aware of the activity life cycle and what gets called when an activity gets created and destroyed.
I'm coming from an iOS background, and over there we have some calls that are made during application startup and shutdown. Is there something similar in the android world? I've searched a lot and all I'm finding are answers relating to an activity, not the entire application.
(Android is relatively new to me, so I may just not know the correct terminology to search for.)
EDIT:
I'll try an be a bit more specific. I have a background task that needs to be continuously running while the user is using the application. It will be streaming data from a server continuously while the application is active. It does not need to run when the application is in the background. It doesn't seem to make sense to me to tie the startup / shutdown of this background process to any one single activity since it may not be the same one activity that starts up when the application becomes active.
I am (possibly mistakenly) assuming that the OS takes care of starting / stopping background threads when the application resumes and pauses. If that is, in fact, the case, then all I really need to do is spin up the background task when the application first launches, i.e. when it is loaded into memory and becomes active for the first time that session.
It doesn't seem to make sense to me to tie the startup / shutdown of this background task to any one single activity since it may not be the same one activity that starts up when the application becomes active.
That's reasonable. It is somewhat difficult to implement, though.
I am (possibly mistakenly) assuming that the OS takes care of starting / stopping background threads when the application resumes and pauses.
You have it exactly backwards. Android pays not one whit of attention to any threads that you fork yourself, directly or via thin wrappers like AsyncTask.
In addition to that point of confusion, you appear to be equating "user switching to another app" with "app shutdown". Those may be the same thing in single-tasking operating systems. They are not the same thing in Windows, OS X, Linux, Android, etc.
So, what you seem to be seeking is having a background thread running doing this streaming work while your UI is in the foreground, and then stop when your UI is in the background. The problem is that there really isn't a straightforward way of accomplishing that in Android.
One close approximation would be to create and register a custom Application class, where you override onTrimMemory(), and stop your background work when you get to TRIM_MEMORY_UI_HIDDEN, TRIM_MEMORY_BACKGROUND, TRIM_MEMORY_MODERATE, or TRIM_MEMORY_COMPLETE -- whichever of those that you encounter first. If, when one of those arrives, you determine that your streaming thread is still outstanding, shut it down.
In terms of startup, you could use onCreate() on that same Application singleton. The problem is that this will be called on any process creation, which may include scenarios in which you do not have UI (e.g., you are responding to some system broadcast, like ACTION_BOOT_COMPLETED), or possibly your process is going to parts of your UI that do not depend on the streaming. If you have none of those scenarios, then onCreate() in Application would be fine. Otherwise, kick off the streaming in onCreate() of whatever activities need it.
While normally we manage long-running threads with a Service, that is for cases where we explicitly want the thread to continue after our UI is in the background. Since you do not want that, you could skip the service.
It depends on what you want to do exactly. When you're just interested in the app starting for the first time you could #Override onCreate().
Or maybe you want to use onResume() as this will get called whenever a user brings the app to the foreground.
But this really depends on what exactly your background task is doing and what you want to do with it, to get an exact answer you need to provide more details.
Here is an overview for the actiity life cycle that should help you:
You can extend the default Application class and implement it's onCreate() method to detect when the app is launched. There is no corresponding method for when the app gets closed though.
Do not forget to specify it in the Manifest file.
In Android the application isn't shut down unless the system runs low on memory. You won't get a warning about that, it will just call your Service's onDestroy lifecycle method. If you want to do it when the Activity is visible on screen, use onStart and onStop. If you want to do it when the Activity is resident in memory, use onCreate and onDestroy.
In the app I'm developing atm. I use asynctasks to upload videos to a website, as it stands now if the application process is killed (User returning to home screen using the back key), those asynctasks are lost. ideally I would want the uploads to carry on despite the application process being killed, but I don't think that is possible.
I wonder if there is a way to retain their progress somehow (Maybe support from the website API is necessary?), or if not at least save the details of the asynctask and restart it when the app is opened again.
Vimeos application seems to have been able to resume video uploads, even after having killed the application process, thats exactly what I'm hoping to achieve.
Appreciate any ideas and suggestions.
I think you may be using the wrong architecture.
Anything that needs to survive in between Activity transitions is more suited for a Service. A service runs in the background (possibly even after the app is closed) and lets you do long running things such as performing uploads.
To kill the app process but have the Service continue to run, you can assign the service to a separate Android process using android:process in the manifest.
http://developer.android.com/guide/topics/manifest/service-element.html#proc
See this thread too:
How to keep a service running in background even after user quits the app?
im currently developing an app which plays the steam audio using MediaPlayer class. And i'd declare its main (Player) activity as SingleTop. Also on button "Back" it does moveTaskToBack(true) which acts the same as button Home does. So it just stays and plays on background and if user wants to see the gui he just starts the app once again (which is less convenient) or he clicks the special app's notify. Exit provided via menu.
but what are the benefits of using service instead of activity in such case? Definitely it would be more complex to develop, i have to say. Even instantiating the GUI while "on background" will take much more time, i'm afraid.
From the Android Documentation:
Activities
An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails.
Services
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.
also
Once started, a service can run in the background indefinitely, even if the component that started it is destroyed.
The Android OS can destroy your Activity if it runs out of resources, but it won't destroy the service.
EDIT: you should use startForeground() to ensure your Service won't be killed in situations where the resources are low. From the docs:
Make this service run in the foreground, supplying the ongoing notification to be shown to the user while in this state. By default services are background, meaning that if the system needs to kill them to reclaim more memory (such as to display a large page in a web browser), they can be killed without too much harm. You can set this flag if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.