Expand description
cargo xtask build-android: build the examples’ shared libraries, then the
APK that packages them.
Two tools, split along the language boundary. cargo ndk cross-compiles the
*_android crates, which hold the exported entry points and nothing else,
and drops each .so into the app’s jniLibs directory, which is where
Gradle looks for native libraries and packages whatever it finds; Gradle then
compiles the activities and assembles the APK around them. The libraries are
built first because an APK without them is an activity that cannot start.
Both tools configure themselves from the environment: cargo ndk reads the
NDK out of ANDROID_NDK_HOME (or the newest one under ANDROID_HOME/ndk)
and Gradle reads the SDK out of ANDROID_HOME (or android/local.properties).
Re-exports§
use std::path::Path;🔒use std::process::Command;🔒use super::BuildAndroidArgs;🔒use super::step;🔒
Constants§
- ABI 🔒
- The ABI the APK carries. Kept in step with
abiFiltersinandroid/app/build.gradle.kts, which is what decides what the APK accepts. - ANDROID_
DIR 🔒 - The Android application’s Gradle project, relative to the workspace root.
- JNI_
LIBS_ 🔒DIR - Where the Rust build puts the shared library, relative to the workspace
root. This is Gradle’s own
jniLibssource directory, whose subdirectory names are ABI identifiers, socargo ndk -owrites exactly its layout. - LIBRARY_
CRATES 🔒 - The crates that build the libraries the activities load, in the order the
tab bar lists them. Each is a
cdylibexportingandroid_main, and each activity names the one it loads in itsandroid.app.lib_namemanifest entry — the package is the example’s name with_androidappended, while the library keeps the example’s own name. - PLATFORM 🔒
- The API level the library is compiled and linked against. Kept in step with
minSdkinandroid/app/build.gradle.kts: linking against a higher one would let the library call into API the APK’s own floor does not promise.