Internal Testing Track in Google Play: Einrichtung des Tracks

Was ist der Internal Testing Track?

Internal Testing Track ist die erste Testebene in der Google Play Console, die für die Verteilung von Builds innerhalb des Entwicklungsteams konzipiert ist. Hauptziel ist die schnelle Überprüfung der Funktionsfähigkeit, das Testen von Integrationen und die Identifizierung kritischer Fehler vor der Erweiterung der Zielgruppe auf Closed- oder Open-Tracks.

Im Gegensatz zu anderen Google Play-Tracks benötigt Internal Testing keine Google-Prüfung vor der Aktivierung. Der Build steht den Testern innerhalb weniger Minuten nach dem Hochladen in die Konsole zur Verfügung. Dies macht den Track ideal für tägliche Builds (Daily Builds) und die automatische Auslieferung aus der CI/CD-Pipeline.

Laut der Google Play Console-Dokumentation (2024) unterstützt der Internal Testing Track zwei Verteilungsoptionen: E-Mail-Liste (bis zu 100 Teilnehmer) und Google Groups (keine Mengenbegrenzung). Gruppen eignen sich für größere Teams, in denen Mitglieder häufiger wechseln, während E-Mail am besten für einen festen Entwicklerkreis funktioniert.

Wann Sie den Internal Testing Track wählen sollten

Der Internal-Track wird in frühen Entwicklungsphasen gewählt, wenn die App noch instabil ist und APIs sich ändern können. Eine CI/CD-Pipeline lädt jeden neuen Build in den Internal-Track hoch, und das Team erhält sofort die neueste Version. Fehler und Absturzprotokolle werden über die Play Console gesammelt, bevor der Build externe Tester oder Benutzer erreicht.

Für neue Entwicklerkonten dient der Internal Testing Track als erster Schritt zur Vorbereitung der Veröffentlichung. Google prüft Builds in dieser Phase nicht, sodass das Team die Produktqualität selbst überprüfen kann, bevor es sie zur Prüfung einreicht.

So richten Sie den Internal Testing Track in der Google Play Console ein

Die Einrichtung des Internal Testing Track erfolgt in der Google Play Console unter Release > Testing > Internal Testing. Der Prozess umfasst das Erstellen des Tracks, das Hochladen des ersten Builds und das Hinzufügen von Testern.

Um den Track zu erstellen, gehen Sie zum Bereich Internal Testing und klicken Sie auf Create track. Nach der Erstellung des Tracks werden Sie vom System aufgefordert, den ersten Build im AAB-Format (Android App Bundle) hochzuladen. Google empfiehlt AAB für alle Testarten, da das Format die App-Größe entsprechend der Gerätearchitektur optimiert.

Nach dem Hochladen des Builds wird der Zugang zum Track durch Hinzufügen von Testern geöffnet. Ohne mindestens einen Tester gilt der Track nicht als aktiv. Die Google Play Console zeigt den Track-Status, eine Liste der hochgeladenen Builds und Installationsstatistiken für jeden Teilnehmer an.

// build.gradle - Automatischer Upload in den Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

    defaultConfig {
        versionCode versionCode.toInteger()
        versionName versionName
    }
}

// Bereitstellung über das Gradle Play Publisher Plugin
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

play {
    track = "internal"
    serviceAccountCredentials = file("play-account.json")
}

Tester zum Internal-Track hinzufügen

Das Hinzufügen von Testern zum Internal Testing Track ist auf zwei Arten möglich: per E-Mail und über Google Groups. Die E-Mail-Liste eignet sich für kleine Teams mit festem Mitgliederbestand. Jeder Tester wird manuell in der Konsole hinzugefügt und erhält eine Einladung an die angegebene Adresse.

Google Groups sind für Teams mit wechselnder Zusammensetzung oder automatisiertem Zugriffsmanagement zu bevorzugen. Fügen Sie einfach die Gruppe zum Track hinzu, und alle Mitglieder erhalten Zugriff auf die Builds. Eine Änderung der Gruppenzusammensetzung erfolgt ohne Aktualisierung der Einstellungen in der Play Console.

Tester installieren die App über Google Play auf ihrem Gerät. Nach dem Hinzufügen zum Track sehen sie die App als verfügbar für ein Update (wenn sie sie zuvor aus einem anderen Track installiert haben) oder als neue App zur Installation. Builds aus dem Internal-Track werden nicht öffentlich veröffentlicht — nur Track-Teilnehmer können sie sehen.

Metriksammlung im Internal-Track

Google Play sammelt automatisch Android Vitals für alle Builds im Internal Testing Track: Absturzrate, ANR und Startzeit. Der Entwickler sieht die Metriken in der Play Console sofort nach der Installation des Builds durch den ersten Tester. Die Daten sind in Echtzeit ohne Aggregationsverzögerungen verfügbar.

Unterschiede zwischen Internal Testing und Closed/Open Tracks

Internal Testing Track unterscheidet sich von Closed- und Open-Tracks in Zugriffsgeschwindigkeit, Prüfungsanforderungen und Zielgruppengröße. Internal benötigt keine Moderation, Closed erfordert Google Groups-Einrichtung und Prüfung, Open durchläuft eine vollständige Google-Prüfung.

Der Internal-Track ist der einzige, bei dem ein Build ohne Wartezeit verfügbar ist. Closed und Open erfordern eine Google-Prüfung, die zwischen mehreren Stunden und 2 Tagen dauert. Für neue Entwicklerkonten ist der Open Testing Track obligatorisch: Die App muss vor der Veröffentlichung in der Produktion 14 Tage offen getestet werden.

Automatisierung von Internal Testing über CI/CD

Die Automatisierung des Uploads in den Internal Testing Track ist eine Standardpraxis für CI/CD-Pipelines in Android-Projekten. Gradle Play Publisher ist das beliebteste Plugin für die automatische Build-Veröffentlichung. Es signiert das AAB, lädt es in Google Play hoch und weist den Track zu.

Fastlane bietet die supply-Aktion zum Hochladen von Builds in die Play Console. Der Track-Parameter gibt den Zieltrack an: internal, closedalpha, openbeta oder production. Die Versionsverwaltung und das Dienstkonto werden einmalig in der Fastfile konfiguriert.

# Fastfile - Automatisierter Upload in den Internal Testing Track
platform :android do
    desc "Build and deploy to Internal Testing"
    lane :internal do
        gradle(task: "bundleRelease")
        supply(
            track: "internal",
            aab: "app/build/outputs/bundle/release/app-release.aab",
            skip_upload_metadata: true,
            skip_upload_images: true
        )
    end
end

Ein Google Play-Dienstkonto wird in der Google Cloud Console mit der Rolle Publisher erstellt und mit dem Entwicklerkonto in der Play Console verknüpft. Der JSON-Schlüssel des Dienstkontos wird im CI/CD-Repository als geschützte Variable gespeichert (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).