ci: Android shares this implementation, and CI says so

[Sunrisepeak]

mcpp 2026.9.11.3 makes aarch64-linux-android and x86_64-linux-android real
target rows. The question that raises for this package has a short answer:
nothing here changes.

This file is written on the Linux kernel's own system-call interface and
borrows nothing from any C library -- that is what lets it be placed beneath
one. Android's kernel is Linux, the per-architecture system-call ABI is the
same, and src/sys.h branches on __x86_64__ / __aarch64__: the
architecture, not the operating system. A consumer needs no new line either,
because cfg(os = "linux") is true for an Android triple.

A claim about what does not change is exactly the kind that rots unmeasured, so
one step asserts it.

What the step checks

both ABIs build	mcpp build --target <t> --features standalone
the objects are the guest's	file names ARM aarch64 / x86-64 -- asserted rather than assumed from --target, because one of the two is not the runner's
no C library symbol	the same permitted set the native step applies, against a different libc

The last one is the interesting half. Compiling is the weaker statement; the
property this package exists for is the symbol closure, and on Android the C
library is bionic. A reference that resolved to glibc by habit would show up
here as a bionic name.

Two names the native set does not have

Measurement decides them rather than judgement:

__emutls_get_address   defined in libclang_rt.builtins-{aarch64,x86_64}-android.a
__aarch64_swp4_acq     defined in libclang_rt.builtins-aarch64-android.a

and in neither bionic libc.so. So they belong to the category the set
already admits for memcpy and its three neighbours: compiler-emitted,
computing rather than calling, and incapable of re-entering this
implementation.

The emulated-TLS one is not mcpp's choice: build.ninja for this target
carries no -femulated-tls, and the NDK's clang emits the reference by itself
from a bare thread_local int x; at API 21 -- its documented default below the
level where bionic gained ELF TLS.

They are permitted in this step only. Widening the native step's set for a
target it was not measured on is how a check stops being one.

What it does not check

Execution. Running an Android artifact needs a device or an emulator.
Measured by hand on an API 24 x86_64 image: a program written against openkal
alone -- no C library, no import std -- printed openkal: 1-2-3 with exit 0.
The device ABI has no execution path from an x86_64 runner at all, because
Google's emulator refuses a foreign guest (QEMU2 emulator does not support arm64 CPU architecture).

One matrix leg, because the axis does not reach this target: the Android rows
carry a capability pin, so mcpp refuses any other toolchain for them and
matrix.toolchain selects nothing here.

Verification

Both directions, by extracting the step and running it locally:

• passes on both ABIs (17 objects each, correct architecture)
• with puts added to a source, reports
  references a symbol it must not: puts for each ABI and exits 1

Depends on

mcpp 2026.9.11.3 (mcpp-community/mcpp#610). Until that is released this job
needs MCPP_SOURCE_REF, which the workflow already supports -- on the released
2026.9.11.2 the Android rows are still planned and the build is refused by
the tier gate.