Взаимозависимости инструментов и библиотек

Зависимости сборки – это внешние компоненты, необходимые для успешной сборки проекта. Сборка может зависеть от библиотек, плагинов, подпроектов, Android SDK, таких инструментов, как компиляторы Kotlin и Java, сред разработки, например Android Studio, и самого Gradle.

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

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

Семантическое версионирование использует формат major.minor.patch. Например, в номере версии 4.8.3 цифра 4 – это major версия, 8 – minor версия, а 3 – номер patch. При изменении части major в библиотеке могут произойти критические изменения в API или поведении. Это может повлиять на сборку или поведение приложения.

Если меняются части minor (новые функции) или patch (исправления ошибок), разработчики библиотеки сообщают вам, что библиотека по-прежнему совместима и не должна влиять на ваше приложение.

Примечание. Некоторые библиотеки могут предоставлять экспериментальные API или API, требующие согласия. Эти API могут меняться даже в минорных или исправленных выпусках. Эти API существуют для того, чтобы разработчики могли попробовать новые функции или изменения API и отправить отзыв, пока они стабилизируются. Используйте эти API с осторожностью, так как они могут измениться и вам придется менять код между обновлениями minor и patch.

Отношения в вашей сборке

Сборки Android содержат связи между:

• Исходный код – код и ресурсы, которые вы контролируете.
• Зависимости библиотек – внешние библиотеки или модули, которые ваш проект и подпроекты включают при сборке.
• Инструменты – компиляторы, плагины и SDK, которые преобразуют исходный код в приложение или библиотеку.

Рисунок 1. Налаживайте сотрудничество

Исходный код

Исходный код – это код Kotlin или Java, который вы пишете в приложении или библиотеке. Подробную информацию об использовании C++ можно найти в документации по Android NDK.

Исходный код зависит от библиотек (включая библиотеки среды выполнения Kotlin и Java) и Android SDK, а также требует соответствующего компилятора Kotlin или Java.

Некоторые исходные коды содержат аннотации, которые требуют дополнительной обработки. Например, если вы пишете код Jetpack Compose, то добавляете аннотации, такие как @Composable, которые должны обрабатываться плагином компилятора Compose Kotlin. Другие аннотации могут обрабатываться Kotlin Symbol Processor (KSP) или отдельными инструментами обработки аннотаций.

Зависимости библиотеки

Библиотеки содержат байт-код, который включается в приложение. Это может быть JAR-файл Java, библиотека Android (AAR) или подпроект в вашей сборке. Многие библиотеки используют семантическое версионирование, которое позволяет понять, сохраняется ли совместимость при обновлении.

Библиотеки часто имеют транзитивные зависимости от других библиотек. Это упрощает управление зависимостями: вы указываете прямые зависимости, а Gradle загружает их вместе с транзитивными. Обновление прямых зависимостей может также привести к обновлению их транзитивных зависимостей.

Иногда для работы библиотеки требуется минимальная версия Android SDK во время выполнения (minSdk) или компиляции (compileSdk). Это необходимо, когда библиотека использует функции, включенные в Android SDK или предоставляемые им API JDK. Эффективное значение minSdk вашего приложения – это максимальное значение minSdk, запрашиваемое вашим приложением и всеми его прямыми и транзитивными зависимостями от библиотек.

Для использования некоторых библиотек может потребоваться определенный плагин Gradle. Эти вспомогательные плагины часто устанавливают процессоры символов Kotlin или другие процессоры аннотаций, которые генерируют код или изменяют компиляцию вашего источника для поддержки использования функций библиотеки. Например, Jetpack Room включает аннотации и KSP, который преобразует их в сгенерированный код для получения и изменения данных в базе данных. Для работы Jetpack Compose требуется плагин компилятора Compose, который изменяет аннотированные функции, чтобы управлять тем, как и когда они перезапускаются.

Инструменты

Gradle	Gradle – это инструмент сборки, который считывает файлы сборки и генерирует приложение или библиотеку, а также предоставляет API для плагинов, расширяющих его возможности. Gradle запускает несколько процессов на одной или нескольких виртуальных машинах Java, а его плагины Java вызывают инструменты Java внутри JDK.
Плагины Gradle	Плагины Gradle расширяют возможности Gradle, определяя новые задачи и конфигурацию. Применение плагина к сборке позволяет использовать определенные возможности сборки, настроенные как данные в скриптах сборки. Для сборок Android самым важным плагином Gradle является плагин Android Gradle (AGP).
Компиляторы	Компилятор Kotlin или Java преобразует исходный код в исполняемый байт-код. Компилятор Kotlin предоставляет API плагина, который позволяет выполнять внешний анализ и генерировать код непосредственно внутри компилятора, получая доступ к проанализированной структуре кода.
Плагины компилятора	Плагины компилятора выполняют анализ и генерацию кода внутри компилятора Kotlin, пока он анализирует ваш код. Они устанавливаются, когда вы применяете их плагины Gradle к сборке.
SDK для Android	Android SDK содержит платформу Android и Java API для определенной версии Android, а также соответствующие инструменты. Эти инструменты помогают управлять SDK, создавать приложения, а также взаимодействовать с устройствами Android и эмулировать их. Каждая версия Android SDK предоставляет определенные Java API, к которым может обращаться ваш исходный код, и поддержку десахаризации для использования этих API в более ранних версиях Android.
JDK	Java Development Kit, содержащий библиотеки Java и исполняемые файлы для компиляции исходного кода Java и запуска приложений Java. В сборке Android используется несколько JDK. Подробнее о версиях Java в сборках Android…

Области видимости Gradle

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

Например, AGP определяет области implementation и api, которые позволяют указать, должна ли зависимость быть доступна пользователям вашего подпроекта. Описания этих и других областей действия, используемых в сборке Android, приведены в разделе Настройка зависимостей.

Добавьте зависимости библиотек в блок dependencies файлов сборки в виде строк group:artifact:version:

Kotlin

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

Яркий

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

или в каталоге версий:

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

и укажите сгенерированные переменные в файлах сборки:

Kotlin

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

Яркий

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}