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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Система сборки 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), который группирует семейства библиотек и их версии. Вы можете включить список материалов в свой каталог версий и файлы сборки и позволить ему управлять этими версиями для вас. Подробнее см. в разделе Использование списка материалов .

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"; это имя должно совпадать с именем библиотеки, определенным с помощью include: в вашем файле settings.gradle.kts . Когда вы собираете свое приложение, система сборки компилирует модуль библиотеки и упаковывает полученное скомпилированное содержимое в приложение.

Файл сборки также объявляет зависимость от плагина 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'
}