Test aarch64-linux-android in emulator

[Brian Smith]

At the time we added 32-bit ARM Android to Travis CI, Aarch64 builds of Rust's libstd weren't available. However, now they are available, so we can add AAarch64 targets now.

[Sean Kelly]

I looked into this and it requires an upgrade to the API level.

18 is less than minimum platform for arm64 (21)

[pietro]

I was hoping I'd be able to add Aarch64 after moving Android to clang because the clang wrapper script shipped by the Android NDK defines the ABI level used when installing it. As a temp hack we could define __ANDROID_API__ to 21 on Aarch64 builds and 18 on all other hardware archs.

[Greg Linklater]

To do as @pietro suggests as a temporary hack, would it be as simple as changing the build.rs file to use API21 everywhere that it uses API18?

Please excuse the ignorance; I'm fairly new to Rust.

[Brian Smith]

To do as @pietro suggests as a temporary hack, would it be as simple as changing the build.rs file to use API21 everywhere that it uses API18?

    if target.os() == "android" {
        // Define __ANDROID_API__ to the Android API level we want.
        // Needed for Android NDK Unified Headers, see:
        // https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md#Supporting-Unified-Headers-in-Your-Build-System
        let _ = c.define("__ANDROID_API__", Some("18"));
    }

Basically, instead of hard-coding 18, we need to select 18 for 32-bit ARM and 21 for 64-bit arm. The target architecture is in target.arch in this function.

I would accept a PR that did that.

[pietro]

@briansmith 759f1cc did that but it got reverted because my changes to add aarch64-linux-android ended up being a bust. Have you done any work on the travis/android setup? I have some time next week to look into this and the other issues ring is having with android on travis if you aren't already working on this.

[Brian Smith]

@briansmith 759f1cc did that

Thanks. I just cherry-picked that specific commit in ring's master branch now: 72397df

but it got reverted because my changes to add aarch64-linux-android ended up being a bust.

They were great! However, there was just some flakiness, which was probably a small issue.

I have some time next week to look into this and the other issues ring is having with android on travis if you aren't already working on this.

It would be great to get your help. Right now I'm working on getting the Android build working in Docker as I find directly working with Travis CI to be painful.

[Brian Smith]

@pietro Could you summarize what needs to happen to get aarch64 Android builds in CI, on top of your recent work? Would it be easier to do now?

[Brian Smith]

As of last year, we no longer define the Android API level to build for in build.rs; instead we expect the person building ring to have already configured tings for the API level they want. And, at the same time, we switched from GCC to clang. So, I think that it might be reasonable to revive this effort now.

[Brian Smith]

In #622, @EternalDeiwos wrote:

I was able to successfully build v0.12.1 for aarch64 using the following environment variables:

PATH=$(PATH):$(NDK_STANDALONE)/arm64/bin \
CC=aarch64-linux-android-gcc \
CXX=aarch64-linux-android-g++ \
cargo build --target aarch64-linux-android --release --lib

The same worked for the armaebi, armaebi-v7a, i686 and x86_64 android builds which will allow me to use the static libraries in JNI. Aside from the API differences mentioned in #486, I don't think there's an issue (maybe aside from some documentation on the topic in BUILDING.md). The above error which I created the issue on was clearly a configuration problem on my end.

And he linked to https://github.com/Terrahop/react-native-rust-demo where his team's configuration lives.

[Brian Smith]

The previous attempt at this is at 968370d. Maybe it's just a matter of rebasing that on current master.

[pietro]

@briansmith the steps are the same as for armv7:

• Install SDK.
• Use SDK to install platform and system image.
• Download NDK and generate the correct standalone toolchain.
• Build.
• Create AVD.
• Run tests in emulator.

I have some local scripts to do that for both armv7 and aarch64, but they are not ready to be merged into ring because of the recent changes I've made. I think I'll be able to get a PR for that tonight.

[Brian Smith]

Update: I updated the CI to build for aarch64-linux-android but I didn't get the tests running. Ideally we'd get the tests running using an API level 21 image, since API level 21 is ring's minimum for AAarch64 android as of now.

Unfortunately, my changes conflict a lot with #783. I'm not opposed to reverting to an approach more like #783 once it is working