Разница между версиями подписей – V1 (подпись Jar) и V2 (полная подпись APK) при генерации подписанного apk в AndroidStudio?

Это новый механизм подписания, введенный в Android 7.0, с дополнительными функциями, призванными сделать подпись APK более безопасной.

Это не обязательно. Вы должны проверить оба эти флажка, если это возможно, но если новый механизм подписания V2 дает вам проблемы, вы можете его опустить.

Таким образом, вы можете просто оставить V2 непроверенным, если у вас возникнут проблемы, но должны проверить его, если это возможно.

Здесь написано: «По умолчанию Android Studio 2.2 и Android Plugin для Gradle 2.2 подписывают ваше приложение, используя как APK Signature Scheme v2, так и традиционную схему подписания, в которой используется подписка JAR».

Похоже, что эти новые флажки появились с Android 2.3, я понимаю, что мои предыдущие версии Android Studio (по крайней мере, 2.2) подписали оба подписи. Итак, чтобы продолжить, как и раньше, я думаю, что лучше проверить оба флажка.

EDIT 31 марта 2017 года: представил несколько приложений с двумя сигнатурами => без проблем 🙂

Должен ли я использовать (или оба) для подписания apk для выпуска в магазине воспроизведения? Ответ: ДА .

Согласно https://source.android.com/security/apksigning/v2.html#verification :

В Android 7.0 APK можно проверить в соответствии с APK Signature Scheme v2 (схема v2) или JAR-подписью (схема v1). Старые платформы игнорируют подписи v2 и проверяют только сигнатуры v1.

Я попытался создать сборку с проверкой опции V2 (Full Apk Signature) . Затем, когда я попытался установить выпускную версию ниже 7.0, и я не могу установить сборку на устройстве.

После этого я попытался построить, установив флажок в обеих версиях и создав сборку релизов. Затем можно установить сборку.

Я думаю, что это хороший ответ.

Проверка подписей APK v2

1. Найдите блок подписки APK и убедитесь, что: a. Два поля размера блока подписки APK содержат одно и то же значение. б. Записью ZIP Central Directory немедленно следует запись ZIP End of Central Directory. с. У ZIP End of Central Directory больше не будет данных.
2. Найдите первую схему подписки APK v2. Блок внутри блока подписки APK. Если блок v2, если он присутствует, перейдите к шагу 3. В противном случае вернитесь к проверке APK с помощью схемы v1.
3. Для каждого подписчика в APK Signature Scheme v2 Block: a. Выберите наиболее сильный идентификатор алгоритма подписи подписи. Порядок прочности зависит от каждой версии реализации / платформы. б. Проверьте соответствующую подпись от подписей на подписанные данные с помощью открытого ключа. (Теперь можно безопасно разбирать подписанные данные.) C. Убедитесь, что упорядоченный список идентификаторов алгоритма сигнатуры в дайджестах и ​​подписях идентичен. (Это необходимо для предотвращения зачистки / добавления подписи). D. Вычислить дайджест содержимого APK, используя тот же алгоритм дайджеста, что и алгоритм дайджеста, используемый алгоритмом подписи. е. Убедитесь, что вычисленный дайджест идентичен соответствующему дайджесту из дайджеста. е. Убедитесь, что SubjectPublicKeyInfo первого сертификата сертификатов идентичен открытому ключу.
4. Проверка завершается успешно, если был найден хотя бы один подписчик, а шаг 3 – для каждого найденного подписывающего лица.

Примечание. APK не должен проверяться с использованием схемы v1, если сбой происходит на шагах 3 или 4.

JAR-подписанная проверка APK (схема v1)

JAR-подписанный APK является стандартным подписанным JAR, который должен содержать точно записи, перечисленные в META-INF / MANIFEST.MF, и где все записи должны быть подписаны одним и тем же набором подписчиков. Его целостность проверяется следующим образом: 1. Каждый подписыватель представляет собой запись JAR META-INF / .SF и META-INF /. (RSA | DSA | EC). 2. (RSA | DSA | EC) представляет собой PKCS # 7 CMS ContentInfo с структурой SignedData, чья подпись проверяется по файлу .SF. 3. .SF-файл содержит полный файл дайджеста META-INF / MANIFEST.MF и дайджесты каждого раздела META-INF / MANIFEST.MF. Проверяется полный файл файла MANIFEST.MF. Если это не удастся, вместо этого проверяется дайджест каждой секции MANIFEST.MF. 4. META-INF / MANIFEST.MF содержит для каждой записи JAR, защищенной целостностью, соответствующий раздел, содержащий дайджест несжатого содержимого записи. Все эти дайджесты проверены. 5. Проверка APK завершается с ошибкой, если APK содержит записи JAR, которые не указаны в MANIFEST.MF и не являются частью JAR-подписи. Таким образом, цепь защиты (RSA | DSA | EC) -> .SF -> MANIFEST.MF -> содержимое каждой записи JAR, защищенной целостностью.