Sie können App Distribution mit dem Gradle-Plug-in App Distribution in Ihren Android-Build-Prozess einbinden. Mit dem Plug-in können Sie Ihre Tester und Versionshinweise in der Gradle-Datei Ihrer App angeben und so die Verteilung für verschiedene Build-Typen und Varianten Ihrer App konfigurieren.
In diesem Leitfaden wird beschrieben, wie Sie APKs mit dem App Distribution-Gradle-Plug-in an Tester verteilen.
Hinweis
Falls noch nicht geschehen, fügen Sie Ihrem Android-Projekt Firebase hinzu.
Wenn Sie keine anderen Firebase-Produkte verwenden, müssen Sie nur ein Projekt erstellen und Ihre App registrieren. Wenn Sie sich jedoch entscheiden, in Zukunft weitere Produkte zu verwenden, müssen Sie alle Schritte auf der oben verlinkten Seite ausführen.
Öffnen Sie die Seite App Distribution der Firebase Console. Wählen Sie Ihr Firebase-Projekt aus, wenn Sie dazu aufgefordert werden, wählen Sie Ihre App über den App-Schnellzugriff aus und klicken Sie auf Jetzt starten.
Schritt 1: Android-Projekt einrichten
Fügen Sie in der Gradle-Datei auf Stammebene (Projektebene) (
<project>/build.gradle.ktsoder<project>/build.gradle) das App Distribution-Gradle-Plug-in als Abhängigkeit hinzu:Kotlin
plugins { // ... id("com.android.application") version "7.3.0" apply false // Make sure that you have the Google services Gradle plugin dependency id("com.google.gms.google-services") version "4.5.0" apply false // Add the dependency for the App Distribution Gradle plugin id("com.google.firebase.appdistribution") version "5.3.0" apply false }
Groovy
plugins { // ... id 'com.android.application' version '7.3.0' apply false // Make sure that you have the Google services Gradle plugin dependency id 'com.google.gms.google-services' version '4.5.0' apply false // Add the dependency for the App Distribution Gradle plugin id 'com.google.firebase.appdistribution' version '5.3.0' apply false }
Fügen Sie in der Gradle-Datei Ihres Moduls (auf App-Ebene) (normalerweise
<project>/<app-module>/build.gradle.ktsoder<project>/<app-module>/build.gradle) das Gradle-Plug-in App Distribution hinzu:Kotlin
plugins { id("com.android.application") // Make sure that you have the Google services Gradle plugin id("com.google.gms.google-services") // Add the App Distribution Gradle plugin id("com.google.firebase.appdistribution") }
Groovy
plugins { id 'com.android.application' // Make sure that you have the Google services Gradle plugin id 'com.google.gms.google-services' // Add the App Distribution Gradle plugin id 'com.google.firebase.appdistribution' }
Wenn sich Ihre Umgebung hinter einem Unternehmensproxy oder einer Firewall befindet, fügen Sie die folgende Java-Systemeigenschaft hinzu, damit App Distribution Ihre Distributionen in Firebase hochladen kann:
-Djavax.net.ssl.trustStore=/path/to/truststore -Djavax.net.ssl.trustStorePassword=password
Schritt 2: Mit Firebase authentifizieren
Bevor Sie das Gradle-Plug-in verwenden können, müssen Sie sich zuerst auf eine der folgenden Arten bei Ihrem Firebase-Projekt authentifizieren. Standardmäßig sucht das Gradle-Plug-in nach Anmeldedaten aus der Firebase-Befehlszeile, wenn keine andere Authentifizierungsmethode verwendet wird.
Schritt 3: Verteilungsattribute konfigurieren
Konfigurieren Sie in der Gradle-Datei Ihres Moduls (auf App-Ebene) (normalerweise <project>/<app-module>/build.gradle.kts oder <project>/<app-module>/build.gradle) App Distribution, indem Sie mindestens einen firebaseAppDistribution-Abschnitt hinzufügen.
So stellen Sie beispielsweise den Build release für Tester bereit:
Kotlin
import com.google.firebase.appdistribution.gradle.firebaseAppDistribution android { // ... buildTypes { getByName("release") { firebaseAppDistribution { artifactType = "APK" releaseNotesFile = "/path/to/releasenotes.txt" testers = "ali@example.com, bri@example.com, cal@example.com" } } } // ... }
Groovy
android { // ... buildTypes { release { firebaseAppDistribution { artifactType="APK" releaseNotesFile="/path/to/releasenotes.txt" testers="ali@example.com, bri@example.com, cal@example.com" } } } // ... }
Sie können App Distribution für Build-Typen und Produktvarianten konfigurieren.
Wenn Sie beispielsweise debug- und release-Builds in den Produktvarianten „demo“ und „full“ bereitstellen möchten, folgen Sie dieser Anleitung:
Kotlin
import com.google.firebase.appdistribution.gradle.firebaseAppDistribution android { // ... buildTypes { getByName("debug") {...} getByName("release") {...} } flavorDimensions += "version" productFlavors { create("demo") { dimension = "version" firebaseAppDistribution { releaseNotes = "Release notes for demo version" testers = "demo@testers.com" } } create("full") { dimension = "version" firebaseAppDistribution { releaseNotes = "Release notes for full version" testers = "full@testers.com" } } } // ... }
Groovy
android { // ... buildTypes { debug {...} release {...} } flavorDimensions "version" productFlavors { demo { dimension "version" firebaseAppDistribution { releaseNotes="Release notes for demo version" testers="demo@testers.com" } } full { dimension "version" firebaseAppDistribution { releaseNotes="Release notes for full version" testers="full@testers.com" } } } // ... }
Verwenden Sie die folgenden Parameter, um die Verteilung zu konfigurieren:
| App Distribution-Build-Parameter | |
|---|---|
appId
|
Die Firebase-App-ID Ihrer App. Nur erforderlich, wenn das Gradle-Plug-in für Google-Dienste nicht installiert ist. Sie finden die App-ID in der Datei appId="1:1234567890:android:321abc456def7890" |
serviceCredentialsFile
|
Der Pfad zur JSON-Datei mit dem privaten Schlüssel Ihres Dienstkontos. Nur erforderlich, wenn Sie die Dienstkontoauthentifizierung verwenden. |
artifactType
|
Gibt den Dateityp Ihrer Anwendung an. Kann auf |
artifactPath
|
Absoluter Pfad zur APK- oder AAB-Datei, die Sie hochladen möchten. |
releaseNotes oder releaseNotesFile |
Versionshinweise für diesen Build. Sie können entweder die Versionshinweise direkt oder den Pfad zu einer Nur-Text-Datei angeben. |
testers oder testersFile |
Die E-Mail-Adressen der Tester, an die du Builds verteilen möchtest. Sie können die Tester als durch Kommas getrennte Liste von E-Mail-Adressen angeben: testers="ali@example.com, bri@example.com, cal@example.com" Alternativ können Sie den Pfad zu einer Datei mit einer durch Kommas getrennten Liste von E-Mail-Adressen angeben: testersFile="/path/to/testers.txt" |
groups oder groupsFile |
Die Testergruppen, an die Sie Builds verteilen möchten (siehe Tester verwalten).
Gruppen werden mit Sie können die Gruppen als durch Kommas getrennte Liste von Gruppen-Aliassen angeben: groups="qa-team, android-testers" Alternativ können Sie den Pfad zu einer Datei angeben, die eine durch Kommas getrennte Liste von Gruppen-Aliassen enthält: groupsFile="/path/to/tester-groups.txt" |
testDevices oder testDevicesFile |
Die Testgeräte, auf denen Sie Tests mit dem KI-Agent zum Testen von Anwendungen ausführen möchten. Sie können die Testgeräte als durch Semikolons getrennte Liste von Gerätespezifikationen angeben: testDevices="model=shiba,version=34,locale=en,orientation=portrait" Alternativ können Sie den Pfad zu einer Datei mit einer durch Semikolons getrennten Liste von Gerätespezifikationen angeben: testDevicesFile="/path/to/testDevices.txt" |
testUsername |
Der Nutzername für die automatische Anmeldung, der bei Tests mit dem KI-Agenten zum Testen von Anwendungen verwendet werden soll. |
testPassword oder testPasswordFile |
Das Passwort für die automatische Anmeldung, das bei Tests mit dem KI-Agenten zum Testen von Anwendungen verwendet werden soll. Alternativ können Sie den Pfad zu einer Nur-Text-Datei mit einem Passwort angeben: testPasswordFile="/path/to/testPassword.txt" |
testUsernameResource |
Ressourcenname für das Feld für den Nutzernamen für die automatische Anmeldung, das bei Tests mit dem KI-Agenten zum Testen von Anwendungen verwendet werden soll. |
testPasswordResource |
Ressourcenname für das Passwortfeld für die automatische Anmeldung, das bei Tests mit dem KI-Agent zum Testen von Anwendungen verwendet werden soll. |
testNonBlocking |
Wenn diese Option beim Ausführen von KI-Agent zum Testen von Anwendungen-Tests festgelegt ist, werden die Tests gestartet und der Befehl wird sofort zurückgegeben, anstatt auf den Abschluss der Tests zu warten. Die Testergebnisse finden Sie in der Firebase Console. Wenn dieses Flag nicht festgelegt ist, wird der Befehl blockiert, bis die Tests abgeschlossen sind. Wenn einer der Tests fehlschlägt, wird der Befehl mit einem Fehlercode beendet. |
resultsBucket
|
Ein benutzerdefinierter Google Cloud Storage-Bucket (GCS), in dem Testergebnisse gespeichert werden. Wenn Sie dieses Feld leer lassen, wird der Standard-Bucket verwendet. Der Bucket muss zu einem Projekt mit aktivierter Abrechnung gehören. Wenn Sie einen Bucket angeben, fallen Abrechnungsgebühren für den verwendeten Speicher an. |
stacktrace
|
Gibt den Stacktrace für Nutzerausnahmen aus. Dies ist hilfreich bei der Fehlerbehebung. |
Schritt 4: App für Tester bereitstellen
Zum Schluss erstellen Sie die Ziele
BUILD-VARIANTundappDistributionUploadBUILD-VARIANTmit dem Gradle-Wrapper Ihres Projekts, um Ihre Test-App zu verpacken und Tester einzuladen. Dabei ist BUILD-VARIANT die optionale Produktvariante und der Build-Typ, die Sie im vorherigen Schritt konfiguriert haben. Weitere Informationen zu Produktvarianten finden Sie unter Build-Varianten konfigurieren.Wenn Sie Ihre App beispielsweise mit der Build-Variante
releasebereitstellen möchten, führen Sie den folgenden Befehl aus:./gradlew assembleRelease appDistributionUploadRelease
Wenn Sie sich mit Ihrem Google-Konto authentifiziert und keine Anmeldedaten in Ihrer Gradle-Build-Datei angegeben haben, fügen Sie die Variable
FIREBASE_TOKENhinzu:export FIREBASE_TOKEN=1/a1b2c3d4e5f67890 ./gradlew --stop // Only needed for environment variable changes ./gradlew assembleRelease appDistributionUploadRelease
Sie können die in der Datei
build.gradlefestgelegten Werte auch überschreiben, indem Sie Befehlszeilenargumente im Format--<property-name>=<property-value>übergeben. Beispiel:So laden Sie einen Debug-Build in App Distribution hoch:
./gradlew bundleDebug appDistributionUploadDebug --artifactType="APK"So laden Sie weitere Tester ein oder entfernen vorhandene Tester aus Ihrem Firebase-Projekt:
./gradlew appDistributionAddTesters --projectNumber=<project_number> --emails="anothertester@email.com, moretesters@email.com"./gradlew appDistributionRemoveTesters --projectNumber=<project_number> --emails="anothertester@email.com, moretesters@email.com"Nachdem ein Tester Ihrem Firebase-Projekt hinzugefügt wurde, können Sie ihn einzelnen Releases hinzufügen. Entfernte Tester haben keinen Zugriff mehr auf Releases in Ihrem Projekt, können aber für einen bestimmten Zeitraum weiterhin auf Ihre Releases zugreifen.
Sie können Tester auch mit
--file="/path/to/testers.txt"anstelle von--emailsangeben.Die Aufgaben
appDistributionAddTestersundappDistributionRemoveTestersakzeptieren auch die folgenden Argumente:projectNumber: Ihre Firebase-Projektnummer.serviceCredentialsFile: Der Pfad zur Datei mit den Google-Dienstanmeldedaten. Dies ist dasselbe Argument, das von der Upload-Aktion verwendet wird.
Das Gradle-Plug-in gibt nach dem Upload des Release die folgenden Links aus. Mit diesen Links können Sie Binärdateien verwalten und dafür sorgen, dass Tester und andere Entwickler die richtige Version haben:
firebase_console_uri: Ein Link zur Firebase-Konsole, in der ein einzelner Release angezeigt wird. Sie können diesen Link mit anderen Entwicklern in Ihrer Organisation teilen.testing_uri: Ein Link zum Release in der Tester-Ansicht (integrierte Android-App), über den Tester die Versionshinweise aufrufen und die App auf ihrem Gerät installieren können. Der Tester benötigt Zugriff auf den Release, um den Link verwenden zu können.binary_download_uri: Ein signierter Link, über den die Binärdatei der App (APK- oder AAB-Datei) direkt heruntergeladen und installiert wird. Der Link läuft nach einer Stunde ab.
Nachdem Sie Ihren Build bereitgestellt haben, ist er 150 Tage (fünf Monate) lang im App Distribution-Dashboard der Firebase-Konsole verfügbar. Wenn der Build in 30 Tagen abläuft, wird sowohl in der Console als auch in der Liste der Builds auf dem Testgerät des Testers ein Ablaufhinweis angezeigt.
Tester, die noch nicht zum Testen der App eingeladen wurden, erhalten eine Einladung per E-Mail, um loszulegen. Bestehende Tester erhalten eine E-Mail-Benachrichtigung, dass ein neuer Build zum Testen bereit ist. Eine Anleitung zum Installieren der Test-App findest du im Leitfaden zur Einrichtung für Tester. In der Firebase Console kannst du den Status der einzelnen Tester im Blick behalten, also ob sie die Einladung angenommen und die App heruntergeladen haben.
Tester haben 30 Tage Zeit, eine Einladung zum Testen der App anzunehmen, bevor sie abläuft. Wenn eine Einladung in 5 Tagen abläuft, wird in der Firebase Console neben dem Tester für einen Release ein Ablaufhinweis angezeigt. Eine Einladung kann erneuert werden, indem sie über das Drop-down-Menü in der Zeile des Testers noch einmal gesendet wird.
Nächste Schritte
Implementieren Sie In-App-Feedback, um Feedback von Testern zu Ihrer App zu erhalten (einschließlich Screenshots).
Hier erfahren Sie, wie Sie Ihren Testern In-App-Benachrichtigungen anzeigen lassen, wenn neue Builds Ihrer App zur Installation verfügbar sind.
Im Codelab zum Android App Bundle finden Sie eine detaillierte Anleitung zum Veröffentlichen von App-Bundle-Releases.
Best Practices für die Bereitstellung von Android-Apps für QA-Tester mit CI/CD