Android target for a _transitive closure_ library aar

[mrdomino]

One of my work projects is an Android library with a substantial JNI footprint, designed for inclusion in third-party Android apps. I'd love to be able to specify it as a single bazel target (say for an aar, which seems to be what the Android people want us to generate these days) that depends on my android_library and cc_library.

My current planned stopgap is to build an android_binary and then take the .jar and .so out of the target for redistribution. Improvements and suggestions welcome.

[aj-michael]

android_library has an implicit AAR output called name.aar.

As an example,

$ cat java/com/foo/BUILD
cc_library(
    name = "cc_lib",
    srcs = ["foo.cc"],
)
android_library(
    name = "android_lib",
    srcs = ["Foo.java"],
    deps = [":cc_lib"],
)
$ bazel build //java/com/foo:android_lib.aar
INFO: Found 1 target...
Target //java/com/foo:android_lib.aar up-to-date:
  bazel-bin/java/com/foo/android_lib.aar
INFO: Elapsed time: 4.138s, Critical Path: 3.59s
$

[aj-michael]

Augh, I should not have closed this. Per the documentation of android_library:

name.aar: An android 'aar' bundle containing the java archive and resources of this target. It does not contain the transitive closure.

https://bazel.build/versions/master/docs/be/android.html#android_library

So the .aar output of android_library will not contain the .so from the cc_library.

I'm going to use this as the tracking bug for support transitive-closure-aars from android_library.

[andrewharp]

This would also be useful for TensorFlow so that we can build a full Android distributable in a single file (using only Bazel) during our nightly build process.

edit: We'd like to be able to package all relevant architectures in the same AAR, much like --fat_apk_cpu packages multiple target architectures in APKs.

[spinorx]

+1. Any update of expected support for this?

[ahumesky]

We're working on getting our testing for android apps in better shape, this is something we'll likely work on after that.

[steeve]

hey guys, i'm having another issue: the cc_library on which my android_library depends is not built when building via name.aar.
And when I build via name, it seems it is not built for the android ndk (unable to include jni.h, for instance)

[balazsbanyai]

+1

[spinorx]

Use sample in https://github.com/spinorx/grpc_andr_ios to unblock urself till this is fixed.

[balazsbanyai]

@spinorx thank you very much. I can build the app using the provided project, but the android_library target (eg. bazel build --config android //android:GreeterClient) won't build in this example either.

[spinorx]

Yeah, android_library does not propogate needed config to cc_library yet. See detailed discussion in: #3924

[aj-michael]

@steeve, see my response in #4407 (comment) if you want to build the cc_library for Android directly. Note that that will not get you a .so. To build a .so outside of android_binary, you need a cc_binary.

[steeve]

@aj-michael thanks! however, I'm trying to build an aar (not an apk) file that depends on the cc_library.
I would assume the toolchain configuration to be transitive to the cc_library with android_library the way android_binary does.

Also, there is the case of fat apks, which is better handled by building for the Android env via android_{binary,library} rules imho.

[aj-michael]

Yes, I was responding to your comment:

And when I build via name, it seems it is not built for the android ndk (unable to include jni.h, for instance)

android_library .aar output does not currently support bundling native libraries. This is a known deficiency that I believe @dkelmer has plans to work on.

If you're so inclined, you could workaround this deficiency by creating an additional android_binary and a genrule for the android_library, something like this:

genrule(
    name = "aar_with_jni",
    srcs = [
        ":abin_unsigned.apk",
        ":alib.aar",
    ],
    outs = ["alib_with_jni.aar"],
    cmd = """
cp $(location :alib.aar) $(location :alib_with_jni.aar)
chmod +w $(location :alib_with_jni.aar)
origdir=$$PWD
cd $$(mktemp -d)
unzip $$origdir/$(location :abin_unsigned.apk) "lib/*"
cp -r lib jni
zip -r $$origdir/$(location :alib_with_jni.aar) jni/*/*.so
""",
)

android_binary(
    name = "abin",
    manifest = "AndroidManifest.xml",
    custom_package = "does.not.matter",
    deps = [":alib"],
)

android_library(
    name = "alib",
    srcs = ["A.java"],
    deps = [":clib"],
)

cc_library(
    name = "clib",
    srcs = ["c.cc"],
)

[steeve]

nice, I hadn't though about this! thanks @aj-michael

[aj-michael]

This is a common enough request (JNI in .aar) that I decided to throw together an example repository for how to workaround it:

https://github.com/aj-michael/aar_with_jni

[andrewharp]

FWIW you can just use zip -ur to add files to an existing archive (we do this to create the TensorFlow AAR for release), no need to unzip first.

[jcayzac]

@aj-michael adding to this discussion, in my understanding the aar produced by bazel are also "incomplete" in the sense there is no (obvious) way to specify a consumer proguard file yet.

Should I file a separate issue for this, or better keep it here together with the related jni problem?

[aj-michael]

@jcayzac , please file a separate issue. If I understand what you mean, that is probably a much easier problem to solve. The JNI issue is a little tricky because at the moment android_library doesn't do any linking.

[cpsauer]

Ran across this while looking for a workaround for our team. Can confirm that there are still people who'd use this :) (looks like Tensorflow/MediaPipe are also using AJ's good workaround.)

Any updates on official support?

[steeve]

Once starlark rules_android lands (they are in alpha iirc), it'll be much easier to add it

[cpsauer]

After some more time hacking in and around the issue--and thinking about what we'd want in an eventual distributable AAR rule:

I think a key feature will be to not include the transitive dependencies downloaded from Maven. And to be able to push the generated AAR up to Maven, listing pointers to those Maven-based dependencies.

Unlike an APK where you want all the dependencies inside, with an AAR, you're (usually) trying to add a new node to the dependency graph of Maven dependencies. But you may very well want to structure your code inside that AAR into multiple bazel rules; it's your internal structure that you want bundled up transitively.

If anyone's got a good solution for this, I'd love to learn from you, if you're willing. We've just run into this, and it's a bit tricky to hack around at the moment, since Maven AAR imports seem to be either "always bundle", or "neverlink", when you want "link in a true APK, don't link in the AAR we're hacking out of an APK".

[cpsauer]

Also, another learning that might be useful to others:

Heads for others reading this issue that the current workaround it doesn't copy transitive java dependencies into the aar. I'm working on a version that does....but in the meantime Google libraries (like Tensorflow, etc.) are working around this workaround by filegrouping all the Java files into one android_library rather than have a Java build graph.

[cpsauer]

In case it's useful for thinking about the interface: looks like FB's buck has this pretty well handled: https://buck.build/rule/android_aar.html

[cpsauer]

@ahumesky, is this functionality you think will be rolled into your rules_android work in the near term? Wanted to check in before I do a bunch of hand-rolling here.

[ahumesky]

Unfortunately no, this is unlikely to be part of the Starlark android rules in the near term. We have mechanisms for this internally, but we're not in a position to open source them right now, and they may not even work externally. At some point it may make sense to integrate community contributions for this.

[cpsauer]

Bummer, but great to know. Thank you, Alex.

(I'm sure you guys already know all about why it's wanted, given, e.g. Tensorflow's need, so I won't say more on that.)

If you want what I end up building, lmk.

[cpsauer]

Hey all! We ended up building something pretty sweet to fix this.

The rule creates AARs that contain the transitive closure of their dependencies. It also crawls the graph to auto-generate POM files with dependencies, and lets you deploy to maven local or upload to a remote maven repository, including those of your own making, like S3 buckets. It also works with ProGuard on the AAR itself, plays nice with Bazel platforms, and provides control over resource exporting.

If enough people want this, too, we'll work on open sourcing (or contributing!) it. Maybe rules_jvm_external would be the most natural place. Say something if you want that.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[cpsauer]

@bazelbuild/triage, this issue is definitely still relevant for all the folks tracking.

(@bazelbuild/triage didn't seem to create a tag last I tried (no link) so I'm going to also tag @sgowroji and @Pavank1992 manually. Please coach me if you'd have preferred otherwise--and maybe update the bot's instructions)

[nkoroste]

Hey all! We ended up building something pretty sweet to fix this.

The rule creates AARs that contain the transitive closure of their dependencies. It also crawls the graph to auto-generate POM files with dependencies, and lets you deploy to maven local or upload to a remote maven repository, including those of your own making, like S3 buckets. It also works with ProGuard on the AAR itself, plays nice with Bazel platforms, and provides control over resource exporting.

If enough people want this, too, we'll work on open sourcing (or contributing!) it. Maybe rules_jvm_external would be the most natural place. Say something if you want that.

@cpsauer did you end up open-sourcing your solution?