Если у меня есть доступ к исходному хранилищу ключей, используемому для подписи apk для Android, есть ли способ перенести будущие версии приложения для использования другого хранилища ключей, предпочтительно сохраняя возможность разработки с помощью ADT, как если бы всегда использовалось второе хранилище ключей?
Из того, что мне удалось выяснить, похоже, что мы должны иметь возможность использовать jarsigner для подписи первого обновления файла apk дважды с двумя разными хранилищами ключей. Затем в будущем любые обновления можно будет выполнять с помощью любого ключа, что позволит клиенту полностью взять на себя обслуживание приложения.
Version Keystore
1.0 A
2.0 A & B
3.0 B
4.0 B
... ...
Я хотел бы, чтобы клиент мог использовать ADT для экспорта apk-файла версии 2.0, подписанного с помощью хранилища ключей B. Когда мы попытаемся, чтобы их apk-файл содержал CERT.SF, сопоставленный с хранилищем ключей B, тогда как CERT.SF версии 1.0 сопоставляется с хранилищем ключей A. .
Когда я пытаюсь это сделать, я все еще получаю сообщение об ошибке:
An existing package by the same name with a conflicting signature is already installed.
Я заметил, что когда apk экспортируется, он содержит CERT.SF в своем каталоге META-INF. Когда я подписываю второй раз, используя jarsigner вот так...
jarsigner -keystore /path/to/keystore_b -storepass STOREPASS -keypass KEYPASS ./AndroidApp.apk ALIAS
... META-INF теперь также содержит ALIAS.SF.
Это обновление Android жалуется из-за файлов .SF? CERT.SF сопоставляется с двумя разными ключами, хотя ALIAS.SF действительно содержит искомый ключ.
(Извлеченный урок: создавайте новые хранилища ключей для клиентов как можно раньше)
