Mit den optionalen Firebase App Distribution iOS- und Android SDKs können Sie In-App-Benachrichtigungen an Ihre Tester, wenn neue Builds Ihrer App installieren. In diesem Leitfaden wird die Verwendung der App Distribution SDKs für iOS und Android erläutert um neue Build-Benachrichtigungen für Ihre Tester zu erstellen und anzupassen.
Hinweis
Falls noch nicht geschehen, fügen Sie Ihrem Android-Projekt Firebase hinzu.
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 zu Ihrer App hinzufügen
Das Android-SDK App Distribution 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? Beginnend mit der Version Oktober 2023, Sowohl Kotlin- als auch Java-Entwickler können sich auf das Hauptbibliotheksmodul (Details finden Sie in der FAQs 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 App-Update- und Anmeldedialogfeldern, die Testern angezeigt werden.
- Eine erweiterte Benachrichtigungskonfiguration, mit der Sie Ihren eigenen Nutzer anpassen können .
Wenn du das App Distribution Android SDK zum ersten Mal verwendest, empfehlen wir dir, unter Verwendung der Grundkonfiguration.
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. Beim Aufrufen führt die Methode die folgende Sequenz aus:
Prüft, ob ein Tester Warnungen 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 es sich bei dem neuen Build um ein Android-Anwendungspaket (APK) handelt, 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 Benachrichtigungen zum Downloadfortschritt für den Nutzer mit
NotificationManager
. Sie können auch Ihren eigenen Fortschritt hinzufügen Indikator durch Anhängen einesonProgressUpdate
-Handlers an den Aufgabe „updateIfNewReleaseAvailable
“
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. Hier können Sie auswählen,
nur für Tester, 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 über die Anmelde-UI entscheidet, fortzufahren, 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
sind Sie flexibler,
wenn der Tester zum Aktualisieren aufgefordert wird. 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 das Update über Ihre Update-UI durchführt, rufen Sie
updateApp()
:
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 Ihre Implementierung, Verteilung des Builds über die Firebase-Konsole verfügbar.
Besuchen Sie die App Distribution Leitfaden zur Fehlerbehebung , um Hilfe bei häufigen Problemen zu erhalten, wie zum Beispiel:
- Tester erhalten keine In-App-Benachrichtigungen
- Tester werden mehrmals aufgefordert, sich bei Google anzumelden