Intégration au build

Vérifier l’enregistrement d’un package Android avec Gradle

Gradle connaît l’applicationId et la variante de build : c’est le bon endroit pour exporter des entrées fiables. L’appel réseau doit rester une tâche de release et ne pas s’exécuter sur chaque build debug local.

En bref

Créez un contrôle Gradle du package Android qui utilise l’applicationId final et l’identité de l’artefact signé plutôt que des valeurs codées en dur.

Pour qui: Ingénieurs Android qui maintiennent de nombreuses variantes ou plusieurs product flavors.

Étapes de publication

  1. Résoudre applicationId depuis la variante de release sélectionnée.
  2. Lancer le contrôle seulement après la signature de l’artefact de production.
  3. Extraire le SHA-256 du certificat avec les outils de build Android.
  4. Émettre pour la CI un résultat minimal lisible par machine, sans identifiants.

Repères

Source de véritéVariante de release finale
À éviterPackages debug codés en dur
ExécutionContrôle de release, pas chaque build
Point d’attention

Les product flavors et applicationIdSuffix provoquent souvent de faux résultats NOT_REGISTERED.

Conseils détaillés

Résoudre les valeurs de la variante choisie

Un build Android moderne peut comporter plusieurs applicationId et configurations de signature. Reliez une tâche réservée à la release à la variante sélectionnée et à sa sortie signée, au lieu de maintenir une seconde liste d’identités en dur.

Gardez la requête réseau hors des tâches normales de compilation et de test. Exportez package et empreinte dans un petit artefact lisible par machine, puis laissez la CI protégée appeler l’API.

  • Ne pas l’exécuter pour chaque build debug.
  • Ne pas supposer que namespace est égal à applicationId.
  • Ne pas lire une configuration de signature debug pour contrôler une release.
Inspection de l’artefact
./gradlew assembleRelease
apksigner verify --print-certs app/build/outputs/apk/release/app-release.apk

Saisissez le nom de production et, pour contrôler la signature, l’empreinte SHA-256 du certificat de l’APK livré aux utilisateurs. L’API indique l’état d’enregistrement, pas l’approbation du store.

Lancer la vérification →

Questions fréquentes

Pourquoi ne pas appeler l’API depuis chaque build Gradle ?

Cela consomme le quota, ralentit les builds locaux et diffuse les identifiants dans davantage d’environnements. Réservez l’appel à un contrôle de release maîtrisé.

Comment représenter les flavors ?

Utilisez l’applicationId final de la variante et le certificat présent sur son artefact signé.

Sources et révision

Dernière révision: