В то время как Android Studio обновлена ​​до v3.3, получение API 'variable.getAssemble ()' устарело и было заменено на 'variable.getAssembleProvider ()' - PullRequest
Новая
       12

В то время как Android Studio обновлена ​​до v3.3, получение API 'variable.getAssemble ()' устарело и было заменено на 'variable.getAssembleProvider ()'

0 голосов
/ 15 января 2019

Получение этого предупреждения (даже когда variant.getAssemble() нигде не используется): 

API 'variant.getAssemble()' is obsolete and has been replaced with 'variant.getAssembleProvider()'.

Я обновил следующие компоненты: Android Studio

v3.3

Подключаемый модуль Gradle

v3.3

URL рассылки Gradle (gradle-wrapper.properties)

distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.1-all.zip

gradle.properties

android.debug.obsoleteApi=true

Ответы [ 4 ]

0 голосов
/ 01 февраля 2019

variable.assemble устарело и заменено новым API провайдера.

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

variant.outputs.all { output ->
        variant.assemble.doLast {
            ....
        }
    }
}

Затем замените его новым API провайдера: 

variant.outputs.all { output ->
    variant.getAssembleProvider().configure() {
        it.doLast { 
            ....
            }
        }
}
0 голосов
/ 24 января 2019

Временное решение!
- Отредактируйте корневой файл build.gradle.
- Измените "com.android.tools.build:gradle:3.3.0" на "3.2.0"
Готово.

та же проблема:

https://stackoverflow.com/a/52470224/8920453

и увидите это:

https://stackoverflow.com/a/54239512/8920453

0 голосов
/ 24 января 2019

Это предупреждение , оно не оказывает негативного влияния на вашу сборку. Вы можете пойти дальше и обновить до AGP 3.3.0 .

Новый плагин Android Gradle начал использовать ленивую конфигурацию (API предотвращения задач и API провайдера), которая при правильном использовании может повысить скорость сборки, оценивая только необходимые задачи и свойства. Потребители AGP должны использовать обновленный API (например, getAssembleProvider().configure() вместо getAssemble()), в противном случае задачи и свойства всегда оцениваются.

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

Подробнее:

Что делать

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

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

libraryVariants.all {
    it.generateBuildConfig.enabled = false
}

При использовании нового ленивого API это выглядит следующим образом. 

libraryVariants.all {
    it.generateBuildConfigProvider.configure {
        it.enabled = false
    }
}

Стремительный API приведет к настройке задачи generateBuildConfig, даже если она мне не понадобится, например, запуск clean. Ленивый API настраивает задачу , только если является частью графика задачи для запуска. Это экономит время на этапе настройки.

Как выяснить, исходит ли оно из вашего кода? Поместите это в ваш gradle.properties

android.debug.obsoleteApi=true

Теперь запустите сборку и проверьте вывод на наличие следов стека.

Полная ошибка

Для полноты вот пример полного сообщения об ошибке, вызванного плагином Fabric 1.27.0 с AGP 3.3.0: 

WARNING: API 'variant.getExternalNativeBuildTasks()' is obsolete and has been replaced with 'variant.getExternalNativeBuildProviders()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
To determine what is calling variant.getExternalNativeBuildTasks(), use -Pandroid.debug.obsoleteApi=true on the command line to display a stack trace.

Плохой пример

Вот пример того, как Facebook React справился с миграцией API в своем плагине: https://github.com/facebook/react-native/pull/23103/files

Другими словами, они этого не сделали. taskProvider.get() равно task - оба стремятся. Задачи всегда настроены.

Единственное, что достигается этим подходом, это удаление предупреждения, поэтому

  • потребитель не знает, что он не получает никаких преимуществ от ленивого API,
  • автору плагина больше не напоминают, что он использует его неправильно.

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

0 голосов
/ 15 января 2019

Этот тип предупреждения может появиться, если какая-то используемая библиотека используется в вашем проекте с использованием этого метода

...