Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

While Android Studio Updated to v3.3 getting API 'variant.getAssemble()' is obsolete and has been replaced with 'variant.getAssembleProvider()'

Getting this Warning (Even when variant.getAssemble() is not used anywhere):

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

I have updated following components: Android Studio

v3.3

Gradle PlugIn

v3.3

Gradle Distribution URL (gradle-wrapper.properties)

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

gradle.properties

android.debug.obsoleteApi=true

like image 207
Er. Kaushik Kajavadara Avatar asked Jan 15 '19 06:01

Er. Kaushik Kajavadara


2 Answers

variant.assemble has been deprecated and replaced by a new provider API.

If for example you are using it as next:

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

Then replace it the new provider API:

variant.outputs.all { output ->
    variant.getAssembleProvider().configure() {
        it.doLast { 
            ....
        }
    }
}
like image 107
PerracoLabs Avatar answered Oct 20 '22 08:10

PerracoLabs


It's a warning, it doesn't negatively impact your build. You may go forward and update to AGP 3.3.0.

The new Android Gradle Plugin started leveraging lazy configuration (Task Configuration Avoidance API and Provider API) which, if used properly, may improve build speeds by only evaluating tasks and properties which are needed. Consumers of AGP need to use the updated API (e.g. getAssembleProvider().configure() instead of getAssemble()) otherwise the tasks and properties are always evaluated.

The point of lazy API: Don't configure tasks which aren't going to run in a particular build.

Read more:

  • https://docs.gradle.org/4.10/userguide/lazy_configuration.html
  • https://docs.gradle.org/4.10/userguide/task_configuration_avoidance.html

What to do

If it's not coming from your code there's nothing for you to do other than wait for updated libraries (and pray they do it right).

If it comes from your code, here's an example of migration: I'm using this bit of code from Jake Wharton to disable BuildConfig.java generation for my library modules.

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

Using the new lazy API it looks like this.

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

The eager API would cause the generateBuildConfig task to be configured even if I didn't need it, such as running clean. The lazy API configures the task only if it's part of the task graph to run. This saves time during the configuration phase.

How to figure out if it comes from your code? Put this in your gradle.properties

android.debug.obsoleteApi=true

Now run a build and check the output for stack traces.

Full error

For completeness, here's an example of a full error message caused by the Fabric plugin 1.27.0 with 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.

Bad example

Here's a diff of how Facebook React dealt with the API migration in their plugin: https://github.com/facebook/react-native/pull/23103/files

In other words, they didn't. taskProvider.get() is equal to task - both uses are eager. The tasks are always configured.

The only thing this approach achieves is removing the warning so

  • the consumer has no idea they're not getting any benefits of the lazy API,
  • the plugin author is no longer reminded they're using it wrong.

The Task Configuration Avoidance API docs contain a migration guide and a helpful table describing how to create and chain tasks lazily. If you're a plugin author, please read it.

like image 34
Eugen Pechanec Avatar answered Oct 20 '22 06:10

Eugen Pechanec