Related
I have some confusion in mind. Being new to android, I am writing an App which should:
check if bluetooth is available
if it is, enable it if turned off
scan for nearby devices and show them to the user
the user clicks (chooses) a device
the app, cyclically, pools the device and shows it status
while polling, the user can ask for more operations (other activities on the same device), then return to main screen
Passages from 1 to 4 are mandatory, but it seems difficult to lay them down in a straight (simple) manner: the main activity, which calls two intents (to enable BT and to scan devices) seems to interfere. It seems that the main activity's onCreate is called too often...
Question #1: should I do all the work in the onActivityResult() method? Or should that method be used to collect results, and the true work should be done in onResume()? I say so because while in step 5, when trying to launch other activities, android complains about "not having a context and you need to set the flag NEWTASK in the intent - "is that really what you want?")" (sorry, can't remember the exact message).
Moreover: the main screen shows some statuses from device, refreshed via postDelayed(), and also accepts button's clicks. When the user clicks a button and a new activity is created, what happens to the main activity? Does it lose its variables, context, or whatever? In that loop, I don't need anymore any result from the user clicked activities, so question #2 is should I use onResume? Or is onCreate() called again? If using onResume() I need to keep track of the app status, where to store that status? I am using a static global class, and it seem to work, but I've read that it is not a good idea.
I know this question is kind of a mess, but I've read google documentation and many questions here in SO, and found a mess. In this moment the app is more or less working, but it does strange things at times and, worse (question #3) by using it a few minutes it gets slower and slower - can it be it leaks memory, or it creates too many threads because of postDelayed()?
For reasons outside of my control (so, please no "you're doing it wrong" replies), my Android app needs to play extremely nicely, i.e. when a user hits the home button, my app needs to go away and release all of its resources (which are heayy, more than 1GB RAM consumption etc). It seemed calling finish() in onPause() would do the trick, but here's the problem: onPause() and onStop() also get called when I start an activity of my own, e.g. a preference activity, for which I just want to normally return.
So, my problem is: How can I determine the reason for losing the focus? I can think of two options, neither of which are pretty:
Keep state, i.e. the new activity sets some global flag that I can check in the "covered" activity so it doesn't stop when onStop() gets called. Annoying because every new activity of mine would have to do that.
Use the ActivityManager to check the top activity, and if it's one of mine, don't commit suicide. Maybe better, but the documentation heavily discourages use of the ActivityManager for this type of stuff.
Any ideas?
You are welcome to use onUserLeaveHint(). It may cover some scenarios (e.g., HOME), but not all (e.g., incoming phone call).
please no "you're doing it wrong" replies
IMHO, "more than 1GB RAM consumption" is already "doing it wrong" for a Play Store app. Specialized apps (e.g., specific enterprise scenarios, dedicated hardware) might be able to get away with that.
One approach for option 1 that will make it less annoying to implement and maintain would be to use Application.registerActivityLifecycleCallbacks. At least this way you don't have to implement this logic multiple times in multiple classes or unnecessarily force your activities into a single otherwise unrelated base class.
Not that I necessarily endorse this option. Also note you'll need API 14+.
Moving on in my attempt to learn Android, I just read the following:
Question: Does the user have a choice to kill the application
unless we put a menu option in to kill it? If no such option exists,
how does the user terminate the application?
Answer: (Romain Guy): The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.
Hehe, for every step I take in the Android world I run into some sort of problem =(
Apparently, you cannot quit an application in Android (but the Android system can very well totally destroy your app whenever it feels like it). What's up with that? I am starting to think that it's impossible to write an app that functions as a "normal app" - that the user can quit the app when he/she decides to do so. That is not something that should be relied upon the OS to do.
The application I am trying to create is not an application for the Android Market. It is not an application for "wide use" by the general public, it is a business app that is going to be used in a very narrow business field.
I was actually really looking forward to developing for the Android platform, since it addresses a lot of issues that exist in Windows Mobile and .NET. However, the last week has been somewhat of a turnoff for me... I hope I don't have to abandon Android, but it doesn't look very good right now =(
Is there a way for me to really quit the application?
This will eventually get to your question, but I first want to address a number of issues you raise in your various comments to the various answers already given at the time of this writing. I have no intention of changing your mind -- rather, these are here for others who come to read this post in the future.
The point is that I cannot allow for
Android to determine when my app is
going to be terminated. that must be
the choice of the user.
Millions of people are perfectly happy with the model where the environment closes up the application as needed. Those users simply don't think about "terminating" the Android app, any more than they think about "terminating" a Web page or "terminating" a thermostat.
iPhone users are much the same way, in that pressing the iPhone button does not necessarily "feel" like the app was terminated since many iPhone apps pick up where the user left off, even if the app really was shut down (since iPhone only allows one third-party app at a time, at present).
As I said above, there is a lot of
things going on in my app (data being
PUSHed to the device, lists with tasks
that always should be there, etc.).
I don't know what "lists with tasks that always should be there" means, but the "data being PUSHed to the device" is a pleasant fiction and should not be done by activity in any case. Use a scheduled task (via AlarmManager) to update your data for maximum reliability.
Our users log in and can't be doing
that every time they get a phone call
and Android decides to kill the app.
There are many iPhone and Android applications that deal with this. Usually, it is because they hold onto login credentials, rather than forcing users to log in every time manually.
For example, we want to check updates
when exiting the application
That is a mistake on any operating system. For all you know, the reason your application is being "exited" is because the OS is shutting down, and then your update process will fail mid-stream. Generally, that's not a good thing. Either check updates on start or check updates totally asynchronously (e.g., via a scheduled task), never on exit.
Some comments suggest that hitting the
back button does not kill the app at
all (see link in my question above).
Pressing the BACK button does not "kill the app". It finishes the activity that was on-screen when the user pressed the BACK button.
It should only terminate when the
users want to terminate it - never
ever any other way. If you can't write
apps that behave like that in Android,
then I think that Android can't be used
for writing real apps =(
Then neither can Web applications. Or WebOS, if I understand their model correctly (haven't had a chance to play with one yet). In all of those, users don't "terminate" anything -- they just leave. iPhone is a bit different, in that it only presently allows one thing to run at a time (with a few exceptions), and so the act of leaving implies a fairly immediate termination of the app.
Is there a way for me to really quit
the application?
As everybody else told you, users (via BACK) or your code (via finish()) can close up your currently-running activity. Users generally don't need anything else, for properly-written applications, any more than they need a "quit" option for using Web applications.
No two application environments are the same, by definition. This means that you can see trends in environments as new ones arise and others get buried.
For example, there is a growing movement to try to eliminate the notion of the "file". Most Web applications don't force users to think of files. iPhone apps typically don't force users to think of files. Android apps generally don't force users to think of files. And so on.
Similarly, there is a growing movement to try to eliminate the notion of "terminating" an app. Most Web applications don't force the user to log out, but rather implicitly log the user out after a period of inactivity. Same thing with Android, and to a lesser extent, iPhone (and possibly WebOS).
This requires more emphasis on application design, focusing on business goals, and not sticking with an implementation model tied to a previous application environment. Developers who lack the time or inclination to do this will get frustrated with newer environments that break their existing mental model. This is not the fault of either environment, any more than it is the fault of a mountain for storms flowing around it rather than through it.
For example, some development environments, like Hypercard and Smalltalk, had the application and the development tools co-mingled in one setup. This concept did not catch on much, outside of language extensions to apps (e.g., VBA in Excel, Lisp in AutoCAD). Developers who came up with mental models that presumed the existence of development tools in the app itself, therefore, either had to change their model or limit themselves to environments where their model would hold true.
So, when you write:
Along with other messy things I
discovered, I think that developing
our app for Android is not going to
happen.
That would appear to be for the best, for you, for right now. Similarly, I would counsel you against attempting to port your application to the Web, since some of the same problems you have reported with Android you will find in Web applications as well (e.g., no "termination"). Or, conversely, someday if you do port your app to the Web, you may find that the Web application's flow may be a better match for Android, and you can revisit an Android port at that time.
I'd just like to add a correction here for the future readers of this thread. This particular nuance has escaped my understanding for a long time so I want to make sure none of you make the same mistakes:
System.exit() does not kill your app if you have more than one activity on the stack. What actually happens is that the process is killed and immediately restarted with one fewer activity on the stack. This is also what happens when your app is killed by the Force Close dialog, or even when you try to kill the process from DDMS. This is a fact that is entirely undocumented, to my knowledge.
The short answer is, if you want to exit your application, you've got to keep track of all activities in your stack and finish() ALL of them when the user wants to exit (and no, there is no way to iterate through the Activity stack, so you have to manage all of this yourself). Even this does not actually kill the process or any dangling references you may have. It simply finishes the activities. Also, I'm not sure whether Process.killProcess(Process.myPid()) works any better; I haven't tested it.
If, on the other hand, it is okay for you to have activities remaining in your stack, there is another method which makes things super easy for you: Activity.moveTaskToBack(true) will simply background your process and show the home screen.
The long answer involves explanation of the philosophy behind this behavior. The philosophy is born out of a number of assumptions:
First of all, this only happens when your app is in the foreground. If it is in the background the process will terminate just fine. However, if it is in the foreground, the OS assumes that the user wants to keep doing whatever he/she was doing. (If you are trying to kill the process from DDMS, you should hit the home button first, and then kill it)
It also assumes that each activity is independent of all the other activities. This is often true, for example in the case that your app launches the Browser Activity, which is entirely separate and was not written by you. The Browser Activity may or may not be created on the same Task, depending on its manifest attributes.
It assumes that each of your activities is completely self-reliant and can be killed/restored in a moment's notice. (I rather dislike this particular assumption, since my app has many activities which rely on a large amount of cached data, too large to be efficiently serialized during onSaveInstanceState, but whaddya gonna do?) For most well-written Android apps this should be true, since you never know when your app is going to be killed off in the background.
The final factor is not so much an assumption, but rather a limitation of the OS: killing the app explicitly is the same as the app crashing, and also the same as Android killing the app to reclaim memory. This culminates in our coup de grace: since Android can't tell if the app exited or crashed or was killed in the background, it assumes the user wants to return where they left off, and so the ActivityManager restarts the process.
When you think about it, this is appropriate for the platform. First, this is exactly what happens when the process is killed in the background and the user comes back to it, so it needs to be restarted where it left off. Second, this is what happens when the app crashes and presents the dreaded Force Close dialog.
Say I want my users to be able to take a picture and upload it. I launch the Camera Activity from my activity, and ask it to return an image. The Camera is pushed onto the top of my current Task (rather than being created in its own Task). If the Camera has an error and it crashes, should that result in the whole app crashing? From the standpoint of the user, only the Camera failed, and they should be returned to their previous activity. So it just restarts the process with all the same Activities in the stack, minus the Camera. Since your Activities should be designed so that they can be killed and restored at the drop of a hat, this shouldn't be a problem. Unfortunately, not all apps can be designed that way, so it is a problem for many of us, no matter what Romain Guy or anyone else tells you. So, we need to use workarounds.
So, my closing advice:
Don't try to kill the process. Either call finish() on all activities or call moveTaskToBack(true).
If your process crashes or gets killed, and if, like me, you need the data that was in memory which is now lost, you'll need to return to the root activity. To do this, you should call startActivity() with an Intent that contains the Intent.FLAG_ACTIVITY_CLEAR_TOP flag.
If you want to kill your app from the Eclipse DDMS perspective, it had better not be in the foreground, or it will restart itself. You should press the Home button first, and then kill the process.
All of my applications have quit buttons... and I quite frequently get positive comments from users because of it. I don't care if the platform was designed in a fashion that applications shouldn't need them. Saying "don't put them there" is kind of ridiculous. If the user wants to quit... I provide them the access to do exactly that. I don't think it reduces how Android operates at all and seems like a good practice. I understand the life cycle... and my observation has been that Android doesn't do a good job at handling it.... and that is a basic fact.
Stop thinking of your application as a monolithic application. It is a set of UI screens that the user can interact with your "application", and "functions" provided via Android services.
Not knowing what your mysterious app "does" is not really important. Let's assume it tunnels into some super secure corporate intranet, performing some monitoring or interaction and stays logged in until the user "quits the application". Because your IT department commands it, users must be very conscious of when they are IN or OUT of the intranet. Hence your mindset of it being important for users to "quit".
This is simple. Make a service that puts an ongoing notification in the notification bar saying "I'm in the intranet, or I am running". Have that service perform all the functionality that you need for your application. Have activities that bind to that service to allow your users to access the bits of UI they need to interact with your "application". And have an Android Menu -> Quit (or logout, or whatever) button that tells the service to quit, then closes the activity itself.
This is, for all intents and purposes exactly what you say you want. Done the Android way. Look at Google Talk or Google Maps Navigation for examples of this "exit" is possible mentality. The only difference is that pressing back button out of your activity might leave your UNIX process lying in wait just in case the user wants to revive your application. This is really no different than a modern operating system that caches recently accessed files in memory. After you quit your windows program, most likely resources that it needed are still in memory, waiting to be replaced by other resources as they are loaded now that they are no longer needed. Android is the same thing.
I really don't see your problem.
This is an interesting and insightful discussion with so many experts contributing. I feel this post should be looped back from within the Android development main website, because it does revolve around one of the core designs of the Android OS.
I would also like to add my two cents here.
So far I have been impressed with Android's way of handling lifecycle events, bringing the concept of a web-like experience to native apps.
Having said that I still believe that there should be a Quit button. Why? ... not for me or Ted or any of the tech gurus here, but for the sole purpose of meeting an end user demand.
Though I am not a big fan of Windows, but long back they introduced a concept that most end users are used to (an X button) ... "I want to quit running a widget when 'I' want to".
That does not mean someone (OS, developer?) will take care of that at its/his/her own discretion... it simply means "where is my Red X button that I am used to". My action should be analogous to 'end a call on pressing of a button', 'turn off the device by pressing a button', and so on and so forth ... it's a perception. It brings a satisfaction per se that my action indeed achieve its purpose.
Even though a developer can spoof this behavior using suggestions given here, the perception still remains i.e. an application should completely cease to function (now), by an independent, trusted and neutral source (OS) on demand from the end user.
You can quit, either by pressing the Back button or by calling finish() in your Activity. Just call finish() from a MenuItem if you want to explicitly kill it off.
Romain isn't saying it can't be done, just that it's pointless — users don't need to care about quitting or saving their work or whatever, as the way the application lifecycle works encourages you to write smart software that automatically saves and restores its state no matter what happens.
This debate boils down to the age-old question of whether the developers know best or whether the user knows best. Professional designers in all areas of human factors struggle with this every day.
Ted has made a point in that one of the most downloaded apps on the Market is the 'App Killer'. People get a bit of extra serotonin when they quit applications. They're used to it with a desktop/laptop. It keeps things moving fast. It keeps the processor cool and the fan from turning on. It uses less power.
When you consider that a mobile device is a much smaller ship, then you can especially appreciate their incentive to 'throw overboard what you no longer need'. Now the developers of Android have reasoned that the OS knows best and that quitting an app is antique. I wholeheartedly support this.
However, I also believe that you should not frustrate the user, even if that frustration is borne out of their own ignorance. Because of that, I conclude that having a 'Quit' option is good design, even if it is mostly a placebo button that does nothing more than close a View.
Ted, what you are trying to accomplish can be done, perhaps just not how you are thinking of it right now.
I suggest you read up on Activities and Services. Stop using the term "app" and start referring to the components, i.e. Activity, Service. I think you just need to learn more about the Android platform; it is a change in mindset from a standard PC app. The fact that none of your posts have had the word "Activity" (short of a FAQ quote, i.e. not your words) in them tells me you need to read some more.
Blog post When to Include an Exit Button in Android Apps (Hint: Never) explains it far, far better than I can. I wish every Android developer has read it already.
Excerpts:
In my experience what [the users] really want is:
An unambiguous way to guarantee that an app will stop consuming resources (battery, CPU cycles, data transfer, etc.).
Many users perceive that an exit button implements this requirement
and ask for it to be added. Developers, looking to please their users,
obligingly add one. Shortly thereafter they both fail.
In most cases the exit button simply calls Activity.finish(). This is exactly equivalent to hitting the back button.
Exactly. Services keep running and polling keeps happening. Users may think they've killed the app but they haven't, and soon
they'll be even more annoyed.
Exit behavior is now ambiguous. Should your exit button just close the Activity, or should it also stop all associated Services, Receivers, and Alarms? What should Back do? What happens if they hit Home instead? What happens if your app has a widget? Should the exit button stop that from updating too?
The solution is to make the back button behave as you'd expect the
exit button to. Better yet, simply stop consuming resources whenever
the app isn't visible.
Go ahead and read the complete article.
Answer: (Romain Guy): The user doesn't, the system handles this
automatically. That's what the activity lifecycle (especially
onPause/onStop/onDestroy) is for. No matter what you do, do not put a
"quit" or "exit" application button. It is useless with Android's
application model. This is also contrary to how core applications
work.
1: Totally exiting an application may be generally unmandatory, but it is not useless. What if windows had no exit option? System would be doggy slow as memory was full and the OS had to guess at which programs you were done with. I don't care what Romain Guy or even Larry Page and Sergey Brin say - these are unquestionable facts: Systems run slower when they have to kill tasks to get their memory before a new app can be launched. You just can't tell me that it doesn't take time to kill an app! Even the light from distant stars take time... There is some use in allowing the user to fully close apps.
2: Contrary to how core applications work? What's that supposed to mean? When I'm done running an app for now, it is no longer doing any work...It's just waiting to be killed by the OS when its memory is needed.
In summary, there is a distinct difference between minimizing and exiting, and neither pinch hits well for the other. Do we leave a screwdriver in every screw? Or a key in every door? Do we leave all of our appliances on high until the breaker blows and we need to turn on another appliance? Do we leave the dish washer full of dishes, and only take out enough each time to make room for some new dirty ones? Do we leave all the cars running in the driveway until -- oh never mind.
If the user wants to minimize an app, then the best thing is to minimize it. If a user wants to exit an app, then by all means it is best to exit.
Is it frowned on? That's Android's view - they frown on it. And many many independent rookie Android developers frown on it.
But when it comes right down to it, there is good coding and bad coding. There is good program flow models and there are bad program flow models.
Leaving programs in memory when the user knows they are done with them simply is not good program flow. It serves absolutely no purpose whatsoever, and it slows things down when launching new apps or when running apps allocate more memory.
It is sort of like your car: There are times when you leave it running, like stopping at a stop light, or perhaps the fast food drive through, or stopping at the ATM. But there are other situations where you do want to shut it off - like when you get to work, or the grocery store or even home.
Similarly, if you're playing a game and the phone rings, yes. Pause the game and keep it running. But if the user is done with the game for a while, then by all means let them exit.
The exit button on some applications should be more out in front than others. Games, for example, or programs where the user is likely to want to fully exit, should have an obvious exit. Other programs, like, perhaps, email programs, where exiting is an unlikely desire (so that it can keep checking for email) -- these programs should not waste prime control input screen space with an exit option, but for good program flow, it should have an exit option. What if someone decides they don't want their mail program trying to check email when they are in poor coverage area, or maybe in a Skype call or whatever? Let them exit the email program if they want!
Suspending and exiting are two vital tasks and neither fulfills the role of the other.
If you are unable to fathom how to make your data/connections (and thereby your "application") persistent, then you will be unable to do what you "need" to do with Android.
Those who do download those cutesy little App Killers usually find they do not help battery life or memory usage, but hinder the OS from doing it's job of managing memory efficiently...
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
I think the point is that there is no need to quit the app unless you have buggy software. Android quits the app when the user is not using it and the device needs more memory. If you have an app that needs to run a service in the background, you will likely want a way to turn the service off.
For example, Google Listen continues to play podcast when the app is not visible. But there is always the pause button to turn the podcast off when the user is done with it. If I remember correctly, Listen, even puts a shortcut in the notification bar so you can always get to the pause button quickly. Another example is an app like a twitter app for instance which constantly polls a service on the internet. These types of apps should really allow the user to choose how often to poll the server, or whether even to poll in a background thread.
If you need to have code that runs on exit, you can override onPause(), onStop(), or onDestroy() as appropriate.
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
I would consider reading "Android Wireless Application Development" published by Addison-Wesley. I am just finishing it up and it is VERY thorough.
It appears that you have some fundamental misunderstandings of the Android platform. I too was a little frustrated at first with the application life-cycle of Android apps, but after coming to a greater understanding, I have come to really enjoy this approach. This book will answer all of your questions and much more. It really is the best resource I have found for new Android developers.
Also, I think you need to let go of a line-for-line port of the existing app. In order to port your application to the Android platform, some of the application design is going to change. The application-lifecycle used is necessary as mobile devices have very limited resources relative to desktop systems and allows Android devices to run several applications in an orderly and resource-aware fashion. Do some more in depth study of the platform, and I think you will realize that what you are wanting to do is entirely feasible. Best of luck.
By the way, I am no way affiliated with Addison-Wesley or any person or organization associated with this book. After re-reading my post I feel that I came off a little fanboyish. I just really, really enjoyed it and found it extremely helpful. :)
Almost 99% of the time there is no need for an Android application to take over its own life cycle. Most of the time it comes down to better planning or smarter design of the application. For example, rather build an internal service (not exported) to handle downloads, etc., or design actions and tasks around user workflow.
But that being said, where there is a will there is a way. Android provides - through the android.os.Process class, a much better API than Java to control the underlying process. And unlike Java it does not treat the developer like a moron by hiding it all behind a simple java.lang.System.exit() call.
So how do you ask your application to commit suicide in Android? Well, the trick is simple:
Create your own Android application class by inheriting from the standard android.app.Application class (remember to declare it in the AndroidManifest.xml file).
Override the onCreate() method, and store the process ID which started your application:
this.pid = android.os.Process.myPid(); // Save for later use.
Now to kill your application, provide a kill() method:
android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);
Now whenever you need your app to commit suicide just type cast the application context, and call your kill method!
((MySuicidalApp) context.getApplicationContext()).kill()
Just remember that due to the process management policies in Android, specifically related to services, Android may just opt to restart your service (see You should not use task killers on Android).
When I conceive an application in Android, I see it this way:
You are working with your application
The phone rang
You take the call
At the end of the call, you come back to your application at the same place you were
To do that, you only need the Back button or the Home button of your phone (either by short or long press) and the notification bar.
When I exit my application, I only use the Back button until I am out of it or the Home button.
That's how most of the applications are conceived I think. But if I need some sort of session or connection, I made it clear to the user with a login/logout button and notification (title bar or anything else). This is a rather different style than the pure "exit" style application.
On PCs, you have a multi-GUI desktop, and on Android, you obviously have multi-tasks, but you only display one app at a time (I don't consider widgets here ^^). And on a mobile phone, at anytime, you could have a notification for something more important than what you are doing.
So the whole concept of an application rely on something different that "enter application - work - exit application".
Hmmmm...
I think that you just don't see the Android app the right way. You can do something almost like what you want easily:
Do the app activities save/restore state like it is encouraged in the developer livecycle documentation.
If some login is needed at the restore stage (no login/session information available) then do it.
Eventually add a button/menu/timeout in which case you will do a finish() without saving the login and other session info, making implicitly the end of app session: so if the app is started/brought to front again it will start a new session.
That way you don't really care if the app is really removed from memory or not.
If you really want to remove it from memory (this is discouraged, and BTW for what purpose?) you can kill it conditionally at the end of onDestroy() with java.lang.System.exit(0) (or perhaps restartPackage(..)?). Of course do it only in the case where you want to "really end the app", because the onDestroy() is part of the normal lifecycle of activities and not an app end at all.
As an Application in an Android context is just a bunch of vaguely related Activities, quitting an Application doesn't really make much sense. You can finish() an Activity, and the view of the previous Activity in the Activity stack will be drawn.
I agree with Ted. I understand that exiting the application is not the
"Android way", but it doesn't seem like it should be precluded. Here
are three reasons why you might want a real exit to the application (not
just the activity):
The user might want some control over which app gets killed in the
case of low memory. If important app A is running in the background,
then you might like to exit app B when you are done with it so
that app A doesn't get killed by the operating system.
If your application has sensitive data cached in memory, you might
like to kill the app so that a virus/worm/rogue app can't get at it. I
know the security model is supposed to prevent that, but just in case...
If your application uses resources (like network, CPU, sensors, etc.)
that could adversely affect the phone, then one way of ensuring that
those resources are freed up is to exit the application. I understand
that well-behaved apps should free up resources when they are not needed. But again, exiting the application seems like a reasonable way of ensuring that.
I hope things will change over time. The user should be able to kill an app or process if the app process is sandboxed correctly by the OS. There is a notion that apps should be written perfectly or user will use only the apps that follow all SDK recommendations. I think that is a tall order.
The Linux kernel has a feature called Out-of-memory killer (as mentioned above, the policies are configurable at the userspace level as well as the kernel is not an optimal one, but by no means unnecessary).
And it is heavily used by Android:
OOM killer is not for userspace
Android Notes (OOM Killer Info - where you can configure the OOM feature on Android)
Android Porting On Real Target
Some userspace apps are available to assist with these kill apps, for example:
Autokiller/Configuring Android's internal task killer
You apparently have found the answer you want in the finish() command. This will not remove your app from memory, but Android will do so whenever it needs the resources, so it doesn't make any difference that you won't be doing that explicitly.
I would only add that in order to attain the full effect that an application exit would typically have, you would want to reset the app's state to whatever its state is normally at the time it is first run after a boot of the device, just prior to calling finish() on all of your activities. That way, if the user selects your app again, it will appear to have been run "fresh," without any state left over from the point prior to the simulated "exit."
If there are some special actions that should only occur on "exit," such as saving the user's work or whatever, you can also perform them prior to the re-initialization part of the above routine.
This approach allows you to accomplish your goal of having an "exit" command without violating Android's philosophy of leaving the management of OS resources, including the closing of apps, in the hands of the operating system.
Personally, I would not use this approach, because Android users expect an app to preserve its continuity when they revisit it, and so they are not used to the modality of "exiting" an app. I would instead support a "clear" function that a user can invoke to reset the app to some default initial state, without the necessity of "leaving" it in the process.
The one exception would be when the user has hit the back button a sufficient number of times to cause the app to close. In that situation, there is no expectation on the user's part that state will have been saved (and if there is unsaved state in the app, then you, as the developer, should have code handling the back button that detects that unsaved data, and prompts the user to save it to SharedPreferences or to a file, or to some other non-volatile medium).
Regarding system.exit(0):
If you do decide to use system.exit(0) to close your app with rude finality (e.g., as a result of a final back button press), then I would warn you that although for me this "works," and in some cases has been the only way I've been able to close an app without any trace of it remaining, there is one minor glitch that occurs in Jelly Bean when you use this approach.
Specifically, if you use the Recent Apps list to open your app, and then use the back button to close the app (with that close implemented via system.exit(0)), the Recent Apps list will become visible again, as it will never have been closed. If you then tap on your app's entry in that list to run it a second time from the same, already-open, Recent Apps list, there will be no response.
I suspect that the cause of this is that the Recent Apps list is holding on to a reference to your app that has become non-functional due to your having closed the app using system.exit(0). A more civilized closing of your app using finish() might have informed the OS in a manner that would have allowed it to refresh its Recent Apps list, but system.exit(0) apparently does not do this.
This is not a huge problem in and of itself, as very few people will open an app from Recent Apps, then exit it, and then immediately open it again from the same open Recent Apps list. And if they tap the home button and then re-open the Recent Apps list, your app's entry will be there, and it will be fully functional. But I think that it shows that the use of system.exit(0) can interfere with proper communication between your app and the OS, and this suggests that there may be other, more serious, possibly subtle, consequences of using this approach.
The Android application life cycle is designed for mobile phone users, not computer users.
The app life-cycle is the brutally simplistic paradigm required to turn a Linux server into a consumer appliance.
Android is Java over Linux, a real cross-platform server OS. That is how it spread so quickly. The app life-cycle encapsulates the underlying reality of the OS.
To mobile users, apps are just installed or not installed. There is no concept of running or exiting. In fact, app processes are meant to run until the OS releases them for their held resources.
Since this is Stack Overflow, anyone reading this is a computer user and must turn off 90% of their knowledge to understand the mobile app lifecycle.
There is a (relatively) simple design which will allow you to get around the "exit" conundrum. Make your app have a "base" state (activity) which is just a blank screen. On the first onCreate of the activity, you can launch another activity that your app's main functionality is in. The "exit" can then be accomplished by finish()ing this second activity and going back to the base of just a blank screen. The OS can keep this blank screen in memory for as long as it wants...
In essence, because you cannot exit out to OS, you simply transform into a self-created nothingness.
Without an exit function for the application developer to kill their own application it is very bad design.
My application needs to allow the user to dynamically change data dynamically during runtime and the user needs to restart my application to make the change effect, but Android did not allow my application restart by itself. Android OS has a very bad design application life cycle.
For closing an app at any point use FLAG_ACTIVITY_CLEAR_TOP flag in Intent and then system.exit();
Or there is similar way, but without system.exit() when you want to exit call this method:
public void exit() {
startActivity(new Intent(this, HomeActivity.class).
setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}
In your HomeActivity.onCreate() add following code
protected void onCreate(Bundle savedInstanceState) {
if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
finish();
}
}
......................
This will work without breaking the Android life-cycle.
First of all, never never never use System.exit(0). It is like making a person sleep punching him on the head!
Second: I'm facing this problem. Before sharing my solution a I want to share my thoughts.
I think that an "Exit Button" is stupid. Really really really stupid. And I think that users (consumer) that ask for an exit button for your application is stupid too. They don't understand how the OS is working and how is managing resources (and it does a great job).
I think that if you write a good piece of code that do the right things (updates, saves, and pushes) at the right moment and conditions and using the correct things (Service and Receiver) it will work pretty well and no one will complain.
But to do that you have to study and learn how things works on Android.
Anyway, this is my solution to provide to users an "Exit Button".
I created an Options Menu always visible in each activity (I've a super activity that do that).
When the user clicks on that button this is what happens:
Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);
// Commit the edits!
editor.commit();
startActivity(intent);
finish();
So I'm saving in SharedPreferences that I want to kill my app, and I start an Intent. Please look at those flags; those will clear all my backstack calling my DashBoard Activity that is my "home" activity.
So in my Dashboard Activity I run this method in the onResume:
private void checkIfForceKill() {
// CHECK IF I NEED TO KILL THE APP
// Restore preferences
SharedPreferences settings = getSharedPreferences(
getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
boolean forceKill = settings.getBoolean(
MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);
if (forceKill) {
//CLEAR THE FORCE_EXIT SETTINGS
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, false);
// Commit the edits!
editor.commit();
//HERE STOP ALL YOUR SERVICES
finish();
}
}
And it will work pretty well.
The only thing that I don't understand why it's happening is that when I do the last finish (and I've checked: it's following all the correct flow of onPause → onStop → onDestroy) the application is still on the recent activity (but it's blank).
It seems like the latest intent (that has started the DashboardActivity) is still in the system.
I've to dig more in order to also remove it.
It took me longer to read this Q&A than to actually implement a semi-proper Android Application Lifecycle.
It's a GPS app that polls for points and sends the current location to a webservice every few seconds using a thread... This could be polling every 5 minutes in Ted's case for an update, then onStop can simply start the update activity Ted was soo concerned about if one was found (asynchronous Ted, don't code like a Windows programmer or your programs will run like Windows programs ... eww, it's not that hard).
I did some initial code in onCreate to set up things for the activity lifetime, including checkUpdate.start();:
...
#Override
public void onStart() {
super.onStart();
isRemote = true;
checkUpdate.resume();
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}
#Override
public void onPause() {
isRemote = false;
checkUpdate.suspend();
locationManager.removeUpdates(luh);
super.onStop();
}
This code may be completely wrong, but it works. This is one of my first Android applications.
Voilà, an application that doesn't consume CPU when it's in the background, yet is instantly ready to reopen because it is in RAM (although not holding RAM as is the Android lifecycle) ... an app is always ready, it's a phone, guys/gals. If an app was to use up all the RAM and couldn't be shut down by the OS then the thing might stop ringing =P That's why the OS needs to be able to close your app when it's in the background (if your application isn't a resource hog it won't be closed BTW), so let's just write better applications.
Every time while you move to the next page through intent, use:
`YourActivityname.this.finish()`;
Example:
Intent intent = new Intent(getApplicationContext(), SMS.class);
startActivity(intent);
MainActivity.this.finish();
So that no activity will be running on background and when you want to Exit your app, use:
MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();
This exiting worked like a charm for me :)
You have probably spent many years writing "proper" programs for "proper" computers. You say you are learning to program in Android. This is just one of the things you have to learn. You can't spent years doing watercolour painting and assume that oil painting works exactly the same way. This was the very least of the things that were new concepts to me when I wrote my first app eight years ago.
In any case, if you want to terminate your application you can always call System.exit(0);.
I'm building an Android application that's based around an enhanced WebView (based on PhoneGap). I've enhanced the WebView so that from JavaScript running inside you can invoke the native contact picker to choose a phone number (which may be supplied by Facebook for example).
The problem I have is that the native contact picker runs in an activity in another process and the Android docs say that while another activity is open my activity may get destroyed due to memory constraints. I haven't actually seen this happen in my application but if it did then I'm guessing my WebView's state would be destroyed and the code that was waiting for the picked contact would be terminated.
It seems a bit crazy that the activity requesting a contact could be destroyed while the contact picker is open. Does anyone know if that does indeed happen? Is there a way to persist the state of the WebView if it does?
Thanks,
-Shaun
Does anyone know if that does indeed
happen?
You're looking at the problem too simply.
You have a WebView. You open the contacts application. While the user is in the contacts application, a phone call comes in. While on the phone call (using a Bluetooth headset), a text message comes in, so the user opens that up from its Notification. While still on the phone call and texting away, a text comes in with a link, so she taps it and brings up the Browser application.
By this time, your activity is surely destroyed, except on maybe some of the most recent phones that have a fair bit of RAM.
Now, is that common? No. However, this also has nothing to do with the contacts application -- if the user presses HOME, at some point in the future, your activity may be destroyed to free up RAM as well.
Is there a way to persist the state of
the WebView if it does?
That depends on what you consider "the state of the WebView" to be. This really is PhoneGap's job, if you are making a PhoneGap-based app. So, you might consider asking them.
There is no way to persist the DOM. There are trivial ways to persist the URL (see onSaveInstanceState()). And there may be stuff in between that you consider part of "the state of the WebView" that may or may not be possible to save.
The long and detailed answer is a bit complicated, but essentially it comes down to a few points:
If the Android OS has to go cleaning up Activities or Services, it knows how to prioritise which ones should go first. It does this based on whether they're currently in the foreground (last to go), in the middle of executing code, waiting for a result, or simply sitting inactive in the background (first to go). You can be reasonably certain that if your WebView Activity launched the contact picker using the startActivityForResult, it won't be killed
There's a whole system for saving data if an activity is killed, such as the onPause method (which are triggered as soon as your activity leaves the foreground), the onSaveInstanceState method which is called when your activity is about to die. Read up on those to get more information, and the configurationChanged method when the screen orientation changes. If you haven't at least skim read the Activity Lifecycle document on the developers page, you must do that.
Lastly, I'm sure this question has been addressed many times, but with slightly varying wording or situations. Have a look around, see what else you can find.
Moving on in my attempt to learn Android, I just read the following:
Question: Does the user have a choice to kill the application
unless we put a menu option in to kill it? If no such option exists,
how does the user terminate the application?
Answer: (Romain Guy): The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.
Hehe, for every step I take in the Android world I run into some sort of problem =(
Apparently, you cannot quit an application in Android (but the Android system can very well totally destroy your app whenever it feels like it). What's up with that? I am starting to think that it's impossible to write an app that functions as a "normal app" - that the user can quit the app when he/she decides to do so. That is not something that should be relied upon the OS to do.
The application I am trying to create is not an application for the Android Market. It is not an application for "wide use" by the general public, it is a business app that is going to be used in a very narrow business field.
I was actually really looking forward to developing for the Android platform, since it addresses a lot of issues that exist in Windows Mobile and .NET. However, the last week has been somewhat of a turnoff for me... I hope I don't have to abandon Android, but it doesn't look very good right now =(
Is there a way for me to really quit the application?
This will eventually get to your question, but I first want to address a number of issues you raise in your various comments to the various answers already given at the time of this writing. I have no intention of changing your mind -- rather, these are here for others who come to read this post in the future.
The point is that I cannot allow for
Android to determine when my app is
going to be terminated. that must be
the choice of the user.
Millions of people are perfectly happy with the model where the environment closes up the application as needed. Those users simply don't think about "terminating" the Android app, any more than they think about "terminating" a Web page or "terminating" a thermostat.
iPhone users are much the same way, in that pressing the iPhone button does not necessarily "feel" like the app was terminated since many iPhone apps pick up where the user left off, even if the app really was shut down (since iPhone only allows one third-party app at a time, at present).
As I said above, there is a lot of
things going on in my app (data being
PUSHed to the device, lists with tasks
that always should be there, etc.).
I don't know what "lists with tasks that always should be there" means, but the "data being PUSHed to the device" is a pleasant fiction and should not be done by activity in any case. Use a scheduled task (via AlarmManager) to update your data for maximum reliability.
Our users log in and can't be doing
that every time they get a phone call
and Android decides to kill the app.
There are many iPhone and Android applications that deal with this. Usually, it is because they hold onto login credentials, rather than forcing users to log in every time manually.
For example, we want to check updates
when exiting the application
That is a mistake on any operating system. For all you know, the reason your application is being "exited" is because the OS is shutting down, and then your update process will fail mid-stream. Generally, that's not a good thing. Either check updates on start or check updates totally asynchronously (e.g., via a scheduled task), never on exit.
Some comments suggest that hitting the
back button does not kill the app at
all (see link in my question above).
Pressing the BACK button does not "kill the app". It finishes the activity that was on-screen when the user pressed the BACK button.
It should only terminate when the
users want to terminate it - never
ever any other way. If you can't write
apps that behave like that in Android,
then I think that Android can't be used
for writing real apps =(
Then neither can Web applications. Or WebOS, if I understand their model correctly (haven't had a chance to play with one yet). In all of those, users don't "terminate" anything -- they just leave. iPhone is a bit different, in that it only presently allows one thing to run at a time (with a few exceptions), and so the act of leaving implies a fairly immediate termination of the app.
Is there a way for me to really quit
the application?
As everybody else told you, users (via BACK) or your code (via finish()) can close up your currently-running activity. Users generally don't need anything else, for properly-written applications, any more than they need a "quit" option for using Web applications.
No two application environments are the same, by definition. This means that you can see trends in environments as new ones arise and others get buried.
For example, there is a growing movement to try to eliminate the notion of the "file". Most Web applications don't force users to think of files. iPhone apps typically don't force users to think of files. Android apps generally don't force users to think of files. And so on.
Similarly, there is a growing movement to try to eliminate the notion of "terminating" an app. Most Web applications don't force the user to log out, but rather implicitly log the user out after a period of inactivity. Same thing with Android, and to a lesser extent, iPhone (and possibly WebOS).
This requires more emphasis on application design, focusing on business goals, and not sticking with an implementation model tied to a previous application environment. Developers who lack the time or inclination to do this will get frustrated with newer environments that break their existing mental model. This is not the fault of either environment, any more than it is the fault of a mountain for storms flowing around it rather than through it.
For example, some development environments, like Hypercard and Smalltalk, had the application and the development tools co-mingled in one setup. This concept did not catch on much, outside of language extensions to apps (e.g., VBA in Excel, Lisp in AutoCAD). Developers who came up with mental models that presumed the existence of development tools in the app itself, therefore, either had to change their model or limit themselves to environments where their model would hold true.
So, when you write:
Along with other messy things I
discovered, I think that developing
our app for Android is not going to
happen.
That would appear to be for the best, for you, for right now. Similarly, I would counsel you against attempting to port your application to the Web, since some of the same problems you have reported with Android you will find in Web applications as well (e.g., no "termination"). Or, conversely, someday if you do port your app to the Web, you may find that the Web application's flow may be a better match for Android, and you can revisit an Android port at that time.
I'd just like to add a correction here for the future readers of this thread. This particular nuance has escaped my understanding for a long time so I want to make sure none of you make the same mistakes:
System.exit() does not kill your app if you have more than one activity on the stack. What actually happens is that the process is killed and immediately restarted with one fewer activity on the stack. This is also what happens when your app is killed by the Force Close dialog, or even when you try to kill the process from DDMS. This is a fact that is entirely undocumented, to my knowledge.
The short answer is, if you want to exit your application, you've got to keep track of all activities in your stack and finish() ALL of them when the user wants to exit (and no, there is no way to iterate through the Activity stack, so you have to manage all of this yourself). Even this does not actually kill the process or any dangling references you may have. It simply finishes the activities. Also, I'm not sure whether Process.killProcess(Process.myPid()) works any better; I haven't tested it.
If, on the other hand, it is okay for you to have activities remaining in your stack, there is another method which makes things super easy for you: Activity.moveTaskToBack(true) will simply background your process and show the home screen.
The long answer involves explanation of the philosophy behind this behavior. The philosophy is born out of a number of assumptions:
First of all, this only happens when your app is in the foreground. If it is in the background the process will terminate just fine. However, if it is in the foreground, the OS assumes that the user wants to keep doing whatever he/she was doing. (If you are trying to kill the process from DDMS, you should hit the home button first, and then kill it)
It also assumes that each activity is independent of all the other activities. This is often true, for example in the case that your app launches the Browser Activity, which is entirely separate and was not written by you. The Browser Activity may or may not be created on the same Task, depending on its manifest attributes.
It assumes that each of your activities is completely self-reliant and can be killed/restored in a moment's notice. (I rather dislike this particular assumption, since my app has many activities which rely on a large amount of cached data, too large to be efficiently serialized during onSaveInstanceState, but whaddya gonna do?) For most well-written Android apps this should be true, since you never know when your app is going to be killed off in the background.
The final factor is not so much an assumption, but rather a limitation of the OS: killing the app explicitly is the same as the app crashing, and also the same as Android killing the app to reclaim memory. This culminates in our coup de grace: since Android can't tell if the app exited or crashed or was killed in the background, it assumes the user wants to return where they left off, and so the ActivityManager restarts the process.
When you think about it, this is appropriate for the platform. First, this is exactly what happens when the process is killed in the background and the user comes back to it, so it needs to be restarted where it left off. Second, this is what happens when the app crashes and presents the dreaded Force Close dialog.
Say I want my users to be able to take a picture and upload it. I launch the Camera Activity from my activity, and ask it to return an image. The Camera is pushed onto the top of my current Task (rather than being created in its own Task). If the Camera has an error and it crashes, should that result in the whole app crashing? From the standpoint of the user, only the Camera failed, and they should be returned to their previous activity. So it just restarts the process with all the same Activities in the stack, minus the Camera. Since your Activities should be designed so that they can be killed and restored at the drop of a hat, this shouldn't be a problem. Unfortunately, not all apps can be designed that way, so it is a problem for many of us, no matter what Romain Guy or anyone else tells you. So, we need to use workarounds.
So, my closing advice:
Don't try to kill the process. Either call finish() on all activities or call moveTaskToBack(true).
If your process crashes or gets killed, and if, like me, you need the data that was in memory which is now lost, you'll need to return to the root activity. To do this, you should call startActivity() with an Intent that contains the Intent.FLAG_ACTIVITY_CLEAR_TOP flag.
If you want to kill your app from the Eclipse DDMS perspective, it had better not be in the foreground, or it will restart itself. You should press the Home button first, and then kill the process.
All of my applications have quit buttons... and I quite frequently get positive comments from users because of it. I don't care if the platform was designed in a fashion that applications shouldn't need them. Saying "don't put them there" is kind of ridiculous. If the user wants to quit... I provide them the access to do exactly that. I don't think it reduces how Android operates at all and seems like a good practice. I understand the life cycle... and my observation has been that Android doesn't do a good job at handling it.... and that is a basic fact.
Stop thinking of your application as a monolithic application. It is a set of UI screens that the user can interact with your "application", and "functions" provided via Android services.
Not knowing what your mysterious app "does" is not really important. Let's assume it tunnels into some super secure corporate intranet, performing some monitoring or interaction and stays logged in until the user "quits the application". Because your IT department commands it, users must be very conscious of when they are IN or OUT of the intranet. Hence your mindset of it being important for users to "quit".
This is simple. Make a service that puts an ongoing notification in the notification bar saying "I'm in the intranet, or I am running". Have that service perform all the functionality that you need for your application. Have activities that bind to that service to allow your users to access the bits of UI they need to interact with your "application". And have an Android Menu -> Quit (or logout, or whatever) button that tells the service to quit, then closes the activity itself.
This is, for all intents and purposes exactly what you say you want. Done the Android way. Look at Google Talk or Google Maps Navigation for examples of this "exit" is possible mentality. The only difference is that pressing back button out of your activity might leave your UNIX process lying in wait just in case the user wants to revive your application. This is really no different than a modern operating system that caches recently accessed files in memory. After you quit your windows program, most likely resources that it needed are still in memory, waiting to be replaced by other resources as they are loaded now that they are no longer needed. Android is the same thing.
I really don't see your problem.
This is an interesting and insightful discussion with so many experts contributing. I feel this post should be looped back from within the Android development main website, because it does revolve around one of the core designs of the Android OS.
I would also like to add my two cents here.
So far I have been impressed with Android's way of handling lifecycle events, bringing the concept of a web-like experience to native apps.
Having said that I still believe that there should be a Quit button. Why? ... not for me or Ted or any of the tech gurus here, but for the sole purpose of meeting an end user demand.
Though I am not a big fan of Windows, but long back they introduced a concept that most end users are used to (an X button) ... "I want to quit running a widget when 'I' want to".
That does not mean someone (OS, developer?) will take care of that at its/his/her own discretion... it simply means "where is my Red X button that I am used to". My action should be analogous to 'end a call on pressing of a button', 'turn off the device by pressing a button', and so on and so forth ... it's a perception. It brings a satisfaction per se that my action indeed achieve its purpose.
Even though a developer can spoof this behavior using suggestions given here, the perception still remains i.e. an application should completely cease to function (now), by an independent, trusted and neutral source (OS) on demand from the end user.
You can quit, either by pressing the Back button or by calling finish() in your Activity. Just call finish() from a MenuItem if you want to explicitly kill it off.
Romain isn't saying it can't be done, just that it's pointless — users don't need to care about quitting or saving their work or whatever, as the way the application lifecycle works encourages you to write smart software that automatically saves and restores its state no matter what happens.
This debate boils down to the age-old question of whether the developers know best or whether the user knows best. Professional designers in all areas of human factors struggle with this every day.
Ted has made a point in that one of the most downloaded apps on the Market is the 'App Killer'. People get a bit of extra serotonin when they quit applications. They're used to it with a desktop/laptop. It keeps things moving fast. It keeps the processor cool and the fan from turning on. It uses less power.
When you consider that a mobile device is a much smaller ship, then you can especially appreciate their incentive to 'throw overboard what you no longer need'. Now the developers of Android have reasoned that the OS knows best and that quitting an app is antique. I wholeheartedly support this.
However, I also believe that you should not frustrate the user, even if that frustration is borne out of their own ignorance. Because of that, I conclude that having a 'Quit' option is good design, even if it is mostly a placebo button that does nothing more than close a View.
Ted, what you are trying to accomplish can be done, perhaps just not how you are thinking of it right now.
I suggest you read up on Activities and Services. Stop using the term "app" and start referring to the components, i.e. Activity, Service. I think you just need to learn more about the Android platform; it is a change in mindset from a standard PC app. The fact that none of your posts have had the word "Activity" (short of a FAQ quote, i.e. not your words) in them tells me you need to read some more.
Blog post When to Include an Exit Button in Android Apps (Hint: Never) explains it far, far better than I can. I wish every Android developer has read it already.
Excerpts:
In my experience what [the users] really want is:
An unambiguous way to guarantee that an app will stop consuming resources (battery, CPU cycles, data transfer, etc.).
Many users perceive that an exit button implements this requirement
and ask for it to be added. Developers, looking to please their users,
obligingly add one. Shortly thereafter they both fail.
In most cases the exit button simply calls Activity.finish(). This is exactly equivalent to hitting the back button.
Exactly. Services keep running and polling keeps happening. Users may think they've killed the app but they haven't, and soon
they'll be even more annoyed.
Exit behavior is now ambiguous. Should your exit button just close the Activity, or should it also stop all associated Services, Receivers, and Alarms? What should Back do? What happens if they hit Home instead? What happens if your app has a widget? Should the exit button stop that from updating too?
The solution is to make the back button behave as you'd expect the
exit button to. Better yet, simply stop consuming resources whenever
the app isn't visible.
Go ahead and read the complete article.
Answer: (Romain Guy): The user doesn't, the system handles this
automatically. That's what the activity lifecycle (especially
onPause/onStop/onDestroy) is for. No matter what you do, do not put a
"quit" or "exit" application button. It is useless with Android's
application model. This is also contrary to how core applications
work.
1: Totally exiting an application may be generally unmandatory, but it is not useless. What if windows had no exit option? System would be doggy slow as memory was full and the OS had to guess at which programs you were done with. I don't care what Romain Guy or even Larry Page and Sergey Brin say - these are unquestionable facts: Systems run slower when they have to kill tasks to get their memory before a new app can be launched. You just can't tell me that it doesn't take time to kill an app! Even the light from distant stars take time... There is some use in allowing the user to fully close apps.
2: Contrary to how core applications work? What's that supposed to mean? When I'm done running an app for now, it is no longer doing any work...It's just waiting to be killed by the OS when its memory is needed.
In summary, there is a distinct difference between minimizing and exiting, and neither pinch hits well for the other. Do we leave a screwdriver in every screw? Or a key in every door? Do we leave all of our appliances on high until the breaker blows and we need to turn on another appliance? Do we leave the dish washer full of dishes, and only take out enough each time to make room for some new dirty ones? Do we leave all the cars running in the driveway until -- oh never mind.
If the user wants to minimize an app, then the best thing is to minimize it. If a user wants to exit an app, then by all means it is best to exit.
Is it frowned on? That's Android's view - they frown on it. And many many independent rookie Android developers frown on it.
But when it comes right down to it, there is good coding and bad coding. There is good program flow models and there are bad program flow models.
Leaving programs in memory when the user knows they are done with them simply is not good program flow. It serves absolutely no purpose whatsoever, and it slows things down when launching new apps or when running apps allocate more memory.
It is sort of like your car: There are times when you leave it running, like stopping at a stop light, or perhaps the fast food drive through, or stopping at the ATM. But there are other situations where you do want to shut it off - like when you get to work, or the grocery store or even home.
Similarly, if you're playing a game and the phone rings, yes. Pause the game and keep it running. But if the user is done with the game for a while, then by all means let them exit.
The exit button on some applications should be more out in front than others. Games, for example, or programs where the user is likely to want to fully exit, should have an obvious exit. Other programs, like, perhaps, email programs, where exiting is an unlikely desire (so that it can keep checking for email) -- these programs should not waste prime control input screen space with an exit option, but for good program flow, it should have an exit option. What if someone decides they don't want their mail program trying to check email when they are in poor coverage area, or maybe in a Skype call or whatever? Let them exit the email program if they want!
Suspending and exiting are two vital tasks and neither fulfills the role of the other.
If you are unable to fathom how to make your data/connections (and thereby your "application") persistent, then you will be unable to do what you "need" to do with Android.
Those who do download those cutesy little App Killers usually find they do not help battery life or memory usage, but hinder the OS from doing it's job of managing memory efficiently...
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
I think the point is that there is no need to quit the app unless you have buggy software. Android quits the app when the user is not using it and the device needs more memory. If you have an app that needs to run a service in the background, you will likely want a way to turn the service off.
For example, Google Listen continues to play podcast when the app is not visible. But there is always the pause button to turn the podcast off when the user is done with it. If I remember correctly, Listen, even puts a shortcut in the notification bar so you can always get to the pause button quickly. Another example is an app like a twitter app for instance which constantly polls a service on the internet. These types of apps should really allow the user to choose how often to poll the server, or whether even to poll in a background thread.
If you need to have code that runs on exit, you can override onPause(), onStop(), or onDestroy() as appropriate.
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
I would consider reading "Android Wireless Application Development" published by Addison-Wesley. I am just finishing it up and it is VERY thorough.
It appears that you have some fundamental misunderstandings of the Android platform. I too was a little frustrated at first with the application life-cycle of Android apps, but after coming to a greater understanding, I have come to really enjoy this approach. This book will answer all of your questions and much more. It really is the best resource I have found for new Android developers.
Also, I think you need to let go of a line-for-line port of the existing app. In order to port your application to the Android platform, some of the application design is going to change. The application-lifecycle used is necessary as mobile devices have very limited resources relative to desktop systems and allows Android devices to run several applications in an orderly and resource-aware fashion. Do some more in depth study of the platform, and I think you will realize that what you are wanting to do is entirely feasible. Best of luck.
By the way, I am no way affiliated with Addison-Wesley or any person or organization associated with this book. After re-reading my post I feel that I came off a little fanboyish. I just really, really enjoyed it and found it extremely helpful. :)
Almost 99% of the time there is no need for an Android application to take over its own life cycle. Most of the time it comes down to better planning or smarter design of the application. For example, rather build an internal service (not exported) to handle downloads, etc., or design actions and tasks around user workflow.
But that being said, where there is a will there is a way. Android provides - through the android.os.Process class, a much better API than Java to control the underlying process. And unlike Java it does not treat the developer like a moron by hiding it all behind a simple java.lang.System.exit() call.
So how do you ask your application to commit suicide in Android? Well, the trick is simple:
Create your own Android application class by inheriting from the standard android.app.Application class (remember to declare it in the AndroidManifest.xml file).
Override the onCreate() method, and store the process ID which started your application:
this.pid = android.os.Process.myPid(); // Save for later use.
Now to kill your application, provide a kill() method:
android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);
Now whenever you need your app to commit suicide just type cast the application context, and call your kill method!
((MySuicidalApp) context.getApplicationContext()).kill()
Just remember that due to the process management policies in Android, specifically related to services, Android may just opt to restart your service (see You should not use task killers on Android).
When I conceive an application in Android, I see it this way:
You are working with your application
The phone rang
You take the call
At the end of the call, you come back to your application at the same place you were
To do that, you only need the Back button or the Home button of your phone (either by short or long press) and the notification bar.
When I exit my application, I only use the Back button until I am out of it or the Home button.
That's how most of the applications are conceived I think. But if I need some sort of session or connection, I made it clear to the user with a login/logout button and notification (title bar or anything else). This is a rather different style than the pure "exit" style application.
On PCs, you have a multi-GUI desktop, and on Android, you obviously have multi-tasks, but you only display one app at a time (I don't consider widgets here ^^). And on a mobile phone, at anytime, you could have a notification for something more important than what you are doing.
So the whole concept of an application rely on something different that "enter application - work - exit application".
Hmmmm...
I think that you just don't see the Android app the right way. You can do something almost like what you want easily:
Do the app activities save/restore state like it is encouraged in the developer livecycle documentation.
If some login is needed at the restore stage (no login/session information available) then do it.
Eventually add a button/menu/timeout in which case you will do a finish() without saving the login and other session info, making implicitly the end of app session: so if the app is started/brought to front again it will start a new session.
That way you don't really care if the app is really removed from memory or not.
If you really want to remove it from memory (this is discouraged, and BTW for what purpose?) you can kill it conditionally at the end of onDestroy() with java.lang.System.exit(0) (or perhaps restartPackage(..)?). Of course do it only in the case where you want to "really end the app", because the onDestroy() is part of the normal lifecycle of activities and not an app end at all.
As an Application in an Android context is just a bunch of vaguely related Activities, quitting an Application doesn't really make much sense. You can finish() an Activity, and the view of the previous Activity in the Activity stack will be drawn.
I agree with Ted. I understand that exiting the application is not the
"Android way", but it doesn't seem like it should be precluded. Here
are three reasons why you might want a real exit to the application (not
just the activity):
The user might want some control over which app gets killed in the
case of low memory. If important app A is running in the background,
then you might like to exit app B when you are done with it so
that app A doesn't get killed by the operating system.
If your application has sensitive data cached in memory, you might
like to kill the app so that a virus/worm/rogue app can't get at it. I
know the security model is supposed to prevent that, but just in case...
If your application uses resources (like network, CPU, sensors, etc.)
that could adversely affect the phone, then one way of ensuring that
those resources are freed up is to exit the application. I understand
that well-behaved apps should free up resources when they are not needed. But again, exiting the application seems like a reasonable way of ensuring that.
I hope things will change over time. The user should be able to kill an app or process if the app process is sandboxed correctly by the OS. There is a notion that apps should be written perfectly or user will use only the apps that follow all SDK recommendations. I think that is a tall order.
The Linux kernel has a feature called Out-of-memory killer (as mentioned above, the policies are configurable at the userspace level as well as the kernel is not an optimal one, but by no means unnecessary).
And it is heavily used by Android:
OOM killer is not for userspace
Android Notes (OOM Killer Info - where you can configure the OOM feature on Android)
Android Porting On Real Target
Some userspace apps are available to assist with these kill apps, for example:
Autokiller/Configuring Android's internal task killer
You apparently have found the answer you want in the finish() command. This will not remove your app from memory, but Android will do so whenever it needs the resources, so it doesn't make any difference that you won't be doing that explicitly.
I would only add that in order to attain the full effect that an application exit would typically have, you would want to reset the app's state to whatever its state is normally at the time it is first run after a boot of the device, just prior to calling finish() on all of your activities. That way, if the user selects your app again, it will appear to have been run "fresh," without any state left over from the point prior to the simulated "exit."
If there are some special actions that should only occur on "exit," such as saving the user's work or whatever, you can also perform them prior to the re-initialization part of the above routine.
This approach allows you to accomplish your goal of having an "exit" command without violating Android's philosophy of leaving the management of OS resources, including the closing of apps, in the hands of the operating system.
Personally, I would not use this approach, because Android users expect an app to preserve its continuity when they revisit it, and so they are not used to the modality of "exiting" an app. I would instead support a "clear" function that a user can invoke to reset the app to some default initial state, without the necessity of "leaving" it in the process.
The one exception would be when the user has hit the back button a sufficient number of times to cause the app to close. In that situation, there is no expectation on the user's part that state will have been saved (and if there is unsaved state in the app, then you, as the developer, should have code handling the back button that detects that unsaved data, and prompts the user to save it to SharedPreferences or to a file, or to some other non-volatile medium).
Regarding system.exit(0):
If you do decide to use system.exit(0) to close your app with rude finality (e.g., as a result of a final back button press), then I would warn you that although for me this "works," and in some cases has been the only way I've been able to close an app without any trace of it remaining, there is one minor glitch that occurs in Jelly Bean when you use this approach.
Specifically, if you use the Recent Apps list to open your app, and then use the back button to close the app (with that close implemented via system.exit(0)), the Recent Apps list will become visible again, as it will never have been closed. If you then tap on your app's entry in that list to run it a second time from the same, already-open, Recent Apps list, there will be no response.
I suspect that the cause of this is that the Recent Apps list is holding on to a reference to your app that has become non-functional due to your having closed the app using system.exit(0). A more civilized closing of your app using finish() might have informed the OS in a manner that would have allowed it to refresh its Recent Apps list, but system.exit(0) apparently does not do this.
This is not a huge problem in and of itself, as very few people will open an app from Recent Apps, then exit it, and then immediately open it again from the same open Recent Apps list. And if they tap the home button and then re-open the Recent Apps list, your app's entry will be there, and it will be fully functional. But I think that it shows that the use of system.exit(0) can interfere with proper communication between your app and the OS, and this suggests that there may be other, more serious, possibly subtle, consequences of using this approach.
The Android application life cycle is designed for mobile phone users, not computer users.
The app life-cycle is the brutally simplistic paradigm required to turn a Linux server into a consumer appliance.
Android is Java over Linux, a real cross-platform server OS. That is how it spread so quickly. The app life-cycle encapsulates the underlying reality of the OS.
To mobile users, apps are just installed or not installed. There is no concept of running or exiting. In fact, app processes are meant to run until the OS releases them for their held resources.
Since this is Stack Overflow, anyone reading this is a computer user and must turn off 90% of their knowledge to understand the mobile app lifecycle.
There is a (relatively) simple design which will allow you to get around the "exit" conundrum. Make your app have a "base" state (activity) which is just a blank screen. On the first onCreate of the activity, you can launch another activity that your app's main functionality is in. The "exit" can then be accomplished by finish()ing this second activity and going back to the base of just a blank screen. The OS can keep this blank screen in memory for as long as it wants...
In essence, because you cannot exit out to OS, you simply transform into a self-created nothingness.
Without an exit function for the application developer to kill their own application it is very bad design.
My application needs to allow the user to dynamically change data dynamically during runtime and the user needs to restart my application to make the change effect, but Android did not allow my application restart by itself. Android OS has a very bad design application life cycle.
For closing an app at any point use FLAG_ACTIVITY_CLEAR_TOP flag in Intent and then system.exit();
Or there is similar way, but without system.exit() when you want to exit call this method:
public void exit() {
startActivity(new Intent(this, HomeActivity.class).
setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}
In your HomeActivity.onCreate() add following code
protected void onCreate(Bundle savedInstanceState) {
if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
finish();
}
}
......................
This will work without breaking the Android life-cycle.
First of all, never never never use System.exit(0). It is like making a person sleep punching him on the head!
Second: I'm facing this problem. Before sharing my solution a I want to share my thoughts.
I think that an "Exit Button" is stupid. Really really really stupid. And I think that users (consumer) that ask for an exit button for your application is stupid too. They don't understand how the OS is working and how is managing resources (and it does a great job).
I think that if you write a good piece of code that do the right things (updates, saves, and pushes) at the right moment and conditions and using the correct things (Service and Receiver) it will work pretty well and no one will complain.
But to do that you have to study and learn how things works on Android.
Anyway, this is my solution to provide to users an "Exit Button".
I created an Options Menu always visible in each activity (I've a super activity that do that).
When the user clicks on that button this is what happens:
Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);
// Commit the edits!
editor.commit();
startActivity(intent);
finish();
So I'm saving in SharedPreferences that I want to kill my app, and I start an Intent. Please look at those flags; those will clear all my backstack calling my DashBoard Activity that is my "home" activity.
So in my Dashboard Activity I run this method in the onResume:
private void checkIfForceKill() {
// CHECK IF I NEED TO KILL THE APP
// Restore preferences
SharedPreferences settings = getSharedPreferences(
getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
boolean forceKill = settings.getBoolean(
MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);
if (forceKill) {
//CLEAR THE FORCE_EXIT SETTINGS
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, false);
// Commit the edits!
editor.commit();
//HERE STOP ALL YOUR SERVICES
finish();
}
}
And it will work pretty well.
The only thing that I don't understand why it's happening is that when I do the last finish (and I've checked: it's following all the correct flow of onPause → onStop → onDestroy) the application is still on the recent activity (but it's blank).
It seems like the latest intent (that has started the DashboardActivity) is still in the system.
I've to dig more in order to also remove it.
It took me longer to read this Q&A than to actually implement a semi-proper Android Application Lifecycle.
It's a GPS app that polls for points and sends the current location to a webservice every few seconds using a thread... This could be polling every 5 minutes in Ted's case for an update, then onStop can simply start the update activity Ted was soo concerned about if one was found (asynchronous Ted, don't code like a Windows programmer or your programs will run like Windows programs ... eww, it's not that hard).
I did some initial code in onCreate to set up things for the activity lifetime, including checkUpdate.start();:
...
#Override
public void onStart() {
super.onStart();
isRemote = true;
checkUpdate.resume();
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}
#Override
public void onPause() {
isRemote = false;
checkUpdate.suspend();
locationManager.removeUpdates(luh);
super.onStop();
}
This code may be completely wrong, but it works. This is one of my first Android applications.
Voilà, an application that doesn't consume CPU when it's in the background, yet is instantly ready to reopen because it is in RAM (although not holding RAM as is the Android lifecycle) ... an app is always ready, it's a phone, guys/gals. If an app was to use up all the RAM and couldn't be shut down by the OS then the thing might stop ringing =P That's why the OS needs to be able to close your app when it's in the background (if your application isn't a resource hog it won't be closed BTW), so let's just write better applications.
Every time while you move to the next page through intent, use:
`YourActivityname.this.finish()`;
Example:
Intent intent = new Intent(getApplicationContext(), SMS.class);
startActivity(intent);
MainActivity.this.finish();
So that no activity will be running on background and when you want to Exit your app, use:
MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();
This exiting worked like a charm for me :)
You have probably spent many years writing "proper" programs for "proper" computers. You say you are learning to program in Android. This is just one of the things you have to learn. You can't spent years doing watercolour painting and assume that oil painting works exactly the same way. This was the very least of the things that were new concepts to me when I wrote my first app eight years ago.
In any case, if you want to terminate your application you can always call System.exit(0);.