Android Studio предоставляет широкие возможности как для разработки приложений, так и для повышения автоматизации и комфортности при программировании.
Если вы используете систему сборки Gradle для создания своих приложений, то вы можете также настроить несколько параметров для создания подписей к вашим приложениям.
Скорее всего, вам не хочется публиковать свои ключи для подписи, пароли и имена пользователей в публичном (или даже частном) репозитории. Поэтому вы можете определить ключ, пароль и имя пользователя как свойства в отдельном файле.
Перед тем, как начать подписание приложения, вам необходимо в файле gradle.properties создать новое свойство. Назовём его Keys.repo и, в качестве значения, укажем путь до папки, где впоследствии будут находиться хранилище ключей и файл со свойствами (например, C:/Users/UserName/.signing).
Keys.repo=C:/Users/UserName/.signing
Затем нужно создать эту папку или, если вы указали существующую, открыть её. В ней необходимо создать файл YourProjectName.properties, внутри которого будут прописаны в качестве свойств путь до хранилища ключей, псевдоним ключа и пароль в следующем виде.
RELEASE_STORE_FILE=/YourProjectName/KeyStoreName.jks RELEASE_STORE_PASS=****** RELEASE_ALIAS=KeyAlias RELEASE_KEY_PASS=******
Как создать хранилище ключей?
Если у вас нет хранилища ключей, его можно легко создать с помощью Android Studio. Для этого нужно выбрать в меню пункт Build -> Generate Signed APK.
В появившемся окне нужно нажать Create new… В результате откроется окно, в котором вы можете указать, где будет располагаться хранилище ключей (для данного урока лучше сразу выбрать путь, который вы указали в YourProjectName.properties в свойстве RELEASE_STORE_FILE), а также данные о ключе.
Затем нужно создать папку YourProjectName и перенести туда нужный файл хранилища ключей.
Теперь можно приступить непосредственно к процессу подписания. Для этого в вашем проекте нужно открыть файл build.gradle (расположенный в папке app). Внутри него в блоке android нужно добавить следующий код.
signingConfigs {
debug { /* здесь никаких изменений нет */ }
release {
if (project.hasProperty("Keys.repo")) {
def projectPropsFile = file(project.property("Keys.repo") + "/YourProjectName.properties")
if (projectPropsFile.exists()) {
Properties props = new Properties()
props.load(new FileInputStream(projectPropsFile))
storeFile file(file(project.property("Keys.repo") + props['RELEASE_STORE_FILE']))
storePassword props['RELEASE_STORE_PASS']
keyAlias props['RELEASE_ALIAS']
keyPassword props['RELEASE_KEY_PASS']
}
} else {
println "======================================================="
println "[ERROR] - Please configure release-compilation environment - e.g. in ~/.signing directory"
println "======================================================="
}
}
}
Какие бывают схемы получения подписи?
Существуют две схемы получения подписи APK: v1 JAR и v2 Full APK.
В первом случае подписывается JAR-файл, что является традиционным способом подписания. Подпись v1 не защищает некоторые части APK, такие как метаданные ZIP. Верификатор APK должен обрабатывать множество ненадёжных (ещё не проверенных) структур данных, а затем отбрасывать данные, которые не подписаны, что предоставляет большой простор для атаки. Кроме того, верификатор APK должен распаковать все сжатые записи, что тратит много времени и памяти. Чтобы решить эти проблемы, была разработана вторая схема v2 Full APK.
Схема v2 была представлена в Android 7.0 Nougat (API 25) и работает, начиная с версии Android Studio 2.2 и Android Gradle plugin 2.2. Эта схема обеспечивает более быструю установку приложения и хорошую защиту от несанкционированных изменений в APK. Содержимое APK хешируется и подписывается, затем полученный блок подписи APK вставляется в APK.
Во время проверки схема v2 рассматривает APK как blob и выполняет проверку подписи по всему файлу. Любая модификация APK, включая модификации метаданных ZIP, делает подпись недействительной. Эта форма проверки значительно быстрее и позволяет обнаружить больше несанкционированных модификаций.
Новый формат обратно совместим, поэтому APK, подписанные новой схемой, могут быть установлены на более ранних устройствах (которые будут просто игнорировать новую подпись), если эти APK также подписаны схемой v1.
По умолчанию при подписании используются обе схемы, чтобы приложения могли быть установлены на любых устройствах. Однако если есть такая необходимость, можно отключить подпись v1 или v2. Для этого в вышеприведённом коде в блоке release достаточно дописать следующие строки.
v1SigningEnabled false
или
v2SigningEnabled false
Важно также учитывать, что подписывать схемой v1 нужно до подписания схемой v2, поскольку APK не пройдёт проверку по схеме v2, если он будет подписан дополнительными сертификатами после подписания схемой v2.
После того, как код добавлен, укажите этот код в блоке buildTypes внутри release. Например:
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
Теперь можно смело в пункте меню Build выбирать Build APK, предварительно сменив тип сборки с debug на release. Как видно, данный способ удобен тем, что он автоматический, его достаточно настроить лишь раз и ваши хранилища ключей могут быть в безопасности.