Ein Großteil der zurzeit verbreiteten Android- Phones läuft noch unter einer älteren Version und stellt somit die Error-Reporting-Funktion

Transkript

1 Ein eigenes für Android implementieren Hurra, ein Fehlerreport! Fehler macht jeder. Wer schlau ist, lässt sich jeden Fehler sofort mit allen Daten servieren, die er für die Fehlerreproduktion benötigt. Dann kann er seine App schnell korrigieren. Tobias Knell Auf einen Blick Wo Computer sind, da treten Fehler auf. Die Gründe für Fehler können in den verschiedenen Konfigurationen und Ausstattungen der Android-Phones liegen oder in der hohen Komplexität der App. Wichtig ist, dass Sie als Entwickler über Fehler möglichst schnell und genau informiert werden. Zu diesem Zweck bauen Sie in diesem Artikel eine einfache, aber effektive -Funktion, die Sie in jede App integrieren können. Plattform Android Inhalte auf beiliegender CD enthalten Anzeige der Fehler im Market (Bild 2) Die Zahl der Android-Phones mit unterschiedlichen Konfigurationen und Ausstattungen steigt stetig. Sie als Entwickler werden kaum all diese Modelle besitzen können, um Ihre App auf jedem Gerät einzeln zu testen. Gerade in diesem Umfeld ist eine gute -Funktion wichtig. Seit Android 2.2 (in einigen Fällen auch seit 2.1) gibt es eine Funktion, die Abstürze von Apps meldet. Dem Benutzer wird beim Absturz der in Bild 1 dargestellte Dialog angezeigt. Wenn er sich dafür entscheidet, das Problem zu melden, kann er anschließend eine zusätzliche Nachricht eingeben, die den Fehler näher beschreibt. Als Entwickler bekommen Sie auf der Developer-Seite im Android Market an Ihren Apps angezeigt, wie viele neue Fehler jeweils berichtet wurden, siehe Bild 2. Sie erhalten folgende Informationen: die Nachricht des Benutzers, den Stacktrace (Bild 3) und die Version der App. Außerdem stellt Google Statistiken bereit, wie oft die Apps abstürzen oder einfrieren, sowohl als Gesamtzahl pro App als auch für die einzelnen Fehler. Das ist alles in allem eine nette Funktion, doch reicht dies bei komplexeren Apps wirklich aus? Und was ist mit Abstürzen bei Versionen unter 2.2? Ein Großteil der zurzeit verbreiteten Android- Phones läuft noch unter einer älteren Version und stellt somit die -Funktion Fehlerdialog in Android 2.2 (Bild 1) überhaupt nicht zur Verfügung. Daher bekommen Sie auch nur einen sehr geringen Teil der Meldungen zu Gesicht und können auf Fehler, die nur bei älteren Versionen auftreten, überhaupt nicht reagieren. Mit etwas Glück werden Ihnen diese Fehler über Kommentare im Market mitgeteilt, wahrscheinlich auch noch mit einer schlechten Bewertung als Anhang. Fazit: Eine eigene Implementierung muss her! Was sollte ein können? Da wären zunächst diejenigen Funktionen, die das native Reporting schon bereitstellt: Der Benutzer wird gefragt, ob er den Bericht senden will. Er kann einen Kommentar eingeben. Stacktrace, Name und Version der App werden gesendet. Die erweiterten Funktionen sollten umfassen: Smartphone-spezifische Informationen wie das Modell und die verwendete Android-Version sollten gesammelt werden. Für besonders kritische Stellen ist es denkbar, auch Werte bestimmter Variablen mitzusenden. Das Wichtigste jedoch ist, dass das unter allen Android-Versionen läuft, Listing 1: Fehler machen auf Befehl <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:gravity="center"> <Button android:id="@+id/crashbutton" android:layout_width="100dp" android:layout_height="100dp" android:text="- CRASH ME -" android:textstyle="bold"/> 42 Mobile Developer Android 1/2011

2 ANDROID oder mindestens ab der Version 1.5, denn Version 1.1 wird kaum noch verwendet (0,1 Prozent Verbreitung). Gesendet wird der Report im JSON-Format per HTTP-POST an einen Server, dessen URL auch konfigurierbar sein soll. Das JSON-Format hält diese Informationen sehr kompakt. Crashtest Um Fehler melden zu können, benötigen Sie zunächst eine Codebasis, die Fehler erzeugt. Zu Demonstrationszwecken wird in diesem Artikel ein simples Android-Projekt namens CrashTest verwendet mit der dazugehörigen Activity CrashTestActivity. Zunächst geht es an das Layout in der main.xml. Dieses hat nur den Zweck, eine Funktion aufzurufen, deshalb reicht ein einfacher Button dafür aus, siehe Listing 1. Verzieren könnte man das Ganze noch mit einem Hintergrundbild für den Button, damit die App nicht so schlicht und leer aussieht, siehe Bild 4. Nun geht es an die Activity, die nichts weiter tun muss, als beim Druck auf den Button eine Exception zu erzeugen, siehe Listing 2. Damit wird der Fehler erzeugt. Nun muss er nur noch abgefangen werden. Das ist einfach: Legen Sie dafür eine neue Klasse an, zum Beispiel MyExceptionHandler. Diese Klasse wird ein Singleton und implementiert Thread.Uncaught- ExceptionHandler, siehe Listing 3. Den Context benötigen Sie, um den Dialog, der bei einer UncaughtException angezeigt werden soll, zu starten. Der URL bestimmt die Zieladresse, an die der Report geschickt wird, und die HashMap speichert die zu versendenden Daten. Als Nächstes kommt die Methode dran, die den ExceptionHandler in der App registriert, siehe Listing 4. Hier wird der Standard-Uncaught- ExceptionHandler durch einen eigenen ersetzt, der alle nicht behandelten Ausnahmen abfangen soll. Wer in bestimmten Fällen auf den Standard zurückgreifen will, sollte sich den DefaultUncaughtExceptionHandler vorher als Member zwischenspeichern. In der CrashTestActivity müssen Sie in der Methode oncreate()folgende Zeile hinzufügen: MyExceptionHandler.get- Instance().register(this, " Um die Exceptions abzufangen, überschreiben Sie die uncaughtexception-methode, in der Sie entscheiden können, was mit der Exception geschehen soll, siehe Listing 5. Bei einer abgefangenen Exception werden die nötigen Daten beschafft, ein Dialog wird gestartet und ihm werden die Daten übergeben. Die Methode put- ExtraValue benötigen Sie, um zum Beispiel Variablenwerte zum Senden hinzuzufügen. In Ihrer App können Sie sich die Instanz des Error- Handlers halten und dieser, wenn nötig, die Werte bestimmter Variablen übermitteln. In der HashMap werden bereits vorhandene Werte überschrieben, sodass immer die aktuellsten Daten übermittelt werden. Listing 2: Einen Fehler erzeugen public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.main); findviewbyid(r.id.crashbutton).setonclicklistener ); (new OnClickListener(){ public void onclick(view v) { new String().charAt(1); Listing 3: Den Fehler abfangen public class MyExceptionHandler implements Thread.UncaughtExceptionHandler { private static MyExceptionHandler instance; private Context context; private String url; private static Map<String, String> values = new HashMap<String, String>(); public static final String STACKTRACE = "stacktrace"; public static final String APPLICATION_NAME = "application_name"; public static final String APPLICATION_VERSION = "application_version"; public static final String ANDROID_VERSION="android_version"; public static final String MODEL = "model"; public static final String URL = "url"; public static final String KEYS = "keys"; public static final String VALUES = "values"; private MyExceptionHandler(){ public static MyExceptionHandler getinstance() {... if (instance == null) { instance = new MyExceptionHandler(); return instance; Listing 4: Den Handler registrieren public void register(context context, String url) { this.context = context; this.url = url; Thread.setDefaultUncaughtExceptionHandler(this); 1/

3 Listing 5: Eine Exception abfangen public void uncaughtexception(thread thread, Throwable ex) { //Den Stacktrace aus der Exception holen StringWriter stacktrace = new StringWriter(); ex.printstacktrace(new PrintWriter(stackTrace)); //Name und Version der App beschaffen PackageManager packagemanager = context.getpackagemanager(); String appname = ""; String version = ""; try { appname = String.valueOf(packageManager.getApplicationInfo (context.getpackagename(),0).loadlabel(packagemanager)); version = packagemanager.getpackageinfo (context.getpackagename(),0).versionname; catch (NameNotFoundException e){ e.printstacktrace(); Intent intent = new Intent(context, ErrorReportDialog.class); //Die zu versendenden Daten der Hashmap hinzufügen values.put(stacktrace, stacktrace.tostring()); values.put(application_name, appname); values.put(application_version, version); values.put(android_version, Build.VERSION.RELEASE); values.put(model, Build.MODEL); // Dem Dialog die benötigten Daten mitgeben intent.putextra(application_name, appname); intent.putextra(url, url); intent.putextra(keys, values.keyset().toarray (new String[values.size()])); intent.putextra(values, values.values().toarray (new String[values.size()])); //Den Dialog starten context.startactivity(intent); //Den Prozess der App beenden Process.killProcess(Process.myPid()); System.exit(10); public void putextravalue(string key, String value) { values.put(key, value); Autor Der Error-Report-Dialog ReportDialog benötigt. Beim Eintragen in die Datei manifest.xml wählen Sie, da es ja schließlich ein Dialog werden soll, das passende Theme dafür aus: <activity android:name = "ErrorReportDialog" android:theme= "@android:style/theme.dialog"/> Der Dialog erklärt dem Benutzer mit einem Text die Situation und enthält außerdem ein Kommentarfeld und zwei Buttons. Mit dem ersten Button kann der Anwender den Error-Report versenden, mit dem zweiten Button kann er den Dialog beenden. Den Titel des Dialogs setzen Sie im Code, da er sich je nach App, in der das benutzt wird, ändert, siehe dazu Listing 6. Das Layout report_dialog.xml könnte ungefähr so aussehen wie in Bild 5 dargestellt. Den Text könnte man natürlich in die strings.xml auslagern, aber für das Beispiel ist das nebensächlich. Nun geht es an die Activity des Dialogs. Diese implementiert das Interface OnClickListener, da Sie für die simplen Funktionen der beiden definierten Buttons keine eigene Klasse benötigen, siehe Listing 7. Wenn der Benutzer den Cancel- Button anklickt, sollte die Activity beendet werden. Anderenfalls werden vor dem Beenden die Daten gesendet und es wird eventuell ein netter Toast angezeigt, um sich beim Benutzer zu bedanken, siehe Listing 8. Die reporterror-methode startet für das Senden einen neuen Thread, um den UI-Thread nicht zu blockieren, siehe Listing 9. Auf diese Weise kann der Benutzer sein Android-Phone sofort weiterbenutzen. Beachten Sie bei Threads, dass der Exception-Handler immer nur per Thread gesetzt wird. Denken Sie also bei jedem neuen Thread daran, den Handler zu registrieren! In diesem Fall würde es jedoch keinen Sinn machen, den Handler im neuen Thread zu registrieren, da sich der Handler bei einem Fehler nur wieder selbst aufrufen würde. Tobias Knell arbeitet als Softwareentwickler bei der Firma Synyx GmbH & Co. KG in Karlsruhe an Webanwendungen und Android-Apps. Der Dialog soll dem Benutzer mitteilen, was bei dem Programm schiefgelaufen ist. Gleichzeitig soll er ihm auch die Möglichkeit geben, den Entwickler von dem Absturz in Kenntnis zu setzen. Wenn der Benutzer darüber hinaus in einer Kommentarbox noch zusätzliche Angaben zum Fehler machen kann, so kann das die Reproduktion dieses Fehlers erleichtern. Wieder wird eine neue Activity Error- Der Stacktrace zum Fehler wird dem Entwickler angezeigt (Bild 3) Den Report versenden Der Dialog ist fertig, es fehlt nur noch die Klasse ErrorSender, die den Fehlerbericht an einen Server sendet. Für das Senden des Reports ist ein kleines, leichtes Format wie JSON hervorragend 44 Mobile Developer Android 1/2011

4 ANDROID Mit dem beschriebenen Ansatz ist es leider nicht möglich, die Fehlermeldung Application not responding (ANR) abzufangen, die auftritt, wenn eine Benutzerinteraktion länger als fünf Sekunden nicht bearbeitet werden Version, das Modell des Geräts und eigene Wer- wichtig sind, wie beispielsweise die Androidkonnte. In diesem Fall wird wie gewohnt der te, wie etwa die Inhalte von Variablen. Darüber Standard-Handler aufgerufen. Ein weiterer hinaus können Sie die Funktionen dieses An- Nachteil besteht darin, dass Sie die Serverseite selbst implementieren müssen und diese Listing 7: Die Activity des Error-Dialogs nicht schon, wie im Android public class ErrorReportDialog extends Activity implements OnClickListener { Market, hübsch aufbereitet zur private String url; Verfügung steht. private String[] keys; Ein Vorteil ist, dass Sie sämtliche Informationen übermit- private EditText reporttext; private String[] values; teln können, die für die Nachvollziehbarkeit von Fehlern geeignet. Die Daten können schnell in einen JSON-String umgewandelt werden und sind aufgrund des geringen Umfangs rasch verschickt, siehe Listing 10. An dieser Stelle soll darauf verzichtet werden, Fehler beim Versenden abzufangen und die Reports für einen erneuten Sendeversuch zu speichern. Wenn Sie diese Funktion selbst ergänzen, dann müssen Sie auf die Menge der gespeicherten Reports achten. Falls der Benutzer längere Zeit keine Verbindung zum Server aufbaut, können sich ziemlich schnell größere Pakete mit Reports ansammeln. Vor- und Nachteile dieses Ansatzes Die CrashTest-App mit Android- Maskottchen als Button (Bild 4) Listing 6: Die Oberfläche für den eigenen Fehlerdialog <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:padding="10dp" android:gravity="center_horizontal"> <TextView android:id="@+id/reporttext" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="an unexpected error has occured and forced the app to close.\n Please help us to fix this error by reporting it." /> <EditText android:id="@+id/comment" android:hint="optional comment" android:lines="2" android:layout_width="fill_parent" android:layout_height="wrap_content" android:layout_margintop="20dp" android:imeoptions="actiondone" /> <LinearLayout android:orientation="horizontal" android:layout_width="fill_parent" android:layout_height="wrap_content" android:gravity="center_horizontal" android:layout_margintop="20dp"> <Button android:id="@+id/cancelbutton" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="cancel" android:layout_weight="1" android:layout_marginright="10dp"/> <Button android:id="@+id/reportbutton" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="report" android:layout_weight="1"/> protected void oncreate(bundle savedinstancestate) {... super.oncreate(savedinstancestate); requestwindowfeature(window.feature_left_icon); setcontentview(r.layout.report_dialog); Intent intent = getintent(); url = intent.getstringextra(myexceptionhandler.url); keys = intent.getstringarrayextra(myexceptionhandler.keys); values = intent.getstringarrayextra(myexceptionhandler.values); settitle(intent.getstringextra(myexceptionhandler.application_name) setfeaturedrawableresource + " has crashed"); (Window.FEATURE_LEFT_ICON,android.R.drawable.ic_dialog_alert); findviewbyid(r.id.cancelbutton).setonclicklistener(this); findviewbyid(r.id.reportbutton).setonclicklistener(this); reporttext = (EditText) findviewbyid(r.id.comment); 1/

5 Listing 8: Ein Toast auf den geduldigen Anwender! public void onclick(view v) { if (v.getid() == R.id.reportButton){ reporterror(); Toast.makeText(this.getApplicationContext(), "Thank you for supporting us!", Toast.LENGTH_SHORT).show(); finish(); Listing 9: Daten für den Error-Report zusammenstellen private void reporterror() { new Thread() { public void run() { //In neuen Threads den Handler erneut registrieren //MyExceptionHandler.getInstance().register (ErrorReportDialog.this," submiterror/"); //Den Benutzer-Kommentar aus dem EditText holen String comment = reporttext.gettext().tostring(); //Und letztendlich den Fehler abschicken ErrorSender.sendError(url, comment, keys, values);.start(); Listing 10: Den Fehlerbericht versenden public class ErrorSender { public static void senderror(string url, String comment, String[] keys, String[] values) { try { //Den JSON-String aus den Daten erstellen JSONObject jsonobj = new JSONObject(); for (int i = 0; i < keys.length; i++) { jsonobj.put(keys[i], values[i]); //Nur ausgefüllte Kommentar hinzufügen if (!comment.equals("")) { jsonobj.put("comment",comment); send(url, jsonobj.tostring()); catch (Exception ex) { ex.printstacktrace(); private static void send(string url, String jsonstring) throws Exception { StringEntity entity; entity = new StringEntity(jsonString); HttpClient client = new DefaultHttpClient(); HttpPost post = new HttpPost(url); post.setentity(entity); client.execute(post); Der selbst gebaute Fehlerdialog (Bild 5) satzes je nach Bedarf anpassen. Dazu zählen verschiedene Anzeigemöglichkeiten bei Abstürzen oder alternative Arten, den Report zu senden. Der vielleicht größte Vorteil des hier vorgestellten Ansatzes besteht jedoch in der hohen Durchdringung. Er unterstützt nämlich anders als bei der nativen Lösung auch Apps, die nicht aus dem Android Market heruntergeladen wurden. Und nicht zuletzt funktioniert diese Lösung für alle Android-Versionen ab 1.5. Andere Lösungen Natürlich gibt es auch schon andere Ansätze, die ein eigenes bereitstellen. Bekannt ist ACRA [1], eine - Bibliothek mit zahlreichen Funktionen. Ihr fehlt allerdings momentan ein direkt angezeigter Fehlerdialog. Das Feedback für den Benutzer wird lediglich über eine Notification realisiert, die den Dialog aufruft. Eine weitere Lösung ist Flurry Analytics [2], eine mächtige Analysebibliothek, mit der man die Möglichkeit hat, alle erdenklichen Informationen über das Benutzerverhalten, aber auch Fehlermeldungen zu sammeln. Sie ist zurzeit kostenlos, kostenpflichtige Leistungen sollen aber folgen. Fazit Der in diesem Artikel vorgestellte Ansatz deckt sicherlich nicht alle Anforderungen an ein ab, er bietet aber die wichtigsten Funktionalitäten in schlanker Form. Der Quelltext der Lösung ist unter der Apache-2.0-Lizenz auf der Heft-CD vorhanden und kann beliebig erweitert werden. [ml] [1] ACRA; [2] Flurry Analytics; 46 Mobile Developer Android 1/2011