[pre-release] Statically linking fails with custom styles that depend on resources in an aar about rules_android HOT 6 OPEN

Thanks for the detailed report.
I was able to reproduce this problem, and I was able to get past it by specifying the android namespace in the item name:

<item name="android:autoSizeMinTextSize">1sp</item>

Can you try this and see if it works?

from rules_android.

@ahumesky The usage of autoSizeMinTextSize without the android: namespace is intentional (and definitely works with Gradle/Buck). The android.R.attr.autoSizeMinTextSize attribute was added in API 26 as part of an effort to introduce auto-resizing text to the Android native TextView. Since using android:autoSizeMinTextSize doesn't work on API 25 and older (since old platforms won't understand it), AppCompat added the ability In order to backport the ability to older devices by creating its own R.attr.autoSizeMinTextSize attribute. The idea being that developers would prefer using the app-namespaced attributes instead of the android-namespaced attributes so they can make use of the feature safely on old platforms.

You can read more about this specific attribute here. But the idea extends to many other attributes too. The support libraries rely on creating these app-name spaced attributes pretty heavily to backport new platform features, so avoiding android: is definitely intentional and works in other build systems like Buck/Gradle too.

I think the fact that <item name="android:autoSizeMinTextSize">1sp</item> worked but not <item name="autoSizeMinTextSize">1sp</item> is an indication that maybe something weird is going on specifically with app-namespaced resources.

from rules_android.

Thanks for the details here.

Using the native android rules (i.e. the built-in / non-starlark rules), an app with name="autoSizeMinTextSize" and with appcompat dependencies builds, so it does look like something is missing in the starlark version of the rules.

One thing to note is that maven_install actually uses the native version of aar_import by default. These attributes enable the starlark version:

maven_install(
  ...
  use_starlark_android_rules = True,
  # the default is "@build_bazel_rules_android//android:rules.bzl"
  aar_import_bzl_label = "@rules_android//rules:rules.bzl",
)

And further, looking at the providers of native aar_import for appcompat:

$ ~/bazel/bazel-bin/src/bazel cquery @maven//:androidx_appcompat_appcompat --experimental_google_legacy_api --output=starlark --starlark:expr="'\n'.join(sorted(providers(target)))"
AndroidAssetsInfo
AndroidManifestInfo
AndroidNativeLibsInfo
AndroidResourcesInfo
DataBindingV2Info
FileProvider
FilesToRunProvider
InstrumentedFilesInfo
JavaInfo
OutputGroupInfo
ProguardSpecProvider

vs starlark aar_import:

<set use_starlark_android_rules = True on maven_install>
$ ~/bazel/bazel-bin/src/bazel cquery @maven//:androidx_appcompat_appcompat --experimental_google_legacy_api --output=starlark --starlark:expr="'\n'.join(sorted(providers(target)))"
AndroidIdeInfo
AndroidLibraryResourceClassJarProvider
AndroidNativeLibsInfo
FileProvider
FilesToRunProvider
JavaInfo
OutputGroupInfo
ProguardSpecProvider

AndroidResourcesInfo and others are missing.

So that means that starlark android_library + native aar_import also doesn't work (while native aar_import works with native android_library), and so perhaps there's something missing in android_library too. (On the other hand, it's not clear that we really need to support this mix of native and starlark rules). We'll go through the code to see what the disconnect is.

from rules_android.

@ahumesky I did some digging yesterday afternoon to try to figure out what's going on here. We found a few things:

1. Inside rules_jvm_external the _get_aar_import_statement_or_empty_str macro seems to be returning an empty string even when aar_import_bzl_label and use_starlark_android_rules are set. Hard coding the return value to @rules_android//rules:rules.bzl causes the aar_import rule in rules_android alpha to get called.
2. propagate_resources is False for all aar_import targets which results in the providers that would normally provide symbols.zip not being there (I'm able to confirm this looking at the symbols.zip being passed to aapt2 via -R during static linking).

from rules_android.

I think I found another reason this is not working: a chunk of code in aar_import related to resource processing is not being exported to github, because that code relies on other parts of the native android rules in bazel that haven't been open sourced. We may need to refactor this part of resource processing, and that might take a bit of time to work through.

from rules_android.

Hi, do we have an approximate expected time for pre-alpha to be officially merged into master?

Currently we encountered some problems when building Android app with bazel. Like bazelbuild/bazel#13295 bazelbuild/bazel#11497

seems the starlark version rule_android is key to solve these problems or at least make it easier.

Is there anything we can do to help speed up the process?

Thanks.

from rules_android.