Release 0.6.0

[ahumesky]

Release 0.6.0 is expected to comprise:

1. Starlark implementations of all rules
2. Starlark implementations of all providers
3. Tools migrated from the Bazel repo to the rules_android repo
4. Compatibility with {linux, mac, windows} x {bzlmod, WORKSPACE} x {bazel 6, bazel 7, bazel 8}
5. No longer requiring --experimental_enable_android_migration_apis / --experimental_google_legacy_api
6. Remove the "this doesn't work" disclaimer in the README

[ahumesky]

The current status is:

• All rule implementations are complete (except for a small handful of "native" calls for specific things that don't have Starlark equivalent APIs)

• All providers except ProguardSpecsInfo have been moved to Starlark, because the native version of ProguardSpecsInfo is actually in the Java rules. There is now a Starlark version of ProguardSpecsInfo in rules_java that we can migrate to, but this may or may not be in 0.6.0

• All Android tools have been moved out of bazel, however due to an array of dependency / logistics issues many of the tools rely on the "remote android tools" package that is built out of the bazel repo instead of the dependencies living / being defined in rules_android. This will be addressed in future updates

• Current compatibility for rules_android is {linux, mac, windows} x {bzlmod} x {bazel 7, bazel 8}.

  • WORKSPACE with Bazel 8 requires updating many dependent repositories (rules_java, protobuf, rules_go, gazelle, bazel itself, etc), mainly due to Bazel 8 removing java, proto, python, and shell rules. The impact is mitigated by 'autoloads' of Starlark rules for BUILD file which do not explicitly load these rules, but this does not cover all use cases. Work is ongoing to make each piece work with the other @comius
  • Bazel 6 support, motivated at present primarily for rules_jvm_external compatibility goals, is not yet tested @jin @shs96c

[ahumesky]

With 53cd4dc and many updates to dependencies, rules_android at head is compatible with Bazel 8 + WORKSPACE.

In cleaning up --experimental_google_legacy_api, we discovered two dependencies on deprecated APIs (cc_link_params_info and java_common.add_constraints()), those are being worked on next.

We've also done some testing with Bazel 6 and found a few things missing (optimizing_dexer is missing, bazelbuild/bazel@9337dfe), and ProguardSpecInfo is still guarded behind --experimental_google_legacy_api in Bazel 6.x. We may try to work around optimizing_dexer, and migrate to Starlark ProguardSpecInfo from rules_java. There may be other undiscovered issues, so we may need to investigate dropping Bazel 6 support from rules_android 0.6.0 and checking if rules_jvm_external can continue to be Bazel 6 compatible for non-Android uses while still depending on rules_android 0.6.0.

[jin]

@shs96c FYI on #278 (comment)

[ahumesky]

There are still a number of issues with compatibility between bazel 6 and rules_android, and I'm not sure if they can be worked around in a reasonable amount of time. The main driver we are aware of is rules_jvm_external that aims to support 3 versions of bazel (current + 2 previous), but I think for bazel 6, rules_jvm_external can test against the native Android rules which are still in bazel 6 (and bazel 7). Users who use the Android rules with bazel 6 would have to be using the native Android rules now anyway (or a much earlier version of the Starlark Android rules). Some more info in bazel-contrib/rules_jvm_external#1215 (comment)

So with that, we can create a 0.6.0 release with {bazel 7, bazel 8} x {bzlmod, WORKSPACE} x {linux, mac, windows} compatibility.

[ahumesky]

0.6.0 is relased: https://github.com/bazelbuild/rules_android/releases/tag/v0.6.0