[ahumesky]

Remove build_tools_version and api_level to let android_sdk_repository automatically select the latest installed version.

One of the fixes for bazelbuild/bazel#13409 (comment)

[philwo]

This broke the tests on Bazel CI: https://buildkite.com/bazel/android-testing/builds/1283

Any idea how we could fix this?

[ahumesky]

androidsdk/build-tools/30.0.1/zipalign: error while loading shared libraries: /usr/local/lib/libc++.so: file too short

Well, could be that removing api_level = 28 caused something to go wrong in native code generation (seems unlikely), or the zipalign tool in 30.0.1 behaves differently from the zipalign tool in 28.0.2, or something else... I'll try to see what's happening

[philwo]

I wonder if that's a missing dependency in our image. 🤔 Let me try manually running that file..

[ahumesky]

Yeah, I didn't read the error closely enough, I thought it was complaining about a .so file in the apk, but it looks like this is the zipalign tool itself not being able to run

[philwo]

Seems to work:

buildkite-agent@bk-docker-239d:/opt/android-sdk-linux$ build-tools/30.0.1/zipalign
Zip alignment utility
Copyright (C) 2009 The Android Open Source Project
[...] 

buildkite-agent@bk-docker-239d:/opt/android-sdk-linux$ ldd build-tools/30.0.1/zipalign
	linux-vdso.so.1 (0x00007ffe7f7ce000)
	libc++.so => /opt/android-sdk-linux/build-tools/30.0.1/lib64/libc++.so (0x00007f069da68000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f069d755000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f069d536000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f069d198000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f069cf90000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f069cd78000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f069c987000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f069d959000)

It's interesting that it is dynamically linked against a bundled copy of libc++.so. Maybe this doesn't work when Bazel runs the tool for some reason?

However for build-tools 28.0.2 it looks the same (but maybe when using build-tools 28.0.2, our rules don't call zipalign? Sorry, I don't know the details of our Android support, just guessing here..).

[ahumesky]

Yeah, we have a wrapper that's supposed to enable the tools to find their lib directories:
https://cs.opensource.google/bazel/bazel/+/master:tools/android/android_sdk_repository_template.bzl;l=199-225;drc=37ea3d53330acaa1ea27c8c426297b683ba0220a

[philwo]

Alex and me debugged this a bit more directly in the Docker container that's used on Bazel CI.

The problem is this:

• The project configuration runs actions in the rbe-ubuntu16-04 container, which uses the JDK 8 by default.
• build-tools 30.0.1 apparently is built against JDK 11, so it can no longer run with JDK 8.
• We can switch the project config to use a JDK 11 that's apparently stored somewhere in the container, but this then breaks two emulator tests, because they try to use Qt which doesn't work and then they crash.

I'll have to think about how to fix this a bit more tomorrow.

How I switched the project to JDK 11:

# Replace the rbe_autoconfig(...) part in WORKSPACE with:
rbe_autoconfig(
    name = "rbe_jdk11",
    java_home = "/usr/lib/jvm/11.29.3-ca-jdk11.0.2/reduced",
    use_checked_in_confs = "Force",
)

[philwo]

I guess, in the worst case if I can't get the RBE stuff working, we might have to revert to enabling KVM support on our instances and running the emulator locally (at least temporarily).