Плагин Android для Gradle. Конфигурация сборки проекта.

Home » AndroidStudio » Плагин Android для Gradle. Конфигурация сборки проекта.
AndroidStudio, Gradle Комментариев нет

оригинал
Система сборки Android собирает ресурсы приложения и исходный код, упаковывает их в APK файлы, которые вы можете тестировать, разворачивать, подписывать и распространять. Android Studio использует Gradle, продвинутый инструмент сборки, для автоматизации и управления процессом сборки, тем самым позволяя определить гибкие настройки конфигурации под разные проекты. Каждая конфигурация сборки может определять собственный набор кода и ресурсов, используя те части приложения, которые используются во всех его версиях. Плагин Android для Gradle работает с инструментом сборки обеспечивая те процессы и настройки конфигурации, которые специфичны именно для приложений на платформе Android.

Gradle и плагин Android работают независимо от Android Studio. Это значит, что вы можете собирать ваши Android приложения в среде Android Studio, с помощью командной строки или же на машинах где Android Studio не установлен(таких как серверы непрерывной интеграции). Если у вас нет Android Studio, вы можете узнать как собрать и запустить приложение с помощью командной строки. На выходе, независимо от выбранного вами(любого из вышеизложенных Android Studio, командная строка, сервер) способа сборки проекта вы получите одно и то же.

Замечание: Так как Gradle и Android plugin выполняются независимо от Android Studio, необходимо обнавлять инструмент сборки в отдельном порядке. (Как обновлять Gradle и плагин)

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

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

Процесс сборки

Процесс сборки вовлекает в себя участие разных инструментов и процессов, которые, в итоге, конвертируют ваш проект в файл APK(Android Application Package). Процесс сборки очень гибок, поэтому довольно полезно знать его внутреннюю логику.

схема процесса сборки типичного Android приложения
build-process_2x

Процесс сборки приложения Android обычно включает последовательность шагов:
1) Компилятор преобразует исходный код в выполняемый JVM Delvik(Android-версией джава машины)(DEX(Delvik Executable files). На выходе: байт код и скомпилированные ресурсы

2) Упаковщик APK(APK Packager) комбинирует DEX файлы и откомпилированные ресурсы в единый APK. Однако, прежде чем APK можно будет опубликовать, необходимо его подписать.

3) Упаковщик APK подписывает APK используя либо отладочное, либо релизное хранилище ключей.
а) Если вы создаете отладочную версию приложения, то есть если она нужна вам только для отладки, тестирования и профилирования, упаковщик подпишет приложения используя хранилище отладочных ключей. Android Studio по умолчанию конфигурирует проекты используя хранилище отладочных ключей.
б)Если же нужно собрать приложение для релиза и распространения, упаковщик подписывает его с помощью хранилища релизных ключей. Как сделать релизное хранилище можно узнать тут.

4) Перед тем как создать APK, упаковщик использует инструмент
zipalign для оптимизации приложения,чтобы оно расходовало меньше памяти будучи запущенным на устройстве.

Наконец, по завершению процесса сборки, у вас будет отладочный или релизный APK готовый к тестированию, развертыванию или распространению среди пользователей.

Свои конфигурации сборки

С помощью Gradle и плагина Android можно сконфигурировать сборку:

Типы сборок (Build Types)

Типы сборок определяют отдельные свойства которые Gradle использует собирая и упаковывая приложение, и обычно настраиваются под разные стадии жизненного цикла разработки. Например, отладочный тип сборки задействует отладочные возможности и подписывает приложение отладочным ключом. В то время как релизный тип может сократить код, произвести обфускацию(антиплагиатная мера) и подписать приложение релизным ключом. Вам нужно определить по крайней мере один тип сборки, чтобы построить приложение – Android Studio создает отладочный и релизный тип по-умолчанию. Чтобы приступить к настройке упаковки вашего приложения, узнайте как конфигурировать типы сборки здесь.

Продукты (Product Flavors)

Продукты представляют из себя разные версии вашего приложения, которые вы можете предложить пользователям, такие например, как бесплатные, пробные или платные версии.Вы можете кастомизировать продукты используя в них отличный от других продуктов код и отличные ресурсы. Оставляя при этом часть приложения общей для всех версий продукта. “Продукты” – вещь опциональная и вы можете создавать их вручную. Как создавать различные версии продуктов можно узнать тут.

Варианты сборок (Build Variants)

Варианты сборок – это результат скрещивания типов сборки и продуктов, и представляют из себя конфигурации Gradle для сборки приложения.Используя варианты сборки, вы можете собрать, к примеру, отладочную версию для полной версии продукта или версию подписанного релиза для распространения. Вам не обязательно отдельным образом, напрямую настраивать варианты сборки, если у вас уже есть продукты и типы сборок их формирующие, они создаются автоматически. Как создавать и управлять вариантами сборок можно узнать тут.

Записи манифеста(Manifest Entries)

Можно определить значения для некоторых свойств файла манифеста в конфигурации варианта сборки. Эти значения сборки переписывают значения определенные в файле манифеста.Эту возможность трудно переоценить, если нужно сгенерировать несколько APK для ваших модулей приложений, где каждый файл APK имеет свое имя, минимальную версию SDK, целевую версию SDK. Когда присутствуют несколько файлов манифеста, Gradle объединяет настройки манифеста.

Зависимости

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

Подписывание

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

ProGuard

Система сборки позволяет вам определить правила ProGuard для каждого из вариантов сборки. Система сборки может выполнить запуск ProGuard для сокращения и обфускации классов исходного кода во время процесса сборки.

Поддержка нескольких APK

Система сборки позволит вам автоматически собрать разные APK, каждый из которых содержит только тот код и ресурсы, которые соответствуют определенным плотностям экранного разрешения или бинарному интерфейсу приложения(Application Binary Interface (ABI)). Больше информации о том как собрать несколько APK тут.

Файлы конфигурации сборки

Cоздание своих конфигураций сборки потребует от вас внесения изменений в один или несколько конфигурационных файлов или файлов build.gradle. Эти простые текстовые файлы используют доменно специфичный язык(Domain Specific Language (DSL)) для описания и манипулирования логикой сборки использующей, в свою очередь, Groovy, который является динамическим языком виртуальной машины Java.(скрипты из файлов gradle работают с помощью groovy). Однако, знания Groovy не требуются для того, чтобы начать конфигурировать свою сборку, потому что плагин Android для Gradle представляет большинство необходимых DSL-элементов. Больше об
Android плагине DSL.
При создании нового проекта, Android Studio автоматически создает некоторые из этих файлов(как показано на схеме ниже) и заполняет их, опираясь на разумные значения по умолчанию.

Структура проекта по умолчанию для модуля приложения
project-structure_2x

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

Файл настройки Gradle (settings.gradle)

Файл settings.gradle расположен в коренной директории проекта, он рассказывает сборщику Gradle какие модули нужно подключить, чтобы собрать приложение. Для большинстаа приложений, этот файл прост и включает лишь следующие строки

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

However, multi-module projects need to specify each module that should go into the final build.

Файл сборки верхнего уровня(build.gradle)

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

Обычное содержание файла build.gradle сразу после создания нового проекта:

Конфигурация общих настроек проекта

Для Android-проектов, которые содержат несколько модулей, может оказаться полезным выводить некоторые настройки на уровень всего проекта(project-wide properties) и разделять их со всеми модулями проекта. Это можно сделать добавив экстра настройки в блок ext в файле build.gradle верхнего уровня.

Для доступа к этим настройкам из модуля данного проекта, схожий синтаксис используется в файлах build.gradle модулей проекта
как показано ниже.

Замечание: хотя Gradle позволяет определить настройки проекта(project-wide properties) и на уровне модуля, этого следует избегать. не нужно делить настройки между модулями, которые можно сопрягать. Сопряжение модулей(module coupling) затрудняет экспорт модуля как самостоятельного проекта и предотвращает параллельную сборку проектов дабы ускорить сборку многомодульных проектов.

Файл сборки уровня модуля(build.gradle)

Файл build.gradle уровня модуля расположен в каждой директории project/module/ и позволяет конфигурировать настройки сборки для текущего модуля. Такая конфигурация позволяет настраивать типы сборки, продукты и другие настройки упаковки. Эти настройки перекрывают все что написано в файлах main/ app manifest и в build.gradle верхнего уровня.

Пример настройки файла build.gradle уровня модуля с некоторыми популярными настройками и основными DSL элементами.

Файлы свойств Gradle(Gradle Properties Files)

Gradle также имеет два файла свойств, расположенных в коренной директории проекта, в которых можно прописать настройки самого инструментария Gradle.

Здесь можно настроить Gradle под проект: например задать размер файла подкачки. Больше информации тут – настройка окружения сборки.

Конфигурирует свойства локального окружения системы сборки, такие как путь к SDK. Контент этого файла автоматически генерируется с помощью Android Studio и он специфичен для локального окружения разработки(build environment). Этот файл нельзя модифицировать вручную или подключать к системе контроля версий.

Синхронизация проекта с файлами Gradle

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

Чтобы синхронизировать файлы проекта, нажмите на ссылку Sync Now, желтой панели уведомлений, или нажмите на Sync Project панели меню. Если Android Studio обнаруживает наличие ошибок в конфигурации, например, что исходный код использует API выше, чем указанная версия SDK, выскакивает соответствующее уведомление.

Исходные наборы(source sets)

Android Studio логически группирует исходные коды и ресурсы каждого модуля в наборы ресурсов(source sets). Папка main/ ресурса включает коды и ресурсы используемые всеми вариантами сборки (build variants). Дополнительные директории наборов ресурсов не создаются программой Android Studio автоматически при создании вариантов сборки. Однако, создание наборов ресурсов, схожих с main/ помогает организовать файлы и ресурсы, которые и только которые Gradle будет использовать при сборке разнообразных версий приложения.

Этот набор ресурсов включает код и ресурсы общие для всех вариантов сборки.

Создайте этот набор ресурсов чтобы включить код и ресурсы только для определенного типа сборки.

Создайте этот набор ресурсов чтобы включить код и ресурсы только под определенный продукт(product flavor).

Замечание: если вы хотите сконфигурировать вашу сборку для того чтобы объединить сразу несколько продуктов, вы можете создать для каждой комбинации продуктов соответствующую директорию по следующему образцу: src/productFlavor1ProductFlavor2/

Создайте этот набор ресурсов чтобы включить код и ресурсы только для определенного варианта сборки.

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

src/fullDebug/ (the build variant source set)
src/debug/ (the build type source set)
src/full/ (the product flavor source set)
src/main/ (the main source set)

Замечание: когда вы создаете новый файл или директорию в Android Studio используя File > New …, вы создаете ее для определенного набора ресурсов. Наборы ресурсов, которые вы выбираете основаны на ваших конфигурациях сборки, и Android Studio автоматически создает необходимые директории если их к тому времени не существует.

Если разные наборы ресурсов содержат разные версии одного и того же файла, Gradle использует следующий порядок приоритетов, какой из файлов использовать(наборы ресурсов слева главнее файлов и настроек наборов ресурсов справа):

вариант сборки > тип сборки > продукт > главный набор ресурсов > библиотечные зависимости
(build variant > build type > product flavor > main source set > library dependencies)

Это позволяет Gradle использовать файлы, выделенные для варианта сборки, который вы пытаетесь собрать используя заново активности, логику приложения, и ресурсы общие с другими версиями приложения. При соединении нескольких манифестов Gradle использует такой же порядок приоритетов, так что каждый вариант сборки может определить несколько компонентов или разрешений в окончательном манифесте. Чтобы узнать больше о создании наборов ресурсов, прочтите Create Source Sets for Build Variants.

LEAVE A COMMENT