Android Crash Reporting

Absturzursachenforschung

Arne Limburg, Lars Röwekamp


Es gibt wohl nichts, was ein Android-App-Entwickler mehr fürchtet, als die berühmt-berüchtigte Meldung „Tut uns leid! Die Anwendung ... wurde unerwartet beendet. Versuchen Sie es erneut.“ oder auf Englisch: „Sorry! The application ... has stopped unexpectedly. Please try again.“

Seit der Version 2.2 bietet Android neben dem Button Schließen erzwingen (Force Close) einen weiteren Button, um dem Senden eines Berichts an den Play Store zuzustimmen, sofern die App über den Play Store auf dem Gerät installiert wurde. Die Crashs können vom App-Entwickler dann im Developer-Account des Play Store eingesehen werden.

Google legt hier sehr viel Wert auf die Privatsphäre der Nutzer: Vor dem Senden kann der Benutzer entscheiden, ob er Geräte- und Systeminformationen mitsenden möchte. Außerdem kann er optional einen Feedbackkommentar zu dem Problem mitschicken. Leider werden die gesendeten Daten dem App-Entwickler nicht uneingeschränkt zur Verfügung gestellt. Er erhält lediglich den zugehörigen Stacktrace, Informationen und ggf. den Kommentar. Informationen über das Gerät, die verwendete Android-Version, den Mobilfunkanbieter, das Land usw. werden dem App-Entwickler nicht zur Verfügung gestellt, sondern lediglich intern von Google genutzt. Dabei sind gerade diese Informationen häufig wichtig und sinnvoll, um einem Problem, das in der eigenen App existiert, auf die Schliche zu kommen.

Wie kann man als App-Entwickler hier also Abhilfe schaffen? Dazu muss man zunächst wissen, wann eine solche „Force Close“-Situation in Android überhaupt auftritt: Das ist jedes Mal dann der Fall, wenn eine nicht behandelte Exception in der Anwendung auftritt. Die Lösung, um solche Situationen zu vermeiden, ist also, alle Exceptions zu behandeln. Da man sicherlich nicht den gesamten Code mit Try-Catch-Blöcken versehen möchte, muss eine zentrale Lösung her. Diese ist unabhängig von Android bereits im Java-API vorgesehen und funktioniert auch in Android: Die Klasse Thread bietet zwei Methoden, die uns weiterhelfen: setDefaultUncaughtExceptionHandler und setUncaughtExceptionHandler. Beide erwarten als Argument ein Objekt vom Typ Thread.UncaughtExceptionHandler. Um dieses Interface zu implementieren, muss man genau eine Methode überschreiben: void uncaughtException(Thread, Throwable).

Der Unterschied zwischen setDefaultUncaughtExceptionHandler und setUncaughtExceptionHandler ist, dass mit der ersten Methode ein UncaughtExceptionHandler für die gesamte Anwendung registriert werden kann, wohingegen...

Android Crash Reporting

Absturzursachenforschung

Arne Limburg, Lars Röwekamp


Es gibt wohl nichts, was ein Android-App-Entwickler mehr fürchtet, als die berühmt-berüchtigte Meldung „Tut uns leid! Die Anwendung ... wurde unerwartet beendet. Versuchen Sie es erneut.“ oder auf Englisch: „Sorry! The application ... has stopped unexpectedly. Please try again.“

Seit der Version 2.2 bietet Android neben dem Button Schließen erzwingen (Force Close) einen weiteren Button, um dem Senden eines Berichts an den Play Store zuzustimmen, sofern die App über den Play Store auf dem Gerät installiert wurde. Die Crashs können vom App-Entwickler dann im Developer-Account des Play Store eingesehen werden.

Google legt hier sehr viel Wert auf die Privatsphäre der Nutzer: Vor dem Senden kann der Benutzer entscheiden, ob er Geräte- und Systeminformationen mitsenden möchte. Außerdem kann er optional einen Feedbackkommentar zu dem Problem mitschicken. Leider werden die gesendeten Daten dem App-Entwickler nicht uneingeschränkt zur Verfügung gestellt. Er erhält lediglich den zugehörigen Stacktrace, Informationen und ggf. den Kommentar. Informationen über das Gerät, die verwendete Android-Version, den Mobilfunkanbieter, das Land usw. werden dem App-Entwickler nicht zur Verfügung gestellt, sondern lediglich intern von Google genutzt. Dabei sind gerade diese Informationen häufig wichtig und sinnvoll, um einem Problem, das in der eigenen App existiert, auf die Schliche zu kommen.

Wie kann man als App-Entwickler hier also Abhilfe schaffen? Dazu muss man zunächst wissen, wann eine solche „Force Close“-Situation in Android überhaupt auftritt: Das ist jedes Mal dann der Fall, wenn eine nicht behandelte Exception in der Anwendung auftritt. Die Lösung, um solche Situationen zu vermeiden, ist also, alle Exceptions zu behandeln. Da man sicherlich nicht den gesamten Code mit Try-Catch-Blöcken versehen möchte, muss eine zentrale Lösung her. Diese ist unabhängig von Android bereits im Java-API vorgesehen und funktioniert auch in Android: Die Klasse Thread bietet zwei Methoden, die uns weiterhelfen: setDefaultUncaughtExceptionHandler und setUncaughtExceptionHandler. Beide erwarten als Argument ein Objekt vom Typ Thread.UncaughtExceptionHandler. Um dieses Interface zu implementieren, muss man genau eine Methode überschreiben: void uncaughtException(Thread, Throwable).

Der Unterschied zwischen setDefaultUncaughtExceptionHandler und setUncaughtExceptionHandler ist, dass mit der ersten Methode ein UncaughtExceptionHandler für die gesamte Anwendung registriert werden kann, wohingegen...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang