Develop Reference

Detect app crash in android

I'm building an app that sometimes crashes, I want to know that it crashed in the next time I opened it so I can suggest to the user some post-crash options.
How can I detect the crash?
Also I want to be able to save the user's work before it crashes, I means real time detection of crash, can I do it without knowing where it crashed?

You will need to know where it crashed in order to set the try/catch blocks in the right place to, er, catch the crash and save the data or whatever you have in mind.
This is known as "graceful" termination if you want to consider it in more detail.
Unfortunately neither Java destructor/finalize methods nor lifecycle methods such as onDestroy are anywhere near as robust as try/catch blocks so I'm afraid that is your only option, and how many of us deal with exception prevention. No-one would wittingly provide a user experience that crashes, much less with loss of their data.

Take a took at the ACRA library. You can configure it so whenever a crash happens you can control it and even send the crash log by email

You can use try/catch blocks, then send details on the Exception in your catch.

There are implement UncaughtExceptionHandler as mentioned in these answers and write crash report in some file or use it another way.

ACRA is already mentioned.
However for paid version, I found BugSnag is very good at this.
Or if you want to take the extra mile, try AppSee.
AppSee even has video recording session of how the crash happens. It is from tapping that button on the second list, the menu button or even when the user slides left in your viewpager.

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?

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.

update application state(global variables) from broadcastreceiver

I've been searching and reading and not fond a concise answer that fits what I need so hopefully you guys can point me in the right direction.
I have a simple app which needs to periodically check the web for results. Reading around, it seemed using an AlarmManager was the most appropriate way to schedule an event to happen as opposed to a background service.
The main activity shows the most recent result of the web query, when that query took place, and the next time it's due to re-query.
THe problem I'm having is that I didn't realise the BroadcastReceiver ran in a separate process...when the receiver updates the applications last query result, last check time and next check time, it's obviously not doing it in the copy of the object the app uses ;-) so it looks stale when I open the app...
I've tried Static variables on a StateManager class that are set from the broadcastrecevier and main activity, i've tried specifying the StateManager to be an Application subclass and specifying that as the android:name in the manifest...both seem to end up with distinct copies so the state updated from the broadcastreceiver isn't the state that the app sees.
NOw I'm beginning to understand what's happening...I'm struggling to understand the best way to resolve it.
Using a SQLLite DB to persist state is going to be too mcuh trouble because I want to store an object graph and it appears you can't do that yet (even if SQLLite stores blobs, the android interface doesn't cover it yet ?). I obviously don't want to spend hours on O-R mapping either.
I 'Do' currently raise a notification through the notificationmanager when the web query highlights a need, and that allows me to pass the intent and extras through to the app..so that part works for me...however, when the webquery returns a result that doesn't need notifications generated, I have no 'path' back to the application to give it the next check time, and I dont' want to bring the app forward just for the sake of having a way to pass extras to it.
I guess the crux of the problem is that I want,
from a broadcastrecevier, to persist an object somewhere that my app can retrieve when it's live
or
have a broadcastreceiver perform work within the app process (without bringing the app to the foreground) so that any static variable changes are made to instances that the activity use.
if the best way is to write this as a service, then so be it (if that's the case, before I start coding..does the service run in the same process as the application or will I get similar 'it's not doing what a singleton was supposed to do' problems that I've been having with the broadcastreceiever!)

Seems I'd specified android:process=":remote" in the receiver section of the app manifest. Removing that makes the Alarm run int he apps thread which resolved the issue.

How do I create debug viewer for an Android Application?

I need a starting point to make the following possible.
I have a Main activity start when the Android application starts, as well as an alternate screen that I want to be Debug output (only strings). What I am struggling with is, what layout do I use for the debug screen, and how do I keep this screen constantly populating while I am viewing my Main activity? I do not have any code for this functionality as everything I have tried has crashed my application, so I was hoping to start fresh. I am a super noob to Android so any information would be helpful.
Thanks in advance.
EDIT:
I am sorry, I should have been more specific. I will be receiving Debug information over Bluetooth from a robot. Sensor information, location, possibly a camera feed, etc. At the moment I am looking for a good way to display the Debug information that is Text only. I have a Main Activity that will have the controls of the Robot, and I want to have a second separate screen (that can be switched to from the Options menu) that will have the debug information updated in real time. Don't worry about any of the Bluetooth stuff I can already read and write to the socket. Just the "debug screen"

I would suggest using the log associated with each method, listener, etc. you'd like to keep track of. See here: http://developer.android.com/reference/android/util/Log.html
The TAG identifies the aspect you'd like to track in your logCat:
private static final String TAG = "MyActivity";
Then you simply add the following into your methods, listeners, etc.
Log.v(TAG, insert variables and other info here);
You use your app on the device or emulator normally and filter your logCat output for the items your tracking. You can do it simultaneously or inspect you logcat after you've used the app for a bit.
Hope that helps...

I would use the eclipse debugger. The console output as well as logcat are also very useful for debugging.
If you must create your own debug screen I would create an asynctask that can run in the background. Each time you get output that should go to your debugger I would send it to your asynctask and have the asynctask store it in the database along with a time stamp. Then any time you want to view debug output pull up your custom view that pulls data from your database. You could use a LinearLayout that has 6 textviews. The textviews could display the last 6 messages from your debugger. How you implement the layout is really up to you. Just make sure you persist the debug info in your database rather than in memory or I can almost guarantee some of your debug info will be lost.

After doing some more research I have decided to use a TabActivity instead of trying to do two separate screens. This allows the Tabs to be under 1 Activity and I do not need to worry about inter-Activity communication. Thank you all for you help.