IssueTracker

This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.

Almost 2 months later and this is still broken

Since there is no progression, I wanted to share our quick-fix for the issue.

#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages

jb...@google.com What is the update on this?

What is the status of this item?

This has been fixed on master today (internal ref: ag/2945015) and will be available in the next SDK release.

Any ETA on next release?

Still broken and not updated? --package_file argument is not usable in it's current form on 26.1.1 straight from the developer site.

Comfirmed that this seems to still be broken. Can we have an update please?

```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1

(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```

Hi, is there any update to this issue? Thanks.

Hi Google. You claim it's been fixed on master, but we haven't had a new release since the broken version 26.1.1. Can you please release the fix?

Yeah, still not fixed --'

Can't believe this still isn't fixed 2 years later for a command line utility that sits on the main dev site.

Any updates on this? The help for this command clearly states this argument is supported.

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