IssueTracker

Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.

it's a known issue of the databinding annotation processor, we working on fixing this in the 3.3 release time frame

Thanks! It's just a little bit sad, that it will not be in 3.2, especially when fix which I saw on existing project is relatively small, like
https://github.com/evernote/android-state/commit/0072478291e2735223d6c14cb79a6b26524ec075

Is it still planned for 3.3?

Yes, we are actively working on this issue.

(Making data binding incremental is not a straightforward fix because data binding changes resource files, and whenever a resource changes, Gradle needs to do a full recompile. For more info, please see https://github.com/gradle/gradle/issues/4701.)

Starting with AGP 3.3.0-alpha10, JavaCompile will be incremental if you set the new experimental flag android.enableSeparateAnnotationProcessing=true in the gradle.properties file. (If your project is using Kapt, then you don't even need to set the flag.) See Issue 115774858.

Please try out this feature and let us know your performance gains. (Also let us know whether you are using Kapt or not.) Thanks!

I tried it on my project, where Kotlin is used and also Databinding.
I was testing it by the alpha 11 version.
It warns me that data binding annotation processor does not support incremental compilation and I should consider using android.enableSeparateAnnotationProcessing=true
But it doesn't bring any speed improvement. I tried several times just change one line of code inside one method and re-run the app and it takes exactly the same time as with build plugin 3.2, maybe few seconds wors.
It takes a very long time to decompress data from build cache (something like 20s)  and 3.2 whole compilation takes something like 30s.
So I don't understand what exactly was changed so far? Just android.enableSeparateAnnotationProcessing=true as kind of workaround how to use incremental compilation also in the situation I'm using annotation processor without direct support for it?
Probably I need to wait for incremental compilation support of Data Binding directly.

Thank you for the feedback.

I assume that you are using Kotlin but not Kapt (if you were using Kapt, then the warning wouldn't show up). After you enable the flag, you should be able to see the Java compile task (:module:compile[Variant]JavaWithJavac) being incremental. For a full description of the feature, please see comment #4 of Issue 115774858.

However, from what you said, it looks like the Java compile task is still non-incremental, so I'd like to find out why.

Could you run a build from the command line with --info after a one-line change and attach the console's contents here?

Yes I forgot about that, am still using annotationProcessor instead of kapt for the historical reason I will try to change it.
And kapt does not require support of annotation processor itself like it is necessary for Java only projects?
compile task looks incremental, but it doing something with cache very long time
Do you want the log with kapt already or still with annotationProcessor?

But it looks that Kapt also doesn't support incremental compilation
https://youtrack.jetbrains.com/issue/KT-23880

To clarify this topic, it is helpful to separate the notion of annotation processing and that of compilation.

When the Kapt plugin is not used, the JavaCompile task does both annotation processing and Java compilation. When Kapt is used, Kapt does annotation processing, KotlinCompile does Kotlin compilation, and JavaCompile does Java compilation.

For faster builds, we want all of the above 3 tasks to be incremental. Since KotlinCompile is already incremental, the focus is on making both annotation processing and Java compilation incremental.

Incremental annotation processing requires participation from the following parties:
  - Gradle: This work is already complete.
  - Annotation processors (ongoing):  https://github.com/gradle/gradle/issues/5277
  - Kapt (ongoing/has not started): https://youtrack.jetbrains.com/issue/KT-23880

Incremental Java compilation requires participation from the following parties:
  - Gradle: This work is already complete.
  - Annotation processors (ongoing): https://github.com/gradle/gradle/issues/5277
  - No changes are required from Kapt as Kapt is not involved in Java compilation.

As you can see above, the work that annotation processor authors are doing (https://github.com/gradle/gradle/issues/5277) serves two purposes: It helps to make both annotation processing and Java compilation incremental. When Kapt is used, we will also need support from Kapt in order for annotation processing to be incremental.


The role of the Android Gradle plugin: Our new feature (android.enableSeparateAnnotationProcessing=true) helps make *Java compilation* incremental even when annotation processors are not yet incremental. It doesn't make annotation processing incremental, as it is outside of our scope. Again, please refer to Issue 115774858 comment #4 for more background.

> compile task looks incremental, but it doing something with cache very long time
> Do you want the log with kapt already or still with annotationProcessor?

I'd like to investigate your use case to see what is taking so long. Please send me the --info logs from your actual day-to-day workflow (e.g., if your actual project is not using Kapt, then send me the logs without Kapt); the key here is for the logs to reflect your actual builds. Thanks!

Thanks for the explanation!

I created logs with --info, it takes more time than when I'm running it directly from AS.

And here is --scann report from the incremental build with one line changed:
https://scans.gradle.com/s/yscuctqraxkw2

Both the build scan and the logs are really helpful! I understand your scenario a bit more now.

This part is slowing down your build:
        "Full recompilation is required because 'BuildConfig.java' was changed. Analysis took 0.019 secs."

Can you let me know what was your change and in what file, what module? Can you also try changing a Java file and see if it's faster?

I forgot about that. I'm using this

                        if (project.ext.isIDEBuild()) {
                            variant.buildConfigField "long", "BUILD_TIMESTAMP", "System.currentTimeMillis()"
                        } else {
                            variant.buildConfigField "long", "BUILD_TIMESTAMP", Long.toString(System.currentTimeMillis()) + "L"
                        }

So for IDE build it remains still the same and should not cause recompiling, but for command line build it put real compilation time to the app.
So I need to disable it or make --info log export somehow directly from IDE.
But why the change in BuildConfig require the full recompile and not an incremental one? And the change in any other file is OK?

> But why the change in BuildConfig require the full recompile and not an incremental one? And the change in any other file is OK?

Changing constants usually causes Gradle to perform a full recompile, and the contents of BuildConfig are all constants. Please refer to https://blog.gradle.org/incremental-compiler-avoidance for a background, particularly this paragraph: "Those of you who have already tried the incremental Java compiler before may have seen that it wasn’t very smart when a changed class contained a constant. For example, this class contains a constant:
    public class SomeClass {
        public static int MAGIC_NUMBER = 123;
    }
If this class was changed, then Gradle gave up and recompiled not just all the classes of that project but also all the classes in projects that depend on that project."


Can you comment out the script that adds variant.buildConfigField (both for the IDE and command line), and see if compilation is faster? If it is still not fast, please attach another build scan and I will debug it further.

I created new logs without modifying BuildConfig class.

Here is also scan results
https://scans.gradle.com/s/yvff3yytuus2g - build without any change
https://scans.gradle.com/s/kybqkbt5xvzms/ - build with one modified method

Without --info and --scan it takes 30s without change and something like 1 minute with one change.
Also configuration phase is very slow :-(, but this is different topic.

Configuration time will get better in upcoming versions of the Android Gradle plugin, based on the idea of task configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html. (If you want, you can create a new bug, let me know the bug number, and I will keep you updated on that bug when there is progress in this area.)

For this bug, let's focus on making your Java compilation task incremental. With the change above, I see this line:
        "Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.867 secs."

Can you describe what the change was? (For future experiments, please describe the change + send me the log + build scan. Thanks!)

I just added a new flag to the existing intent. So I added one more intent.setFlag() to here

    public static void callWithShortcutFlow(@NonNull Context context, @ShortcutFlow final String shortcutFlow) {
        final Intent intent = new Intent(context, DashboardActivity.class);
        intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
        context.startActivity(intent);
    }

Can you send me the contents of DashboardActivity (after removing any confidential stuff)?

Can you retry with a change that does not involve a flag or a constant?

I understand that change the value of constant needs to recompile but just use of constant... Constants are used almost everywhere.

So I tried to change the string value, change the value of a primitive type local variable, add else branch, remove else branch and also add one simple indentation space and it always ends with "Full recompilation" in the log.

Then I created new unused class and there was possible do changes without "Full recompilation" in the log.
But when I started using this class in my project, it stops incremental compilation again.

So it looks that incremental compilation is a very sensitive thing.

.

There are cases that Gradle has to do full recompilation, but it shouldn't be that common. If adding spaces causes full recompile, then it is probably a Gradle bug. If you could share a project (either real or artificial) that shows these issues, I will try to find out what happens.

It's incremental data binding annotation processor already implemented in the latest 3.4 beta release of build plugin, please?
I'm expecting that in 3.3 not.
Thanks.

It is being scheduled for 3.5. I am expecting to release this feature to 3.5 canaries soon (within a week or two).

Thanks a lot!

I am pleased to inform that data binding has become incremental, starting with AGP 3.5.0-alpha05. For safety we've put this feature behind a flag, currently off by default. To enable it, please set

    android.databinding.incremental=true

in the Gradle properties file.

Relevant commit: https://android.googlesource.com/platform/tools/base/+/85292f7e7b41e741fe5354d31a30c97ec79d18a6


Please try out the feature and let us know how it goes. If we receive enough good feedback, we will enable it by default. I'm leaving this bug open to keep track of that.

Thanks a lot! Currently, I'm testing 3.4.0 version. I will try 3.5.0 ASAP.

In response to #29, any feedback yet from you or anyone else with this flag? If it works out, this could be a huge productivity gain. Will try for myself ASAP.

I just tested it on a relatively small project and it looks good, here is incremental build, with one line changed
https://scans.gradle.com/s/bt2obrtrrrj2y/timeline?task=arbuq4molzx42
And here a clean compilation
https://scans.gradle.com/s/4talkldkc2qro/timeline?task=arbuq4molzx42
According to logs, it looks that incremental compilation was used. I'm using data binding, Glide, and Butterknife

But I need to test it on a bigger project, where compilation takes 30s

I did a test on a big project and the incremental compiling didn't work.
https://scans.gradle.com/s/b3qs53n4silqa/timeline?task=cnfo4lpnihue4

I updated all annotation processors to versions which support incremental compiling and used 3.5.0-alpha05
I changed just two lines of code in java