Mit den optionalen Firebase App Distribution iOS- und Android-SDKs können Sie Ihren Testern In-App-Benachrichtigungen anzeigen, wenn neue Builds Ihrer App zur Installation verfügbar sind. In diesem Leitfaden wird beschrieben, wie Sie mit den App Distribution iOS- und Android-SDKs neue Buildbenachrichtigungen für Ihre Tester erstellen und anpassen.
Hinweis
Fügen Sie Ihrem Android-Projekt Firebase hinzu, falls noch nicht geschehen.
Schritt 1: App Distribution Tester API aktivieren
Wählen Sie in der Google Cloud Console Ihr Projekt aus.
Klicken Sie unter „Firebase App Testers API“ auf Aktivieren.
Schritt 2: App Distribution zur App hinzufügen
Das App Distribution Android SDK besteht aus zwei Bibliotheken:
firebase-appdistribution-api
: Die API-Bibliothek, die Sie in alle Buildvarianten einbinden können.firebase-appdistribution
– die vollständige SDK-Implementierung (optional)
Mit der API-Bibliothek kann Ihr Code das SDK aufrufen. Die Aufrufe haben keine Auswirkungen, wenn die vollständige SDK-Implementierung nicht vorhanden ist.
Deklarieren Sie die Abhängigkeit für das App Distribution Android SDK in der Gradle-Datei des Moduls (auf App-Ebene) (in der Regel <project>/<app-module>/build.gradle.kts
oder <project>/<app-module>/build.gradle
). Wenn Sie die Funktion zum automatischen Aktualisieren der vollständigen SDK-Implementierung nicht in Ihre Play-Builds aufnehmen möchten, fügen Sie allen Buildvarianten die Abhängigkeit von der API-Bibliothek hinzu.
Fügen Sie die vollständige SDK-Implementierung nur Varianten hinzu, die ausschließlich für Vorabtests vorgesehen sind.
dependencies {
// ADD the API-only library to all variants
implementation("com.google.firebase:firebase-appdistribution-api:16.0.0-beta14")
// ADD the full SDK implementation to the "beta" variant only (example)
betaImplementation("com.google.firebase:firebase-appdistribution:16.0.0-beta14")
}
Sie suchen nach einem Kotlin-spezifischen Bibliotheksmodul? Ab der Veröffentlichung im Oktober 2023 können sowohl Kotlin- als auch Java-Entwickler das Hauptbibliotheksmodul verwenden. Weitere Informationen finden Sie in den häufig gestellten Fragen zu dieser Initiative.
Schritt 3: In-App-Benachrichtigungen konfigurieren
Mit dem App Distribution Android SDK können Sie In-App-Build-Benachrichtigungen für Ihre Tester auf folgende Arten einrichten:
- Eine grundlegende Benachrichtigungskonfiguration mit vorgefertigten Dialogfeldern für App-Updates und Anmeldungen, die Testern angezeigt werden.
- Eine erweiterte Benachrichtigungskonfiguration, mit der Sie Ihre eigene Benutzeroberfläche anpassen können.
Wenn Sie das App Distribution Android SDK zum ersten Mal verwenden, empfehlen wir die einfache Konfiguration.
Grundlegende Konfiguration
Mit updateIfNewReleaseAvailable
können Sie Testern, die Benachrichtigungen noch nicht aktiviert haben, einen vordefinierten Dialog zum Aktivieren von Benachrichtigungen anzeigen und dann prüfen, ob ein neuer Build verfügbar ist. Bei einem Aufruf führt die Methode die folgende Sequenz aus:
Prüft, ob ein Tester Benachrichtigungen aktiviert hat. Wenn der Tester Benachrichtigungen noch nicht aktiviert hat, wird er aufgefordert, sich mit seinem Google-Konto in App Distribution anzumelden.
Prüft, ob neue Builds verfügbar sind, die der Tester installieren kann.
Es wird eine vordefinierte Benachrichtigung angezeigt, in der der Tester zum Aktualisieren aufgefordert wird.
Wenn es sich bei dem neuen Build um ein Android App Bundle (AAB) handelt, wird der Tester zu Google Play weitergeleitet, um den Aktualisierungsprozess abzuschließen.
Wenn der neue Build ein Android-Anwendungspaket (APK) ist, lädt das SDK den neuen Build im Hintergrund herunter und fordert den Tester auf, ihn zu installieren, sobald der Download abgeschlossen ist. Das SDK sendet dem Nutzer über
NotificationManager
Benachrichtigungen zum Downloadfortschritt. Sie können auch einen eigenen Fortschrittsanzeige hinzufügen, indem Sie derupdateIfNewReleaseAvailable
-Aufgabe einenonProgressUpdate
-Handler zuweisen.
Sie können updateIfNewReleaseAvailable
jederzeit in Ihrer App aufrufen. Sie können updateIfNewReleaseAvailable
beispielsweise während der onResume
-Methode der Hauptaktivität der App aufrufen.
Im folgenden Beispiel wird geprüft, ob der Tester Benachrichtigungen aktiviert hat und Zugriff auf einen neuen Build hat. Wenn diese Bedingungen erfüllt sind, wird ein Dialogfeld angezeigt, wenn der Build zur Installation verfügbar ist:
Kotlin+KTX
// Copy and paste this into any part of your app - for example, in your main
// activity's onResume method.
val firebaseAppDistribution = FirebaseAppDistribution.getInstance()
firebaseAppDistribution.updateIfNewReleaseAvailable()
.addOnProgressListener { updateProgress ->
// (Optional) Implement custom progress updates in addition to
// automatic NotificationManager updates.
}
.addOnFailureListener { e ->
// (Optional) Handle errors.
if (e is FirebaseAppDistributionException) {
when (e.errorCode) {
Status.NOT_IMPLEMENTED -> {
// SDK did nothing. This is expected when building for Play.
}
else -> {
// Handle other errors.
}
}
}
}
Java
// Copy and paste this into any part of your app - for example, in your main
// activity's onResume method.
FirebaseAppDistribution firebaseAppDistribution = FirebaseAppDistribution.getInstance();
firebaseAppDistribution.updateIfNewReleaseAvailable()
.addOnProgressListener(updateProgress -> {
// (Optional) Implement custom progress updates in addition to
// automatic NotificationManager updates.
})
.addOnFailureListener(e -> {
// (Optional) Handle errors.
if (e instanceof FirebaseAppDistributionException) {
switch (((FirebaseAppDistributionException)e).getErrorCode()) {
case NOT_IMPLEMENTED:
// SDK did nothing. This is expected when building for Play.
break;
default:
// Handle other errors.
break;
}
}
});
Erweiterte Konfiguration
Erweiterte Anmeldekonfiguration
Mit den Methoden signInTester
und isTesterSignedIn
können Sie die Anmeldung der Tester flexibler anpassen, damit sie besser zum Erscheinungsbild Ihrer App passt.
Im folgenden Beispiel wird geprüft, ob sich der Tester bereits in seinem App Distribution-Testerkonto angemeldet hat. So können Sie festlegen, dass die Anmeldeoberfläche nur für Tester angezeigt wird, die sich noch nicht angemeldet haben. Nachdem sich der Tester angemeldet hat, können Sie updateIfNewReleaseAvailable
aufrufen, um zu prüfen, ob er Zugriff auf einen neuen Build hat.
Kotlin+KTX
// Only show sign-in UI if this is the "beta" variant (example).
if (BuildConfig.BUILD_TYPE == "beta" && !firebaseAppDistribution.isTesterSignedIn) {
// Start your sign-in UI here.
}
// Only check for updates if the tester is already signed in (do not prompt).
if (firebaseAppDistribution.isTesterSignedIn) {
firebaseAppDistribution.updateIfNewReleaseAvailable().addOnFailureListener {
// Handle failed update.
}
}
Java
// Only show sign-in UI if this is the "beta" variant (example).
if (BuildConfig.BUILD_TYPE == "beta" && !firebaseAppDistribution.isTesterSignedIn()) {
// Start your sign-in UI here.
}
// Only check for updates if the tester is already signed in (do not prompt).
if (firebaseAppDistribution.isTesterSignedIn()) {
firebaseAppDistribution.updateIfNewReleaseAvailable().addOnFailureListener( e -> {
// Handle failed update.
});
}
Wenn der Tester auf Ihrer Anmelde-Benutzeroberfläche fortfahren möchte, rufen Sie signInTester()
auf:
Kotlin+KTX
firebaseAppDistribution.signInTester().addOnSuccessListener {
// Handle successful sign-in.
}.addOnFailureListener {
// Handle failed sign-in.
});
Java
firebaseAppDistribution.signInTester().addOnSuccessListener( unused -> {
// Handle successful sign-in.
}).addOnFailureListener(e -> {
// Handle failed sign-in.
});
Erweiterte Updatekonfiguration
Mit den Methoden checkForNewRelease
und updateApp
können Sie flexibler anpassen, wann Ihre Tester zum Aktualisieren aufgefordert werden. Sie können auch das vordefinierte Update-Dialogfeld und die Download-Fortschrittsanzeige anpassen, damit sie besser zum Erscheinungsbild Ihrer App passen.
Beachten Sie, dass updateApp
keinen Downloadfortschritt anzeigt. Das bedeutet, dass Sie Ihre eigene Fortschrittsanzeige mit NotificationManager
, einer Art In-App-Statusanzeige oder einem anderen Ansatz implementieren müssen.
Im folgenden Beispiel wird geprüft, ob eine neue Version verfügbar ist, und dann eine benutzerdefinierte Benutzeroberfläche angezeigt. Bevor du checkForNewRelease
und updateApp
aufrufst, musst du dich mit der erweiterten Anmeldekonfiguration anmelden.
Kotlin+KTX
firebaseAppDistribution.checkForNewRelease().addOnSuccessListener { release ->
if (release != null) {
// New release available. Start your update UI here.
}
}.addOnFailureListener {
// Handle failed check for new release. Fails with Status#NOT_IMPLEMENTED
// if built for Play.
}
Java
firebaseAppDistribution.checkForNewRelease().addOnSuccessListener(release -> {
if (release != null) {
// New release available. Start your update UI here.
}
}).addOnFailureListener(e -> {
// Handle failed check for new release. Fails with Status#NOT_IMPLEMENTED
// if built for Play.
});
Wenn der Tester über die Update-Benutzeroberfläche mit dem Update fortfahren möchte, rufe updateApp()
auf:
Kotlin+KTX
firebaseAppDistribution.updateApp()
.addOnProgressListener { updateState ->
// Use updateState to show update progress.
}
Java
firebaseAppDistribution.updateApp()
.addOnProgressListener(updateState -> {
// Use updateState to show update progress.
});
Schritt 4: Implementierung erstellen und testen
Erstellen Sie Ihre App und testen Sie die Implementierung, indem Sie den Build über die Firebase-Konsole an Tester verteilen.
Im App DistributionLeitfaden zur Fehlerbehebung finden Sie Hilfe zu häufigen Problemen wie:
- Tester erhalten keine In-App-Benachrichtigungen
- Tester werden mehrmals aufgefordert, sich bei Google anzumelden