Vous pouvez intégrer App Distribution à votre processus de compilation Android à l'aide du plug-in Gradle App Distribution. Le plug-in vous permet de spécifier vos testeurs et les notes de version dans le fichier Gradle de votre application, ce qui vous permet de configurer des distributions pour différents types de compilation et variantes de votre application.
Ce guide explique comment distribuer des APK aux testeurs à l'aide du plug-in Gradle App Distribution.
Avant de commencer
Si ce n'est pas déjà fait, ajoutez Firebase à votre projet Android.
Si vous n'utilisez aucun autre produit Firebase, il vous suffit de créer un projet et d'enregistrer votre application. Toutefois, si vous décidez d'utiliser d'autres produits à l'avenir, veillez à suivre toutes les étapes de la page indiquée ci-dessus.
Ouvrez la page App Distribution de la console Firebase. Sélectionnez votre projet Firebase lorsque vous y êtes invité, sélectionnez votre application à l'aide du sélecteur d'applications, puis cliquez sur Commencer.
Étape 1 : Configurer votre projet Android
Dans votre fichier Gradle au niveau racine (au niveau du projet) (
<project>/build.gradle.ktsou<project>/build.gradle), ajoutez le plug-in Gradle App Distribution en tant que dépendance :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 }
Dans le fichier Gradle de votre module (au niveau de l'application) (généralement
<project>/<app-module>/build.gradle.ktsou<project>/<app-module>/build.gradle), ajoutez le plug-in Gradle App Distribution :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' }
Si vous êtes protégé par un pare-feu ou un proxy d'entreprise, ajoutez la propriété système Java suivante qui permet à App Distribution d'importer vos distributions dans Firebase :
-Djavax.net.ssl.trustStore=/path/to/truststore -Djavax.net.ssl.trustStorePassword=password
Étape 2 : S'authentifier avec Firebase
Avant de pouvoir utiliser le plug-in Gradle, vous devez d'abord vous authentifier auprès de votre projet Firebase de l'une des manières suivantes. Par défaut, le plug-in Gradle recherche les identifiants de la CLI Firebase si aucune autre méthode d'authentification n'est utilisée.
Étape 3 : Configurer les propriétés de votre distribution
Dans le fichier Gradle de votre module (au niveau de l'application) (généralement <project>/<app-module>/build.gradle.kts ou <project>/<app-module>/build.gradle), configurez App Distribution en ajoutant au moins une section firebaseAppDistribution.
Par exemple, pour distribuer la compilation release aux testeurs, suivez ces instructions :
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" } } } // ... }
Vous pouvez configurer App Distribution pour les types de compilation et les types de produit.
Par exemple, pour distribuer des builds debug et release dans les types de produit "demo" et "full", suivez ces instructions :
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" } } } // ... }
Utilisez les paramètres suivants pour configurer la distribution :
| App Distribution Paramètres de compilation | |
|---|---|
appId
|
ID de l'application Firebase de votre application. Obligatoire uniquement si le plug-in Gradle des services Google n'est pas installé. Vous trouverez l'ID d'application dans le fichier appId="1:1234567890:android:321abc456def7890" |
serviceCredentialsFile
|
Chemin d'accès au fichier JSON de la clé privée de votre compte de service. Obligatoire uniquement si vous utilisez l'authentification par compte de service. |
artifactType
|
Spécifie le type de fichier de votre application. Peut être défini sur |
artifactPath
|
Chemin absolu vers le fichier APK ou AAB que vous souhaitez importer. |
releaseNotes ou releaseNotesFile |
Notes de version pour cette compilation. Vous pouvez spécifier les notes de version directement ou indiquer le chemin d'accès à un fichier texte brut. |
testers ou testersFile |
Adresses e-mail des testeurs auxquels vous souhaitez distribuer des builds. Vous pouvez spécifier les testeurs sous la forme d'une liste d'adresses e-mail séparées par une virgule : testers="ali@example.com, bri@example.com, cal@example.com" Vous pouvez également spécifier le chemin d'accès à un fichier contenant une liste d'adresses e-mail séparées par une virgule : testersFile="/path/to/testers.txt" |
groups ou groupsFile |
Les groupes de testeurs auxquels vous souhaitez distribuer des builds (voir Gérer les testeurs).
Les groupes sont spécifiés à l'aide d' Vous pouvez spécifier les groupes sous la forme d'une liste d'alias de groupes séparés par une virgule : groups="qa-team, android-testers" Vous pouvez également spécifier le chemin d'accès à un fichier contenant une liste d'alias de groupe séparés par une virgule : groupsFile="/path/to/tester-groups.txt" |
testDevices ou testDevicesFile |
Les appareils de test sur lesquels vous souhaitez exécuter les tests de l'Agent de test d'application. Vous pouvez spécifier les appareils de test sous la forme d'une liste de spécifications d'appareils séparées par un point-virgule : testDevices="model=shiba,version=34,locale=en,orientation=portrait" Vous pouvez également spécifier le chemin d'accès à un fichier contenant une liste de spécifications d'appareils séparées par des points-virgules : testDevicesFile="/path/to/testDevices.txt" |
testUsername |
Nom d'utilisateur pour la connexion automatique à utiliser lors des tests de l'agent de test d'application. |
testPassword ou testPasswordFile |
Mot de passe de connexion automatique à utiliser lors des tests de l'agent de test d'application. Vous pouvez également spécifier le chemin d'accès à un fichier texte brut contenant un mot de passe : testPasswordFile="/path/to/testPassword.txt" |
testUsernameResource |
Nom de ressource du champ de nom d'utilisateur pour la connexion automatique à utiliser lors des tests de l'agent de test d'application. |
testPasswordResource |
Nom de ressource du champ de mot de passe pour la connexion automatique à utiliser lors des tests de l'agent de test d'application. |
testNonBlocking |
Si cette option est définie lors de l'exécution des tests de l'agent de test d'application, la commande démarre les tests, puis renvoie immédiatement un résultat au lieu d'attendre qu'ils se terminent. Pour consulter les résultats du test, accédez à la console Firebase. Si cette option n'est pas définie, la commande se bloque jusqu'à ce que les tests soient terminés et se ferme avec un code d'échec si l'un des tests échoue. |
resultsBucket
|
Un bucket Google Cloud Storage (GCS) personnalisé dans lequel les résultats des tests sont stockés. Si vous ne renseignez pas ce champ, le bucket par défaut est utilisé. Le bucket doit appartenir à un projet pour lequel la facturation est activée. La spécification d'un bucket entraîne des frais de facturation pour l'espace de stockage utilisé. |
stacktrace
|
Affiche la trace de la pile pour les exceptions utilisateur. Cela est utile pour déboguer les problèmes. |
Étape 4 : Distribuer votre application aux testeurs
Enfin, pour empaqueter votre application de test et inviter des testeurs, créez les cibles
BUILD-VARIANTetappDistributionUploadBUILD-VARIANTavec le wrapper Gradle de votre projet, où BUILD-VARIANT est la version de produit et le type de compilation facultatifs que vous avez configurés à l'étape précédente. Pour en savoir plus sur les types de produits, consultez Configurer des variantes de compilation.Par exemple, pour distribuer votre application à l'aide de la variante de compilation
release, exécutez la commande suivante :./gradlew assembleRelease appDistributionUploadRelease
Si vous vous êtes authentifié avec votre compte Google et que vous n'avez pas fourni d'identifiants dans votre fichier de compilation Gradle, incluez la variable
FIREBASE_TOKEN:export FIREBASE_TOKEN=1/a1b2c3d4e5f67890 ./gradlew --stop // Only needed for environment variable changes ./gradlew assembleRelease appDistributionUploadRelease
Vous pouvez également remplacer les valeurs définies dans votre fichier
build.gradleen transmettant des arguments de ligne de commande sous la forme--<property-name>=<property-value>. Exemple :Pour importer une version de débogage dans App Distribution :
./gradlew bundleDebug appDistributionUploadDebug --artifactType="APK"Pour inviter d'autres testeurs ou supprimer des testeurs existants de votre projet Firebase :
./gradlew appDistributionAddTesters --projectNumber=<project_number> --emails="anothertester@email.com, moretesters@email.com"./gradlew appDistributionRemoveTesters --projectNumber=<project_number> --emails="anothertester@email.com, moretesters@email.com"Une fois qu'un testeur a été ajouté à votre projet Firebase, vous pouvez l'ajouter à des versions individuelles. Les testeurs supprimés n'auront plus accès aux versions de votre projet, mais ils pourront peut-être encore y accéder pendant un certain temps.
Vous pouvez également spécifier des testeurs à l'aide de
--file="/path/to/testers.txt"au lieu de--emails.Les tâches
appDistributionAddTestersetappDistributionRemoveTestersacceptent également les arguments suivants :projectNumber: numéro de votre projet Firebase.serviceCredentialsFile: chemin d'accès au fichier d'identifiants de votre service Google. Il s'agit du même argument que celui utilisé par l'action d'importation.
Le plug-in Gradle génère les liens suivants après l'importation de la version. Ces liens vous aident à gérer les binaires et à vous assurer que les testeurs et les autres développeurs disposent de la bonne version :
firebase_console_uri: lien vers la console Firebase affichant une seule version. Vous pouvez partager ce lien avec d'autres développeurs de votre organisation.testing_uri: lien vers la version dans l'expérience de test (application Android intégrée) qui permet aux testeurs de consulter les notes de version et d'installer l'application sur leur appareil. Le testeur doit avoir accès à la version pour pouvoir utiliser le lien.binary_download_uri: lien signé qui télécharge et installe directement le binaire de l'application (fichier APK ou AAB). Le lien expire au bout d'une heure.
Une fois votre build distribué, il est disponible dans le tableau de bord App Distribution de la console Firebase pendant 150 jours (cinq mois). Trente jours avant l'expiration de la compilation, un avis d'expiration s'affiche à la fois dans la console et dans la liste des compilations de votre testeur sur son appareil de test.
Les testeurs qui n'ont pas été invités à tester l'application reçoivent des invitations par e-mail pour commencer, et les testeurs existants reçoivent des notifications par e-mail indiquant qu'un nouveau build est prêt à être testé (consultez le guide de configuration des testeurs pour savoir comment installer l'application de test). Vous pouvez surveiller l'état de chaque testeur (s'il a accepté l'invitation et s'il a téléchargé l'application) dans la console Firebase.
Les testeurs disposent de 30 jours pour accepter une invitation à tester l'application avant qu'elle n'expire. Lorsqu'une invitation expire dans cinq jours, un avis d'expiration s'affiche dans la console Firebase à côté du testeur d'une version. Vous pouvez renouveler une invitation en la renvoyant à l'aide du menu déroulant de la ligne du testeur.
Étapes suivantes
Implémentez les commentaires dans l'application pour recueillir les commentaires des testeurs sur votre application (y compris les captures d'écran).
Découvrez comment afficher des alertes dans l'application pour vos testeurs lorsque de nouvelles versions de votre application sont disponibles pour l'installation.
Consultez l'atelier de programmation sur les Android App Bundles pour découvrir comment distribuer des versions d'app bundle étape par étape.
Découvrez les bonnes pratiques pour distribuer des applications Android aux testeurs QA à l'aide de la CI/CD.