В чем различие complie vs runtime scope maven api vs implementation gradle

Обновлено: 05.07.2024

После обновления до Android Studio 3.0 и создания нового проекта я заметил, что в build.gradle есть новый способ добавления новых зависимостей вместо compile - implementation и вместо testCompile - testImplementation .

В чем разница между ними и что я должен использовать?

; Т.Л. Dr

compile с implementation (если вам не нужна транзитивность) или api (если вам нужна транзитивность)
testCompile с testImplementation
debugCompile с debugImplementation
androidTestCompile с androidTestImplementation
compileOnly все еще действует. Он был добавлен в 3.0, чтобы заменить предоставленный и не компилировать. ( provided появился, когда у Gradle не было имени конфигурации для этого варианта использования, и он был назван в соответствии с предоставленной областью Maven.)

Это одно из последних изменений, появившихся в Gradle 3.0, что Google анонсирован на IO17 .

Конфигурация compile : сейчас устарела и должна быть заменена на implementation или api

зависимости больше не попадают в путь к классам компиляции потребителей, поэтому вы никогда не будете случайно зависеть от транзитивной зависимости
более быстрая компиляция благодаря уменьшенному размеру пути к классам
меньше перекомпиляций при изменении зависимостей реализации: не нужно перекомпилировать потребителей
более чистая публикация: при использовании в сочетании с новым плагином maven-publish библиотеки Java создают файлы POM, которые точно различают то, что требуется для компиляции с библиотекой, и то, что требуется для использования библиотеки во время выполнения (в Другими словами, не смешивайте то, что необходимо для компиляции самой библиотеки, и то, что нужно для компиляции с библиотекой).

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

Этот ответ продемонстрирует разницу между implementation , api и compile в проекте.

Допустим, у меня есть проект с тремя модулями Gradle:

приложение (приложение Android)
myandroidlibrary (библиотека Android)
myjavalibrary (библиотека Java)

app имеет myandroidlibrary в качестве зависимостей. myandroidlibrary имеет myjavalibrary в качестве зависимостей.

myjavalibrary имеет класс MySecret

myandroidlibrary имеет класс MyAndroidComponent , который манипулирует значением из класса MySecret .

Наконец, app интересует только значение из myandroidlibrary

Теперь поговорим о зависимостях .

app нужно использовать :myandroidlibrary , поэтому в app build.gradle используйте implementation .

( Примечание : Вы также можете использовать api/compile. Но подождите немного.)

Как вы думаете, myandroidlibrary build.gradle должен выглядеть? Какой объем мы должны использовать?

У нас есть три варианта:

В чем разница между ними и что я должен использовать?

Компилировать или API (вариант № 2 или № 3)

Если вы используете compile или api . Наше приложение Android теперь может получить доступ к зависимости myandroidcomponent , которая является классом MySecret .

Реализация (вариант № 1)

Если вы используете конфигурацию implementation , MySecret не предоставляется.

Итак, какую конфигурацию вы должны выбрать? Это действительно зависит от вашего требования.

Если вы хотите выставить зависимости , используйте api или compile .

Если вы не хотите показывать зависимости (скрывая свой внутренний модуль), используйте implementation .

Конфигурация Compile устарела и должна быть заменена на implementation или api .

Основное различие между стандартным плагином Java и библиотекой Java заключается в том, что последний представляет концепцию API, предоставляемого потребителям. Библиотека - это компонент Java, предназначенный для использования другими компонентами. Это очень распространенный вариант использования в многопроектных сборках, но также, как только у вас есть внешние зависимости.
Плагин предоставляет две конфигурации, которые можно использовать для объявления зависимостей: API и реализация. Конфигурация api должна использоваться для объявления зависимостей, которые экспортируются библиотечным API, тогда как конфигурация реализации должна использоваться для объявления зависимостей, которые являются внутренними для компонента.

Для дальнейшего объяснения обратитесь к этому изображению.

Краткое решение:

Лучший подход - заменить все зависимости compile на зависимости implementation . И только в случае утечки интерфейса модуля вы должны использовать api . Это должно вызвать гораздо меньше перекомпиляции.

Объясните больше:

До Android Плагин Gradle 3.0 : у нас была большая проблема: одно изменение кода приводит к перекомпиляции всех модулей. Основная причина этого заключается в том, что Gradle не знает, пропускаете ли вы интерфейс модуля через другой или нет.

После Android Плагин Gradle 3.0 : последний Android Плагин Gradle теперь требует от вас явного определения утечки интерфейс модуля. Исходя из этого, он может сделать правильный выбор в отношении того, что следует перекомпилировать.

Таким образом, зависимость compile устарела и заменена двумя новыми:

api : вы пропускаете интерфейс этого модуля через свой собственный интерфейс, что означает то же самое, что и старая зависимость compile

implementation : вы используете этот модуль только для внутреннего использования и не пропускаете его через интерфейс

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

Я пытаюсь понять, в чем разница между конфигурацией api и implementation при построении моих зависимостей.
В документации говорится, что implementation имеет лучшее время сборки, но, видя это comment в аналогичном вопросе, мне стало интересно, правда ли это. Поскольку я не эксперт в gradle, я надеюсь, что кто-то может помочь. Я уже читал документацию, но мне было интересно узнать о простом понимании.

ОТВЕТЫ

Ответ 1

Ключевое слово Gradle compile устарело в пользу ключевых слов api и implementation для настройки зависимостей.

Использование api эквивалентно использованию устаревшего compile , поэтому, если вы замените все compile на api , все будет работать как всегда.

Чтобы понять ключевое слово implementation , рассмотрим следующий пример.

Пример

Предположим, у вас есть библиотека с именем MyLibrary , которая внутренне использует другую библиотеку с именем InternalLibrary . Примерно так:

Предположим, что MyLibrary build.gradle использует конфигурацию api в dependencies<> следующим образом:

Вы хотите использовать MyLibrary в своем коде, чтобы в приложении build.gradle вы добавили эту зависимость:

Используя конфигурацию api (или устарела compile ), вы можете получить доступ к InternalLibrary в коде своего приложения:

Таким образом, модуль MyLibrary потенциально "пропускает" внутреннюю реализацию чего-либо. Вы не должны (быть в состоянии) использовать это, потому что оно не импортировано вами напрямую.

Конфигурация implementation была введена для предотвращения этого. Так что теперь, если вы используете implementation вместо api в MyLibrary :

вы больше не сможете звонить InternalLibrary.giveMeAString() в коде своего приложения.

Этот вид боксерской стратегии позволяет плагину Android Gradle знать, что если вы редактируете что-то в InternalLibrary , он должен запускать только перекомпиляцию MyLibrary , а не перекомпиляцию всего вашего приложения, потому что у вас нет доступа к InternalLibrary .

Когда у вас много вложенных зависимостей, этот механизм может значительно ускорить сборку. (Смотрите видео в конце, чтобы лучше понять это)

ВЫВОДЫ

Когда вы переключаетесь на новый плагин Android Gradle 3.X.X, вы должны заменить все свои compile на ключевое слово implementation (1 *). Затем попробуйте скомпилировать и протестировать ваше приложение. Если все в порядке, оставьте код как есть, если у вас есть проблемы, возможно, у вас что-то не так с вашими зависимостями, или вы использовали что-то частное и не более доступное. Предложение от инженера плагинов Gradle для Android Джерома Дочеза (1) *)

Если вы являетесь управляющим библиотекой, вы должны использовать api для каждой зависимости, которая необходима для общедоступного API вашей библиотеки, в то же время используйте implementation для тестовых зависимостей или зависимостей, которые не должны использоваться конечными пользователями.

Полезная статья, демонстрирующая разницу между реализацией и api

Лит (Это то же самое видео, разделенное для экономии времени)

Ответ 2

Мне нравится думать о зависимости api как public (видятся другими модулями), тогда как implementation зависимость как private (видна только этим модулем).

Обратите внимание, что в отличие от переменных и методов public / private зависимостей api / implementation не выполняются средой выполнения. Это просто оптимизация времени сборки, которая позволяет Gradle знать, какие модули необходимо перекомпилировать, когда одна из зависимостей изменит свой API.

Ответ 3

lib1 вас есть модуль app который использует lib1 в качестве библиотеки, а lib1 использует lib2 в качестве библиотеки. Примерно так: app → lib1 → lib2 .

Теперь при использовании api lib2 в lib1 app может видеть коды lib2 при использовании: api lib1 или implementation lib1 в модуле app .

НО при использовании implementation lib2 в lib1 , app не может видеть коды lib2 .

Ответ 4

При использовании Android Gradle плагина 3.0 в вашем проекте вы могли заметить, что ключевое слово компиляции теперь устарело в пользу реализации и api. Давайте рассмотрим их оба примера.

Предположим, проект с четырьмя библиотечными модулями.

LibraryA
библиотека B
LibraryC
LibraryD

Для чего дерево зависимостей выглядит следующим образом:

Библиотека D

Библиотека C

Библиотека B

Библиотека A

Из вышеприведенных файлов классов видно, что LibraryA и LibraryB в зависимости от LibraryC и LibraryD соответственно. Поэтому эти зависимости, необходимо добавить в build.gradle файлы. Скомпилируйте (2.0) или Api (3.0):

Новое ключевое слово api точно совпадает с старым ключевым словом компиляции. Таким образом, если весь компилятор заменен на api, он работает отлично. Теперь давайте добавим зависимость LibraryD с помощью ключевого слова api в LibraryB.

Аналогично, LibraryB добавляется в модуль приложения.

Теперь доступ к библиотекам и библиотекам можно получить из модуля приложения. В примерном приложении обе библиотеки обращаются следующим образом:

Реализация (3.0):

Время, чтобы узнать, как реализация отличается от api. Вернемся к примеру, на этот раз можно импортировать LibraryC в библиотеку с использованием ключевого слова реализации.

То же самое для модуля App.

Теперь, если мы попытаемся получить доступ к LibraryC из модуля приложения, студия Android выведет ошибку.

Это означает, что доступ к LibraryC не может быть получен непосредственно из модуля App, если мы используем реализацию вместо api. Итак, в чем польза от этого?

Реализация vs api:

В первом сценарии LibraryD скомпилирован с помощью api. Если какое-либо изменение реализовано внутри LibraryD, Gradle необходимо перекомпилировать библиотечные библиотеки, библиотечные библиотеки и все другие модули, которые импортируют LibraryB, поскольку любой другой модуль может использовать реализацию LibraryD.

Но во втором случае, если какая-либо реализация в LibraryC изменилась, Gradle просто нужно перекомпилировать LibraryC и LibraryA, поскольку любой другой класс, который не импортирует LibraryC напрямую, не может использовать какую-либо его реализацию.

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

После обновления до Android Studio 3.0 и создания нового проекта я заметил, что в build.gradle существует новый способ добавления новых зависимостей вместо compile implementation вместо testCompile - testImplementation .

Какая разница между ними и чем я должен пользоваться?

ТЛ; др

compile с implementation
testCompile with testImplementation
debugCompile with debugImplementation
androidTestCompile с androidTestImplementation
compileOnly все еще действует. Он был добавлен в 3.0, чтобы заменить предоставленный и не компилировать. ( provided что Gradle не имеет имени конфигурации для этого варианта использования и назвал его в соответствии с предоставленной областью Maven.)

Конфигурация compile теперь устарела и должна быть заменена implementation или api

зависимости больше не попадают в путь к классам компиляции потребителей, поэтому вы никогда не будете случайно зависеть от транзитивной зависимости
более быстрая компиляция благодаря уменьшенному размеру пути к классам
меньше перекомпиляций при изменении зависимостей реализации: потребителям не нужно будет перекомпилировать
Более чистая публикация: при использовании в сочетании с новым плагином maven-publish библиотеки Java создают файлы POM, которые точно различают то, что требуется для компиляции с библиотекой, и то, что требуется для использования библиотеки во время выполнения (другими словами, не смешайте то, что необходимо для компиляции самой библиотеки и что нужно для компиляции с библиотекой).

Примечание: если вы используете только библиотеку в модуле приложения -the common case-, вы не заметите никакой разницы.
Вы увидите разницу, только если у вас есть сложный проект с модулями, зависящими друг от друга, или вы создаете библиотеку.

потребитель - модуль, использующий библиотеку. в случае с Android это приложение для Android. Я думаю, что это ясно, и я не уверен, что это то, что вы просите. Вот как это звучало и для меня тоже. Но если я делаю библиотеку, конечно, я хочу, чтобы ее API был открыт для приложения. Иначе, как разработчик приложения будет использовать мою библиотеку? Вот почему я не понимаю смысла implementation скрывающей зависимость. Имеет ли смысл мой вопрос? да, теперь это имеет смысл, если ваше приложение зависит от библиотеки x, которая сама зависит от y, z. если вы используете implementation будет отображаться только x api, но если вы используете api y, z также будет отображаться. Понял! Это имеет больше смысла сейчас. Вы можете добавить это объяснение в свой ответ. Это понятнее, чем цитируемая документация. Также замените предоставленный compileOnly Кто-нибудь может объяснить, пожалуйста, простым языком? У меня есть дополнительный вопрос. Это решает конфликты между версиями зависимостей, если они были скрыты реализацией, но мне все еще нужно включить зависимости в приложение? Хотя библиотека, которая использует их, имеет их в качестве реализации? @humazed, что является заменой для компиляции аромата. например, devCompile to? Я не понимаю, что вы имеете в виду под «ароматом компиляции», если вы имеете в виду, что у вас есть аромат под названием «devCompile», то это не связано с этим изменением и вам не нужно ничего делать; вероятно, это не связано с реализацией. Я никогда не слышал о такой проблеме, вы могли бы задать отдельный вопрос для дальнейшего изучения вашей проблемы. Спасибо за ссылку на документацию Gradle. Я хотел бы отметить еще одно важное утверждение: « В качестве руководства, вы должны предпочесть конфигурацию implementation первую очередь: утечка типов реализации потребителям затем напрямую приведет к ошибке компиляции потребителей, которая может быть решена либо удалением введите из общедоступного API или рекламируйте зависимость как зависимость API. "Это объясняется более подробно в другом ответе, но я думаю, что было бы лучше включить это, так как ваш ответ в настоящее время является самым популярным. Итак, когда мы должны использовать API вместо реализации? НЕ заменяйте компиляцию реализацией, если вы используете плагин maven-publish для публикации библиотеки в репозиторий maven. Если ваша зависимость gradle компилируется , сгенерированный pom будет иметь транзитивную зависимость области компиляции. Если Gradle зависимости является реализацией, генерируемый П будет иметь нетранзитивную выполнение область видимости зависимость. Обратите внимание, что если используемая вами библиотека является локальной (файл .aar в папке libs), она не будет транзитивной, несмотря на то, что вы используете api. @Behnam не могли бы вы объяснить, что не так с ответом.

Этот ответ продемонстрирует разницу между implementation , api и compile в проекте. Допустим, у меня есть проект с тремя модулями Gradle:

приложение (приложение для Android)
myandroidlibrary (библиотека Android)
myjavalibrary (библиотека Java)

app имеет myandroidlibrary как зависимости. myandroidlibrary имеет myjavalibrary как зависимости.

приложение → myandroidlibrary → myjavalibrary

myjavalibrary имеет класс MySecret

myandroidlibrary имеет класс MyAndroidComponent который манипулирует значением из класса MySecret .

Наконец, app интересует только значение из myandroidlibrary

Теперь давайте поговорим о зависимостях в app build.gradle. Это просто и интуитивно понятно. app нужно использовать :myandroidlibrary

Но как, на ваш взгляд, должна выглядеть моя myandroidlibrary android myandroidlibrary build.gradle? Какой объем мы должны использовать?

У нас есть три варианта:

Какая разница между ними и что я должен использовать?

Компилировать и Api

Если вы используете compile и api . Наше приложение для Android теперь может получить доступ myandroidcomponent зависимости myandroidcomponent , которая является классом MySecret .

Реализация

Если вы используете конфигурацию implementation , MySecret не выставляется.

Итак, какую конфигурацию вы должны выбрать? Это действительно зависит от вашего требования.

Если вы хотите выставить зависимости, используйте api или compile , если вы не хотите выставлять зависимости (скрывая свой внутренний модуль), тогда используйте implementation .

Я добавил зависимость к одному файлу jar, используя реализацию, если он не предоставляет доступ к нему, почему я все еще могу получить и мой код работает нормально? Реализация @ smkrn110 представит вашу библиотеку jar, но не ваши библиотеки зависимостей jar. @WijaySharma принятый ответ гласит, что compile не гарантирует того же, что гарантирует api . Поймал java.lang.NoClassDefFoundError: Не удалось разрешить: L <package> / MySecret, когда добавить зависимость myandroidlibrary как .jar на приложение. Я думаю, что это должен быть принятый ответ. Хорошо объяснил! «Это просто и интуитивно понятно», когда я читаю, это не просто и интуитивно понятно для меня. Пожалуйста, опишите, почему моя библиотека должна быть реализована. @ MarianPaździoch спасибо за ваш отзыв, я обновил ответ. Чтобы ответить на ваш вопрос: не имеет значения, какое app области зависимостей будет использовать для myandroidlibrary , вы можете использовать api / compile или реализацию. Поскольку в этом примере app не нужно выставлять свою зависимость. В отличие от модуля myandroidlibrary , который выставит свою зависимость от app . Очень подробный ответ, но вы должны прочитать «роман», прежде чем на самом деле получите ответ на вопрос. Я бы изменил свое отрицательное голосование на положительное, если бы в первом абзаце был быстрый ответ, а затем пояснительная записка.

Compile конфигурация устарела и должна быть заменена на implementation или api .

Ключевое различие между стандартным Java-плагином и Java Плагин библиотеки заключается в том, что последний вводит концепцию API подвергается воздействию потребителей. Библиотека представляет собой компонент Java, предназначенный для потребляется другими компонентами. Это очень распространенный случай использования в многопроектные сборки, но также, как только у вас есть внешние зависимостей.

Плагин предоставляет две конфигурации, которые могут быть использованы для объявления зависимостей: api и реализация. Конфигурация api должна быть используется для объявления зависимостей, которые экспортируются библиотечным API, тогда как конфигурацию реализации следует использовать для объявления зависимые, которые являются внутренними для компонента.

Для дальнейшего объяснения обратитесь к этому изображению.

Краткое описание:

Лучшим подходом является замена всех зависимостей compile зависимостями implementation . И только там, где вы протекаете интерфейс модулей, вы должны использовать api . Это должно привести к значительному перекомпиляции.

Объясни подробней:

Перед плагином Android Gradle 3.0: у нас была большая проблема, связанная с одним изменением кода, заставляя все модули перекомпилировать. Основная причина этого заключается в том, что Gradle не знает, протекает ли интерфейс модуля через другой или нет.

После плагина Android Gradle 3.0: последний плагин Android Gradle теперь требует, чтобы вы явно определяли, протекает ли интерфейс модулей. Исходя из этого, он может сделать правильный выбор на том, что он должен перекомпилировать.

Таким образом, зависимость от compile устарела и заменена двумя новыми:

api : вы протекаете интерфейс этого модуля через свой собственный интерфейс, что означает то же, что и прежняя зависимость от compile

implementation : вы используете этот модуль только внутри и не пропускаете его через свой интерфейс

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

После обновления до Android Studio 3.0 и создания нового проекта я заметил, что в build.gradle есть новый способ добавления новых зависимостей вместо compile , есть implementation и вместо > есть testImplementation .

В чем разница между ними и что я должен использовать?

compile с implementation (если вам не нужна транзитивность) или api (если вам нужна транзитивность)
testCompile с testImplementation
debugCompile с debugImplementation
androidTestCompile с androidTestImplementation
compileOnly все еще действует. Он был добавлен в 3.0, чтобы заменить предоставленный и не компилировать. ( provided появился, когда у Gradle не было имени конфигурации для этого варианта использования, и назвал его в соответствии с предоставленной областью Maven.)

Это одно из важнейших изменений, появившихся в Gradle 3.0, о котором Google объявил на IO17.

compile конфигурация теперь устарела и должна быть заменена > или api

зависимости больше не попадают в путь к классам компиляции потребителей, поэтому вы никогда не будете случайно зависеть от переходного зависимость
более быстрая компиляция благодаря уменьшенному размеру пути к классам
меньше перекомпиляций при изменении зависимостей реализации: потребителям не нужно будет перекомпилировать
более чистая публикация: при использовании вместе с новым плагином maven-publish библиотеки Java создают файлы POM, которые точно различать, что требуется для компиляции с библиотека и что требуется для использования библиотеки во время выполнения (в других словами, не смешивайте то, что нужно для компиляции самой библиотеки и что необходим для компиляции с библиотекой).

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

Краткое решение .

Лучшим подходом является замена всех compile зависимостей на implementation . И только в случае утечки интерфейса модуля вы должны использовать api . Это должно вызвать гораздо меньше перекомпиляции.

Объясните больше .

Перед плагином Android Gradle 3.0 : у нас была большая проблема: одно изменение кода приводит к перекомпиляции всех модулей. Основная причина этого заключается в том, что Gradle не знает, пропускаете ли вы интерфейс модуля через другой или нет.

После плагина Android Gradle 3.0 : последний плагин Android Gradle теперь требует от вас явного определения утечки интерфейса модуля. Исходя из этого, он может сделать правильный выбор в отношении того, что следует перекомпилировать.

Таким образом, зависимость compile устарела и заменена двумя новыми:

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

Краткая разница в терминах непрофессионала:

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

Прочитайте ответ @aldok для подробного примера.

Compile конфигурация устарела и должна быть заменена implementation или api .

Основное различие между стандартным плагином Java и плагином Java Library заключается в том, что последний представляет концепцию API, предоставляемого потребителям. Библиотека - это компонент Java, предназначенный для использования другими компонентами. Это очень распространенный вариант использования в многопроектных сборках, но также, как только у вас есть внешние зависимости.

Плагин предоставляет две конфигурации, которые можно использовать для объявления зависимостей: API и реализация. Конфигурация api должна использоваться для объявления зависимостей, которые экспортируются библиотечным API, тогда как конфигурация реализации должна использоваться для объявления зависимостей, которые являются внутренними для компонента.

Для дальнейшего объяснения обратитесь к этому изображению.

Этот ответ продемонстрирует разницу между implementation , api и compile в проекте.

Допустим, у меня есть проект с тремя модулями Gradle:

приложение (приложение для Android)
myandroidlibrary (библиотека Android)
myjavalibrary (библиотека Java)

app имеет myandroidlibrary в качестве зависимостей. myandroidlibrary имеет myjavalibrary в качестве зависимостей.

myjavalibrary имеет класс MySecret

myandroidlibrary имеет класс MyAndroidComponent , который манипулирует значением из класса MySecret .

Наконец, app интересует только значение из myandroidlibrary

Теперь поговорим о зависимостях .

app нужно использовать :myandroidlibrary , поэтому в app build.gradle используйте implementation .

( Примечание : вы также можете использовать api / compile. Но подождите немного.)

Как вы думаете, как myandroidlibrary build.gradle должен выглядеть? Какой объем мы должны использовать?

У нас есть три варианта:

В чем разница между ними и что я должен использовать?

Компиляция или API (вариант № 2 или № 3)

Если вы используете compile или api . Наше приложение для Android теперь может получить доступ к myandroidcomponent зависимости, которая является MySecret классом.

Реализация (вариант № 1)

Если вы используете конфигурацию implementation , MySecret не отображается.

Итак, какую конфигурацию вы должны выбрать? Это действительно зависит от вашего требования.

Если вы хотите выставить зависимости , используйте api или compile .

Если вы не хотите показывать зависимости (скрывая свой внутренний модуль), используйте implementation .

Читайте также: