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

I also tested it on a large and very complex project already.
Here is build without any changes in the code, it takes just 8s
https://gradle.com/s/2xhpe7aamx7uw
And here I just commented out one line of code in the fragment, no method signature change
https://gradle.com/s/e7iuvbqttdxn2
It takes 40s, just compiling java code is 12s https://scans.gradle.com/s/e7iuvbqttdxn2/timeline?task=a2moppdi3f2qu

In log is
Compiling with JDK Java compiler API.
Incremental compilation of 688 classes completed in 10.061 secs.
There is no information, that something prevents to incremental compilation
So hard to say if "compilation of 688 classes" means that it really compile all of them, because just one file was changed or it means the total class count.

When I delete build folder and turn off build cache, the build takes 1m 10s, and just the compilation takes 11.2s
https://scans.gradle.com/s/3qas6nl3ze3c6/timeline?task=a2moppdi3f2qu
So from this looks that 11s is time for full compilation, not an incremental one.

Btw. Do the build with deleted build folder and without build cache with the build plugin 3.3.1 takes 1m 31s.
So it looks that 3.5 brings 23% increase of speed build, but I did not enough measures to prove it. It is just from one build.
https://gradle.com/s/tdgnlpokgs5zi

All tests are from the command line, I did not run the build directly from IDE.

I forgot to add that I'm using
apply plugin: "kotlin-android"
as some code is written in kotlin however I'm using java annotation processor - not kapt

I have also Kotlin code in the project, but I'm using just java annotation process also.

@32, 34: Can you run with --info to see whether Java compile in your project is incremental and how many classes are recompiled?

@33, 35: "Incremental compilation of 688 classes completed in 10.061 secs." => This means that Java compile is incremental in your project. 688 of all the classes are actually recompiled. The number of recompiled classes depends on the nature of the change. You can try changing a class that is not used by any other class, and observe that the number of recompiled classes will be much lower.

If the number of recompiled classes is always high for you, can you run with --debug and attach the log here? It will show exactly what classes are recompiled, and we can debug from there. Note that it's enough to just run the Java compile task, and make sure you remove any confidential info if any from the log first.

I changed one line in Activity class it is definitely not used in any other class. I will try it with debug and send log here later today.

From the huge log I extracted this
" Full recompilation is required because com.google.auto.value.processor.AutoValueProcessor is not incremental. Analysis took 5.306 secs. "

the dex task detected the single file change
"AnalyticsManager.dex:CHANGED"

I'm using AutoValue 1.6.3 and according to release notes it should be incremental
https://github.com/google/auto/releases/tag/auto-value-1.6.3
Gradle doesn't report it as "non-incremental" as it used to be with older version.

I found just this

01:38:54.680 [INFO] [org.gradle.api.internal.tasks.compile.incremental.SelectiveCompiler] Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.251 secs.

I just added line
        i.putExtra(ACTION, action);
to method creating Intent like this

        Intent i = new Intent(activity, DashboardActivity.class);
        i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
        activity.startActivity(i);

inside of DashboardActivity.java

@38: AutoValue will not be incremental if one of its extensions is not incremental. Please follow the progress for AutoValue extensions here: https://github.com/google/auto/issues/673

@39: This appears to be a Gradle bug. Could you prepare a small project and file a bug with Gradle? You can also attach the project here, and I will try to see what's wrong.

I found that auto-value-parcel is not incremental. Author still didn't release the new version but with help of jitpack I managed to make all my dependencies support incremental compiling.
However when I change a single file the whole module is being recompiled

Task ':app:compileGrubhubStagingJavaWithJavac' is not up-to-date because:
  Input property 'sources' file /Users/rudy/dev/projects/dinerapp-android/app/src/main/java/com/grubhub/dinerapp/android/order/search/searchResults/data/SearchResponseTransformer.java has changed.
Compiling with source level 1.8 and target level 1.8.
file or directory '/Users/rudy/dev/projects/dinerapp-android/app/libs', not found
Created classpath snapshot for incremental compilation in 0.005 secs.
Class dependency analysis for incremental compilation took 0.165 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 2923 classes completed in 28.813 secs.
Packing task ':app:compileGrubhubStagingJavaWithJavac'

Is there something I'm missing ?

"Incremental compilation of 2923 classes completed in 28.813 secs." => This indicates that the Java compile task in your project was already incremental; otherwise you would have seen a message like "Full recompilation is required because <something happened>".

When Java compile is incremental and you still see a lot of classes are recompiled, it usually means that the specific change that you make to the source file affects a lot of classes (especially if you make a change relating to constants). See https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_compile for more background.

If you change a different source file with a different type of change (e.g., adding a comment or modifying a method's body), you'll probably notice that the set of recompiled classes will be much smaller.

Starting with AGP 3.6.0-alpha02, we are enabling incremental data binding by default. Please let us know if you see more improvements in your build.

Change: https://android.googlesource.com/platform/tools/base/+/399103996d94d961fe82ca82cd0cffdfe3044f29


Since next week will be our last check-in date for 3.5.0-rc01, I feel that cherry-picking this change back to 3.5 is a bit risky.

@Jerome: Please let me know if you think cherry-picking to 3.5 still makes sense.

Only blocking thing for me is still Room library, but it also looks that version with incremental support will be available really fast.
I meantime changed also java annotation processor to kapt. So I'm curious if I will still have an issue with it as I have so far like every minimal code change always caused full recompilation.

Yes, the work to make Room incremental is tracked at Issue 112110217.

Please open a new bug with us if you think your build is still not as fast as expected.

>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.

>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.

I know, but not happen on small demo project, its happen only on the big one. I will investigate it more.

I updated project to use 3.5.0-rc03 and enabled android.databinding.incremental=true
I made change in single file and rerun the compilation. Got such output
"Full recompilation is required because 'AppUtils.java' was changed. Analysis took 0.162 secs."
I added few lines in the file but I don't understand why it needed to do full recompilation.

Is there a flag or other debug method that would tell me more about the case?

>>> I added few lines in the file but I don't understand why it needed to do full recompilation.

Might be due to https://github.com/gradle/gradle/issues/2767#issuecomment-323975456

Yes, that seems to explain it. A workaround is also posted on that bug: https://github.com/gradle/gradle/issues/2767#issuecomment-362192761

This situation has actually already been documented in the Gradle docs (https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_compile): "Since constants can be inlined, any change to [*** a class containing ***] a constant will result in Gradle recompiling all source files. For that reason, you should try to minimize the use of constants in your source code and replace them with static methods where possible". Note that the docs should probably say "any change to a class containing a constant" instead of "any change to a constant".

Here is the bug that tracks the work to improve this: https://github.com/gradle/gradle/issues/6482.

I commented[1] on the issue about the misleading documentation. Assuming we're right, it will be trivial to update the docs to reflect the full reality.

[1] https://github.com/gradle/gradle/issues/6482#issuecomment-522672671

guys anyone had the same issue C:\Users\Edgar\Desktop\GithubTask\app\build\generated\data_binding_base_class_source_out\debug\dataBindingGenBaseClassesDebug\out\android\com\githubtask\databinding\FragmentRepositoriesBinding.java:20: error: cannot find symbol
  public final EditTextSearch etMainSearch;
               ^
  symbol:   class EditTextSearch
  location: class FragmentRepositoriesBinding