On a tous vécu la situation : un APK modifié, téléchargé depuis une source tierce ou recompilé après un changement de ressources, qui refuse de s’installer parce que sa signature est absente ou invalide. Android vérifie systématiquement la signature d’un fichier APK avant toute installation. Sans elle, le système bloque le paquet, point final. Voici comment procéder pour signer ou re-signer un APK proprement, en ligne de commande, sans dépendre d’un IDE.
Zipalign avant signature : l’étape que beaucoup sautent
Quand on re-signe un APK, le réflexe naturel est de foncer sur la commande de signature. Le problème, c’est qu’un APK mal aligné provoque des erreurs silencieuses ou des performances dégradées à l’exécution. L’outil zipalign, fourni avec le SDK Android, réorganise les données non compressées du fichier pour qu’elles tombent sur des frontières de quatre octets.
La règle est simple : zipalign s’exécute avant la signature, jamais après. Si vous signez d’abord puis alignez, la signature est invalidée et l’APK redevient inutilisable. La commande ressemble à ceci :
zipalign -v 4 mon-appli-non-alignee.apk mon-appli-alignee.apk
Le paramètre -v active le mode verbose pour vérifier que l’alignement s’est bien passé. Une fois cette étape franchie, on passe à la génération du keystore si on n’en possède pas déjà un.
Générer un keystore avec keytool pour signer un APK
Un keystore est un conteneur chiffré qui stocke votre clé privée et le certificat associé. Sans lui, aucune signature possible. L’outil keytool, intégré au JDK, permet de le créer en une seule commande :
keytool -genkeypair -v -keystore ma-cle.jks -keyalg RSA -keysize 2048 -validity 10000 -alias mon-alias
Quelques points à garder en tête :
- L’alias identifie la clé dans le keystore. Notez-le quelque part, il sera demandé à chaque signature.
- La validité se compte en jours. Pour une application distribuée sur le long terme, on choisit une durée large.
- Le mot de passe du keystore et celui de la clé peuvent être identiques ou différents. Si vous les perdez, la clé est irrécupérable et vous ne pourrez plus publier de mise à jour sous la même identité.
Pour un APK destiné uniquement à du test ou du sideload personnel, un keystore auto-signé suffit. Pour une publication sur le Play Store, Google gère désormais la clé de signature via Play App Signing, mais le keystore de téléversement reste de votre responsabilité.
Signer un APK avec apksigner : la commande complète
L’outil apksigner, disponible dans les Build-Tools du SDK Android (à partir de la révision 24.0.3), est la méthode recommandée par Google. Il remplace l’ancien jarsigner pour tout ce qui touche aux APK.
La syntaxe de base :
apksigner sign --ks ma-cle.jks --ks-key-alias mon-alias mon-appli-alignee.apk
Le terminal demande le mot de passe du keystore. L’APK est signé sur place (le fichier est modifié directement). Pour vérifier que tout est en ordre :
apksigner verify --verbose mon-appli-alignee.apk
Cette commande affiche les schémas de signature utilisés (v1, v2, v3) et confirme si l’APK passera la vérification sur les différentes versions d’Android.
Pourquoi éviter jarsigner pour les APK récents
jarsigner ne gère que le schéma de signature v1 (basé sur JAR). Les schémas v2 et v3, qui protègent l’intégrité de l’ensemble du fichier et pas seulement des entrées individuelles, ne sont pas pris en charge. Sur les appareils récents, un APK signé uniquement en v1 peut être refusé ou déclencher des avertissements.
Si vous re-signez un APK existant, apksigner applique automatiquement les schémas v2 et v3 en plus de v1, ce qui assure une compatibilité maximale. On n’a aucune raison de revenir à jarsigner sauf contrainte d’outillage très ancienne.
Re-signer un APK déjà signé : supprimer l’ancienne signature
Quand on modifie un APK (ajout de ressources, patch, changement de configuration), la signature d’origine devient invalide. Android refuse l’installation avec une erreur de type INSTALL_PARSE_FAILED_NO_CERTIFICATES ou INSTALL_FAILED_UPDATE_INCOMPATIBLE.
Pour re-signer, il faut d’abord retirer les traces de l’ancienne signature. Concrètement, on supprime le répertoire META-INF/ à l’intérieur de l’APK (qui est un fichier ZIP) :
zip -d mon-appli.apk "META-INF/*"
Ensuite, on reprend la séquence classique : zipalign puis apksigner. L’APK est alors signé avec votre propre clé. Attention : si l’application était déjà installée sur un appareil avec une signature différente, Android bloquera la mise à jour. Il faudra désinstaller l’ancienne version avant d’installer la nouvelle.
Schéma de signature APK v3.2 et vérification post-quantique
Les schémas v1, v2 et v3 couvrent la grande majorité des cas actuels. Android 17 (API 37) introduit un schéma de signature APK v3.2 qui combine une signature classique (RSA ou ECDSA) avec une signature post-quantique basée sur l’algorithme ML-DSA. Les deux signatures coexistent dans le même APK.
Sur Android 17 et au-delà, le système vérifie les deux signatures. Pour les versions antérieures, un bloc v3.0/v3.1 classique est conservé dans l’APK, ce qui assure la compatibilité descendante. En pratique, cela signifie qu’à moyen terme, re-signer un APK pourra nécessiter la gestion d’une clé supplémentaire pour la partie post-quantique.
Les retours varient sur le calendrier exact d’adoption, mais le mécanisme est déjà documenté dans les sources du projet Android Open Source.
Vérification d’identité développeur et sideloading en 2026
Signer un APK ne garantit plus automatiquement qu’il pourra être installé partout. Google déploie progressivement un programme de vérification d’identité développeur (Android Developer Verification Program). À partir du 30 septembre 2026, dans certains pays (Brésil, Indonésie, Singapour, Thaïlande), les appareils Android certifiés pourront bloquer l’installation d’APK provenant de développeurs non vérifiés, même en sideload.
La signature reste techniquement valide, mais si elle ne renvoie pas à une identité développeur enregistrée dans le programme, l’appareil peut refuser le paquet. Pour du déploiement en entreprise ou de la distribution hors Play Store, c’est un changement à anticiper dès maintenant.
La signature d’un APK reste une opération en trois temps (zipalign, keystore, apksigner) qui n’a pas fondamentalement changé depuis plusieurs années. Ce qui évolue, c’est le contexte autour : schémas cryptographiques plus exigeants, vérification d’identité côté Google, restrictions progressives du sideloading. Garder un keystore bien protégé et suivre les mises à jour des Build-Tools du SDK reste le meilleur moyen de ne pas se retrouver bloqué au moment de déployer.
