Différence entre les versions de signature - V1 (Jar Signature) et V2 (Full APK Signature) lors de la génération d'un APK signé dans Android Studio ?

Question

Veuillez sélectionner au moins une des versions de signature à utiliser dans Android Studio 2.3

Maintenant, lors de la génération d'un APK signé dans Android Studio, il montre deux options (CheckBox) à savoir 1. V1 (Jar Signature) et 2. V2 (Full APK Signature) comme Versions Signature dans la dernière étape du processus de génération d'APK signé.

Alors, quelle est la différence entre V1 (Signature du bocal) y V2 (Signature APK complète) dans la nouvelle mise à jour d'Android Studio ?

Et lequel dois-je utiliser (ou les deux) pour signer l'apk pour la publication sur le play store ?

De plus, j'ai une erreur Echec de l'analyse syntaxique de l'installation Aucun certificat pendant l'installation de l'APK lorsque j'utilise la deuxième option.

Answer 1

Il s'agit d'un nouveau mécanisme de signature introduit dans Android 7.0, avec des fonctionnalités supplémentaires destinées à rendre la signature APK plus sûre.

Ce n'est pas obligatoire. Vous devriez cocher les DEUX cases si possible, mais si le nouveau mécanisme de signature V2 vous pose des problèmes, vous pouvez l'omettre.

Vous pouvez donc laisser V2 décoché si vous rencontrez des problèmes, mais vous devriez le faire vérifier si possible.

MISE À JOUR : Ceci est maintenant obligatoire lorsqu'on vise Android 11.

Answer 2

Dois-je utiliser (ou les deux) pour signer l'apk pour la sortie du play store ? Une réponse est OUI .

Conformément à https://source.Android.com/security/apksigning/v2.html#verification :

Dans Android 7.0, les APK peuvent être vérifiés selon le schéma de signature APK v2 (schéma v2) ou la signature JAR (schéma v1). Les plateformes plus anciennes ignorent les signatures v2 et ne vérifient que les signatures v1.

J'ai essayé de générer la compilation avec la vérification V2(Full Apk Signature) option. Ensuite, lorsque j'ai essayé d'installer une version de la version de base dans la fenêtre suivante 7.0 et je ne parviens pas à installer le build dans l'appareil.

Après cela, j'ai essayé de construire en cochant la case des deux versions et de générer la version de sortie. Puis j'ai pu installer le build.

Answer 3

Il est écrit aquí que "Par défaut, Android Studio 2.2 et le plugin Android pour Gradle 2.2 signent votre application en utilisant à la fois le schéma de signature APK v2 et le schéma de signature traditionnel, qui utilise la signature JAR".

Comme il semble que ces nouvelles cases à cocher soient apparues avec Android 2.3, je comprends que mes versions précédentes d'Android Studio (au moins la 2.2) signaient avec les deux signatures. Donc, pour continuer comme avant, je pense qu'il est préférable de cocher les deux cases.

EDIT 31 mars 2017 : j'ai soumis plusieurs applications avec les deux signatures => pas de problème :)

Answer 4

Selon ce lien : aide à la signature

APK Signature Scheme v2 offre :

1. Des temps d'installation des applications plus rapides
2. Plus de protection contre les modifications non autorisées des fichiers APK.

Android 7.0 introduit le schéma de signature APK v2, un nouveau schéma de signature d'applications. qui accélère l'installation des applications et offre une meilleure protection contre les modifications non autorisées des fichiers APK. Par défaut, Android Studio 2.2 et le Le plugin Android pour Gradle 2.2 signe votre application en utilisant les deux APK Signature Scheme v2 et le schéma de signature traditionnel, qui utilise la signature JAR.

Il est recommandé pour utiliser le schéma de signature APK v2 mais c'est non obligatoire .

Bien que nous recommandions d'appliquer le schéma de signature APK v2 à votre application, ce nouveau schéma n'est pas obligatoire. Si votre application ne se construit pas correctement en utilisant APK Signature Scheme v2, vous pouvez désactiver le nouveau schéma.

Answer 5

Je pense este représente une bonne réponse.

Vérification du schéma de signature APK v2

1. Localisez le APK Signing Block et vérifier que :
   1. Les champs de deux tailles de APK Signing Block contiennent la même valeur.
   2. ZIP Central Directory est immédiatement suivi par ZIP End of Central Directory record.
   3. ZIP End of Central Directory n'est pas suivi d'autres données.
2. Localisez le premier APK Signature Scheme v2 Block à l'intérieur de la APK Signing Block . Si le bloc v2 est présent, passez à l'étape 3. Sinon, revenez à la vérification de l'APK en utilisant le schéma v1.
3. Pour chaque signataire de la APK Signature Scheme v2 Block :
   1. Choisissez l'algorithme de signature ID le plus solide parmi les signatures. L'ordre de force dépend de la version de chaque implémentation/plateforme.
   2. Vérifier la signature correspondante des signatures contre les données signées en utilisant la clé publique. (Il est maintenant sûr d'analyser les données signées).
   3. Vérifier que la liste ordonnée des ID des algorithmes de signature dans les condensés et les signatures est identique. (Ceci afin d'empêcher la suppression/addition de signatures).
   4. Calculer le condensé du contenu de l'APK en utilisant le même algorithme de condensé que celui utilisé par l'algorithme de signature.
   5. Vérifiez que le condensé calculé est identique au condensé correspondant des condensés.
   6. Vérifier que SubjectPublicKeyInfo du premier certificat des certificats est identique à la clé publique.
4. La vérification réussit si au moins un signataire a été trouvé et si l'étape 3 a réussi pour chaque signataire trouvé.

Note : L'APK ne doit pas être vérifié en utilisant le schéma v1 si un échec se produit à l'étape 3 ou 4.

Vérification des APK signés en JAR (schéma v1)

L'APK signé en JAR est un JAR signé standard, qui doit contenir exactement les entrées énumérées dans le tableau suivant META-INF/MANIFEST.MF et où toutes les entrées doivent être signées par le même ensemble de signataires. Son intégrité est vérifiée comme suit :

1. Chaque signataire est représenté par un META-INF/<signer>.SF y META-INF/<signer>.(RSA|DSA|EC) Entrée JAR.
2. <signer>.(RSA|DSA|EC) est un PKCS #7 CMS ContentInfo avec une structure de SignedData dont la signature est vérifiée sur les <signer>.SF fichier.
3. <signer>.SF contient un condensé du fichier entier de l'adresse de l'utilisateur. META-INF/MANIFEST.MF et des résumés de chaque section de META-INF/MANIFEST.MF . Le condensé du fichier entier du MANIFEST.MF est vérifié. Si cela échoue, le condensé de chaque MANIFEST.MF est vérifiée à la place.
4. META-INF/MANIFEST.MF contient, pour chaque entrée JAR à intégrité protégée, une section portant le nom correspondant et contenant le condensé du contenu non compressé de l'entrée. Tous ces condensés sont vérifiés.
5. La vérification de l'APK échoue si l'APK contient des entrées JAR qui ne sont pas répertoriées dans le fichier MANIFEST.MF et ne font pas partie de la signature JAR. La chaîne de protection est donc <signer>.(RSA|DSA|EC) <signer>.SF MANIFEST.MF le contenu de chaque entrée JAR à intégrité protégée.