IssueTracker

The source code for this appears to be correct:

        if (name.startsWith(".")) {
            // Relative to the app package. Prepend the app package name.
            fullName = context.getPackageName() + name;
        }

And there are no references to applicationId in CoordinatorLayout.

Can you provide a sample project that reproduces the issue?

Actually, the code looks wrong to me.

According to the documentation (same like provided above):

Note: The application ID used to be directly tied to your code's package name; so some Android APIs use the term "package name" in their method names and parameter names, but this is actually your application ID. For example, the Context.getPackageName() method returns your application ID. There's no need to ever share your code's true package name outside your app code.

I'll provide a sample project if needed, but it should be pretty straight forward to reproduce by taking any sample project that uses CoordinatorLayout with a app:layout_behavior attribute, creating a Custom Layout Behavior class and assigning the custom class to it by using relative path .to.my.CustomClass

From the documentation you linked, it sounds like the concept of an application ID that's distinct from a package name only exists at design time and is removed at build time,

once the build has made use of the original value (to namespace the R class and resolve manifest class names), it discards that value and replaces it with the application ID

I cannot find anything in the platform APIs that suggests the package name (as expressed in AGP documentation) exists as a distinct value from the application ID (again, using AGP terminology) at run time.

Where are you expecting the value to come from?

Let me put you in context for when this problem can occur. Let's say an app is being developed under a certain applicationId and package structure. Before publishing to the store, it's decided to go with another applicationId, so the developers just need to change the applicationId whichout altering the package name and the whole package structure of the project.

When the app devs change the applicationId, the app should still work fine as long as the package name declared in the AndroidManifest.xml remains the same.

App components using relative paths work this way. I understand that it's easy for them to get the package name as it's declared in the same file. In layout files, tools:context attrs also seem to be working fine. Perhaps the app:layout_behavior attr shouldn't allow to set relative paths if it can't use the package name.

I guess a similar case is the app:layoutManager attr on RecyclerView. Looking at its sources, I see that it's doing the exact same.

It's really unfortunate that AGP would have implemented a feature like this without any consideration for the impact on run-time package resolution.

Assigning over to AGP team for suggestions.

Sorry for the late reply. AGP does not do anything fancy to resolve this. It's the same as manually setting a value in the package attribute of the manifest to be something else than your root java package name after the fact and not refactoring your code. Doing this prevents you from using non fully qualified class names in layout files.

BTW the default behavior should work fine. This is only a problem if you customize the applicationID, which again is no different than manually doing it in the manifest.

Jerome, what do you think? I don't see how we can change this.

this is hard, could we leverage the namespace feature (which in this example would remain unchanged) ? we would need to massage the resource files to use namespace value for non fully qualified class names, manifest merging, etc...

We could detect that

1. applicationID is overriden from the default package value
2. the layout file contains a relative reference to a layout that is present in the default package.

This adds quite a bit of processing to these files that we probably don't want to do if this is not used often (and since it's the first time we see this report, I would argue it's rare).

I think a better improvement would be a lint check.