Status Update
Comments
uc...@google.com <uc...@google.com> #2
We're seeing a similar error in our code. Appears to be a combination of AGP 8.6.0 and Kotlin 2 needed to hit it.
private fun Intent.stripUnwantedFlags() {
// Explicitly remove the new task and clear task flags (Our browser activity is a single
// task activity and we never want to start a second task here).
flags = flags and Intent.FLAG_ACTIVITY_NEW_TASK.inv()
flags = flags and Intent.FLAG_ACTIVITY_CLEAR_TASK.inv()
// IntentReceiverActivity is started with the "excludeFromRecents" flag (set in manifest). We
// do not want to propagate this flag from the intent receiver activity to the browser.
flags = flags and Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS.inv()
}
All 3 lines then hit:
Must be one or more of: Intent.FLAG_GRANT_READ_URI_PERMISSION, Intent.FLAG_GRANT_WRITE_URI_PERMISSION, Intent.FLAG_FROM_BACKGROUND, Intent.FLAG_DEBUG_LOG_RESOLUTION, Intent.FLAG_EXCLUDE_STOPPED_PACKAGES, Intent.FLAG_INCLUDE_STOPPED_PACKAGES, Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION, Intent.FLAG_GRANT_PREFIX_URI_PERMISSION, Intent.FLAG_ACTIVITY_MATCH_EXTERNAL, Intent.FLAG_ACTIVITY_NO_HISTORY, Intent.FLAG_ACTIVITY_SINGLE_TOP, Intent.FLAG_ACTIVITY_NEW_TASK, Intent.FLAG_ACTIVITY_MULTIPLE_TASK, Intent.FLAG_ACTIVITY_CLEAR_TOP, Intent.FLAG_ACTIVITY_FORWARD_RESULT, Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP, Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS, Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT, Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED, Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY, Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, Intent.FLAG_ACTIVITY_NEW_DOCUMENT, Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, Intent.FLAG_ACTIVITY_NO_USER_ACTION, Intent.FLAG_ACTIVITY_REORDER_TO_FRONT, Intent.FLAG_ACTIVITY_NO_ANIMATION, Intent.FLAG_ACTIVITY_CLEAR_TASK, Intent.FLAG_ACTIVITY_TASK_ON_HOME, Intent.FLAG_ACTIVITY_RETAIN_IN_RECENTS, Intent.FLAG_ACTIVITY_LAUNCH_ADJACENT, Intent.FLAG_ACTIVITY_REQUIRE_NON_BROWSER, Intent.FLAG_ACTIVITY_REQUIRE_DEFAULT, Intent.FLAG_RECEIVER_REGISTERED_ONLY, Intent.FLAG_RECEIVER_REPLACE_PENDING, Intent.FLAG_RECEIVER_FOREGROUND, Intent.FLAG_RECEIVER_NO_ABORT, Intent.FLAG_RECEIVER_VISIBLE_TO_INSTANT_APPS
je...@google.com <je...@google.com> #3
The initial report (
However,
to...@gmail.com <to...@gmail.com> #4
Thanks for fixing! What release should we be able to verify the fix in? And is there any chance of a backport for 8.6.1?
hu...@google.com <hu...@google.com> #7
Thanks for the update!
to...@gmail.com <to...@gmail.com> #8
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 2
- Android Gradle Plugin 8.8.0-alpha02
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
hu...@google.com <hu...@google.com> #9
The fixes for this issue are now also available in:
- Android Studio Ladybug | 2024.2.1 RC 1
- Android Gradle Plugin 8.7.0-rc01
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
to...@gmail.com <to...@gmail.com> #10
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?
to...@gmail.com <to...@gmail.com> #11
hu...@google.com <hu...@google.com> #12
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):
- Kapt (ongoing/has not started):
Incremental Java compilation requires participation from the following parties:
- Gradle: This work is already complete.
- Annotation processors (ongoing):
- 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 (
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
hu...@google.com <hu...@google.com> #13
> 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!
to...@gmail.com <to...@gmail.com> #14
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:
hu...@google.com <hu...@google.com> #15
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?
to...@gmail.com <to...@gmail.com> #16
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?
hu...@google.com <hu...@google.com> #17
Changing constants usually causes Gradle to perform a full recompile, and the contents of BuildConfig are all constants. Please refer to
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.
to...@gmail.com <to...@gmail.com> #18
Here is also scan results
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.
hu...@google.com <hu...@google.com> #19
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!)
to...@gmail.com <to...@gmail.com> #20
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);
}
hu...@google.com <hu...@google.com> #21
Can you retry with a change that does not involve a flag or a constant?
to...@gmail.com <to...@gmail.com> #22
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.
to...@gmail.com <to...@gmail.com> #23
hu...@google.com <hu...@google.com> #24
to...@gmail.com <to...@gmail.com> #25
I'm expecting that in 3.3 not.
Thanks.
hu...@google.com <hu...@google.com> #26
to...@gmail.com <to...@gmail.com> #27
hu...@google.com <hu...@google.com> #28
android.databinding.incremental=true
in the Gradle properties file.
Relevant commit:
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.
to...@gmail.com <to...@gmail.com> #29
an...@gmail.com <an...@gmail.com> #30
to...@gmail.com <to...@gmail.com> #31
And here a clean compilation
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
pj...@gmail.com <pj...@gmail.com> #32
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
to...@gmail.com <to...@gmail.com> #33
Here is build without any changes in the code, it takes just 8s
And here I just commented out one line of code in the fragment, no method signature change
It takes 40s, just compiling java code is 12s
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
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.
All tests are from the command line, I did not run the build directly from IDE.
pj...@gmail.com <pj...@gmail.com> #34
apply plugin: "kotlin-android"
as some code is written in kotlin however I'm using java annotation processor - not kapt
to...@gmail.com <to...@gmail.com> #35
hu...@google.com <hu...@google.com> #36
@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.
to...@gmail.com <to...@gmail.com> #37
pj...@gmail.com <pj...@gmail.com> #38
" 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
Gradle doesn't report it as "non-incremental" as it used to be with older version.
to...@gmail.com <to...@gmail.com> #39
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
hu...@google.com <hu...@google.com> #40
@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.
pj...@gmail.com <pj...@gmail.com> #41
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 ?
hu...@google.com <hu...@google.com> #42
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
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.
hu...@google.com <hu...@google.com> #43
Change:
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.
to...@gmail.com <to...@gmail.com> #44
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.
hu...@google.com <hu...@google.com> #45
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.
to...@gmail.com <to...@gmail.com> #46
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.
pj...@gmail.com <pj...@gmail.com> #47
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?
[Deleted User] <[Deleted User]> #48
Might be due to
hu...@google.com <hu...@google.com> #49
This situation has actually already been documented in the Gradle docs (
Here is the bug that tracks the work to improve this:
[Deleted User] <[Deleted User]> #50
[1]
ky...@gmail.com <ky...@gmail.com> #51
public final EditTextSearch etMainSearch;
^
symbol: class EditTextSearch
location: class FragmentRepositoriesBinding
Description
I'm using annotation processor that support this feature already.
List of all is here
But in the build log is still this
"Incremental Java compilation disabled in variant ... as you are using an incompatible plugin"
Without any detailed explanation.
I tried to report it here
But according to Gradle team it comes directly from Android Build plugin.
And Xavier Ducrohet confirm it here:
I tried also to use
android.databinding.enableV2=true
And it doesn't help.
I'm creating this issue to track any further progress of this issue.
I think that incremental compilation can help a lot with our big projects, where just compilation on every run takes almost 40s because everything is recompiled every time.
Android Gradle Plugin: 3.2.0-alpha18
Gradle: 4.8