Добавить зависимости сборки

Система сборки Gradle в Android Studio позволяет включать внешние двоичные файлы или другие библиотечные модули в вашу сборку в качестве зависимостей. Зависимости могут располагаться на вашем компьютере или в удалённом репозитории, и любые объявленные ими транзитивные зависимости также автоматически включаются. На этой странице описывается, как использовать зависимости в вашем проекте Android, включая сведения о поведении и конфигурациях, специфичных для плагина Android Gradle (AGP). Более подробное концептуальное руководство по зависимостям Gradle см. в руководстве Gradle по управлению зависимостями , но помните, что ваш проект Android должен использовать только конфигурации зависимостей, определённые на этой странице.

Добавить зависимость от библиотеки или плагина

Лучший способ добавления и управления зависимостями сборки — использовать каталоги версий, метод, который новые проекты используют по умолчанию. В этом разделе рассматриваются наиболее распространённые типы конфигураций, используемые в проектах Android; за дополнительными возможностями обратитесь к документации Gradle . Пример приложения, использующего каталоги версий, см. в статье «Теперь в Android» . Если у вас уже настроены зависимости сборки без каталогов версий и у вас многомодульный проект, рекомендуем выполнить миграцию .

Инструкции по добавлению и управлению собственными зависимостями (встречаются нечасто) см. в разделе Собственные зависимости .

В следующем примере мы добавляем в наш проект удалённую бинарную зависимость ( библиотеку Jetpack Macrobenchmark ), локальную зависимость от модуля библиотеки ( myLibrary ) и зависимость от плагина (плагин Android Gradle). Вот общие шаги для добавления этих зависимостей в ваш проект:

1. Добавьте псевдоним для нужной вам версии зависимости в раздел [versions] файла каталога версий с именем libs.versions.toml (в каталоге gradle в представлении Project или в Gradle Scripts в представлении Android ):

   [versions]
   agp = "8.3.0"
   androidx-macro-benchmark = "1.2.2"
   my-library = "1.4"
   
   [libraries]
   ...
   
   [plugins]
   ...
   

   Псевдонимы могут включать дефисы или символы подчёркивания. Эти псевдонимы генерируют вложенные значения, на которые можно ссылаться в скриптах сборки. Ссылки начинаются с имени каталога, части libs файла libs.versions.toml . При использовании каталога с одной версией рекомендуется оставить значение по умолчанию «libs».

2. Добавьте псевдоним для зависимости в разделах [libraries] (для удаленных двоичных файлов или локальных библиотечных модулей) или [plugins] (для плагинов) файла libs.versions.toml .

   [versions]
   ...
   
   [libraries]
   androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
   my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }
   
   [plugins]
   androidApplication = { id = "com.android.application", version.ref = "agp" }
   

   Некоторые библиотеки доступны в опубликованном списке материалов (BOM), который группирует семейства библиотек и их версии. Вы можете включить список материалов (BOM) в свой каталог версий и файлы сборки, и система будет управлять этими версиями автоматически. Подробнее см. в разделе «Использование списка материалов» .

3. Добавьте ссылку на псевдоним зависимости в скрипт сборки модуля(ей), которому эта зависимость необходима. При ссылке на него из скрипта сборки замените подчёркивания и тире в псевдониме точками. Наш скрипт сборки на уровне модуля будет выглядеть следующим образом:

   Котлин

   plugins {
     alias(libs.plugins.androidApplication)
   }
   
   dependencies {
     implementation(libs.androidx.benchmark.macro)
     implementation(libs.my.library)
   }

   Круто

   plugins {
     alias 'libs.plugins.androidApplication'
   }
   
   dependencies {
     implementation libs.androidx.benchmark.macro
     implementation libs.my.library
   }

   Ссылки на плагины включают plugins после имени каталога, а ссылки на версии включают versions после имени каталога (ссылки на версии встречаются редко; примеры ссылок на версии см. в разделе Зависимости с одинаковыми номерами версий). Ссылки на библиотеки не включают квалификатор libraries , поэтому вы не можете использовать versions или plugins в начале псевдонима библиотеки.

Настроить зависимости

Внутри блока dependencies вы можете объявить зависимость библиотеки, используя одну из нескольких различных конфигураций зависимостей (например, implementation ранее). Каждая конфигурация зависимости предоставляет Gradle различные инструкции по её использованию. В следующей таблице описаны все конфигурации, которые вы можете использовать для зависимости в вашем проекте Android.

dependencies {
  // Executes lint checks from the ":checks" project at build time.
  lintChecks(project(":checks"))
  // Compiles lint checks from the ":checks-to-publish" into a
  // lint.jar file and publishes it to your Android library.
  lintPublish(project(":checks-to-publish"))
}

dependencies {
  // Executes lint checks from the ':checks' project at build time.
  lintChecks project(':checks')
  // Compiles lint checks from the ':checks-to-publish' into a
  // lint.jar file and publishes it to your Android library.
  lintPublish project(':checks-to-publish')
}

Настройте зависимости для конкретного варианта сборки

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

Например, чтобы добавить удаленную бинарную зависимость только к вашей «бесплатной» версии продукта с помощью конфигурации implementation , используйте следующее:

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

Однако если вы хотите добавить зависимость для варианта, который объединяет разновидность продукта и тип сборки, то вам необходимо инициализировать имя конфигурации:

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

Чтобы добавить зависимости implementation для локальных тестов и инструментированных тестов, это выглядит так:

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
}

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.6.1'
}

Однако некоторые конфигурации в этой ситуации не имеют смысла. Например, поскольку другие модули не могут зависеть от androidTest , при использовании конфигурации androidTestApi вы получите следующее предупреждение:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

Порядок зависимости

Порядок, в котором вы перечисляете зависимости, указывает на приоритет каждой из них: первая библиотека имеет более высокий приоритет, чем вторая, вторая — более высокий приоритет, чем третья, и т. д. Этот порядок важен в случае объединения ресурсов или добавления элементов манифеста из библиотек в ваше приложение.

Например, если в вашем проекте заявлено следующее:

• Зависимость от LIB_A и LIB_B (в указанном порядке)
• И LIB_A зависит от LIB_C и LIB_D (именно в таком порядке)
• И LIB_B также зависит от LIB_C

Тогда порядок плоской зависимости будет следующим:

1. LIB_A
2. LIB_D
3. LIB_B
4. LIB_C

Это гарантирует, что LIB_A и LIB_B могут переопределить LIB_C ; и LIB_D по-прежнему имеет более высокий приоритет, чем LIB_B поскольку LIB_A (которая зависит от нее) имеет более высокий приоритет, чем LIB_B .

Дополнительную информацию об объединении манифестов из разных источников/зависимостей проекта см. в разделе Объединение нескольких файлов манифеста .

Информация о зависимостях для Play Console

При сборке приложения AGP включает метаданные, описывающие зависимости библиотек, скомпилированных в ваше приложение. При загрузке приложения Play Console проверяет эти метаданные, чтобы выдавать оповещения об известных проблемах с SDK и зависимостями, используемыми вашим приложением, а в некоторых случаях — и рекомендации по их решению.

Данные сжимаются, шифруются ключом подписи Google Play и сохраняются в блоке подписи вашего релизного приложения. Мы рекомендуем сохранить этот файл зависимостей для безопасного и комфортного использования. Вы можете отказаться от этого, добавив следующий блок dependenciesInfo в файл build.gradle.kts вашего модуля.

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

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

Информация о SDK

Android Studio отображает предупреждения lint в файле каталога версий и диалоговом окне структуры проекта для общедоступных SDK в индексе Google Play SDK, если возникают следующие проблемы:

• Авторы отмечают, что SDK устарели.
• Пакеты SDK нарушают политику Play.
• В SDK имеются известные уязвимости безопасности.
• Авторы объявили пакеты SDK устаревшими.

Предупреждения являются сигналами о том, что вам следует обновить эти зависимости, поскольку использование устаревших версий может помешать вам публиковать приложения в Google Play Console в будущем.

Добавить зависимости сборки без каталогов версий

Мы рекомендуем использовать каталоги версий для добавления и управления зависимостями, но для простых проектов они могут быть не нужны. Вот пример файла сборки, в котором каталоги версий не используются:

plugins {
    id("com.android.application")
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation("com.example.android:app-magic:12.3")
    // Dependency on a local library module
    implementation(project(":mylibrary"))
}

plugins {
    id 'com.android.application'
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
    // Dependency on a local library module
    implementation project(':mylibrary')
}

В этом файле сборки объявлена ​​зависимость от версии 12.3 библиотеки «app-magic» внутри группы пространства имён «com.example.android». Объявление удалённой двоичной зависимости представляет собой сокращённую запись следующего:

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

В файле сборки также объявляется зависимость от модуля библиотеки Android с именем «mylibrary»; это имя должно совпадать с именем библиотеки, указанным в файле settings.gradle.kts с помощью include: :. При сборке приложения система сборки компилирует модуль библиотеки и упаковывает полученное скомпилированное содержимое в приложение.

Файл сборки также объявляет зависимость от плагина Android Gradle ( com.application.android ). Если у вас есть несколько модулей, использующих один и тот же плагин, в classpath сборки для всех модулей может быть только одна версия плагина. Вместо указания версии в каждом скрипте сборки модуля, необходимо включить зависимость от плагина в корневой скрипт сборки вместе с версией и указать, что её не следует применять. Добавление apply false указывает Gradle учитывать версию плагина, но не использовать её в корневой сборке. Обычно корневой скрипт сборки пуст, за исключением этого блока plugins .

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

plugins {
    id ‘com.android.application’ version ‘8.3.0-rc02’ apply false
}

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

plugins {
    id("com.android.application") version "8.3.0"
}

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}