IssueTracker

Here's a sample app that shows this issue:
https://github.com/SimpleNexus/simplecallerid/

When you import it and update gradle version as the IDE suggests, it fails to build.

Hi there, thank you for reporting this issue.
This was a problem with the constraint layout library, which used attributes under declare styleables without defining them. This has been fixed in constraint layout version 2.0.0 beta 3. You can read more about the issue in https://issuetracker.google.com/136103084

@3 Hello, I can't use beta 3 and beta 2, because of serious issues that I've reported about.
Here's about beta 3:
https://issuetracker.google.com/issues/143411144

You can workaround the missing attribute issue by *temporarily* adding it locally in your values/attrs.xml: <attr name="flow_horizontalSeparator"/>

@5 Just a single attribute?
But why is it considered missing only when I use this gradle version?

In the linked issue https://buganizer.corp.google.com/issues/136103084 there is a full list of attributes to add, but in comment #1 only one of them is reported, so I this is how to fix that particular one.

The newer version of AGP included a fix to aapt2. The bug in aapt2 was that it accidentally allowed non-explicit definition of attributes, when it shouldn't have. Pre 3.0.0 it was disallowed, but the bug was only noticed recently.

@7 I wrote "..." because it was very long.
If you look at the video, you will see the rest...
Why are those attributes missing on a library? How could the library be made without having errors before publishing it?

It was a bug, that went unnoticed because of a bug in aapt2. Both have been fixed now, but since https://issuetracker.google.com/issues/143411144 is preventing you from updating to the newest version of constraint layout, you can use the workaround mentioned in https://buganizer.corp.google.com/issues/136103084 until that one is fixed.

Add to your res/values/attrs.xml:
<resources>
        <attr name="motionProgress"/>
        <attr name="motionTarget"/>
        <attr name="layout_marginBottom"/>
        <attr name="motionPathRotate"/>
        <attr name="duration"/>
        <attr name="flow_verticalSeparator"/>
        <attr name="flow_horizontalSeparator"/>
        <attr name="waveDecay"/>
</resources>

(beta 3 of constraint layout includes these in its own values file, so then there's no need for adding them locally)

@9 I can't use the workaround on the link you've put, because I can't access this link.
Maybe I should join Google to make it easier? Seems I could be a good QA there ...
:)

I tried to add the attributes you wrote, while updating to com.android.tools.build:gradle:4.0.0-alpha04 .
Seems to fix it, but the same issue exists on this dependency :
https://github.com/JcMinarro/RoundKornerLayouts

I don't get yet how this could happen. Do those libraries have the attributes or not? How can gradle know what's missing?
How could a library use its attributes without declaring them in the resources files, and still be able to be built and used by other apps?
It doesn't make sense. The IDE should show a build error in this case, and even if it succeeds to build for some reason, it should crash...

No?

Whoops, sorry. :) Here's the correct link: https://issuetracker.google.com/136103084

These libraries were build with the older version of AGP that had that bug, so that's why it went unnoticed. Now when someone tries to release a library without these attributes they will get a build error. The IDE is also warning about this now.

@11 I meant how on previous versions it was on the side of the library.
How could they use R.attr.some_attribute, if  some_attribute wasn't declared anywhere?

Seems fixed

@13 Thanks for confirming!
@12 The attribute that'd be accessed would be empty, and could lead to crashes at runtime. It was a bug in aapt2 that it didn't fail when it detected these at build time (as it does now).

@14 So now, suppose a library wishes to use an attribute, could it use something that's existing, should it use its own...?

A library (or an app) can use its own resources or resources from any of its dependencies. The issue here was that attributes need to be declared explicitly, so if you had:

<declare-styleable name="foo">
   <item type="attr" name="bar"/>
</declare-styleable>

the attr bar was not defined anywhere, yet is used here. It should be defined anywhere, either this file, this module, library or any of the dependencies, so you could have:

lib A depends on lib B

lib B contains:
<resources>
    <attr name="bar" format="string"/>
</resources>

lib A contains:
<resources>
    <declare-styleable name="foo">
        <attr name="bar"/> //using the attr bar from lib B
    </declare-styleable>
</resources>

And of course you can use your own resources as well, for example:

my module/main/res/values/styleables.xml:
<resources>
    <attr name="bar" format="string"/>

    <declare-styleable name="foo">
        <attr name="bar"/> //using the attr bar defined above
    </declare-styleable>
</resources>


And in the case where you're consuming a library affected by this bug (declare styleable using an attr without a definition) you can do the "hack" mentioned in previous comments:
app depends on lib

lib contains:
<resources>
    <declare-styleable name="foo">
        <attr name="bar"/> //trying to access not existing attr bar
    </declare-styleable>
</resources>

app needs to contain:
<resources>
    <attr name="bar" format="string"/> // fixing libs resources
</resources>

This issue has been fixed a while ago, and if a library owner tries to publish a library with missing resources, their build will fail during a release build, because the VerifyLibraryReleaseResources task will alert them to the missing attribute.

Hope this helps!

I see. So it needs to be defined.
But what if I use 2 libraries, and each declare the same attribute, while each has a different type for it?

Would it cause an issue? Or would it magically work somehow, letting me use both ?

@17 Now this is where things get interesting. :)

Because in the current situation, resources do not have namespaces or packages, like Java/Kotlin classes do. Because of that, we merge all resources at the app level, with "overrides" or "overwrites" strategy of "higher one wins". This means if a resource is defined in an app and in a lib, at runtime (and compile time) the one from the app "wins". Similarly, when you have an app that depends on lib A and on lib B (separately, A does not depend on B and vice versa), and both A and B define the same resource, whichever one is higher in Gradle's dependency hierarchy wins (by the order the implementation/api dependency on them were added in build.gradle). Of course, if these conflict, e.g. have different formats, this mean that the one that gets overridden might result in unexpected behaviour (for example format="integer" getting overridden by format="string"). These are rare cases, but definitely possible.

In the future, we might introduce the concept of resource namespaces, which would mean that if both A and B define the same resource you can use both at the same time, accessing them using the full package name, e.g. lib.a.package:attr/foo and lib.b.package:attr/foo. However, this would not work yet, because, as I mentioned above, all resources are merged at app level and effectively have the same package name of the app (side note: exception is the "android:" namespace, as you might have noticed, e.g. "android:color/white" or similar). Either way, please follow release notes and updates in videos from future conferences (e.g. Google IO, Android Dev Summit) and be on the lookout for any upcoming features! :)