Crash Reporting in Android

Bug-freie Software gibt es nicht. Wär’ ja auch schlecht für die ganzen Leute, die viel Arbeit in Tools stecken, die allein dazu dienen, App Entwicklern das Leben beim Suchen und Beheben dieser Bugs zu erleichtern. Mit Hilfe solcher Tools wird aus einem “Die App geht nicht!” ein nachvollziehbarer Fehlerbericht, der sehr gezielt bearbeitet werden kann. Ich habe mir 3 der bekanntesten Tools angesehen und werde dir im Folgenden meine Erfahrungen berichten.

crashreporting

Die Tools, um die sich hier alles drehen wird, sind Firebase Crash Reporting, Crashlytics und ACRA. Natürlich gibt es noch andere (z.B.: Hockeyapp, Bugsnag, Apteligent, …), aber die Ausführung all dieser Tools will ich deinem Scroll-Finger nicht antun.

Was wir uns im Folgenden ansehen werden:

– Setup: Wie einfach/schnell ist die Integration in eine App?
– Berichte: Wie sehen die Berichte aus? Sind sie überhaupt hilfreich?
– Vor-/Nachteile der einzelnen Tools

Geht los!

Setup

Wir gehen einfach mal davon aus, es existiert bereits ein Android Projekt, in das die einzelnen Crash Reporting Tools eingebaut werden sollen.

Firebase Crash Reporting

Es gibt die Möglichkeit, dieses Tool manuell zu integrieren, aber wir werden hier auf den absolut einfachsten Weg zurückgreifen:

– In Android Studio rechts oben einloggen
– Tools →  Firebase →  Crash Reporting
– Ein paar Button-Klicks → Fertig

firebase setup

Schon sendet die App automatisch Berichte über unerwartete Fehler ab.
Dauer des Setup Prozesses: 1 Minute (inkl. Kaffeepause). Easy peasy.

Crashlytics (Fabric)

Fabric stellt ebenfalls eine automatisierte Methode zur Verfügung, und zwar mit Hilfe eines Android Studio Plugins welches zuerst installiert werden muss. Für Crashlytics ist die einfachste Methode also:

– Settings → Plugins → Browse repositories → “Fabric” suchen → Installieren
– Plugin öffnen
– Durch die fancy Benutzeroberfläche klicken und Crashlytics installieren

fabric setup

Der Code für die Initialisierung des Tools wird vom Plugin automatisch hinzugefügt, somit schickt auch hier die App ohne weiteres Zutun Fehlerberichte ab.

Dauer des Setup Prozesses: 3 Minuten (Hier ist nicht die längere Kaffeepause schuld, sondern das etwas träge Plugin)

ACRA

Für ACRA gibt es kein Plugin mit dem die Installation automatisch abgewickelt werden kann. Der manuelle Weg ist aber ebenfalls extrem einfach:

– Im build.gradle der App folgendes hinzufügen:

compile 'ch.acra:acra:4.9.0'

– Der App die Internet Berechtigung verleihen:

<uses-permission android:name="android.permission.INTERNET"/>

– Eine Application Klasse im Projekt anlegen und annotieren mit:

@ReportsCrashes(
      formUri = "http://www.backendofyourchoice.com/reportpath"
)

– In der Application Klasse folgende Methode implementieren:

@Override
      protected void attachBaseContext(Context base) {
         super.attachBaseContext(base);
         // The following line triggers the initialization of ACRA
         ACRA.init(this);
      }

Der aufmerksame Leser hat natürlich sofort die Variable in diesem Prozess erkannt: formUri. Damit wird die URL des Servers angegeben, an den die Fehlerberichte geschickt werden sollen. Standardmäßig ist ACRA also an keine Online-Plattform angebunden, darum müssen sich die Entwickler selbst kümmern. Es gibt jedoch zahlreiche Möglichkeiten an eine visuelle Repräsentation der Berichte zu kommen.

Eine Zeit lang gab es die Möglichkeit die Berichte an Google Docs zu schicken, aufgrund der Beliebtheit dieser Lösung und des dadurch entstandenen Traffics hat Google ACRA jedoch gebeten, diese Lösung einzustellen. Es gibt eine offizielle Open-Source Lösung namens Acralyzer, um das Hosting dieses Systems muss man sich selbst kümmern.

Für meine Tests habe ich eine Cloud-Lösung namens Splunk MINT (früher: Bugsense) verwendet. Das Einrichten davon beläuft sich auf:

– Account bei Splunk MINT erstellen
– “add app” links oben klicken und Information ausfüllen
– API-Key kopieren

Um ACRA nun dazu zu bringen seine Berichte an Splunk MINT zu schicken, trägt man als formUri nun ein:

@ReportsCrashes(
      formUri = "http://www.bugsense.com/api/acra?api_key=YOUR_API_KEY"
)

Dauer des Setup Prozesses: 5 Minuten (mit Splunk MINT als Backend)

Berichte

So, die App ist jetzt randvoll mit Crash-Reportern. Wir bauen noch schnell einen Crash-Bug ein, lassen das Ganze ein paarmal abstürzen und werfen einen Blick auf die Berichte.

Firebase Crash Reporting

Hier loggen wir uns auf Firebase ein und wählen das mit der App assoziierte Projekt. Der Menüpunkt Crash-Reporting liefert uns gleich eine gute Übersicht mit den wichtigsten Metriken.

firebase backend

Eine detaillierte Beschreibung der einzelnen Fehler erhält man durch Auswahl in der Liste. Dort werden alle nötigen Zusatzinformationen wie App Version, Android Version, Gerätename, Sprache des Gerätes, (…) angezeigt. Mit diversen Filteroptionen kann man die Ansichten noch auf die gewünschten Kriterien reduzieren. Alles ist sehr übersichtlich gestaltet, sodass man sich auf den ersten Blick gut zurecht findet.

firebase detail

Crashlytics (Fabric)

Die Berichte findet man hier nach dem Einloggen auf Fabric und Auswahl des Projekts unter dem Menüpunkt Crashlytics. Nachdem sich alle Elemente in der Benutzeroberfläche wieder beruhigt haben …

meme

… erhält man wie bei Firebase eine Übersichtsseite mit den nötigsten Informationen.

creashlytics backend

Details gibts wieder nach der Auswahl eines Fehlers in der Liste. Dort sind im Vergleich zu Firebase nicht alle Geräteinformationen inkludiert, diese sind etwas versteckt hinter dem “View all sessions” Button zu finden. Der gesamte Umfang an präsentierten Daten ist aber wie bei Firebase auf jeden Fall mehr als ausreichend.

crashlytics detail

ACRA bzw Splunk MINT

Die Art der Bericht Darstellung ist hier völlig abhängig von der Wahl des Backends an die diese geschickt werden. Splunk MINT stellt die Berichte jedenfalls nach Einloggen auf Splunk MINT, Auswahl des Projektes und der Wahl des “Errors” Menüpunktes ebenfalls in einer Übersicht dar.

splunk backend

Obwohl ACRA jedes kleinste Detail über das Gerät mitschickt, wird in der Detailansicht nur ein kleiner Teil davon dargestellt.

splunk detail

Vor-/Nachteile

Zum Schluss gibt’s noch eine Gegenüberstellung von einigen Vor-/Nachteilen der einzelnen Tools.

Pro Firebase Crash Analytics

– Gratis
– Extrem einfaches Setup
– Kann mit Firebase Analytics verwendet werden, um den Kontext zu den einzelnen Fehlern zu erhalten (!)
– Verschickt Benachrichtigungs-Emails bei neuen Fehlern
– Fehler können als Geschlossen/Bearbeitet markiert werden
– Entwickelt sich zur Zeit stetig um hoch erwünschte Features weiter
– Berichte erscheinen bereits Sekunden nach Auftreten eines Fehlers

Con Firebase Crash Analytics

– Google Play Services müssen am Gerät laufen (vor allem im chinesischen Markt ein Problem)

Pro Crashlytics

– Gratis
– Extrem einfaches Setup
– Super-fancy Benutzeroberfläche im Web
– Verschickt ebenfalls Benachrichtigungs-Emails bei neuen Fehlern
– In der Weboberfläche kann nach Crashes gesucht werden
– Fehler können auch hier als Geschlossen/Bearbeitet markiert und sogar kommentiert werden
– Google Play Services sind kein Muss

Con Crashlytics

– Zukunft unsicher (mehr dazu später)

Pro ACRA

– Gratis + Open-Source
– Eingebauter Support für selbst definierte Nachrichten bei einem unerwarteten App Crash
– Umfangreiche Konfigurationsmöglichkeiten
– Kann mit eigenem Backend betrieben werden
– Open-Source Backend Implementierung ist verfügbar

Con ACRA

– Backend muss selbst gewählt und eventuell aufgesetzt werden

Fazit

Wie bei so vielen Themen gibt es auch bei der Wahl des Crash Reporting Tools keine allgemeingültige Antwort. Welches der drei besprochenen verwendet werden soll, hängt von den jeweiligen Anforderungen ab. Crashlytics wirkt etwas reifer als Firebase Crash Reporting, aber das hat für Firebase eigentlich nur Vorteile, denn Google hat Fabric übernommen. Die von Fabric angebotenen Dienste werden zwar zur Zeit noch weitergeführt, wie’s weitergeht kann man aber nicht genau sagen. Laut Firebase Product Manager Francis Ma scheint es geplant zu sein, dass Crashlytics zum Kern für das Crash Reporting in Firebase wird.

Wenn man für die Zukunft planen will, ist man also eventuell mit Firebase Crash Reporting auf der sicheren Seite, aber das ist reine Spekulation. Wenn das Senden von Daten in einen fremdgeführten Clouddienst ein Problem darstellt, ist man sicher mit ACRA am besten bedient, da man hier selbst bestimmen kann, wohin gesendet wird.