Develop Reference

Detect when an external android app runs onCreate, onStart, onResume methods

I want to know how to detect when an external app runs one of this methods. I'm working with some classmates in a project where we want to examinate the response time of other applications. The idea is to measure the time between the run of each method to get an aproximation of the response time when opening the app.
Is this possible to achieve?

Android apps are sandboxed and only expose content that they intend to expose. The methods you name are part of components that cannot be accessed directly from the "outside" world. In other ways, if an app wanted you to know when those methods are being called, they will expose that information (i.e. sending a Broadcast or maybe storing the information in a ContentProvider). You can try and see if you can get some information out of the logcat, but I cannot assure how accurate and consistent it will be.

This is imprecise, but I would monitor logcat activity. Depending on the device/VM/AVD logcat is super active during transitions (such as back-grounding and foregrounding) and idle when an app is awaiting user input.
EDIT:
Other than that, if you can do your analysis off the device, perhaps look into using DDMS?

Detect when application is closed

I want to know when the app is closed, because I need to erase a Database when the user shutdown the app, just in the moment when the user close the app is the right moment to erase the SQLite Database, how can I detect this?

This is a flawed design idea, which reflects a misunderstanding of the system - when the process overall dies, it's dead, meaning your code is no longer running.
You can do some tracking and have the last onDestory()'d activity do the cleanup as a courtesy, but don't assume that it will always actually happen (the method is not always called). If having a stale copy is a problem, clean it up on the next run.
That said, you can try using the ndk to provide a handler for process termination signals, but still I wouldn't count on it working in all cases. The limited potential to gain any sound functionality from this would probably not justify the effort unless you are already familiar with the concepts involved.
And do not for a minute mistake cleaning up for a security mechanism, as the file is there while your app is running, and would remain if your app terminated in an unexpected way.

Supposing you don't finish() your main activity, clearing your database inside the onDestroy() method of that activity might be the closest of what you want to accomplish. As has been pointed in the comments, refer to http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle.

My application object's onCreate was called while my app was running, and my app reset. What would cause this?

I have a multi-Threaded android application. One of the things my application does is saves various data to a database on a server via webservices. I was trying to figure out why things were not saving to the server correctly, and saw in one of my log files, that the application objects onCreate() method and constructor were called in the middle of one of the requests going up to the server. These request are in the background and are sent via an intentservice.
I have my application set to catch unhandled exceptions and log them, and I did not see anthing in there. The application onCreate() and constructor was called, the application was kicked back to the main/first screen, the user then had to re-login, and it seems that the database was wiped(which is something else I am wondering about).
So, my main questions are: Why did the application object onCreate() and Constructor get called(why did the application get killed), why did the database get wiped when the above happened because if I do a force stop from inside of settings, applications, it never kills my db.

two words: low memory
I have the same problem. No solution for now. Try to take advantage of the onLowMemory() method, maybe the OS will spare your app.
My application object gets restarted randomly (not any time) when I am coming back from an external application (ex. camera or gallery) for onActivityResult().
Hope that helps someone.

If the application is not a service, but a 'normal' application that calles your intentservice, it is subject to the normal application lifecycle: this means it will get killed when in the background.
Look for the explaining image on this site: http://developer.android.com/guide/topics/fundamentals/activities.html
Take note of the red "Process is killed" part on the left, an the subsequent "onCreate()" afterwards.

I've actually seen very similar behaviour that was caused by a NumberFormater trying to parse a null String. After the call to parse(), the application simply reset itself back to the splash screen with no errors at all. Wasn't fun to track down, pretty much stepped through half the code base trying to find out what was happening - the debugger disconnected and the app restarted when stepping past the parse call.

unable to reopen Android App after this.finish()

My Android App is getting a bit hefty and it runs slow. I haven't got round to optimizing yet. I'm still ironing out some bugs.
Just some background: my app is a game, that the user can win or lose (naturally). I havent made a "win sequence" or "lose sequence yet" so I just put the code in
if(userWins())
this.finish();
where the app exits abruptly. Nothing wrong so far. But, when I try to open the app again I get a blank screen, when I should get option buttons. If I turn off my phone and turn on again I can use the app, but otherwise I can't. I have no idea why this is.
Side note: My copy of AngryBirds has a similar problem. If I exit the game screen "improperly" (i.e. while in the middle of a game, not in the options menu) I cannot turn on the app again until I reboot my phone.

When you call finish() Android don't kill the process yet. In case you restart your application, the process will be kept running unless the OS need the ressources.
see: http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle
This is why it works when you reboot. (you do not need to reboot, just kill the process using adb shell kill <PID> or a task killer if you aren't root)
Your application is likely leaving some variables initialized with old values, and when you restart your activity you find yourself in an unstable state with variables pointing to the old data and other variables to newly initialized data.
You need to either set the old data to null in the onDestroy() event, either ensure initialisation is done in the onCreate() event. You choose wich one depending on if the data can be reused or not.
Look for singletons, or for this kind of initialisation structures:
if (mVar == null) {
mVar = "stuff";
}

Android App Exit Button

I'm not sure whether I need to add an exit button to my app. Is there any point to doing this? And if on exiting one activity or service is not .finish() or closed properly could this cause a lot of damage?

You don't need to add en exit button. If you don't, your activity will just be kept in memory until the system reclaims it. It will not consume any cpu.
Of course, if you have any worker threads running you should stop them in onStop() or onPause(), depending on what your threads are doing.
Many applications add an exit button, for some reason. I guess the reason is that they don't trust themselves to write proper code or they don't trust the Android OS to clean up properly.
Not going through the correct finish procedures will not cause any damage to others than yourself.

Anyone who says you don't need an exit button is right but putting one in never hurts. Users like to see a way to exit to the application, it's not about bad programming, it's actually about proper programming, give the user an exit button and if they never use it great and if it's there even better.

You don't need an exit button in your app. This is how android works. The user is not given any way to actually exit the application.
When you call 'finish', the application stack is just pushed to the background. It still exists in the memory. Android itself decides when to close the application(i.e. remove its instance from the memory) and generally this is done when your application becomes the oldest application which was not used for the longest time.

No, you don't. Read up on the activity lifecycle at developer.android.com
On older versions of android you had to be careful not to accidentally leave a background service running and holding resources but that's been reworked.

Guys you're righteous, but there are some cases when Exit button may have a sense. Let's say you're keeping some application-wide global data in YourApplication class (child of Application), e.g. some sensitive data or so. When user closes final activity and it's destroyed Application won't be terminated. As read Android developer resource - developer should not rely on Application.onTerminate() method. You can easily check it - even in case when all activities closed Application still alive. Whenever Application instance alive it's relatively easy to get access to those object and collect data.
I have found 2 ways how to kill Application class instance:
null'ate all object references (which is hardly possible for large projects) then call garbage collection
call
android.os.Process.killProcess(android.os.Process.myPid());
So Exit button may have function to finish all activities, call garbage collection then call killProcess() - which will guarantee safe removing of global data stored in Application.

I agree with above post by barmaley.
Long story short, you don't need to exit your application if your concerns are related to the Android system itself. Don't worry, be happy. And that applies especially for lazy users (remember the old Symbian days).
However, if you have something in mind about your application itself, then please go ahead and do it. You can finish the activity, nullify and kill. Just be reasonable because, as always, common sense is going to be better than all the tutorials and references in the world.
Anyway, just my 2c.

From a technical perspective, no, you don't need to add a quit button for all the very good reasons listed here.
Unfortunately users aren't informed in this way and regularly drop review scores because they have to 'use a task killer' or 'force close' your app.
It is a regular request and criticism in reviews/feedback for my app. So it may be necessary to appease users.

I think an exit button can provide the user with assurance that your app is closed.
I know, that it still doesn't mean that the app is definitely closed, but if the user feels more in control with an exit button then I say it is a good idea.

When I first started coding for Android, I thought it was a good idea to manually exit my main activity. What I discovered is that closing the activity via stopSelf leads to corrupt instanceState data, which caused a lot of ANRs when the activity was opened again.
The Activity Lifecycle document is information directly from the Google framework engineers. Every word is for a reason.
Consider that garbage collection takes cpu. This may seem trivial, but in designing a framework for a mobile platform, wouldn't you try to cache as much in memory as possible in case it was needed again, as cpu time = battery, and loading from flash is expensive?
GCing an entire app is non-trivial. Especially when the activity might be used repeatedly. The design had to consider all possible use cases. Cacheing makes sense. The system is designed with this principle.
I would say that not following the Activity Lifecycle document is asking for problems.

Some apps alter the configuration of the device while running or consume lots of CPU or data. You may want to give users an option to Exit the app altogether.
There are proper usecases for an Exit button.
For example, an app i made also needs to manage WiFi networks: the device configuration is changed continuously. Terrific and all while app is in active use, in this case a user would expect the behavior to effectively stop after exiting the application.
So my application has an Exit button mainly to cleanup the WiFi configs it created. I could make a button Stop and Cleanup, but no user would understand. They just want to turn the app off, thus Exit.
App running: wifi managed by app.
App exited: diy/android wifi.
Right now, choosing Exit in my application does the cleanup followed by a finish(), but the application itself lingers in the background. Functionally ok but confusing users. I could make a toggle action named "wifi feature on/off" but that wont make things simpler.