linux-arm64 host build for Microsoft.Android.Sdk.Linux

[SuperJMN]

Hi,

I've been trying to build Android apps on a Raspberry Pi 4 (linux-arm64) using the .NET 10 SDK and ran into the fact that Microsoft.Android.Sdk.Linux only ships x86_64 host binaries. I poked around and the missing pieces are pretty narrow — would it be possible to add a linux-arm64 host build to the workload pack matrix?

What's actually x86_64-only inside ~/.dotnet/packs/Microsoft.Android.Sdk.Linux/<version>/:

• tools/Linux/aapt2
• tools/libMono.Unix.so
• tools/libZipSharpNative-3-3.so
• tools/Linux/binutils/bin/{as,ld,llc,llvm-mc,llvm-objcopy,llvm-strip,...} and the matching lib*.so

Everything else under tools/lib/arm64-v8a/, tools/dsostubs/, tools/libstubs/ and the aarch64-linux-android-* cross binaries is already shipped as aarch64 (those are device payloads / cross-compilers, not host tools).

Why this matters now:

• The .NET SDK itself is published for linux-arm64.
• ARM dev hosts and CI runners are increasingly common (Pi 4/5, Apple Silicon Linux VMs, Ampere / Graviton).
• qemu-user emulating amd64 isn't a viable workaround — the .NET runtime hits threading / signal issues under it (PLINQ ETW init failure, segfaults on plain dotnet new console), so you can't just run the existing pack through emulation.

I'd be happy to test any preview build on actual arm64 hardware if it helps. Is this on the radar, or is there a reason the host matrix is intentionally x86_64-only?

Thanks.

[jonathanpeppers]

tools/Linux/aapt2 is from Google redistributed from build-tools, is there a way for us to get an arm64 aapt2?

[SuperJMN]

@jonathanpeppers great question — turns out yes, with a small caveat.

Google does ship aapt2 from platform-tools / build-tools, but the published prebuilts are only windows-x86_64, darwin-x86_64, darwin-arm64 and linux-x86_64. There's no linux-arm64 host build of aapt2 from AOSP.

What does work in practice: the same aapt2 source compiled as a static-bionic arm64-v8a binary (i.e. an Android NDK build, statically linked against bionic, no .so deps) runs natively on Linux arm64 + glibc. The arm64 Linux syscall ABI matches between mainline Linux and the Android kernel, and bionic is fully self-contained, so the binary just runs as a normal Linux ELF — no qemu, no chroot.

The community-friendly source for this is ReVanced/aapt2, which already wraps the AOSP frameworks/base/tools/aapt2 build with NDK + protoc and produces per-ABI artifacts. I cross-compile it (NDK r27c, protoc 21.12) on a linux-x86_64 runner and the resulting arm64-v8a binary:

• passes aapt2 version natively on Pi OS bullseye (glibc 2.31, kernel 6.x)
• handles aapt2 daemon round-trips that MSBuild issues during the _CompileAndroidResourceValues / _LinkAssemblyNoShrink phases
• builds a vanilla dotnet new android template end-to-end on a Pi 4 (8 GB) in ~3m40s (vs ~4 min when aapt2 was running through qemu-user-static x86_64)
• the resulting signed APK installs and launches on a Pixel device with no FATAL/AndroidRuntime errors

The only fiddly bit is the version string — MSBuild greps aapt2 version output and rejects mismatches. AOSP's normal Soong build patches the build-id into a soong_build_number[128] placeholder buffer at link time; a CMake/NDK build doesn't run that step, so I sed-patch the array initializer directly to whatever string the matching Microsoft.Android.Sdk.Linux/<v> ships with. (For 36.1.53 that's 2.20-13193326.)

I've put the full pipeline in SuperJMN/DotnetAndroidArm64Shims — build script at shims/aapt2/build.sh, CI at .github/workflows/build-shims.yml, rationale and discarded approaches in docs/aapt2.md. Releases also include native arm64 builds of libMono.Unix.so and libZipSharpNative-3-3.so, which are the other two host binaries the pack needs on linux-arm64.

So if it's useful for the workload pack: the recipe for aapt2 linux-arm64 is "NDK build of the frameworks/base/tools/aapt2 sources for arm64-v8a, statically linked, with the Soong build-id stamped in via the build pipeline rather than at link time." Happy to help wire it into the official build if there's interest, or to keep maintaining the out-of-band shim release matched to each pack version — whichever is more useful.