IssueTracker

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 b/136103084 - which leads me to believe that perhaps between the builds the gradle version was updated and that's why the bug in constraint layout surfaced.
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 b/136103084, for 2 I'll do a temporary fix of using PathSensitivity.ABSOLUTE and I'll see what we can do to avoid storing the absolute paths.

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.

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.

I'm renaming the bug title to make it more general, as this will probably be a multi-commit fix.

That "temporary fix of using PathSensitivity.ABSOLUTE" is 8 months old, any plan to fix it and make it Relative again?

@6 Thank you for checking in, we're working on it.