I have some utility code in my android application running as part of a shared component. It's scoped to the lifetime of the application, and launched as part of an overridden Application class.
What I'd like to know is if I can be notified when the application itself enters or leaves the foreground - basically the equivalent of iOS' applicationDidEnterBackground or foreground.
I've done a variety of searches, but everything comes back with people saying you should hook onPause and onResume on an activity - This would be great if my app only ever had one activity, however it has lots, and it doesn't seem sensible to hook onPause/Resume on every single one - let alone handling transitions between my activities
There isn't any direct approach to get the application status while in the background or foreground, but you can register your application class to the Activity Lifecycle Callbacks, just add your listener to the application like this:
myApplication.registerActivityLifecycleCallbacks(yourCallback);
and you will be able to know if you have activity on the foreground.
My Android app checks if a specific service is not running, in my Activity's onResume method. If it hasn't been started, then it goes into the background (via startService) and stays there for an action. Clicking on a button causes the service to go into the foreground and it works great. Now the problem:
Scenario #1 :
The foreground service has a button, which sends it back to the background and stops it. I click on it and after that I close my app (the activities from the recents view). Even the Android monitor shows me that it's not running and works as it should.
Scenario #2: (The not expected behavior)
First I close the app (the activities) and then I click on the service's close button. In this case, I can clearly see that my app still uses the same amount of memory it used while the activities were opened. When I reopen my app, I can see that it continues working where I left it (at least the internal app variables don't get garbage collected) Sometimes the CPU usage monitor shows that methods get called, but not from my app. Only Android SDK functions. I couldn't see objects kept in the memory, but a lot of chat[], String, FinalizerReferences etc...
What could cause this? Ruined context lifecycle? Memory leak?
I am working on a project, where while being on a specific Activity we show a local sticky notification. That should also be the case when the app is minimized. What I have to accomplish is to remove the local notification whenever the app is killed (by Android, because of memory lack or by the user, with a swipe from the recent apps list).
Usually onDestroy would be called whenever Android takes the Activity to open some space. That is fine in one of the cases, however swiping an app from the recent app lists doesn't call the onDestroy and the sticky notification stays.
What I did is, I implemented an empty Service which would force the onDestroy when the app is killed (both swipe and system kill) so I can get my notification removed.
However, what I would like to do is to differentiate between the swipes and system kill.
Is this even possible?
In general, if Android wants to kill your application because it has been in the background for too long (or because it wants to reclaim resources), Android will just simply kill the OS process hosting your app. It will not call finish() or onDestroy() on any Activity or Service components. The behaviour of "swipe from recent tasks list" has changed over time and is different in different Android versions. Someone should write a book about that :-(
You can check for when the user swipe-closes the app by adding a service to your app, and implementing the onTaskRemoved method: https://stackoverflow.com/a/26882533/2441655
This is a comment I found in reddit that seems to me really interesting:
Swiping an app away will effectively "kill" most apps. You can test
this out using ADB if you have the SDK installed. Swipe everything out
of your recents list, then launch the browser.
Use ADB to run 'ps' on the device and verify that the com.google.android.browser process is
running. Go to the home screen, it's still running. Launch some other
apps, and the com.google.android.browser process is still there.
Swipe it out of the recents list, however, and the process is gone. You can
create a test app to further verify, and log the onDestroy() call in
your Activity. It's not called when you back or home out of the app,
or when you launch other apps. It does get called when you swipe the
app out of the recents list though. I do agree that the recent apps
list isn't really "multitasking".
The apps in the list aren't necessarily even running, the processes could have been killed by the
memory manager long before you try to re-open it. However, you can't
argue that the only purpose is to jump quickly to other apps when the
swiping makes the actual process go away.
This is another good answer about what happen when you swipe an app out of the recent apps list. But the part that I liked most was:
Actually, removing an entry in recent tasks will kill any background
processes that exist for the process. It won't directly causes
services to stop, however there is an API for them to find out the
task was removed to decide if they want this to mean they should stop.
This is so that removing say the recent task of an e-mail app won't
cause it to stop checking for e-mail.
If you really want to completely stop an app, you can long press on
recent tasks to go to app info, and hit force stop there. For stop is
a complete kill of the app -- all processes are killed, all services
stopped, all notifications removed, all alarms removed, etc. The app
is not allowed to launch again until explicitly requested.
By Swiping from recent task list removes only from recent tasks ..
It was also called onDestroy before android 5.0 .
Might be you are having issue above api level 20 devices.
System kill normally can not be executed in normal android activity lifecycle.
It just finishes the activity on back press event.
when swiping app to left if any Thread still run in your app Interrupted but service not stopped, when you kill handy app Thread and services are stopped.
the behavior is similar to but not exactly the same as closing an app -- in general (for apps that don't define explicit back button handling) it's the same thing as hitting back enough times from within an application that you exit out of it.check out this link discussion it has some good input on the subject
First, let's get one thing clear: Android MAY NOT CALL onDestroy(). Referring to the Activity Page, from Honeycomb onward, onPause() and onStop() are guaranteed to be called before an app is killed.
Be aware that these semantics will change slightly between applications targeting platforms starting with HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned. This impacts when onSaveInstanceState(Bundle) may be called (it may be safely called after onPause() and allows and application to safely wait until onStop() to save persistent state.
So after (hopefully) clearing the air on the Android lifecycle, I think you can achieve what you want by putting the notification removing code in onStop() instead. If you end up needing it back because the user actually DOES come back to the specific Actvitiy(IE not killed), you can bring it back in onRestart().
I'm building an app which requires some security. Everytime user quit the application with the Home button, or when he locks the phone and unlocks it, a PIN code is prompted.
To add this feature, I need a callback fired when these situations happen. I tried to use onResume in my activities, but this method is also called while navigating between activities. I have also tried to implement an Application subclass, but there is no onResume override.
What is my best option?
It's not so trivial task to be honest. I've did it twice, and ended both times in:
- keeping state of app (locked, unlocked)
- using package manager to check if app is on top (==not set to background)
- calling functions that are checking for app locking onResume, onPause, onDestroy
- having timer that locks the app after some period of inactivity
My first implementation was based on activity with pin verification, second one - on fragments, and I'd suggest using fragments as
I have an app that shall be extended with an app tracking code that should track the following events: app started, closed, foreground and background. My application has two activities.
For app started i use app.onCreate(). For foreground and background: onResume and onPause in each activity.
So my questsions are:
How do i detect when the application is completely gone? Something like onTerminate()?
When switching from the first activity to the second, i get a1.onPause() and then a2.onResume() and thus the events background followed by foreground. In that case i don't want those events. How do i know in onPause or onStop that i am staying in my app and only switching activities?
What i want is: App starts with a1 -> app started and app foreground event then switch to a2 -> nothing, press home -> background. When the app gets killed -> closed
At least i think i want that, or should one not use such a linear approach because of androids specific application and activity lifecycle and do something else?
How do i know in onPause or onStop that i am staying in my app and
only switching activities
I'm afraid you can't detect this only using callbacks.
How do i detect when the application is completely gone? Something
like onTerminate()?
AFAIK framework doesn't provide such callbacks for you.