2014-01-27 3 views
0

Если у меня есть доступ к исходному хранилищу ключей, используемому для подписи Android-приложения, есть способ перенести будущие версии приложения, чтобы использовать другое хранилище ключей, предпочтительно поддерживая возможность развивать с ADT, как если бы второе хранилище ключей всегда использовалось?Миграция хранилища версий Android-приложений (путем подписания дважды?)

Из того, что мне удалось выяснить, похоже, что мы должны использовать jarsigner для подписи первого обновления файла apk дважды с двумя разными хранилищами ключей. Затем в будущем любые обновления могут быть сделаны с помощью любого ключа, позволяя клиенту полностью использовать обслуживание приложения.

Version   Keystore 
1.0    A 
2.0    A & B 
3.0     B 
4.0     B 
...    ... 

Я хотел бы, чтобы клиент мог использовать ADT для экспорта Версия файла 2,0 АПК подписал с В. Хранилища ключей Когда мы пытаемся что их файл APK содержит CERT.SF сопоставлен хранилище ключей B, в то время как CERT Version 1.0 .SF отображается в 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 

... МЕТА-INF теперь также содержит ALIAS.SF.

Это обновление для Android связано с файлами .SF? CERT.SF отображается на два разных ключа, хотя ALIAS.SF содержит ключ, который он ищет.

(Урок: создание новых хранилищ ключей для клиентов как можно раньше)

ответ

1

If I have access to the original keystore used to sign an Android apk is there a way to migrate future versions of the app to use a different keystore, preferably maintaining the ability to develop with ADT as though the second keystore had always been used?

Увы, нет. Для поддержки этого потребуется модификация для Android. В прошлом году я немного потрудился в этом вопросе в связи с одним из исследователей, который написал this paper по этому вопросу.

From what I have been able to find out, it looks like we should be able to use jarsigner to sign the first update to the apk file twice with two different keystores

Верно, но все подписи должны соответствовать.

Then in the future any updates can be done with either key, letting the client take over app maintenance completely.

Нет, потому что все подписи должны соответствовать. Это изменение, которое потребуется в Android. В вашем примере, версия 2.0 будет не потому, что оригинальное приложение не подписано с B, даже если он подписан с А.

Lesson learned: create new keystores for clients as early as possible

Consultants, или кто-либо другой, создавая приложения для других, вероятно, следует рассмотреть вопрос о хранилище ключей-за -app или, по крайней мере, по умолчанию для каждого клиента.