Status Update
No update yet.
Comments
xa...@google.com
OP also said
Fwiw I see the same behavior on 8.6.1.
I think we should fix ASAP, and backport to 8.8+.
cm...@google.com
lu...@google.com
We currently only have added support for relative resource path embedding with the application compiled resources. For libraries this still has the benefits of having resources cacheable and relocatable for resource merging and compilation. However, this isn't the case for downstream tasking using the compiled resources e.g resource linking and verification.
It was on the original roadmap to add support for libraries also. A lot of the work for this is already implemented i.e producing a map of the relative paths to the library resource directories. We would also need to propagate the source set mappings to the tasks consuming the compiled resources.
xa...@google.com
We currently only have added support for relative resource path embedding with the application compiled resources. For libraries this still has the benefits of having resources cacheable and relocatable for resource merging and compilation. However, this isn't the case for downstream tasking using the compiled resources e.g resource linking and verification.
I'm confused by For libraries this still has the benefits of having resources cacheable and relocatable .... If relative paths aren't supported in Library projects, how can these projects support caching relocation?
Description
`<module>/build/intermediates/compiled_local_resources/debug/compileDebugLibraryResources/out/<*.xml>.flat` (at least for layouts and xml drawables) files contain _absolute_ paths inside. This likely prevents tasks that depend on these files from being cached across different machines.
Attached partial output of `xxd <module>/build/intermediates/compiled_local_resources/debug/compileDebugLibraryResources/out/layout*.xml.flat`, you can see it references related file from `intermediates` using full path from root