Google added crash report feedback for developers !

Hi all,

I was telling it over and over again : crash reports are essential for developers, to make their apps more stable, and user experience more enjoyable.
It looks like google agree with this statement, as they added some crash reports in the developer page :

This is very good news, as it will make the Android platform a better platform to develop on.

How does it work ?
It looks like when a application crashed, the phone let the user send a feedback to the developer( with a custom message from the user, the callstack, and ... ??? ).
I still don't know what is in this feedback - as I got 0 reports - but it definitively looks interesting !
You can also see that is also reports freezes, that user made crash reporters can not intercept !
The developer can then mark a report as 'old' ( so it won't appear again ? ).

For the moment it is still at experimental state. For instance, it looks like you can check feedbacks from other application, but I couldn't get it to work ( having 'server errors' ), and I find it strange for privacy reasons.

This is good to see that Android is going in the right direction !

How to improve your application : a crash reporter to improve stability ( slight return )

Hi all,

For quite some time, I wanted to return on my crash reporter, and on this article here.

Actually, there are two things that I changed for my crash reporter :
* First, I made it more robust, fixing a bug (that I can't understand, by the way) in it.
* Then, I extended the crash reporter so that it can be even more useful to help me ( and you ? ) in the bug hunt...

1) Making the crash reporter more robust :

At the launch of my crash reporter, I was gathering informations on the application environment, to give me more information on the system the bug was happening on.
The code I was using was this one :

void RecoltInformations( Context context )
{
PackageManager pm = context.getPackageManager();
        try
        {
         PackageInfo pi;
            // Version
            pi = pm.getPackageInfo(context.getPackageName(), 0);
            VersionName = pi.versionName;
            // Package name
            PackageName = pi.packageName;
            // Files dir for storing the stack traces
            FilePath = context.getFilesDir().getAbsolutePath();
            // Device model
            PhoneModel = android.os.Build.MODEL;
            // Android version
            AndroidVersion = android.os.Build.VERSION.RELEASE;
        
            Board = android.os.Build.BOARD;
            Brand  = android.os.Build.BRAND;
            //CPU_ABI = android.os.Build.;
            Device  = android.os.Build.DEVICE;
            Display = android.os.Build.DISPLAY;
            FingerPrint = android.os.Build.FINGERPRINT;
         Host = android.os.Build.HOST;
         ID = android.os.Build.ID;
         //Manufacturer = android.os.Build.;
         Model = android.os.Build.MODEL;
         Product = android.os.Build.PRODUCT;
         Tags = android.os.Build.TAGS;
         Time = android.os.Build.TIME;
         Type = android.os.Build.TYPE;
         User = android.os.Build.USER;
        
        }
        catch (NameNotFoundException e)
        {
                e.printStackTrace();
        }
}

And this code was crashing on some phones...
I still can't understand where this code can crash ( if you have some ideas, I would happily hear them ! ), but it is actually quite easy to fix :
* Catching all the exceptions, and incorporating the getPackageManagerPart in the try part so that its eventual failure would be caught.
* Not calling this function at the start of the application, but only when it really is needed : when a bug occcurs. There was really no need to call it before.

With this sole improvement, I could prevent the crash reporter to crash ( having a debug tool that creates bug is a _bad_ thing ), but still, I was receiving bugs with this info :

Informations :
==============

Version : null
Package : null
FilePath : /data/data/com.alocaly.LetterGame/files
Phone Modelnull
Android Version : null
Board : null
Brand : null
Device : null
Display : null
Finger Print : null
Host : null
ID : null
Model : null
Product : null
Tags : null
Time : 0
Type : null
User : null
Total Internal memory : 274464768
Available Internal memory : 209596416

It means, first that this code is no more crashing and then that the code that was crashing was in the very first lines of the function. So thrown by GetPackageManager, GetPackageName or GetPackageInfo. 
But, from the Android documentation, only the NameNotFoundException could be launched by these functions... And it was handled by my previous code !!

Conclusion : I still don't understand what was happening !

2) Extending the crash reporter.

Taking some time to think about this crash reporter, we could wonder what is the primary goal of this tool. The real goal of this tool is to give us more information on the bugs that occured so that we can understand remotely what was really happening.

The callstack is a very valuable piece of information to get, the environment can give you some clues, but this is just not enough. Trying to understand where a bug lay with so few information is very tricky. 
But we can't add more informations, without doing something really specific for one application...

...

And that was the good idea : we obviously need some information specific for the application !!!

The application developer knows what kind of information would help him understand the bugs !

For instance, in my game 'Word Prospector', I finally had some crash in the function that checks whether or not a word is correct. Knowing what this strange-crash-creating-word is would be very valuable information.

So I decided to add in my crash reporter a way to add any informations. I just added a hash map with some Key/Values strings, add some functions to populate the hash map, and display this hash map in the report the crash reporter is creating when a bug occurs.

This was a really good idea ! I could find that this word was starting with a '?' : the user could enter some letters while quitting the pause state, where all the letters are replaced by some question marks...


So now, when there is a suspicious and hard to understand crash, I can had a lot of value to check, release a new version, and wait in front of my mail box !

Here is the new version of the code.
I still init it from the application object, so I initialize it for the whole game with just one call.

public class ErrorReporter implements Thread.UncaughtExceptionHandler
{
String VersionName;
String PackageName;
String FilePath;
String PhoneModel;
String AndroidVersion;
String Board;
String Brand;
String Device;
String Display;
String FingerPrint;
String Host;
String ID;
String Manufacturer;
String Model;
String Product;
String Tags;
long Time;
String Type;
String User;
HashMap CustomParameters = new HashMap< String, String>();

private Thread.UncaughtExceptionHandler PreviousHandler;
private static ErrorReporter S_mInstance;
private Context CurContext;

public void AddCustomData( String Key, String Value )
{
CustomParameters.put( Key, Value );
}

private String CreateCustomInfoString()
{
String CustomInfo = "";
Iterator iterator = CustomParameters.keySet().iterator();
while( iterator.hasNext() )
{
String CurrentKey = iterator.next();
String CurrentVal = CustomParameters.get( CurrentKey );
CustomInfo += CurrentKey + " = " + CurrentVal + "\n";
}
return CustomInfo;
}

static ErrorReporter getInstance()
{
if ( S_mInstance == null )
S_mInstance = new ErrorReporter();
return S_mInstance;
}

public void Init( Context context )
{
PreviousHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler( this );
CurContext = context;
}

public long getAvailableInternalMemorySize() {
        File path = Environment.getDataDirectory();
        StatFs stat = new StatFs(path.getPath());
        long blockSize = stat.getBlockSize();
        long availableBlocks = stat.getAvailableBlocks();
        return availableBlocks * blockSize;
    }
    
    public long getTotalInternalMemorySize() {
        File path = Environment.getDataDirectory();
        StatFs stat = new StatFs(path.getPath());
        long blockSize = stat.getBlockSize();
        long totalBlocks = stat.getBlockCount();
        return totalBlocks * blockSize;
    }

void RecoltInformations( Context context )
{
        try
        {
     PackageManager pm = context.getPackageManager();
         PackageInfo pi;
            // Version
            pi = pm.getPackageInfo(context.getPackageName(), 0);
            VersionName = pi.versionName;
            // Package name
            PackageName = pi.packageName;
            // Device model
            PhoneModel = android.os.Build.MODEL;
            // Android version
            AndroidVersion = android.os.Build.VERSION.RELEASE;
          
            Board = android.os.Build.BOARD;
            Brand  = android.os.Build.BRAND;
            Device  = android.os.Build.DEVICE;
            Display = android.os.Build.DISPLAY;
            FingerPrint = android.os.Build.FINGERPRINT;
         Host = android.os.Build.HOST;
         ID = android.os.Build.ID;
         Model = android.os.Build.MODEL;
         Product = android.os.Build.PRODUCT;
         Tags = android.os.Build.TAGS;
         Time = android.os.Build.TIME;
         Type = android.os.Build.TYPE;
         User = android.os.Build.USER;
          
        }
        catch( Exception e )
        {
         e.printStackTrace();
        }
}

public String CreateInformationString()
{
RecoltInformations( CurContext );

String ReturnVal = "";
ReturnVal += "Version : " + VersionName;
ReturnVal += "\n";
ReturnVal += "Package : " + PackageName;
ReturnVal += "\n";
ReturnVal += "FilePath : " + FilePath;
ReturnVal += "\n";
ReturnVal += "Phone Model" + PhoneModel;
ReturnVal += "\n";
ReturnVal += "Android Version : " + AndroidVersion;
ReturnVal += "\n";
ReturnVal += "Board : " + Board;
ReturnVal += "\n";
ReturnVal += "Brand : " + Brand;
ReturnVal += "\n";
ReturnVal += "Device : " + Device;
ReturnVal += "\n";
ReturnVal += "Display : " + Display;
ReturnVal += "\n";
ReturnVal += "Finger Print : " + FingerPrint;
ReturnVal += "\n";
ReturnVal += "Host : " + Host;
ReturnVal += "\n";
ReturnVal += "ID : " + ID;
ReturnVal += "\n";
ReturnVal += "Model : " + Model;
ReturnVal += "\n";
ReturnVal += "Product : " + Product;
ReturnVal += "\n";
ReturnVal += "Tags : " + Tags;
ReturnVal += "\n";
ReturnVal += "Time : " + Time;
ReturnVal += "\n";
ReturnVal += "Type : " + Type;
ReturnVal += "\n";
ReturnVal += "User : " + User;
ReturnVal += "\n";
ReturnVal += "Total Internal memory : " + getTotalInternalMemorySize();
ReturnVal += "\n";
ReturnVal += "Available Internal memory : " + getAvailableInternalMemorySize();
ReturnVal += "\n";

return ReturnVal;
}

public void uncaughtException(Thread t, Throwable e)
{
String Report = "";
Date CurDate = new Date();
Report += "Error Report collected on : " + CurDate.toString();
Report += "\n";
Report += "\n";
Report += "Informations :";
Report += "\n";
Report += "==============";
Report += "\n";
Report += "\n";
Report += CreateInformationString();

Report += "Custom Informations :\n";
Report += "=====================\n";
Report += CreateCustomInfoString();

Report += "\n\n";
Report += "Stack : \n";
Report += "======= \n";
final Writer result = new StringWriter();
final PrintWriter printWriter = new PrintWriter(result);
e.printStackTrace(printWriter);
String stacktrace = result.toString();
Report += stacktrace;

Report += "\n";
Report += "Cause : \n";
Report += "======= \n";

// If the exception was thrown in a background thread inside
// AsyncTask, then the actual exception can be found with getCause
Throwable cause = e.getCause();
while (cause != null)
{
cause.printStackTrace( printWriter );
Report += result.toString();
cause = cause.getCause();
}
printWriter.close();
Report += "****  End of current Report ***";
SaveAsFile(Report);
//SendErrorMail( Report );
PreviousHandler.uncaughtException(t, e);
}

private void SendErrorMail( Context _context, String ErrorContent )
{
Intent sendIntent = new Intent(Intent.ACTION_SEND);
String subject = _context.getResources().getString( R.string.CrashReport_MailSubject );
String body = _context.getResources().getString( R.string.CrashReport_MailBody ) +
"\n\n"+
ErrorContent+
"\n\n";
sendIntent.putExtra(Intent.EXTRA_EMAIL,
new String[] {"postmaster@alocaly.com"});
sendIntent.putExtra(Intent.EXTRA_TEXT, body);
sendIntent.putExtra(Intent.EXTRA_SUBJECT, subject);
sendIntent.setType("message/rfc822");
_context.startActivity( Intent.createChooser(sendIntent, "Title:") );
}
private void SaveAsFile( String ErrorContent )
{
try
{
Random generator = new Random();
int random = generator.nextInt(99999);
String FileName = "stack-" + random + ".stacktrace";
FileOutputStream trace = CurContext.openFileOutput( FileName, Context.MODE_PRIVATE);
trace.write(ErrorContent.getBytes());
trace.close();
}
catch( Exception e )
{
// ...
}
}

private String[] GetErrorFileList()
{
File dir = new File( FilePath + "/");
        // Try to create the files folder if it doesn't exist
        dir.mkdir();
        // Filter for ".stacktrace" files
        FilenameFilter filter = new FilenameFilter() {
                public boolean accept(File dir, String name) {
                        return name.endsWith(".stacktrace");
                }
        };
        return dir.list(filter);
}
private boolean bIsThereAnyErrorFile()
{
return GetErrorFileList().length > 0;
}
public void CheckErrorAndSendMail(Context _context )
{
try
{
FilePath = _context.getFilesDir().getAbsolutePath();
if ( bIsThereAnyErrorFile() )
{
String WholeErrorText = "";
// on limite à N le nombre d'envois de rapports ( car trop lent )
String[] ErrorFileList = GetErrorFileList();
int curIndex = 0;
final int MaxSendMail = 5;
for ( String curString : ErrorFileList )
{
if ( curIndex++ <= MaxSendMail )
{
WholeErrorText+="New Trace collected :\n";
WholeErrorText+="=====================\n ";
String filePath = FilePath + "/" + curString;
BufferedReader input =  new BufferedReader(new FileReader(filePath));
String line;
while (( line = input.readLine()) != null)
{
WholeErrorText += line + "\n";
}
input.close();
}

// DELETE FILES !!!!
File curFile = new File( FilePath + "/" + curString );
curFile.delete();
}
SendErrorMail( _context , WholeErrorText );
}
}
catch( Exception e )
{
e.printStackTrace();
}
}
}

Enjoy it !!


NOTE : I'm no more using this mail technic. Now I'm using ACRA, and the results are much more interesting !! See here for more info.


Ps : here is a link I found while googling :
http://web-authoring.seadvd.com/whats-google-up-to-with-android/
:)

Google really takes care of developers !

Google really want developers to be able to develop in the best conditions !

15 days ago, I was in Montreal for my real job...
So I missed the Android Developer Lab in Paris ... and the Nexus One that was given to every attendant !
Then there was an Android Developer Lab during the MWC, in Barcelona... with a new Nexus One distribution...
There will also be a phone distribution at the Game Developer Conference.

And now, I've just received this email :
"Due to your contribution to the success of Android Market, we would like to present you with a brand new Android device as part of our developer device seeding program. You are receiving this message because you're one of the top developers in Android Market with one or more of your applications having a 3.5 star or higher rating and more than 5,000 unique downloads. "

That is really nice !

Actually, I think Google is doing the righ thing... Not only by giving ME a new phone, but by taking care of developers.

The iPhone success has several reasons.
For sure, the phone was really nice, and came with an interface never seen before... But the most important thing, in my opinion, is that they let any developer develop an application for the iPhone. This is why there are so many application on the iPhone, this is why there are so many good applications on the iPhone, so many new little ideas that make the phone really different...
This is such a big thing that this is what they based their ad campaign on !

Archos understood the importance of developers too, by offering a substancial reduction on their android tablet to developers.
And now Google decided to follow the same way.

This is good for developers, this is a good sign for Android - showing how much Google really involves in Android -, this is good for customers...

Thank you, google !!

IMPORTANT UPDATE :
I received this email at 1.00 AM, the email was coming from Eric Chu, who always send us developers mails about Android updates, so I didn't even ask myself about the mail validity.
And this morning, a lot of people were wondering whether it is a fake or a real mail :
The registration form this mail send to us is hosted on Google Site, the google free hosting service, and it's basically filling a document on google docs. So it really could be a Fake mail, trying to collect some 'Google Order Number' ( Can we do something harmful with it ? )

But it now has been validated by google, by several means, including a post by Roman Nurk, whose title is "Android Developer Relations" in this google group :
http://groups.google.com/group/android-developers/browse_thread/thread/49da01a3cb7f8803

Conclusion : you really can trust this mail....

Who said an Android phone should fit in your pocket ?

The iPad looks like 'just' a bigger iPhone, but there is already 'just' a bigger Android phone :

By the way, speaking of the iPad, I have a hard time thinking Apple wants to make it the best Internet device, WITHOUT Flash !!
And it looks like, from the Adobe blog, flash is still not coming in Apple's World ( link to the blog article )

Discovering Flurry

First, I just want to point that I'm not in any way affiliated with Flurry, and blablahbla.... :
NO I DON'T KNOW THOSE GUYS... I just tried their tool !!


What is Flurry ?
When you launch a new application, it's always great to have some feedbacks on it.
There are many different feedbacks : error reports, user evaluations, user mails, online scores, or... 'some' statistics.
It's useful for two different things :
* for your ego, it's always a good thing to have some feedback that basically says that people are trying your application. It's even better if they say they like it ! Even if you don't have the super-developed ego that most developers have, having this kind of information is good for motivation, and helps you improve your application ! As strange as this point may sound, I think it is really important specially if you are an independant developer, as you will need some motivation !
* It's  also crucial if you want to know who your application users are, and how they use it ! It will let you analyse what is good in your application, what are the weaknesses, where to put your efforts in order to satisfy your users...

As I had embedded AdMob ( the now famous ads provider for Android ), I already had some sort of feedback for a while : the number of ads impression for every day. It gives me an indication on how many users are playing my game, and on how this number is evolving.

Flurry ( actually Flurry Analytics ) gives you a lot more statistics on the users and on how they use your application.

How to integrate Flurry ?
The integration of Flurry is really easy.
Create an account on their web site, register your application, add the jar in your application, and copy paste some code on each activity, and voilà ! your first integration is done !!
I also added some special events, in order to know which activity was started, and which game mode was used ( the game has 6 different game modes ).
This is a very good point with this middleware !!


What indications Flurry provides you ?

Flurry provides you informations on :
* users : how many users you have, whether they keep on using your application, how many times did they use it every day, how many sessions you have, how long is a session, and where do they come from.
* Technical : info on which phone was used, which carrier, which firmware, and a simple error reporter is provided ( that does not seem to interfere with mine !! )
* Events : Events are special signals you put in your applications and that are collected by Flurry. You basically do whatever you want with them !

By the way, the information is nicely presented, with some beautiful graphes that make it easy to get the information quickly !


How useful is this information ?

To be honest, I'm kind of fascinated by all this feedback !
All of it is not useful, but it's really interesting to navigate throw this pages and graphes on my game !

In the user pages, you can see the evolution of the way your application is used : if it keeps on increasing.
For instance, I really did see the Chrismas effect : the number of new users has really increased after the 25 !

Welcome to all of those new Android Owners !!



The technical part is also really interesting :
* The firmware versions are divided in about one big third Android 1.5, another third Android 2.0.1, and another little third is Android 1.6...
The rest ( yes, the rest after the 3 thirds... ) is Android 2.0 and Android 2.1. That means that if you want to bypass one of this Android version, you are limiting your audience in large proportions !

* The devices : The droid is the big winner here, with about 1/3 of the devices used. Then the HTC Hero / Eris, the HTC G1/Dream and the MyTouch/Magic...
We can observe that the french version of my game, obviously mainly played in France shows a very different picture :

 

WordProspector version ( essentially played in the US )

"Chasseur de mots" ( the french version, essentially played in France )


We can see that Samsung - that had shipped the Galaxy a long time ago in France - is much more present, and that Motorola is surprisingly unpresent !
Another funny thing : in the french version there is a ... BlackBerry 8230 : I guess someone played with home-made OS and changed the Phone_Model string !

Last point : the events
The events can clearly be the most important point in Flurry if you use them wisely.
If you want to know something specific on how your users are using your application, Events are for you !
For instance, in my game, I registered which game mode the player were playing.
Personally, I always play the game in Full Game mode, 1 minute, but I discovered that  most people played in 'simple mode', for 1 minute.

Conclusion :
Clearly, users want some quick game : both 'simple game' and 'full game' are played.
And the 2 minutes and 3 minutes games are far from being negligeable ( at that point, I was still wondering if I had developed that for more than 3 users :)


Conclusion : was it worth it ?

First, I want to point that, obviously, Flurry your application to open network and localization authorizations. I don't think it is a real issue ( and in my case, I already needed these authorizations for AdMob), but it may be something that you don't want.

If you don't mind opening these authorization, and don't have any other way to get feedbacks, I think Flurry is really a choice to consider.
It's so simple to use and gives you lot of information.
Now I regret that it is not more flexible with the information it gives. I would like to have a way to create my own requests. For instance, I would like to know how the firmwares are distributed on the G1, but you don't have that much freedom ( even if there are a lot of information already available ).
A custom system done by myself would be more flexible. But, let's be honest : I won't invest time enough  to have something as elaborate as their tool ! ( not to mention the fact that I don't know how to present the data in such a nice way ).