[libc++][Android] Enable libc++ testing using adb on an x86-64 emulator

[rprichard]

Summary

Adds a "run-buildbot android-ndk" testing mode that builds libc++
using NDK r25b and runs the tests on an x86-64 API 33 emulator.

A Dockerfile.android builds a docker image based on
ldionne/libcxx-builder, adding the Android SDK and NDK. The Docker
container needs to be started with --privileged so it has access to
KVM.

[philnik]

IMO it would be good to also add the Android job with this patch to make sure everything works properly. You should be able to just add a job to libcxx/utils/ci/buildkite-pipeline.yml. See https://libcxx.llvm.org/AddingNewCIJobs.html#addingnewcijobs for more details.

libcxx/cmake/caches/AndroidNDK.cmake

22

Does Android actually use a different ABI namespace, or is this just to avoid name clashes when testing? If it's just fur testing purposes I'd suggest to rename it to something like __test.

32

This flag isn't honoured anymore. The experimental library will always be built.

libcxx/utils/ci/run-buildbot-container-android

2

IIUC this allows anybody to run the Android test suite in a docker container? If that's the case, it's really nice.

[rprichard]

libcxx/cmake/caches/AndroidNDK.cmake

22

Android has a few different builds of libc++. In the "platform libc++" (/system/lib[64]/libc++.so), the namespace is the ordinary __1. Apps aren't supposed to use the platform libc++, though, and instead they redistribute a libc++_shared.so from the Android NDK. libc++_shared.so uses an __ndk1 namespace. Both the filename and the namespace are supposed to help isolate the NDK libc++ from the platform STL.

With recent Android versions, there are also "APEX modules" that have a copy of libc++.so in them. This copy is very similar to the platform libc++.so, but typically built against an older API level.

Naming it __test for this test configuration seems reasonable.

32

I'll remove this line then. It should be fine to build the library, even though I think the experimental library isn't available in the platform or the NDK currently.

libcxx/utils/ci/run-buildbot-container-android

2

Yes, it should become really easy for others to run the libc++ tests on Android.

[rprichard]

Switch namespace from __ndk1 to __test.

[rprichard]

Add feature LIBCXX-ANDROID-FIXME.

[Mordante]

In D139147#3965119, @philnik wrote:

IMO it would be good to also add the Android job with this patch to make sure everything works properly. You should be able to just add a job to libcxx/utils/ci/buildkite-pipeline.yml. See https://libcxx.llvm.org/AddingNewCIJobs.html#addingnewcijobs for more details.

+1 That makes reviewing the code easier.

[rprichard]

Reword a comment.

[ldionne]

It's awesome to see this taking form! This will be the first time that we have an upstream CI bot running via an emulator, and I know there are many more use cases for this so it's great to break trail.

I have a few comments but this LGTM. I agree with others that it would be nice to add a CI runner in the same patch to test that it all works.

libcxx/cmake/caches/AndroidNDK.cmake

22

Ideally, this cache file would reflect the way you actually build for the NDK. The executables in the test suite should reliably use -nostdlib++ and so on to make sure that we're linking only against the just-built libc++, so I am not sure whether these hoops are necessary. Did you notice that the tests were not being linked/run against the right library?

The same comment holds for the _static renaming above.

libcxx/utils/ci/run-buildbot

632–635

It would be sweet to be able to do this automatically when we startup the test suite. But this is probably fine to improve incrementally, this is already a giant step in the right direction.

libcxxabi/test/configs/llvm-libc++abi-android-ndk.cfg.in

36

Not attached to this line: You should update our platform support matrix to add Android if it's not already there.

[smeenai]

libcxx/cmake/caches/AndroidNDK.cmake

22

Yeah, I feel like it'd be less confusing if this used the __ndk inline namespace like the actual NDK's libc++ does.