I'm new at developing Android. I'm experiencing the following problem:
I'm working on a Android application that extends the Application class. The values for the authentication session are stored in this class, because it is supposed to get created once and it is available in all activitys and services.
When I open my application and close it with the home button, and reopen it after I opened a lot of other apps, the base application class gets recreated (onCreate gets called). When this happens, I lose my authentication values. It seems like it that the onTerminate or onLowMemory are not getting called before the onCreate is getting called again. The current state of my application is not gone, because the previously active activity is still available.
When I close the app with the home button and only open a few other apps, the application resumes normally.
I also tried to implement a singleton class, but the singleton object is also null if the application class gets recreated.
How can I prevent the recreation of the application class, or work around this problem?
Thanks
Jacob
I found out that the application class can also be restarted as part of the application lifecycle. I stored my authentication values in preferences to solve this problem
From documentation of Application.onTerminate():
This method is for use in emulated process environments. It will never
be called on a production Android device, where processes are removed
by simply killing them; no user code (including this callback) is
executed when doing so.
Also there is no guarantee that onLowMemory will be called. Check this answer.
The current state of my application is not gone, because the
previously active activity is still available.
I think activity is just restored from Bundle.
How can I prevent the recreation of the application class, or work
around this problem?
You have to be ready that you application can be recreted in any moment. You can store some data in this class but before grab this data from some activity you should check if it is null. It will be null in first start and after application recreating. Just fill it with your data and return to activity.
Related
I'm programming a video call app and everything seems to be working. There is only one problem. When one person calls another, the activity "Calling activity" (of the called person) opens only if the person who has been called has opened / opened the application (not when the app is closed). I would like to find a way that when one person calls another even if that other person has the app closed it still opens. How could I do? I leave you my callingactivity code
https://codeshare.io/ar0yxE
What you seem to need is a background process which listens for incoming calls on your receiving port or what have you - you can then launch the application if the recipient picks up or accepts thew call. The Android Docs have a page on background processes and another page on overriding the call interface for your own app
Good luck with the app
I am developing an application in which a background service is created to collect sensor data. I am starting the service from my activity:
startService(new Intent(this, MyService.class));
I created the service so if the application is destroyed, the background service still continues to collect data. I tried this, and it worked to a certain extent. My problem is that when I kill the application, the service seems to restart because the onCreate() service and the onStart() methods are invoked. Is there any way with which the service isn't restarted please?
UPDATE:
As suggested in an answer below, I added the following method in the service but no luck.
#Override
public int onStartCommand(Intent intent, int flags, int startId) {
return START_NOT_STICKY;
}
It depends on the value returned in onStartCommand.
You must return START_NOT_STICKY
According to the documentation:
For started services, there are two additional major modes of operation they can decide to run in, depending on the value they return from onStartCommand(): START_STICKY is used for services that are explicitly started and stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are used for services that should only remain running while processing any commands sent to them
In short:
If you return START_STICKY the service gets recreated whenever the resources are available. If you return START_NOT_STICKY you have to re-activate the service sending a new intent.
Since all of this triggered my curiosity, I made a sample app to test this. You can find the zip with all the sources here
There are a startService button and a stopService button that do what you would expect from them.
The service returns START_NOT_STICKY in onStartCommand.
I placed toasts in onCreate, onStartCommand and onDestroy.
Here what happens:
If I press start, onCreate and onStart are called
If I press stop, onDestroy is triggered
If I press start twice, onCreate is called once and onStartCommand twice
So it behaves as one would expect.
If I start the service and kill the app as you described, onDestroy does not get called but neither onCreate or onStart.
If I get back to the app and I press start again, onCreate gets called which means that, as I wrote before, START_NOT_STICKY prevents the service to getting restarted automatically.
I guess you have something else in your app that starts the service again (maybe a pending intent).
The app and the service live on the same process, which means when the app is killed so is your service. Changing the return value of onStartCommand doesn't affect this process. It simply tells the Service to either start/stop when you tell it or when it's finished doing what it needs to. As mentioned in your comment to your original post, setting it as a foreground process worked, but that's really just forcing the service to have a high priority, not solving the problem.
To change the Service so that it's killed separately and assuming it's a started service rather than a bound service due to the use of onStartCommand, specify a process name in the manifest for that Service.
From the Process and Threads Developer Guide:
The manifest entry for each type of component element— <activity>, <service>, <receiver>, and <provider>—
supports an android:process attribute that can specify a
process in which that component should run. You can set
this
attribute so that each component runs in its own process or so
that some components share a process while
others do not. You can also set android:process so that
components of different applications run in the same
process—provided that the applications share the same
Linux user ID and are signed with the same certificates.
Android might decide to shut down a process at some
point, when memory is low and required by other
processes that are more immediately serving the user.
Application components running in the process that's
killed are consequently destroyed. A process is started
again for those components when there's again work for them to do.
From <service> in Manifest File:
android:process
The name of the process where the service is to run.
Normally, all components of an application run in the default process
created for the application. It has the same name as the application
package. The element's process attribute can set a
different default for all components. But component can override the
default with its own process attribute, allowing you to spread your
application across multiple processes.
If the name assigned to this
attribute begins with a colon (':'), a new process, private to the
application, is created when it's needed and the service runs in that
process. If the process name begins with a lowercase character, the
service will run in a global process of that name, provided that it
has permission to do so. This allows components in different
applications to share a process, reducing resource usage.
Not sure why the other answer that mentioned this was down voted. I've used this method in the past and, today, created a simple one Activity app with a Service on a different process just to make sure I wasn't crazy. I used Android Device Monitor to kill the app's process. You can see both, separate processes in ADM and can see that when the app's process is killed, the Service's is not.
Start not sticky doesn't work above kitkat, and the other onTaskRemoved not working above Marshmellow.
onTaskRemoved could be used by handled some exceptions. Did not worked on that. But try that one.
If you are using an IntentService, it has an
onHandleIntent()
method where you should place the code that needs to be executed. It is executed in a separate thread (not a UI thread where your application runs) therefore your app shouldn't affect it. When the code has finished executing, the thread is terminated and the service is stopped automatically.
I ran into the same problem and was able to resolve it by making the service run in a global process. You do this by adding the following to the manifest tag:
process="com.myapp.ProcessName"
(Make up whatever name.)
When I did this I found that my service wasn't killed (and restarted) when the app is swiped off the list. Presumably this is because the app process is killed when you swipe it off, but global service processes are not.
The disadvantage of this is that communication between your app and service now has to be via the IBinder interface; you can't directly call functions in the application or service from the other one, because they're running in different processes.
I know its much late to answer this question, but may be it can be helpful to others. This really helped me for my Music Player App.
If there are services which can be disruptive or can affect the user experience like music etc , then in that case you have to use Notification and when service is started successfully, then create the Notification and use the function
startForeground(int Notification_id,Notification);
This will run your service in background without restarting and reinvoking its methods
https://developer.android.com/reference/android/app/Service.html
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
I have an android app that is opened by a URL on my website. What I am looking to do is, attach Eclipse in debug mode when the app starts. I can start the app in debug mode from Eclipse, but I do not know how to get Eclipse to start when the user/another app starts the app on the device.
Add a call to android.os.Debug.waitforDebugger() on the onCreate of your launch activity. This will make you app wait for a debug to attach whenever it is launched.
If you look in detail, there's a moment when Eclipse tries to couple the runtime session with the debugger so it starts listening to it until the coupling is made. I guess you'll need to trigger that whenever you open your app.
My question would be, why do you need that? Which are the different conditions when you start the app from the web that make it necessary to debug from there? If there are some, is there any possibility to fake them with any constants or db data?
I am currently writing an app that allows a parent to log the events that occurs from their childs phone. The logging takes place in a service which runs in the background. However, the service keeps dying after around a minute..
I dont know what other information you need to help, but any information is useful!
Thanks!
If you are just binding to the service, then that's why your service is killed when the activity unbinds (Read that in the Docs). If you are using .startService() and then bind make sure in the onStartCommand() you return START_STICKY. You can read why and how here
http://developer.android.com/reference/android/app/Service.html#START_STICKY
And yes, use .startForground() as well if you are doing something that user is aware of and shouldn't be killed in extreme cases.
try starting the Service as foreground.
Reasons why a Service gets killed are here