IssueTracker

Update: compilation works fine, both through AS and terminal.

Modules are implementation dependencies, but that oughtn't be an issue since they're direct dependencies.

Hi, thanks for the bug. I'm trying to reproduce this. First, does clicking "Invalidate caches / restart" under "File" have any affect? Next, if possible could you send a reproducible project?

If not, I have some questions which might help figure out the root cause:

• Do you see the relevant R classes from java files?
• If you type simply "R" and do code completion, do you see any other examples of R classes?
• Does the package name you use for the R class match what is in that modules' AndroidManifest.xml
• Can you access any other module R class from the :app module?

Hi!

"Invalidate caches / restart"

It fixes...some of them, sometimes? (I have like ~4 Android lib modules, and ~5 pure Kt modules). Sometimes, it'll fix it and then it'll break the next time I force compilation across multiple modules. (Not a super useful answer I'm sorry)

Do you see the relevant R classes from java files?

I created a fake Java file just to test this; seems like it's broken for Java as well? (See attached)

If you type simply "R" and do code completion, do you see any other examples of R classes?

Vaguely related to the screenshot my original post (helpfully named Thu Dec 10 2020 18:36:05 GMT-0500 (Eastern Standard Time).png) - in most (but not all!) files, R. doesn't resolve to anything. R. works pretty well in :app, but none of the other feature modules.

Does the package name you use for the R class match what is in that modules' AndroidManifest.xml

Yes; I use https://github.com/GradleUp/auto-manifest

Can you access any other module R class from the :app module?

No, only the :app module's R. resolves in :app ☹️

if possible could you send a reproducible project?

Alas, it's a closed-source app. If you're plumb out of ideas, I could ping Xav through other means and see if we can get something set up.

BTW FWIW this has been broken for a while, at least the whole AS/AGP 4.2 line; I'm just a jerk and didn't file the bug until now.

Hi again. Good news, I think I've fixed this! The fix is due to be released in Android Studio 2020.3.1 Canary 15 which should be released soon. If you could let me know if you still experience this issue when that version is released, that would be much appreciated!

I awaited AF C15 with bated breath, and unfortunately the issue still happens 😭

Things I tried:

1. stopping (gw --stop) + re-syncing Gradle
2. rebuilding the project
3. Invalidate Caches + Restart AS

No dice!

I've attached logs on the off-chance that that's useful, as well as some more recent screenshots showing the same issue.

Let me know how I can help debug!

Hi. That's quite unfortunate, thanks for the quick update though. If you could construct a small sample project that triggers this bug for you, that would be extremely helpful. I have a feeling it has to do with the project structure, any info on dependencies and modules will also be helpful (eg. are you using dynamic feature modules? etc). Also, do you re-use the same module package name in multiple AndroidManifest.xml files? Thanks again!

While I see if there's a minimal sample project I can repro the issue in, here's some quick info on my corp project that this is happening in:

• obviously android.nonTransitiveRClass=true is set in the Gradle properties
• 20 modules, probably 3/4 of them are Android lib modules
• I have a buildSrc module with my dependency coordinates and a custom plugin that just externalizes the android { .. } block across all my android lib modules
• use .kts for all build.gradle files (RIP my sync time)
• no dynamic feature modules
• most of the modules are nested (e.g. :features:dashboard)
• core library desugaring is enabled
• all modules have their own package namespace (I use https://github.com/GradleUp/auto-manifest to generate manifest files)

The project structure is roughly:

• app
• models
• common
  • interfaces, annotations
• core
  • analytics, network, db, etc.
• features
  • dashboard, login, etc.

In the :app module, "local" resources work -- e.g. R.string.whatever. Resources from other modules don't work - e.g. hatch.core.design.R.string.anotherWhatever won't resolve in the IDE. In library modules, no resources resolve, local or otherwise.

I believe I've found the underlying issue here. The GradleUp auto-manifest gradle plugin creates AndroidManifest.xml files in directories that the IDE does not yet fully support. We are working on a solution for this and I will update this bug this bug when a fix has been released.

For a workaround:

• Instead of using auto-manifest gradle plugin to generate library module manifests, manually create the AndroidManifest.xml in each of your Android library modules. This can have the same contents as the auto-manifest generated manifest, but needs to be placed in the usual directory structure for modules (eg. MyApplication/lib/src/main/AndroidManifest.xml).

If there are any users experiencing unresolved resources with nonTransitiveRClass=true reading this, who are not using auto-manifest gradle plugin, please open a new bug and I will investigate. Thanks!

A fix for this should be included in Arctic Fox Beta 1. Although the GradleUp auto-manifest is not officially supported, it may now work as intended. Marking this as fixed, but I will update this bug if anything relevant comes up!

Sorry for taking such a long time to look into this. I'm closing this as obsolete since you've reported the issue being fixed. Feel free to open a new bug if the issue still exists.