Каталог расширений

Популярные теги

3gp       avi       fb2       jpg       mp3       pdf      

Главная » Разное » Как собрать apk файл

Как собрать apk файл


Разборка (декомпиляция) APK файла с помощью Apktool

Вам понадобится программа Apktool и Java. Файл, который будете разбирать (в нашем случае (smart.apk)

Установка Apktool на компьютер

Скачиваем и Устанавливаем Java. Скачиваем ApkTool (apktool1.4.3.tar.bz2 и apktool-install-windows-r04-brut1.tar.bz2) и распаковываем в директорию С:\Windows\

Для запуска Apktool нужно нажать сочетание клавиш Win+R

Пишем cmd - переходим в командную строку и пишем apktool.
Весь процесс происходит в командной строке.

Но сделать иначе, есть графический интерфейс ApkTool с названием Smartapktool. Скачиваем приложение Smartapktool (ссылка скачать внизу статьи) распаковываем его в папку. Очень важно, чтобы файлы apktool лежали в папке Windows, не путать с Smartapktool. Запускаем интерфейс SmartApkTool.exe и переходим в меню Распаковать/Запаковать. Выбирайте Ваше приложение ~name .apk (Важно! Отсутствие пробелов, кириллицы, знаков препинания).

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

Статьи по теме APK:


 

Как создать APK-файл в Android Studio

Для того чтобы установка нового мобильного приложения под управлением Android выполнялась легко и быстро, программные файлы и папки упаковывают в один исполняемый документ. В статье подробно описано, что такое Android Studio, как создать APK файл в Android Studio.

Что такое АПК файл

Современные программы, как правило, состоят из десятков документов и папок, которые требуют много места. В интегрированной среде разработки Android Studio, работающей под Windows, OS X и Linux, предусмотрен сервис компиляции программ для платформы Android. В результате получается один упакованный исполняемый файл формата AndroidPackageKit (APK), обеспечивающий установку приложения с необходимыми библиотеками и ресурсами. В процессе распаковки пользователь выбирает полную установку либо распаковку отдельных компонентов. Второй вариант, как правило, выбирают разработчики для дальнейшего просмотра и редактирования программы.

Как создать файл APK

Так как для программирования часто используется Java, среда Android SDK у разработчика, скорее всего, уже есть на компьютере. SDK используется для нахождения и устранения ошибок в программе и должна быть установлена перед компиляцией, так как Android Studio для создания .apk использует компоненты этой среды.

Рассмотрим применительно к Android Studio, как сделать apk документ. В среде AndroidStudio компиляция apk может быть выполнена двумя способами: вручную и автоматически.

Где лежит АПК файл

В смартфонах используются два вида хранилища данных: внутреннее и внешнее. Внутреннее хранилище использует защищенную область памяти смартфона. Для исключения нерегламентированного вмешательства приложения получают доступ только к «своим» документам, расположенным в этом хранилище.

Вешнее хранилище расположено в памяти смартфона или на карте памяти. Данные, размещенные в этом хранилище, пользователь сможет извлечь для собственных целей.

В Android файлы приложений, загруженные из GooglePlay или скачанные с сайта разработчика, хранятся в папке /data/app. Если требуется извлечь файл .apk из установленного приложения, можно использовать менеджер файлов или специальную программу APK Extractor (программа доступна для загрузки в GooglePlay). Если для хранения приложений используется карта памяти, чтобы найти в Android Studio, где лежит APK, нужно проверить папку /mnt/asec/APPNAME/pkg.apk.

Запуск компиляции вручную

Далее необходимо в Android Studio перейти на вкладку «Build», затем – «GenerateSigned APK». Как подписывать АПК файлы? Можно перейти в сценарий, где изменятся настройки подписи (build.gradle). Сгенерированные подписи хранятся в соответствующих файлах.

После окончания сборки появится окно с кнопкой «Locate», которая показывает в Android Studio где находится АПК файл. Найти его можно по имени, одинаковому с именем создаваемого проекта. Например, если проект называется MyProject, документы будут лежать в разделе

MyProject/…

В зависимости от издания Android Studio полученный документ формата .apk размещен в директориях

MyProject/build/apk/...

MyProject/build/outputs/apk.

Запуск автоматической компиляции

Рассмотрим теперь, как в Android Studio собрать apk программным способом.

В Android Studio формирование АПК запускается кнопкой «Run», которая активизирует работу команды «assembleRelease», предварительно помещенную в настройки проекта.

При использовании данного способе создания исполняемого файла нет необходимости каждый раз вводить реквизиты доступа и подписывать документ вручную. Сведения о подписи добавляются в файл сценария. В настройки проекта добавляется команда «assembleRelease», которая запускается кнопкой «Run», как и другие команды. В результате автоматической компиляции в разделе build/apk/ появятся два файла: <Имя>-release-u unaligned.apk и <Имя>-release.apk. Они отличаются тем, что в первом случае документ содержит подпись, но не выровнен. А во втором случае – представляет собой готовый дистрибутив, который после смены имени на коммерческое подлежит свободному распространению.

В помощь новичкам: на youtube содержатся видео с подробным описанием как создать АПК файл в Android Studio. Например, первый урок:

Простой способ модификации Android приложения / Хабр

Бывает после релиза приложения его исходники куда-то деваются. Правда ведь, такое постоянно случается? И ничего не остается кроме как декомпилировать его и подправить несколько сотен строк кода и все это нужно сделать максимально быстро.

Вот и у меня появилась задача модифицировать приложение имея всего лишь его apk. И те, кто занимался декомпиляцией приложений знают насколько тяжело его потом скомпилировать.

Декомпиляция

Для Android'а существуют следующие утилиты:
  • ApkTool для декомпиляции ресурсов.
  • Dex2Jar для преобразования dex в jar.
  • JD-GUI для получения исходников из jar.
  • еще рекомендую JAD, некоторые места лучше декомпилирует чем JD-GUI.

Информации по их использованию в интернете достаточно.

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

На этом можно было и закончить эксперименты с декомпиляцией, но лень двигатель прогресса и родился новый способ.

Переопределение классов

Итак, jar это библиотека, так почему бы просто не подключить ее к новому проекту? Кидаем ее в папку libs, наследуемся от главной активити и компилируем. Все работает, главное чтоб не совпадали имена классов, поэтому названия пакетов должно отличаться иначе как минимум совпадут сгенерированные BuildConfig и R.

Таким способом можно отнаследоваться от Activity, Service, BroadcastReceiver и, возможно, некоторых других классов объявляемых в манифесте, так же в манифесте нужно будет указать новые имена классов, иначе они не будут использоваться.

Теперь можно переопределить виртуальные функции, но и только, тем более ключевое слово final не позволит это сделать и отнаследоваться тоже, поэтому идем дальше.

Замена классов

Разархивировав jar библиотеку получим class файлы, это скомпилированные классы, заметим, что при сборке проекта в папке bin/classes лежат те же class файлы, а что если подсунуть туда файлы из библиотеки…

Не все так просто, для начала нужно скомпилировать проект. Чтобы использовать классы исходного приложения нужно его как-то присоединить к проекту, но при этом не экспортировать. Делается это просто: из папки libs Эклипс сам экспортирует библиотеки, поэтому перемещаем jar библиотеку в папку lib и подключаем к проекту, в Эклипсе это Project->Preferences->Java Build Path->Libraries->Add Jars… далее во вкладке Order and Export нужно убедиться, что не установлен чекбокс, потому что экспортировать библиотеку нам не нужно, все будет в class файлах.

Теперь берем какой-нибудь класс из декомпилированных исходников приложения, исправляем в нем ошибки компиляции, добавляем, например, показ диалога, чтоб убедиться, что используется именно новый класс. Далее очищаем проект, в Эклипсе это Project->Clean, копируем class файлы в папку bin/classes, собираем проект и все работает!

При следующих сборках проекта нет необходимости его очищать, так что использовать такой способ достаточно удобно. Для облегчения исправления ошибок после декомпиляции я использовал исходники полученные из JD-GUI и JAD, обычно этого было достаточно.

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

Заключение

Таким способом декомпилируются только модифицируемые файлы, что избавляет от исправления ошибок во всех исходниках и улучшает надежность, так как всего часть кода подвергнется процессу декомпиляции — исправления — компиляции.

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

Обновление классов в jar — идея замены классов пришла из этой возможности для jar библиотеки.

Создание apk-файла в Android Studio

Конечной целью любой java-разработки является создание завершенного приложения : это может быть как библиотека/исполняемый jar-файл, либо web приложение. Имеются различные типы приложений и библиотек. При всем многообразии возможных разношёрстных типов готовых библиотек и приложений android-устройства выбиваются из общей колеи. Для android-устройств конечным программным продуктом являются apk-файлы, которые можно свободно распространять между пользователями.

На заре развития программного обеспечения вся разработка для android-устройств осуществлялась, как правило, в IDE Eclipse со специализированными плагинами типа ADT (Android Development Tools). Данная среда разработки позволяет создавать для android apk-файлы. Но времена быстро меняются, и сегодня гораздо эффективнее и быстрее создавать apk-файлы в представленной ещё в 2013 году Android Studio, основанную на старом конкуренте Eclipse — системе IntelliJ IDEA.

Аббревиатура apk (Android Package Kit) символизирует формат файлов, которые используются для распространения и установки приложений на устройства android. Файл apk содержит все необходимые элементы для правильной установки приложения на устройстве, и, по своему назначению, чем-то похож на исполняемые exe-файлы в Windows. Когда Вы «заходите в магазин» Google Play, чтобы выбрать и загрузить какое-либо приложение, Ваше устройство android скачивает и устанавливает файл apk с нужным приложением.

Создание apk-файла

Рассмотрим процесс создания apk-файла на примере p13osgi, в котором использовался OSGi-фреймворк. Этот пример подробно рассмотрен на странице Android и OSGI-фреймворк Felix. В данной статье используем готовый модуль из проекта.

Заметка. Почему в качестве примера создания apk-файла выбираем данный модуль/проект, а не какой-либо другой? Дело в том, что в данном примере используется расположенная в поддиректории lib внешняя библиотека. И для нас интерес будет представлять структура apk-файла с внешней jar-библиотекой : какое место в данном пакете будет занимать внешний файл org.apache.felix.framework-6.0.3.jar. Здесь следует понимать, что OSGi-фреймворк (Felix) позволяет создавать модульную структуру приложения. Причем, в режиме run-time можно динамически подключать новые модули (bunlde), останавливать запущенные модули, одновременно подключать разноверсионные модули. Данный функционал OSGi-фреймворка на примере Вы можете реально проверить на своем компьютере; для этого необходимо познакомиться с Уроком 8.

Создание APK-файлов всех модулей проекта

Чтобы использовать самый простой способ создания apk-файла, выберите в Android Studio пункт меню «Build → Build Bundle(s)/APK(s) → APK(s)», как это представлено на следующем скриншоте.

В данном случае для всех модулей проекта будут созданы apk-файлы. Здесь необходимо отметить, что apk-файлы будут без цифровой подписи и распространению не подлежат. Но на них можно «посмотреть», что мы и сделаем в последнем разделе статьи, а также можно проверить работоспособность на android-устройстве. Загрузку apk-файла на android-устройство мы рассмотрим в ближайшее время отдельной статьей. Также отдельной статьей я представлю процесс создания apk-файла с цифровой подписью при выборе пункта меню «Build → Generate Signed Bundle/APK».

А сейчас Вы должны увидеть, что для всех модулей проекта создаются apk-файлы, которые располагаются в поддиректориях проекта [project_name]/[module_name]/build/outputs/apk/debug/. Т.е. в поддиректории модуля build/outputs/apk/debug/ будет размещаться созданный apk-файл, наименование которого включает наименование модуля с постфиксом «-debug». В нашем примере будет создан файл p13osgi-debug.apk.

Определение типа apk : debug-release

Постфикс "-debug", добавляемый к наименованию пакета, определен по умолчанию. Вы можете самостоятельно переименовать файл, и он останется работоспособным. Но можно и изменить настройки. Для этого необходимо указателем мыши нажать на расположенную в левом нижнем углу маленькую кнопочку, как это представлено на нижнем левом скриншоте. Данная кнопка открывает окно со специальными ярлыками различных вспомогательных окон. При простом наведении указателя мыши на эту кнопку, появляется список всех этих окон для быстрого выбора нужного.

Откроем окно Build Variants и в дополнительно открытом окне (скриншот справа) найдем модуль p13osgi (наш пример).

Если в выпадающем списке переключить режим сборки с debug на release, то будет создаваться пакет p13osgi-release-unsigned.apk в поддиректории «build/outputs/apk/release/».

 

Создание APK-файла одного модуля проекта

Для того, чтобы создать apk-файл одного модуля, необходимо открыть панель Gradle (см.ярлык на скриншоте сверху слева). В открывшемся окне, как это представлено на следующем скриншоте, необходимо выбрать пункт меню «module_name → Tasks → build → build». В результате данных действий будет создан apk-файл только одного модуля.

Структура файла APK

В заключении посмотрим на внутренности нашего apk-файла. Сразу же отмечу, что apk-файл можно открыть zip-архиватором, например 7-Zip. Но многое останется недоступным. Лучше использовать анализатор apk-файлов от Android Studio. Далеко ходить не надо : необходимо выбрать пункт меню «Build → Analyze APK ...» (см. самый верхний скриншот). В открывшемся диалоговом окне найти нужный пакет в файловой структуре, после чего в IDE будет открыта панель, как это представлено на следующем скриншоте.

Интерфейс панели анализатора разделен на 2 части. В верхней части Вы видите корневую структуру apk-файла. В нижней части можно просматривать структуру выделенного элемента верхней части.

Что сразу же бросается в глаза? Вспоминаем : в нашем примере/модуле была использована внешняя библиотека с OSGi-фреймворком Felix org.apache.felix.framework-6.0.3.jar, расположенная в поддиректории lib
В структуре созданного пакета поддиректория lib. Все файлы внешней jar-библиотеки размещаются в корне по пакетам. Можно предположить, что и дополнительное использование бандлов/модулей (а для чего использовать фреймворк, если не использовать бандлы) приведет к тому, что и их содержимое также будет интегрировано в общий пакет. Таким образом, мы лишаемся преимуществ использования OSGi-технологии при разработке приложений для android-устройств, поскольку любая доработка отдельного модуля/бандла будет связана с обновлением всей сборки (apk-пакета). Кроме этого, отсутствует возможность одновременного использования разноверсионных бандлов, а межмодульное взаимодействие посредством сервисов становится «слишком дорогим» (можно и напрямую постучаться к классам бандла, зачем нам посредник-активатор). На данном простом примере я не вижу преимуществ использования OSGi для создания многомодульного приложения.

Буду признателен всем, кто опровергнет данное предположение и предложит значимое использование OSGi-технологии в android-устройстве.

Что касается *.class'ов, то их также не будет в apk-файле. Им на смену пришли файлы *.dex .

Файл .dex

«Рабочей лошадкой» в системе Android является Dalvik Virtual Machine, не использующая байт-код Java. Виртуальная машина Dalvik является службой приложения, которая интерпретирует скомпилированный код в dex-файле. Инструкции байт-кода формата DEX не совпадают с инструкциями байт-кода Java. Таким образом, в apk-файле Java-классы представлены в формате .dex. Но необходимо отметить, что структура пакетов сохраняется.

Сборка Android-приложения. Задачка со звёздочкой / Блог компании FunCorp / Хабр

Привет, Хабр! Летом я выступал на Summer Droid Meetup с докладом про сборку Android-приложения. Видеоверсию можно найти здесь: habr.com/ru/company/funcorp/blog/462825. А для тех, кто больше любит читать, я как раз и написал эту статью.

Речь пойдёт о том, что же это такое — Android-приложение. Мы соберём разными способами Hello, world!: начнём с консоли и посмотрим, что вообще происходит под капотом систем сборки, потом вернёмся немного в прошлое, вспомним про Maven и изучим современные решения Bazel и Buck. И, наконец, всё это сравним.

Мы задумались о возможной смене системы сборки, когда начинали новый проект. Нам казалось, что это неплохая возможность поискать какие-нибудь альтернативы Gradle. Тем более, что делать это проще на старте, чем переводить существующий проект. К этому шагу нас подтолкнули следующие недостатки Gradle:

  • у него определённо есть проблемы с инкрементальной сборкой, хотя видны подвижки в этом направлении;
  • он плохо справляется с очень большими монолитными проектами;
  • бывает, что весьма долго стартует демон;
  • требователен к машине, на которой выполняется.

APK


Прежде всего вспомним, из чего состоит Android-приложение: скомпилированного кода, ресурсов и AndroidManifest.xml.

Исходники находятся в файле classes.dex (файлов может быть несколько, в зависимости от величины приложения) в специальном dex-формате, с которым умеет работать виртуальная машина Android. Нынче это ART, на более старых девайсах — Dalvik. Помимо этого можно встретить папку lib, где по подпапкам разложены нативные исходники. Они будут носить названия в зависимости от целевой архитектуры процессора, например x86, arm и т.д. Если вы используете exoplayer, то lib у вас наверняка присутствует. И папка aidl, которая содержит в себе интерфейсы межпроцессного взаимодействия. Они пригодятся, если нужно обратиться к сервису, запущенному в другом процессе. Такие интерфейсы используются и в самом Android, и внутри GooglePlayServices.

Различные некомпилируемые ресурсы вроде картинок лежат в папке res. Все компилируемые ресурсы, такие как стили, строки и т.д., сливаются в файл resource.arsc. В папку assets, как правило, складывают всё, что не укладывается в ресурсы, например кастомные шрифты.

Кроме всего этого, в APK содержится AndroidManifest.xml. В нём мы описываем различные компоненты приложения, такие как Activity, Service, разные разрешения и т.д. Он лежит в бинарном виде, и чтобы заглянуть внутрь, его надо будет сперва сконвертировать в человекочитаемый файл.

CONSOLE


Теперь, когда мы знаем, из чего состоит приложение, можем попробовать собрать Hello, world! из консоли, используя инструменты, которые предоставляет Android SDK. Это довольно важный этап для понимания того, как работают системы сборки, потому что все они в той или иной мере опираются на эти утилиты. Так как проект написан на Kotlin, нам потребуется его компилятор для командной строки. Его несложно загрузить отдельно.

Сборку приложения можно поделить на следующие этапы:

  • загружаем и распаковываем все библиотеки, от которых зависит проект. В моём случае это библиотека обратной совместимости appcompat, которая, в свою очередь, зависит от appcompat-core, поэтому выкачиваем и её;
  • генерируем R.java. Этот чудесный класс содержит в себе идентификаторы всех ресурсов в приложении и используется для того, чтобы обращаться к ним в коде;
  • компилируем исходники в байт-код и транслируем его в Dex, потому что виртуальная машина Android с обычным байт-кодом работать не умеет;
  • упаковываем всё в APK, но сначала выравниваем все несжимаемые ресурсы, такие как картинки, относительно начала файла. Это позволяет ценой совершенно незначительного роста размера APK существенно ускорить его работу. Таким образом система напрямую может отображать ресурсы в оперативную память, используя функцию mmap().
  • подписываем приложение. Эта процедура защищает целостность APK и подтверждает авторство. И благодаря этому, например, Play Market может проверить, что приложение было собрано именно вами.

скрипт сборки
function preparedir() { rm -r -f $1 mkdir $1 } PROJ="src/main" LIBS="libs" LIBS_OUT_DIR="$LIBS/out" BUILD_TOOLS="$ANDROID_HOME/build-tools/28.0.3" ANDROID_JAR="$ANDROID_HOME/platforms/android-28/android.jar" DEBUG_KEYSTORE="$(echo ~)/.android/debug.keystore" GEN_DIR="build/generated" KOTLIN_OUT_DIR="$GEN_DIR/kotlin" DEX_OUT_DIR="$GEN_DIR/dex" OUT_DIR="out" libs_res="" libs_classes="" preparedir $LIBS_OUT_DIR aars=$(ls -p $LIBS | grep -v /) for filename in $aars; do DESTINATION=$LIBS_OUT_DIR/${filename%.*} echo "unpacking $filename into $DESTINATION" unzip -o -q $LIBS/$filename -d $DESTINATION libs_res="$libs_res -S $DESTINATION/res" libs_classes="$libs_classes:$DESTINATION/classes.jar" done preparedir $GEN_DIR $BUILD_TOOLS/aapt package -f -m \ -J $GEN_DIR \ -M $PROJ/AndroidManifest.xml \ -S $PROJ/res \ $libs_res \ -I $ANDROID_JAR --auto-add-overlay preparedir $KOTLIN_OUT_DIR compiledKotlin=$KOTLIN_OUT_DIR/compiled.jar kotlinc $PROJ/java $GEN_DIR -include-runtime \ -cp "$ANDROID_JAR$libs_classes"\ -d $compiledKotlin preparedir $DEX_OUT_DIR dex=$DEX_OUT_DIR/classes.dex $BUILD_TOOLS/dx --dex --output=$dex $compiledKotlin preparedir $OUT_DIR unaligned_apk=$OUT_DIR/unaligned.apk $BUILD_TOOLS/aapt package -f -m \ -F $unaligned_apk \ -M $PROJ/AndroidManifest.xml \ -S $PROJ/res \ $libs_res \ -I $ANDROID_JAR --auto-add-overlay cp $dex . $BUILD_TOOLS/aapt add $unaligned_apk classes.dex rm classes.dex aligned_apk=$OUT_DIR/aligned.apk $BUILD_TOOLS/zipalign -f 4 $unaligned_apk $aligned_apk $BUILD_TOOLS/apksigner sign --ks $DEBUG_KEYSTORE $aligned_apk


По цифрам получается, что чистая сборка занимает 7 секунд, и инкрементальная от неё не отстаёт, потому что мы ничего не кешируем и каждый раз пересобираем всё заново.

MAVEN


Он был разработан ребятами из Apache Software Foundation для сборки Java-проектов. Билд-конфиги для него описываются на языке XML. Ранние ревизии Maven собирались Ant, а сейчас они перешли на последний стабильный релиз.

Плюсы Maven:

  • он поддерживает кеширование артефактов сборки, т.е. инкрементальный билд должен быть быстрее чистого;
  • умеет разрешать сторонние зависимости. Т.е. Когда вы в конфиге Maven или Gradle указываете зависимость от сторонней библиотеки, вам не нужно заботиться о том, от чего она зависит;
  • есть куча подробной документации, потому что он уже весьма давно на рынке.
  • и он может быть привычным механизмом сборки, если вы недавно пришли в мир Android-разработки из бэкенда.

Минусы Maven:
  • зависит от версии Java, установленной на машине, на которой происходит сборка;
  • Android-плагин сейчас поддерживается сторонними разработчиками: лично я считаю это весьма существенным недостатком, потому что в один прекрасный день они могут перестать это делать;
  • XML не очень подходит для описания билд-конфигов в силу своей избыточности и громоздкости;
  • ну и как мы позднее увидим, он работает медленнее Gradle, по крайней мере на тестовом проекте.

Для сборки мы должны создать pom.xml, который содержит описание нашего проекта. В заголовке указываем базовые сведения о собираемом артефакте, а так же версию Kotlin.билд-конфиг pom.xml
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>myapplication</artifactId> <version>1.0.0</version> <packaging>apk</packaging> <name>My Application</name> <properties> <kotlin.version>1.3.41</kotlin.version> </properties> <dependencies> <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency> <dependency> <groupId>com.google.android</groupId> <artifactId>android</artifactId> <version>4.1.1.4</version> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-maven-plugin</artifactId> <version>${kotlin.version}</version> <executions> <execution> <id>compile</id> <phase>process-sources</phase> <goals> <goal>compile</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>com.simpligility.maven.plugins</groupId> <artifactId>android-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <sdk> <platform>28</platform> <buildTools>28.0.3</buildTools> </sdk> <failOnNonStandardStructure>false</failOnNonStandardStructure> </configuration> </plugin> </plugins> </build> </project>


По цифрам всё выходит не слишком радужно. Чистая сборка занимает порядка 12 секунд, тогда как инкрементальная — 10. Это говорит о том, что Maven как-то плохо переиспользует артефакты предыдущих сборок, либо, что на мой взгляд более вероятно, плагин для сборки Android-проекта мешает ему это делать

Используют сейчас всё это, я думаю, прежде всего создатели плагина — ребята из simpligility. Больше достоверных сведений об этом вопросе найти не удалось.

BAZEL


Bazel изобрели инженеры в недрах Google для сборки своих проектов и относительно недавно перевели его в open source. Для описания билд-конфигов используется питоноподобный Skylark или Starlark, оба названия имеют место быть. Собирается с использованием своего же последнего стабильного релиза.

Плюсы Bazel:

  • поддержка разных языков программирования. Если верить документации, то он умеет собирать проекты для iOs, Android или даже бэкенда;
  • умеет кешировать ранее собранные артефакты;
  • умеет работать с Maven-зависимостями;
  • у Bazel очень крутая, на мой взгляд, поддержка распределённых проектов. Ему можно в качестве зависимостей указывать конкретные ревизии git-репозиториев, и он будет сам их выгружать и кешировать в процессе сборки. Для поддержки масштабируемости Bazel умеет, например, распределять различные таргеты по облачным билдсерверам, что позволяет очень быстро собирать громоздкие проекты.

Минусы Bazel:
  • всю эту прелесть весьма тяжело поддерживать, потому что билд-конфиги очень подробные и описывают сборку на низком уровне;
  • помимо прочего, кажется, что Bazel сейчас активно развивается. Из-за этого некоторые примеры не собираются, а те, что собираются, могут использовать уже устаревший функционал, который помечен как deprecated;
  • документация сейчас также оставляет желать лучшего, особенно в сравнении с Gradle;
  • на маленьких проектах прогрев и анализ билд-конфигов может занимать больше времени, чем сама сборка, что не есть хорошо, на мой взгляд.

Концептуально базовый конфиг Bazel состоит из WORKSPACE, где мы описываем всякие глобальные вещи для проекта, и BUILD, который содержит непосредственно таргеты для сборки.
Опишем WORKSPACE. Так как у нас Android-проект, то первое, что мы конфигурируем, — это Android SDK. Также тут импортируется правило для выгрузки конфигов. Потом, так как проект написан на Kotlin, мы должны указать правила для него. Тут мы делаем это, ссылаясь на конкретную ревизию прямо из git-репозитория.WORKSPACE
android_sdk_repository( name = "androidsdk", api_level = 28, build_tools_version = "28.0.3" ) load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") # # KOTLIN RULES # RULES_KOTLIN_VERSION = "990fcc53689c8b58b3229c7f628f843a60cb9f5c" http_archive( name = "io_bazel_rules_kotlin", url = "https://github.com/bazelbuild/rules_kotlin/archive/%s.zip" % RULES_KOTLIN_VERSION, strip_prefix = "rules_kotlin-%s" % RULES_KOTLIN_VERSION ) load("@io_bazel_rules_kotlin//kotlin:kotlin.bzl", "kotlin_repositories", "kt_register_toolchains") kotlin_repositories() kt_register_toolchains()


Теперь приступим к BUILD.

Сперва импортируем правило для сборки Kotlin и описываем то, что хотим собрать. В нашем случае это Android-приложение, поэтому используем android_binary, где задаём манифест, минимальный SDK и т.д. Наше приложение будет зависеть от исходников, поэтому упоминаем их в deps и переходим к тому, что они собой представляют и где их найти. Код также будет зависеть от ресурсов и библиотеки appcompat. Для ресурсов используем обычный таргет для сборки андроидных исходников, но задаём ему только ресурсы без java-классов. И описываем пару правил, которые импортируют сторонние библиотеки. Тут также упоминается appcompat_core, от которой зависит appcompat.

BUILD
load("@io_bazel_rules_kotlin//kotlin:kotlin.bzl", "kt_android_library") android_binary( name = "app", custom_package = "com.example.myapplication", manifest = "src/main/AndroidManifest.xml", manifest_values = { "minSdkVersion": "15", }, deps = [ ":lib", ], ) kt_android_library( name = "lib", srcs = glob(["src/main/java/**/*"]), deps = [ ":res", ":appcompat", ], ) android_library( name = "res", resource_files = glob(["src/main/res/**/*"]), manifest = "src/main/AndroidManifest.xml", custom_package = "com.example.myapplication", ) aar_import( name = "appcompat", aar = "libs/appcompat.aar", deps = [ ":appcompat_core", ] ) aar_import( name = "appcompat_core", aar = "libs/core.aar", )


По цифрам для такого маленького проекта всё выглядит печально. Больше половины минуты на чистую сборку Hello, world! — очень много. Время инкрементальной сборки также далеко от совершенства.

Bazel используют его создатели (Google) для каких-то своих проектов, в том числе серверных, а также Dropbox и Huawei, которые собирают им мобильные приложения. И небезызвестный Dagger 2 также собирается Bazel.

BUCK


Его придумали перебежчики из Google в Facebook. Для описания конфигов раньше он использовал Python, а потом мигрировал на упоминавшийся сегодня Skylark. Собирается же он, внезапно, с помощью системы Ant.

Плюсы Buck:

  • поддерживает разные языки программирования и умеет собирать как Andriod, так и iOS;
  • умеет кешировать ранее собранные артефакты;
  • для Buck сделали свою реализацию dex, которая работает пошустрее стандартной и висит вместе с демоном системы. Так они экономят время на инициализации dex. Инженеры действительно многое оптимизировали. Например, Buck не собирает код, который зависит от библиотеки, если при изменении внутренностей библиотеки не изменился интерфейс. Аналогично и для ресурсов: если идентификаторы не поменялись, то при изменении ресурсов код не пересобирается.
  • есть плагин, который умеет прятать Buck за гредловским конфигом. Т.е. вы получаете примерно обычный Gradle-проект, который на самом деле собирается через Buck.

Минусы Buck:
  • его так же сложно поддерживать, как Bazel. Т.е. тут так же надо описывать низкоуровневые правила, четко описывающие процесс сборки;
  • кроме прочего, Buck не умеет сам разрешать Maven-зависимости.

Итак, как выглядит конфиг сборки Hello, world! посредством Buck? Тут мы описываем один файл конфигурации, где указываем, что хотим собирать Android-проект, который будет подписан дебажным ключом. Приложение аналогичным образом будет зависеть от исходников — lib в массиве deps. Дальше идёт таргет с настройками подписи. Я использую дебажный ключ, который идёт в комплекте с Android SDK. Сразу за ним следует таргет, который соберёт нам исходники Kotlin. Аналогично Bazel, он зависит от ресурсов и библиотек совместимости.

Описываем их. Для ресурсов в Buck есть отдельный таргет, поэтому велосипеды не пригодятся. Следом идут правила для скачанных сторонних библиотек.

BUILD
android_binary( name = 'app', manifest = 'src/main/AndroidManifest.xml', manifest_entries = { 'min_sdk_version': 15, }, keystore = ':debug_keystore', deps = [ ':lib', ], ) keystore( name = 'debug_keystore', store = 'debug.keystore', properties = 'debug.keystore.properties', ) android_library( name = 'lib', srcs = glob(['src/main/java/*.kt']), deps = [ ':res', ':compat', ':compat_core', ], language = 'kotlin', ) android_resource( name = 'res', res = "src/main/res", package = 'com.example.myapplication', ) android_prebuilt_aar( name = 'compat', aar = "libs/appcompat.aar", ) android_prebuilt_aar( name = 'compat_core', aar = "libs/core.aar", )


Собирается всё это дело очень резво. Чистая сборка занимает немногим более 7 секунд, тогда как инкрементальная — совершенно незаметные 200 миллисекунд. Я думаю, это очень хороший результат.

Так делают в Facebook. Кроме своего флагманского приложения, они собирают им Facebook Messenger. И Uber, которые сделали плагин для Gradle и Airbnb с Lyft.

Выводы


Теперь, когда мы поговорили про каждую систему сборки, можно сравнить их между собой на примере Hello, world! Консольная сборка радует своей стабильностью. Время выполнения скрипта из терминала можно считать эталонным для сборки чистых билдов, потому что сторонние затраты на парсинг скриптов тут минимальны. Явным аутсайдером я бы в данном случае назвал Maven за чрезвычайно незначительное убыстрение инкрементальной сборки. Bazel очень долго парсит конфиги и инициализируется: есть мысль, что он кеширует как-то результаты инициализации, потому что инкрементальная сборка у него проходит существенно быстрее чистой. Buck — бесспорный лидер это подборки. Очень быстрая как чистая, так и инкрементальные сборка.

Сравним теперь все за и против. Не буду включать Maven в сравнение, потому что он явно проигрывает Gradle и уже практически не используется на рынке. Buck и Bazel я объединю, потому что они обладают примерно одинаковыми достоинствами и недостатками.

Итак, про Gradle:

  • первое и, на мой взгляд, самое важное — он простой. Очень простой;
  • из коробки разруливает и выгружает зависимости;
  • для него очень много самых разных обучалок и документации;
  • активно поддерживается как Google, так и сообществом. Здорово интегрирован с Android Studio, текущим флагманским инструментом разработки. И все новые фичи для сборки Android-приложения сперва появляются именно в Gradle.

Про Buck/Bazel:
  • определённо могут быть очень быстрыми в сравнении с Gradle. Полагаю, что это особенно заметно на очень больших проектах
  • можно держать один проект, в котором будут исходники и iOS, и Android, и собирать их одной системой сборки. Это позволяет шарить между платформами некоторые части приложения. Например, так собирается Chromium;
  • заставляют подробно описывать зависимости и таким образом буквально принуждают разработчика к многомодульности.

Не забудем и про минусы.

Gradle за свою простоту расплачивается тем, что он медленный и неэффективный.
Buck/Bazel же, напротив, из-за своей скорости страдают от необходимости подробнее описывать в конфигах процесс сборки. Ну и так как появились на рынке они относительно недавно, то документации и разных шпаргалок немного.

iFUNNY


Возможно, у вас возник вопрос, как мы собираем iFunny. Так же, как и многие — используя Gradle. И на то есть причины:
  1. Пока непонятно, какой выигрыш в скорости сборки нам это даст. Чистая сборка iFunny занимает почти 3 минуты, а инкрементальная — около минуты, что на самом деле не особо долго.
  2. Билд-конфиги Buck или Bazel сложнее поддерживать. В случае Buck нужно ещё и следить за актуальностью подключенных библиотек и библиотек, от которых они зависят.
  3. Это банально дорого — переводить существующий проект с Gradle на Buck/Bazel, особенно в условиях непонятного профита.

Если у вас проект собирается больше 45 минут и в команде Android-разработки человек 20, то есть смысл задуматься о смене системы сборки. Если вы со своим другом пилите стартап, то пользуйтесь Gradle и отбросьте эти мысли.

Буду рад обсудить перспективы альтернатив Gradle в комментариях!
Ссылка на проект

Упаковка APK приложения и подпись (компиляция apk и подпись)

Открываем Smartapktool – переходим в Распаковать/Запаковать, выбираем запаковать и ставим галочку на подписать приложение, нажимаем обзор переходим к папке с распакованным приложением и выбираем файл apktool.yml, нажимаем 'Запаковать и подписать'

после подписи ваше приложение будет находиться в папке sign рядом с программой Smartapktool.exe и иметь название sign_name.apk . Или просто 'Запаковать' тогда в (декомпилированном приложение) папке разобранного приложения будут созданы папки build и dist, в папке dist будет собранный apk (то что нам нужно), в папке build содержимое этого apk.

Если Вы сразу не подписали а решили позже ,то нужно забросить приложение в папку sign и подписать программой SmartApkTool.exe на вкладке 'Подписать'.

Статьи по теме APK:


 

android - Как создать APK-файл в Eclipse?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
.

android - Как создать файл .apk из командной строки Windows?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
.

eclipse - Как создать apk файл в студии Android?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
.

android - как сгенерировать apk файл с помощью командной строки?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
.

android - Как создать файл apk с Apache Cordova

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
.

android - Как собрать apk без eclipse или изменить сборку apk с помощью файла конфигурации?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
.

Смотрите также