Почему zipaligning после процесса подписания?

Question

Я недавно спросил себя, почему в Android мы должны сначала подписать, а затем zipalign apk. Я искал некоторую справочную информацию, как эти процессы технически работают в деталях. Я все еще немного недоволен, потому что эти описания на самом деле технически не объясняют, почему эта последовательность необходима.

Но давайте начнем с самого начала:

Я знаю тот факт, что в apk-build-process необходим следующий порядок

1. много предыдущих шагов...
2. создание apk-файла
3. подписание apk-файла (изменяет apk)
4. zipaligning apk-файл (изменяет apk)

Я нашел некоторую информацию здесь:
zipalign

Итак, ясно, что zipalign выровняет внутренние данные по 4-байтовым границам, так что все они могут быть загружены с помощью mmap. Кажется, что процесс подписания разрушил бы это выравнивание. Поэтому zipaligning должен быть вызван в конце процесса после подписания.

Но почему можно сделать перестройку apk-контента, не разрушая подписи apk!?
apk изменяется, и подпись не должна быть действительной после модифицированного apk, я думал...

Может быть, у кого-то есть технически справочная информация, чем я нашел здесь:
Подписание заявки

Спасибо, если у кого-то есть полезная, более технически подробная информация.
Люк

Answer 1

Цифровая подпись APK выполняется путем хэширования компонентов APK. Таким образом, вы защищаете содержимое отдельных файлов, а не их положение в памяти. Другими словами, содержимое APK подписано, но не сам APK в виде одного файла. Как вы правильно заметили, zipalign просто дополняет файлы в APK, чтобы они начинались на выровненной границе, чтобы более эффективно выполнять mmap(2) (и иметь возможность легко отбрасывать файлы). Содержание, однако, не изменяется, и, следовательно, подпись не нарушается.