Android-Apps testen

Ein Android-Scan startet Ihre App in einem Emulator in der Cloud und zeichnet auf, was die App an Analyse- und Werbebibliotheken sendet. Mobile Compliance findet den Einwilligungsdialog in der App und testet ihn selbst. Mobile Events spielen eine Journey ab, die Sie in der App aufzeichnen.

Diese Anleitung erklärt, was der Scanner von Ihnen braucht, was er mit der App macht und wo die Grenzen dessen liegen, was er sieht.

Woher der Scanner die App bekommt

Beim Anlegen eines Tests haben Sie zwei Möglichkeiten:

• Google-Play-URL. AnalyticsProof versucht, die App selbst herunterzuladen, und holt vor späteren Scans die aktuelle Version. Schlägt der Download fehl, bietet es stattdessen den Datei-Upload an.
• Datei hochladen. Eine .apk- oder .xapk-Datei bis 200 MB. Der hochgeladene Build wird unverändert gescannt, bis Sie ihn ersetzen. Das passt für einen Build vor dem Release oder eine interne Version, die nicht im Store ist.

Den Paketnamen (zum Beispiel com.example.app) liest der Scanner aus der Datei. Gelingt das nicht, geben Sie ihn manuell ein.

Eine App, die aus mehreren APKs besteht (Split APKs), laden Sie als .xapk hoch, also als ZIP mit allen .apk-Dateien. Der Scanner installiert sie gemeinsam. Andere Dateien im Archiv, etwa OBB-Daten, installiert er nicht. Eine .aab-Datei lässt sich nicht hochladen. Wenn Sie nur ein App Bundle haben, erzeugen Sie daraus mit bundletool ein universelles APK:

bundletool build-apks --bundle=app.aab --output=app.apks --mode=universal
unzip app.apks universal.apk

build-apks erzeugt ein .apks-Archiv; laden Sie die darin enthaltene Datei universal.apk hoch. Ohne --ks signiert bundletool das APK mit dem Debug-Schlüssel aus ~/.android/debug.keystore, sofern die Datei existiert (Android Studio legt sie an). Fehlt sie, bleibt das APK unsigniert und lässt sich nicht installieren; dann brauchen Sie --ks. Der Debug-Schlüssel genügt, solange die App ihre eigene Signatur nicht prüft und keinen Dienst nutzt, der an das Signaturzertifikat gebunden ist, etwa die Anmeldung mit Google oder einen auf Ihre App beschränkten API-Schlüssel. Andernfalls signieren Sie mit Ihrem eigenen Schlüssel: Ergänzen Sie --ks, --ks-key-alias, --ks-pass und --key-pass.

Was der Scanner mit der App macht

Wir installieren die App genau so, wie Sie sie liefern. Wir packen sie nicht neu und signieren sie nicht neu, sie behält also Ihre Originalsignatur.

Vor dem Scan:

1. stellt der Scanner die Bildschirmausrichtung ein, die für den ganzen Scan gilt,
2. installiert er die App,
3. löscht er ihre Daten, sodass sie wie beim ersten Start nach der Installation startet, samt Einwilligungsdialog,
4. schaltet er auf dem Gerät ausführliche Debug-Logs für die Analysebibliotheken ein, die das unterstützen, zum Beispiel Google Analytics for Firebase.

Der Emulator hat das Zertifikat unseres Mess-Proxys unter seinen Systemzertifikaten. Damit kann der Scanner den Verkehr zu ausgewählten Servern lesen, ohne die App zu verändern.

Was der Scanner im Verkehr sieht

Bei jeder Verbindung entscheidet der Scanner anhand des Namens des Servers, mit dem sich die App verbindet.

• Bekannte Analyseserver (zum Beispiel Meta, Adjust, Amplitude, Mixpanel oder Braze): Der Scanner entschlüsselt den Verkehr und sieht einzelne Anfragen, Events und Parameter.
• Google-Server (Firebase, Google Analytics, Google-Werbung, Play): Der Verkehr läuft unverändert durch, der Scanner sieht nur den Servernamen. Den Inhalt der Batches, die Google Analytics for Firebase sendet, also Events, Parameter und Einwilligungssignale, liest er stattdessen aus den Debug-Logs des Geräts.
• Alles andere, etwa Ihr Backend, ein CDN oder der Login: läuft unverändert durch, der Scanner sieht nur den Servernamen. Ihren eigenen Verkehr entschlüsseln wir nicht, Login und APIs funktionieren also wie auf einem normalen Telefon.

Unabhängig vom Verkehr prüft der Scanner auch das App-Paket, alle Split APKs eingeschlossen. So findet er Bibliotheken, die in der App eingebettet sind, auch wenn sie während des Scans nichts gesendet haben.

Apps mit Certificate Pinning

Certificate Pinning entfernen oder umgehen wir nicht, egal ob es in OkHttp, im nativen Code oder in der eigenen Netzwerkkonfiguration der App steckt.

Lehnt die App bei einem bekannten Analyseserver unser Zertifikat ab, lässt der Scanner diesen Server für den Rest des Scans ohne Entschlüsselung durch. Die Verbindung, bei der die App das Zertifikat abgelehnt hat, schlägt fehl; spätere laufen normal. Bei so einem Server sehen Sie, dass sich die App mit ihm verbindet, und wir erkennen das Tool daran. Was genau gesendet wurde, sehen Sie nicht.

Pinning auf Ihrem eigenen Backend hat keinen Einfluss auf das Ergebnis, denn das entschlüsselt der Scanner ohnehin nicht. Die Debug-Logs des Geräts und die Paketprüfung funktionieren mit und ohne Pinning gleich.

Integritätsprüfungen und Emulator-Erkennung

Da wir die App nicht neu signieren, schlägt eine Prüfung der eigenen Signatur nicht unseretwegen fehl. Die App läuft aber in einem Emulator mit Administratorrechten (Root). Apps, die die Geräteintegrität (zum Beispiel über Play Integrity), Root oder einen Emulator prüfen, können deshalb den Start verweigern, Funktionen einschränken oder einen Fehler zeigen.

Erkennt der Scanner in den Geräte-Logs, dass die App eine Integritätsprüfung nicht bestanden oder Root bzw. einen Emulator erkannt hat, oder zeigt die App gar keinen Inhalt, endet der Scan als „Nicht gemessen“. Ein solcher Scan hat keinen Score und fließt nicht in Vergleiche, die Baseline oder Benachrichtigungen ein.

Zum Testen eignet sich daher ein Build, in dem diese Prüfungen abgeschaltet oder gelockert sind, etwa eine interne Testversion. Laden Sie ihn als Datei hoch.

Eine Journey in der App aufzeichnen

Die Journey zeichnen Sie im Dialog „In-App-Journey aufzeichnen“ auf. Die App läuft im Emulator, das Bild wird in Ihren Browser übertragen. Tippen oder wischen Sie auf dem Bildschirm, um Schritte aufzuzeichnen. Die Systemtasten Zurück, Start und Letzte Apps stehen ebenfalls zur Verfügung. Solange die App nicht geladen ist, sind Taps deaktiviert.

Worauf Sie achten sollten:

• Ausrichtung. Hochformat oder Querformat wählen Sie vor der Aufnahme; während der Aufnahme lässt sie sich nicht ändern. Die Wiedergabe läuft in derselben Ausrichtung, weil Schritte Positionen auf dem Bildschirm sind.
• Einwilligung. Die App startet mit gelöschten Daten, Sie sehen den Einwilligungsdialog also wie ein neuer Nutzer. Tippen Sie auf die Auswahl, die Sie testen möchten. Die Wiedergabe wiederholt genau Ihren Tap. Nichts anderes beantwortet den Dialog für Sie.
• Systemberechtigungen. Bei Aufnahme und Wiedergabe erhält die App ihre Berechtigungen im Voraus, Systemabfragen zu Berechtigungen erscheinen also nicht und sollten nicht aufgezeichnet werden.

Bei der Wiedergabe sucht der Scanner das angetippte Element anhand der Bildschirmstruktur. Findet er es nicht, tippt er auf die aufgezeichneten Koordinaten.

Worin sich die Ergebnisse vom Web unterscheiden

• Andere Spuren. Eine App hat keine Cookies und keinen dataLayer. Der Scanner arbeitet mit dem Verkehr, den Debug-Logs des Geräts und dem Inhalt des Pakets.
• Sichtbarkeit pro Server. Den Inhalt von Anfragen sehen Sie nur bei entschlüsselten Servern. Bei den übrigen sehen Sie, dass sich die App mit dem Server verbunden hat.
• Eine andere Tool-Liste. Die Liste der Tools für das Web gilt nicht für Android; die Erkennung in Apps ist separat.
• Schritte nach Bildschirm. Statt CSS-Selektoren sind Schritte Bildschirmelemente und Koordinaten, deshalb ist die Ausrichtung wichtig.
• Land. Das Gerät meldet sich über Sprache, Zeitzone und SIM-Daten im gewählten Land. Beim Aufzeichnen und Abspielen einer Journey täuscht der Scanner keinen GPS-Standort vor.