Apps
Crash Reporting in Android
09. Februar 2017
![crash reporting](https://codefluegel.com/wp-content/uploads/2017/02/crash-reporting-1-920x480.png)
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.
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
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
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.
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.
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 …
… erhält man wie bei Firebase eine Übersichtsseite mit den nötigsten Informationen.
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.
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.
Obwohl ACRA jedes kleinste Detail über das Gerät mitschickt, wird in der Detailansicht nur ein kleiner Teil davon dargestellt.
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 man nach Crashes suchen
-
Fehler kann man auch hier als Geschlossen/Bearbeitet markieren und sogar kommentieren
-
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.