En bref
Choisissez les bonnes clés de signature Android, enregistrez les certificats SHA-256 supplémentaires et corrigez les messages d’éligibilité ou d’empreinte différente sans exposer vos clés privées.
Pour qui: Responsables release qui rencontrent un message de clé éligible, de clé supplémentaire ou de différence de certificat en enregistrant un package existant.
Étapes de publication
- Recenser l’artefact reçu par les utilisateurs dans chaque canal actif.
- Extraire le SHA-256 public et qualifier la clé : signature d’application, importation, ancienne ou propre au canal.
- Choisir une clé éligible ou lancer l’examen officiel, puis ajouter toute clé légitime qui signe une version distribuée.
- Effectuer la preuve de propriété demandée et recontrôler la paire package-certificat exacte.
Repères
Ne changez pas une clé de production absente d’une liste d’éligibilité. Confirmez l’artefact et le rôle de la clé, préservez la continuité des mises à jour et utilisez la demande ou l’examen officiel.
Conseils détaillés
Enregistrer le certificat qui signe l’application installée
Partez de l’artefact réellement installé. Avec la Signature d’application Play, Google signe les APK livrés avec la clé de signature de l’application ; la clé d’importation authentifie seulement vos envois. Un build web ou un autre store peut employer un autre certificat de production.
Extrayez le SHA-256 de chaque APK distribué et indiquez son canal. Enregistrer un alias de keystore familier ne suffit pas si cette clé ne signe pas l’application installée.
- APK livré par Play : certificat de signature d’application.
- Importation Play : certificat d’importation au rôle distinct.
- Autre canal : inspecter l’APK de production de ce canal.
apksigner verify --print-certs app-release.apkChoisir la clé éligible ou demander un examen
Pour un package existant, la console peut afficher des clés déjà liées à son historique. Choisissez celle qui correspond à la version reçue par les utilisateurs. Si la bonne clé de production n’est pas éligible, vérifiez qu’il ne s’agit pas d’une clé d’importation ou debug, puis utilisez la demande ou l’examen de la console en expliquant l’historique de distribution.
Pour un nouveau package, suivez le parcours actuel et conservez package, certificat et compte développeur dans le même dossier de release. Ne créez pas une clé de remplacement pour la seule faire apparaître dans la liste.
- Comparer les SHA-256, pas les alias.
- Garder les preuves des anciennes releases et des canaux.
- Préserver la clé qui maintient la continuité des mises à jour.
Ajouter chaque clé de distribution légitime
Un package peut avoir plusieurs clés légitimes si différents canaux ou historiques approuvés l’exigent. Ajoutez chaque certificat public par le parcours officiel des clés supplémentaires et associez chaque empreinte à un canal et à un responsable.
Lorsque la console demande une preuve de propriété, signez la preuve avec la clé correspondante. Le parcours peut utiliser un APK signé et adi-registration.properties ; il ne demande jamais d’importer votre clé privée.
- Ajouter uniquement les clés qui signent un artefact réellement distribué.
- Conserver les clés privées dans le système de signature existant.
- Attendre la fin du traitement console avant de recontrôler.
Séparer erreur d’enregistrement et erreur d’importation Play
Une différence d’enregistrement signifie que le package est associé à une autre empreinte. Un App Bundle signé avec la mauvaise clé dans Play concerne la clé d’importation ou la Signature d’application Play. Le package peut être le même, mais les corrections diffèrent.
Utilisez la requête package-certificat pour valider l’enregistrement. Consultez les pages de certificats et l’aide à l’importation Play pour un AAB rejeté. Changer une clé avant d’identifier la couche en échec complique la récupération.
- Enregistrement : package plus certificat public.
- Rejet AAB : certificat d’importation attendu.
- Identité installée depuis Play : certificat de signature d’application.
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
Un package Android peut-il avoir plusieurs clés ?
Oui. Des clés légitimes supplémentaires peuvent être enregistrées pour de vrais canaux ou un historique approuvé. Associez chaque SHA-256 à son artefact et à son canal.
Quelle clé utiliser avec la Signature d’application Play ?
Pour l’identité d’une application livrée par Google Play, utilisez le certificat de signature d’application. Le certificat d’importation authentifie le bundle envoyé et peut être différent.
Que faire si ma clé de production n’est pas éligible ?
Vérifiez d’abord qu’elle signe l’artefact de production installé et qu’il ne s’agit pas d’une clé d’importation ou debug. Utilisez ensuite la demande ou l’examen officiel avec les preuves attendues.
Dois-je importer ma clé privée ?
Non. L’enregistrement utilise l’empreinte du certificat public. La preuve peut exiger un APK signé par la clé correspondante, mais la clé reste dans le keystore ou le service de signature.
Pourquoi Play indique-t-il que mon App Bundle utilise la mauvaise clé ?
Ce message concerne généralement le certificat d’importation attendu par Play, pas le certificat enregistré pour la validation Android. Diagnostiquez-le dans Play Console avant tout changement.
Sources et révision
Dernière révision: