The Android job has never fetched the model. Not because of the header
collision the desktop job hit -- that one is fixed and the desktop job
now pulls all 11 MB -- but because the image has no git-lfs at all:

    git: 'lfs' is not a git command. See 'git --help'.

The fetch step dies on its first line, `git lfs install --local`, before
any of the auth handling runs. The build then panics in dr-segment's
build script with a message telling you to run `git lfs install && git
lfs pull` -- advice that could not have worked, because the client it
names was never in the image to run.

Both jobs failing their fetch step at the same time made this look like
one bug with one cause. It was two, in two different images, and the
desktop one was noisier: it had a client, so it got as far as an HTTP
error worth reading. The android one had nothing to say beyond the name
of a missing command.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-26 06:52:50 +02:00

assemble-apk.sh

Lift the APK assembly out of package.sh so CI can run it too

2026-08-25 23:38:08 +02:00

build.sh

Add the Android app shell; cap cross-build parallelism

2026-08-09 21:10:00 +02:00

Dockerfile

Put git-lfs in the Android image, which never had it

2026-08-26 06:52:50 +02:00

package.sh

Lift the APK assembly out of package.sh so CI can run it too

2026-08-25 23:38:08 +02:00

README.md

Build the Android CI image in CI, not on a laptop

2026-08-16 14:59:57 +02:00

README.md

Android build environment

Reproducible container for cross-compiling DarkRoom to Android. CI and local builds use the same image, so a break appears in one place rather than two.

Use

# Cross-compile for a device ABI
./docker/android/build.sh cargo ndk -t arm64-v8a build --release

# All four ABIs
./docker/android/build.sh cargo ndk -t arm64-v8a -t armeabi-v7a -t x86_64 -t x86 build --release

# Type-check without linking
./docker/android/build.sh cargo check --target aarch64-linux-android

# Interactive shell
./docker/android/build.sh

# After editing the Dockerfile
./docker/android/build.sh --rebuild

Prefers podman, falls back to docker. First run builds the image, which takes several minutes; after that it is cached.

In CI

.gitea/workflows/android-image.yml builds this image and pushes it to gitea.tourolle.paris/dtourolle/darkroom-android, which the Android job then runs inside. It is called on every push and finishes in seconds unless something here changed — the image is tagged with the git tree hash of docker/android/, so a rebuild happens when and only when a file in this directory does.

Nothing needs pushing by hand. Editing the Dockerfile is the trigger; latest follows automatically. To force a rebuild without a content change, run the workflow from the Gitea UI with force set to true.

The job runs on the host runner rather than in a container, because it needs the Docker daemon and the runner host's cached registry credentials.

Pinned versions

Component	Version	Why this one
JDK	17	AGP's stable target. The host's JDK 25 breaks Gradle.
Compile SDK	API 36	Required for Play distribution
Min API	28 (Android 9)	Floor where Vulkan support is dependable (NFR-COMPAT-1)
Build tools	36.0.0	Matches compile SDK
NDK	27.2.12479018 (r27c)	Current LTS
Rust	1.92.0	Slint 1.17 requires it; cargo-ndk 4.1.x needs ≥ 1.86
cargo-ndk	4.1.2

Bumping any of these is a reviewable change, not silent drift.

Compile SDK versus min API

These are different and both matter. ANDROID_API (36) is what the SDK compiles against — the newest APIs available. MIN_API (28) is what native code links against, and determines the oldest device that can run the result.

cargo-ndk defaults to API 21 if not told otherwise, which is far below what this app needs. CARGO_NDK_PLATFORM and the per-target linker paths both pin it to MIN_API. Verify with:

file target/aarch64-linux-android/release/*.so
# → "... for Android 28, built by NDK r27c"

Caching

The cargo registry and target directory persist in ~/.cache/darkroom-android, so rebuilds do not re-download the crate index. Clear with:

rm -rf ~/.cache/darkroom-android

The Android target dir is kept separate from the host's target/ — sharing one directory between host and container builds causes constant rebuilds as they invalidate each other's fingerprints.

What is not here

No emulator, no adb device access. This image cross-compiles; it does not run or deploy. Device testing (spikes S2 and S10, which need two GPU vendors) happens on real hardware — the emulator's GPU behaviour is not representative of Adreno or Mali, which is precisely what those spikes exist to test.