Как поменять ключ подписи приложения

Я удивился, что мало кто знает, и некоторые даже не верят, что возможно поменять сертификат для ключа подписи вашего приложения.

⚠️Работает это только для App Bundle, и в случае Google Play придётся использовать Google Play App Signing.

При этом не стоит путать ключ загрузки и ключ подписи: иногда это один и тот же ключ, но по умолчанию Google предлагает сгенерировать свой ключ подписи, а ключ загрузки нужен, чтобы идентифицировать, что сборка подписана вами. Отсюда следует, что поменять ключ загрузки вообще не проблема, так как итоговый APK всё равно будет подписан другим ключом.

Но как изменить ключ подписи? Ведь система просто не даст установить приложение с одним package id и разными ключами 🤔

На самом деле это возможно, начиная с Android N (API 24). Вы можете сделать это вручную с помощью apksigner, для этого вам потребуется доступ к старому и новому ключам:

apksigner sign --in ${INPUT_APK} \
--out ${OUTPUT_APK} \
--ks ${ORIGINAL_KEYSTORE} \
--ks-key-alias ${ORIGINAL_KEY_ALIAS} \
--next-signer --ks ${UPGRADED_KEYSTORE} \
--ks-key-alias ${UPGRADED_KEY_ALIAS} \
--lineage ${LINEAGE}

Но в случае обновления приложения в Google Play нужно делать это через консоль. Переходим по ссылке и запрашиваем обновление ключа подписи, для этого придётся загрузить приватную часть сертификата в консоль. Сделать это можно только раз в год.

Как это работает?

Все существующие пользователи продолжат получать обновления со старым ключом, а для новых пользователей, у которых версия Android 13 и выше, подпись уже будет другая. Подробнее здесь.

Когда может понадобиться?

🔘Если предыдущий ключ был скомпрометирован.
🔘Вы выбрали автоматическое подписание в Google Play, а теперь хотите сделать одну подпись приложения для всех сторов.
🔘Вы подписывали приложения разными ключами, но теперь хотите использовать один ключ для безопасного обмена данными между приложениями.

#GooglePlay #AppSigning

Как с пользой провести День программиста?

Конечно, посмотреть доклад моего коллеги Евгения Мельцайкина о том, как мы делали медиаленту, решали проблемы синхронизации контента и как нам во всём этом помог Decompose 🌳

Женя выступает на IT-фестивале KODE WAVES, доклад начнётся уже совсем скоро, в 11:30 МСК.

🔴 Ссылка на прямую трансляцию

Manual DI

DI-фреймворки продолжают появляться как грибы после дождя. Теперь рекомендуют использовать Metro, но всё чаще можно услышать, что люди принципиально отказываются от каких-либо библиотек для реализации DI. Так как в моей команде мы в основном делаем переиспользуемые общие модули, мы тоже давно отказались от DI-фреймворков. И знаете что? Мы вообще не испытываем из-за этого каких-либо проблем.

Тут я вспомнил про свой KMP-сэмпл и решил, что будет круто показать всё это на примере и заменить Koin в проекте. Но хорошо, что я не начал делать это раньше времени: буквально на докладе про сравнение DI-фреймворков с Podlodka Android Crew я узнал, что Александр Власюк уже всё сделал раньше и даже заслал pull request 🌐

Примечательно, что Manual DI не только даёт compile-time safety по сравнению с Koin (без всяких плагинов), но даже количество строк кода в проекте сократилось 😲

Понятно, что это всего лишь пример. Если использовать Koin глобально, то кода с Manual DI придётся писать больше. Однако я придерживаюсь подхода, при котором DI должен быть изолирован внутри модуля, а зависимости должны быть объявлены явно, чтобы можно было легко переиспользовать этот модуль где угодно.

А вы что думаете, стоят ли DI-фреймворки, чтобы их изучать и постоянно мигрировать проект на все более новые решения ❓

#DI #Kotlin #KMP

Изменение конфигурации в прошлом

Еще пару лет назад я заметил, что если в AndroidManifest явно прописать все варианты изменения конфигурации в configChanges, то Compose сможет самостоятельно подхватить подавляющее большинство изменений без какого-либо дополнительного кода. Но тогда я был непонят сообществом, и никто это всерьез не воспринял 😨

Теперь же об этом заговорили инженеры из Google, рекомендую посмотреть доклад с Droidcon 🟥. Начиная с compileSdk 36, можно одной строчкой игнорировать все текущие и будущие причины пересоздания Activity из-за изменения конфигурации.

Это позволит нам полностью избавиться от андроидовской ViewModel и инкапсулировать нашу логику в обычных классах. При этом это не значит, что Activity никогда не будет пересоздаваться, изменение конфигурации лишь одна из причин. Но в таких случаях состояние можно сохранить только с помощью SavedInstanceState, ViewModel здесь бы не помогла.

А вы что думаете, готовы ли вы забыть об изменении конфигурации в Android и о ViewModel в частности?

#Android #Compose