bazelbuild/rules_android

AAR libraries from Maven don't expose their resources unlike in built-in Android rules

Closed this issue · 3 comments

Here's an example project that demonstrates this: https://github.com/gottagofaster236/android-starlarkified-project

It has an initial commit which uses the built-in Java Android rules in Bazel and demonstrates using a string resource from androidx.appcompat:appcompat, in that specific example, @string/search_menu_title. This commit builds successfully.

The next commit switches to the starlarkified rules, and receives the following error:

src/main/java/com/example/myapplication/res/layout/activity_main.xml:6: error: resource string/search_menu_title (aka com.example.myapplication:string/search_menu_title) not found.
error: failed linking file resources.

	at com.google.devtools.build.android.CommandHelper.execute(CommandHelper.java:42)
	at com.google.devtools.build.android.AaptCommandBuilder.execute(AaptCommandBuilder.java:286)
	at com.google.devtools.build.android.aapt2.ResourceLinker.linkStatically(ResourceLinker.java:295)
	at com.google.devtools.build.android.ValidateAndLinkResourcesAction.main(ValidateAndLinkResourcesAction.java:235)
	at com.google.devtools.build.android.ResourceProcessorBusyBox$Tool$7.call(ResourceProcessorBusyBox.java:106)
	at com.google.devtools.build.android.ResourceProcessorBusyBox.processRequest(ResourceProcessorBusyBox.java:237)
	at com.google.devtools.build.android.ResourceProcessorBusyBox.main(ResourceProcessorBusyBox.java:184)

I think this might be an issue with the ACL system in the rules, rather than a problem with resource processing itself.

If you're set up for it, does it work if you change this line to propagate_resources = True:

propagate_resources = _acls.in_aar_propagate_resources(str(ctx.label)),

Yes I think this is because under bzlmod, label syntax changes a bit and they look like @@rules_jvm_external~~maven~maven//:androidx_core_core, and ACL resolution in the android rules doesn't fully parse labels with bzlmod:

# Labels with workspace names ("@workspace//pkg:target") are not supported.
# For now, default external dependency ACLs to True to enable rollout features for all
# external users. See https://github.com/bazelbuild/rules_android/issues/68
# Note that this only affects Bazel builds with OSS rules_android.
if fqn.startswith("@") and not fqn.startswith("@//") and not fqn.startswith("@@//"):
return True
# "@//" is the same as the main workspace. It's not completely accurate to treat these as
# absolute labels, because "@//" from within an external repository refers to the main
# workspace, and "//" from within an external repository refers to labels within that
# repository, but this should be fine for ACL resolution.
if fqn.startswith("@//"):
fqn = fqn[1:]
# "@@//" refers to the canonical name of the main repository.
if fqn.startswith("@@//"):
fqn = fqn[2:]

I'm looking at removing this ACL altogether