@@ -1083,6 +1083,48 @@ jobs:
       - name: dist-web produces a static directory, and node runs it
         working-directory: tests/web-consumer
         run: MCPP="$MCPP" ./check-web-plan.sh
+      # `kind = "app"` on `*-linux-android` links a shared object (#622 A3),
+      # so this fixture's own toolchain resolution provisions `xim:android-
+      # ndk` for `--target x86_64-linux-android` exactly as mcpp's own CI
+      # does; `dist-apk` provisions the four payloads on its own
+      # `feature-xlings.dist-apk` table (`xim:android-build-tools`, `xim:
+      # android-platform`, `xim:jdk-temurin`, `xim:android-debug-keystore`).
+      # NOT YET GREEN under this job's pinned `MCPP_VERSION`: `kind = "app"`
+      # and `mcpp::min_platform_version()` are #622 engine additions, and
+      # this step needs the release that carries them (see this repository's
+      # README, `dist-apk`'s own row) -- raising the pin is P5's own change,
+      # together with the rest of this collection's release.
+      - name: dist-apk produces a signed APK, level 0 and level 1
+        working-directory: tests/apk-consumer
+        run: |
+          "$MCPP" build --target x86_64-linux-android
+          "$MCPP" pack --format apk --target x86_64-linux-android | tee pack.log
+          apk=$(find target -name 'apk-consumer.apk' | head -1)
+          test -n "$apk" || { cat pack.log; echo "FAIL: no apk-consumer.apk"; exit 1; }
+
+          BT=$(find "$MCPP_HOME/registry/data/xpkgs/xim-x-android-build-tools" -mindepth 1 -maxdepth 1 -type d | head -1)
+          JDK=$(find "$MCPP_HOME/registry/data/xpkgs/xim-x-jdk-temurin" -mindepth 1 -maxdepth 1 -type d | head -1)
+          AAPT2="$BT/aapt2"
+          APKSIGNER="$BT/bin/apksigner"
+          JAR="$JDK/bin/jar"
+
+          "$APKSIGNER" verify --print-certs "$apk" 2>/dev/null | tee verify.log
+          grep -q 'CN=Android Debug' verify.log \
+            || { echo "FAIL: not signed with the debug key"; exit 1; }
+
+          "$JAR" tf "$apk" | tee listing.log
+          for f in "lib/x86_64/libapk-consumer.so" "assets/mcpp-run.json" \
+                   "AndroidManifest.xml" "assets/generated/res.bin"; do
+            grep -qxF "$f" listing.log \
+              || { echo "FAIL: the apk does not list $f"; exit 1; }
+          done
+
+          "$AAPT2" dump badging "$apk" 2>/dev/null | tee badging.log
+          grep -q "^package: name='" badging.log \
+            || { echo "FAIL: aapt2 could not read the package name"; exit 1; }
+          grep -q "sdkVersion:'24'" badging.log \
+            || { echo "FAIL: minSdkVersion is not 24 (this fixture's own min_api_level)"; exit 1; }
+          echo "ok: dist-apk level 0 -- a signed, aapt2-readable APK carrying the native library, the deployed asset and the run sidecar"
 
       # Compiles the device unit on a machine with no GPU: the clang route
       # produces sm_89 code from the payload toolkit. Running it needs a
 
@@ -75,6 +75,8 @@ engine's own module family and is not used here.
 | `dist-wix` | `mcpp.dist.wix` | 2026.9.11.1 | `xim:wix`, which this feature declares on the Windows target axis; the .NET 6 runtime the tool needs is a Windows component the payload does not carry, and `wix --version` names it when it is missing. Windows only. Renders a `.wxs` and passes the program in as a preprocessor variable, because a bind path that resolves to nothing is silent |
 | `dist-apple` | `mcpp.dist.apple` | 2026.9.11.2 (macOS), 2026.9.12.3 (iOS) | the base macOS install (`ditto`, and `codesign` only when an identity is given). macOS: `Contents/`-shaped, as always. iOS (`aarch64-ios-sim`, `aarch64-ios`): a flat bundle at the same call site -- no separate feature, no separate module -- with `MinimumOSVersion` from `mcpp::min_platform_version()` (#622 A11), `CFBundleSupportedPlatforms` read from `env == "sim"`, `UIDeviceFamily`, `LSRequiresIPhoneOS`, and a directory of flat PNGs listed under `CFBundleIcons` in place of macOS's single `.icns` file. Signing is skipped on the simulator row (`options::identity` is ignored, with a `mcpp::warning` naming why) and unchanged on the device row. **The iOS floor is provisional**, pending the mcpp release that carries #622's engine items ("the release that carries #622" -- filled in at release time; see this repository's CHANGELOG). **The macOS floor is one release higher than its siblings** and the reason is not this member: under 2026.9.11.1 `mcpp pack` staged before dispatching and let a staging failure fail the command, so on a Mach-O program -- which the built-in closure walk refuses, because it uses `LD_TRACE_LOADED_OBJECTS` and dyld answers that by running the program -- every dispatched format was unreachable, including one that reads no staged tree. 2026.9.11.2 makes staging a service to the provider |
 | `dist-web` | `mcpp.dist.web` | 2026.9.12.3, the release that carries #622: the `.js` launcher and the staged stem family, `mcpp::deploy`, and the build program's host compiler under the Web row | nothing beyond mcpp: `wasm32-emscripten` only. Copies `${mcpp.stage_dir}/bin/` -- the `.js` launcher, the implicit `.wasm`, the `.data` when present, and every `mcpp::deploy`'d file, all of which #622 A5 and A4 already stage there -- to `<out_dir>/web/`, dropping the `bin/` prefix a browser has no use for, and writes an `index.html` rendered from a project template or a built-in default that loads the script with a plain `<script src>`. **POSIX hosts only for now**: each file is copied with one `cp SRC DST` action (argv only, no shell), and `cp` does not exist on Windows; a portable copier is future work this member does not need yet |
+| `dist-apple` | `mcpp.dist.apple` | 2026.9.11.2 | the base macOS install (`ditto`, and `codesign` only when an identity is given). macOS now; iOS when the target row is wired, which is a payload rather than a redesign. **The floor is one release higher than its siblings** and the reason is not this member: under 2026.9.11.1 `mcpp pack` staged before dispatching and let a staging failure fail the command, so on a Mach-O program -- which the built-in closure walk refuses, because it uses `LD_TRACE_LOADED_OBJECTS` and dyld answers that by running the program -- every dispatched format was unreachable, including one that reads no staged tree. 2026.9.11.2 makes staging a service to the provider |
+| `dist-apk` | `mcpp.dist.apk` | 2026.9.12.3 (provisional: the release that carries #622 -- `kind = "app"`, `mcpp::deploy`, `mcpp::min_platform_version`) | `xim:android-build-tools`, `xim:android-platform` (versioned by API level, read back for `targetSdkVersion`), `xim:jdk-temurin` (`javac`/`jar`; `android-build-tools`' own runtime dependency provisions a JDK for its OWN wrappers only), `xim:android-debug-keystore`, all on the `cfg(env = "android")` axis. Generates `AndroidManifest.xml` and signs with the published Android debug key by default. Level 0 needs no Java (`hasCode="false"`, `android.app.NativeActivity`); `options::java_sources` adds `javac` + `d8` and a real `<activity>`. Android only -- an `app` target is a shared object on this row (#622 A3), and this member reads its native library from the staged tree and whatever `mcpp::deploy` placed beside the ordinary build's link output, because Android's own closure stages neither the dependency set nor the deployed files (see `dist/apk.cppm`'s header) |
 
 ### Each rule brings its own environment