Fixed
Status Update
No update yet.
Comments
lb...@gmail.com
There are two things that are happening here:
1. The error is saying that the attributes used were not defined, and they match exactly the error in
2. Aapt2 stores the absolute path in the compiled resources for reporting errors. This is why the <CI workspace> path is shown since that was stored in the file. In order to fix this we need to make the input resource-sets to tasks that compile resources as PathSensitivity.ABSOLUTE. A better non-temporary fix would be to make aapt2 accept storing non-absolute paths and for us to figure out the proper error reporting ourselves.
For 1 follow
1. The error is saying that the attributes used were not defined, and they match exactly the error in
2. Aapt2 stores the absolute path in the compiled resources for reporting errors. This is why the <CI workspace> path is shown since that was stored in the file. In order to fix this we need to make the input resource-sets to tasks that compile resources as PathSensitivity.ABSOLUTE. A better non-temporary fix would be to make aapt2 accept storing non-absolute paths and for us to figure out the proper error reporting ourselves.
For 1 follow
am...@google.com
Re 1., the build in question had just added
<!-- Workaround for stricter aapt in AGP 3.6 -->
<attr name="motionProgress" />
<attr name="motionPathRotate" />
<attr name="waveDecay" />
<attr name="flow_verticalSeparator" />
<attr name="flow_horizontalSeparator" />
to app/src/main/res/values/attrs.xml. There was, however, a second com.android.application module that hadn't added that yet. If I'm understanding you correctly, you're saying that this wasn't really trying to reference a path that didn't exist locally (but did exist on the CI workspace), but rather it just _reports_ that path in an attempt to provide a user-friendly error report?
And as far as I can tell, both builds (the one that failed and the one that pushed to the cache) were on Gradle 5.6.2.
<!-- Workaround for stricter aapt in AGP 3.6 -->
<attr name="motionProgress" />
<attr name="motionPathRotate" />
<attr name="waveDecay" />
<attr name="flow_verticalSeparator" />
<attr name="flow_horizontalSeparator" />
to app/src/main/res/values/attrs.xml. There was, however, a second com.android.application module that hadn't added that yet. If I'm understanding you correctly, you're saying that this wasn't really trying to reference a path that didn't exist locally (but did exist on the CI workspace), but rather it just _reports_ that path in an attempt to provide a user-friendly error report?
And as far as I can tell, both builds (the one that failed and the one that pushed to the cache) were on Gradle 5.6.2.
lb...@gmail.com
If you have two app modules and both have (direct or in-direct) dependency on the broken constraint layout then you either need to add those attrs to a common library module that they both depend on, or to both app modules.
And yes, aapt2 wasn't trying to access that path. It consumed a compiled file that had that path saved as the source path just for error messaging, but because the original file to-be-compiled was marked as PathSensitivity.Relative (while it should be Absolute). I'm gonna work on avoiding storing these absolute paths in the compiled res files, but until then for accurate error reporting we'll need to resolve to using PathSensitivity.Absolute for the resources to be compiled.
And yes, aapt2 wasn't trying to access that path. It consumed a compiled file that had that path saved as the source path just for error messaging, but because the original file to-be-compiled was marked as PathSensitivity.Relative (while it should be Absolute). I'm gonna work on avoiding storing these absolute paths in the compiled res files, but until then for accurate error reporting we'll need to resolve to using PathSensitivity.Absolute for the resources to be compiled.
lb...@gmail.com
I'm renaming the bug title to make it more general, as this will probably be a multi-commit fix.
am...@google.com
That "temporary fix of using PathSensitivity.ABSOLUTE" is 8 months old, any plan to fix it and make it Relative again?
lb...@gmail.com
@6 Thank you for checking in, we're working on it.
jg...@gmail.com
Great!
After applyinghttps://github.com/gradle/android-cache-fix-gradle-plugin (using AGP 4.0.0-rc01) 90% of the tasks not coming from the cache are CompileLibraryResourcesTask
After applying
lb...@gmail.com
Reassigning to Luke who's working on relative path support in compiled res files.
jg...@gmail.com
Any update on this? Would be great if this could be cacheable
lb...@gmail.com
Hey Kurtis, we currently have this issue fixed for Linux and MacOS, there is still some more work to be done on Windows. If you are using Linux or MacOS you can add the below to your gradle.properties file which will make these tasks cacheable/relocatable:
android.experimental.enableSourceSetPathsMap=true
android.experimental.cacheCompileLibResources=true
jg...@gmail.com
Ah thanks, I see this is only on AGP 7.0, but unfortunately is not in 4.2. Will give it a try when testing AGP 7.
lb...@gmail.com
I've tried out the flags and it's working very well. There is just one cache miss which is the MergeResources task in com.android.application modules. I'm seeing that the rawLocalResourcesProcessRes uses absolute paths. In com.android.library the task cache is relocatable though.
lb...@gmail.com
I also notice the same behavior. Is there another ticket for tracking the work of making MergeResources use relative paths?
Description
Steps:
1. Double press recent-tasks key after having at least 2 tasks opened.
I've recently updated to Android S beta 4, and now I can't use double-press on recent-tasks key.
Each time I do it, it causes Pixel launcher to crash at least once (if already crashed, might not crash again for a few minutes), even though I don't even have Pixel launcher set as the default launcher and it has nothing to do with it.
And, of course, it doesn't switch between tasks as it should. At most, it goes back to the current task.
See attached.