Довольно просто.

Перейдите по URL, прикреплённому к гиперссылке №1 выше. В верхней правой части страницы будет кнопка «Добавить файлы» (Add Files). Загрузите файл apktool_x.x.x.jar.

После загрузки немедленно посетите страницу и загрузите его снова. Проверьте md5 на соответствие.

GitHub

Этот вариант не сработает, пока тег не будет отправлен. Вы можете перейти на эту страницу, чтобы создать новый релиз. В выпадающем списке «Версия тега» (Tag version) будет новый тег. В данном случае — v2.2.2.

Выберите этот вариант и сделайте заголовок Apktool vx.x.x. На этом релизе будет поле для описания. Не волнуйтесь, мы свяжем пост в блоге с этим релизом, но после факта мы можем отредактировать релиз, чтобы добавить это.

Загрузите двоичный файл apktool_x.x.x.jar и отправьте релиз.

Резервный сервер

Доступ к этому серверу, вероятно, ограничен, поэтому эта опция может быть недоступна. SSH на сервер connortumbleson.com с именем пользователя connor. Перейдите в public_html/apktool и загрузите туда файл apktool_x.x.x.jar.

Теперь заново сгенерируйте хэши md5/sha256 для этих файлов.

md5sum *.jar > md5.md5sum
sha256 *.jar > sha256.shasum

Проверьте файл md5.md5sum на наличие хэшей. Файл будет выглядеть примерно так.

6de3e097943c553da5db2e604bced332  apktool_1.4.10.jar
...
1e6be08d3f9bb4b442bb85cf4e21f1c1  apktool_2.2.2.jar

Также проверьте файл sha256.shasum на наличие хэшей. Этот файл будет почти идентичен предыдущему, за исключением того, что он содержит хэши sha256.

Хэши совпадают, так что резервный сервер работает нормально.

Sonatype

Вам нужно войти в систему и просмотреть репозитории Staging, а затем подтвердить, что вы видите недавно сделанный билд. Вам нужно:

• закрыть его (подождать отчёта об аудите по электронной почте);
• выпустить его (отбросить репозиторий Staging);
• подождать 20 минут — 2 часа, пока он появится здесь.

Когда это будет сделано, пришло время написать пост о выпуске.

В настоящее время мы публикуем сообщения о выпусках в личном блоге Коннора Тумблсона. Этот формат может меняться со временем.

Некоторые недавние выпуски для понимания шаблона можно найти ниже.

1. 2.2.1
2. 2.2.0
3. 2.0.2
4. 2.0.0

Для получения информации об авторах коммитов и количестве коммитов следующая команда выполняет работу:

git shortlog -s -n --all --no-merges --since="05 Sept 2018"

Очевидно, заменяя дату на дату выпуска последней версии.

Итак, напишите пост. Я обычно всегда включаю следующее:

1. Изображение выпуска для показанного изображения при повторном использовании в социальных сетях.
2. Краткое предложение или два для SEO, чтобы описать суть этого выпуска.
3. Количество коммитов и общее количество для этого выпуска с именами авторов.
4. Журнал изменений, ссылающийся на исправленные ошибки.
5. Загрузка, включая хэш md5/sha256.
6. Ссылка на сайт проекта, GitHub, трекер ошибок и ветку XDA.

Теперь, когда вы написали этот пост, нам нужно опубликовать его в разных местах и обновить места, где выпущен Apktool.

Ветвь XDA

У нас есть ветка на XDA Developers. Эта ветка следует тому же шаблону для всех выпусков.

При написании ответа на ветку XDA мы следуем другому шаблону заметок о выпуске. Эти примеры можно найти ниже:

1. 2.2.2
2. 2.2.1
3. 2.0.0

Сайт Apktool

На сайте проекта Apktool есть несколько мест для обновления:

1. Введение на главной странице.
2. Ссылка для скачивания в шапке.
3. Страница журнала изменений.
4. Нижний колонтитул домашней страницы с историей выпусков. ### Обновление этапов

Теперь, когда мы выпустили версию, у нас, надеюсь, не будет больше тикетов в только что опубликованном релизе. Если они есть, переместите эти тикеты на следующий этап.

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

Я обычно создаю следующий релиз (в данном случае 2.2.3) с ожидаемым сроком выполнения через 3 месяца в будущем. Это просто ориентир, но он помогает мне выпускать новую версию каждые 3 месяца.

Социальный спам

Последний шаг — отправить этот релиз в дикую природу через некоторые социальные публикации. Перейдите в блог, где была опубликована запись о выпуске, и отправьте эту ссылку в Twitter, Google и всё остальное, что вы используете.

Расслабьтесь и следите за системой отслеживания ошибок.

Создание двоичных файлов aapt

Шаги, предпринятые для создания наших модифицированных двоичных файлов aapt для apktool.

Получение изменённого репозитория frameworks/base

Первым шагом является использование репозитория platform_frameworks_base.

Хотя ранее он был неорганизован, теперь репозиторий следует соглашению об именовании ветвей в зависимости от текущей версии Android. Таким образом, apktool_7.1 соответствует выпуску Android 7.1. Эта ветка должна работать для всех тегов android-7.1.x для AOSP.

Мы не следовали этому соглашению об именах до Android 7.1. Так что не ищите более старые версии. Текущая версия — apktool-9.0.0, которая соответствует выпуску Android 9.0 (Pie).

В этом репозитории применён ряд изменений. Эти изменения варьируются от отключения оптимизаций до уменьшения правил, которые регулярно применяются к aapt. Мы делаем это, потому что задача apktool состоит не в том, чтобы исправлять apks, а в том, чтобы сохранять их как можно ближе к оригиналу.

Сначала нам нужен исходный код AOSP

Как бы банально это ни было, просто перейдите по этой ссылке для скачивания downloading, чтобы загрузить исходный код. Это немаленькая загрузка, ожидайте использования 150–250 ГБ.

После этого вам необходимо собрать AOSP с помощью этого руководства по документации. Сейчас мы собираем не весь пакет AOSP, первоначальная сборка предназначена только для того, чтобы проверить, способны ли вы его собрать.

Мы проверяем определённый тег или ветку. В настоящее время мы используем:

• aapt2 — master.
• aapt1 — master.

Включение нашего изменённого пакета frameworks/base

Вероятно, существует более автоматизированный способ сделать это, но пока:

1. cd frameworks/base.
2. git remote add origin git@github.com:iBotPeaches/platform_frameworks_base.git.
3. git fetch origin -v.
4. git checkout origin/master.

Сборка двоичного файла aapt1 (Legacy)

Следующие шаги различаются в зависимости от вкуса и операционной системы.

Linux / Windows

1. source build/envsetup.sh.
2. lunch sdk-eng.
3. m aapt.
4. strip out/host/linux-x86/bin/aapt.
5. strip out/host/linux-x86/bin/aapt_64.
6. strip out/host/windows-x86/bin/aapt.exe.
7. strip out/host/windows-x86/bin/aapt_64.exe.

Mac

1. source build/envsetup.sh.
2. m aapt.
3. strip out/host/darwin-x86/bin/aapt_64.

Для Linux и Windows будут созданы 32- и 64-разрядные двоичные файлы.

Создание двоичного файла aapt2

Следующие шаги различаются в зависимости от вкуса и операционной системы.

Linux / Windows

1. m aapt2.
2. strip out/host/linux-x86/bin/aapt2.
3. strip out/host/linux-x86/bin/aapt2_64.
4. strip out/host/windows-x86/bin/aapt2.exe.
5. strip out/host/windows-x86/bin/aapt2_64.exe.

Mac

1. export ANDROID_JAVA_HOME=/Path/To/Jdk.
2. source build/envsetup.sh.
3. m aapt2.
4. strip out/host/darwin-x86/bin/aapt2_64.

Подтверждение статической сборки aapt/aapt2

Существуют некоторые проблемы с некоторыми зависимостями (а именно libc++), в которых они создаются в общем состоянии. Это нормально в контексте AOSP/Android Studio, но как только вы покидаете эти два и начинаете использовать aapt самостоятельно, вы сталкиваетесь с некоторыми проблемами. Ключ в том, чтобы заставить libc++ создаваться статически, что требует некоторых настроек в системах сборки AOSP, поскольку эта зависимость не является стандартной, как libz и другие.

Вы можете протестировать...