Files
DarkRoom/docker/android
dtourolle cc1c5c892d Support requesting VFS hydration; fix Android TLS cross-compilation
Correcting the previous commit: I claimed VFS placeholders could not be
downloaded. That was wrong. The desktop client exposes a socket at
$XDG_RUNTIME_DIR/Nextcloud/socket speaking newline-delimited
COMMAND:argument, and MAKE_AVAILABLE_LOCALLY:<path> does fetch the file.
Verified against client 4.0.7: a 1-byte stub became a real 2.8MB file in
2.8 seconds.

Implemented as dr-sync-nextcloud::desktop_client, deliberately optional.
Android has no desktop client, no XDG_RUNTIME_DIR socket and no
placeholders, so detect() returns None there and callers fall back to the
connector. It earns its place only because it is ~30 lines with no
dependencies: where a library already lives in a VFS folder, asking the
client to fetch beats downloading a second copy over WebDAV and leaving
the client's placeholder state inconsistent.

What this does not change: hydration is whole-file, so it suits the
original tier and never browsing. Filling a grid this way downloads the
entire library. Range extraction remains the only mechanism satisfying
FR-NC-3, and ARCH §9.0 now says so precisely.

Also fixes two real Android build failures found by cross-compiling:

  - reqwest's `rustls` feature defaults to aws-lc-rs, whose aws-lc-sys
    crate is C and fails under the NDK — exactly the pain D1 chose Rust
    to avoid. Switched to rustls-no-provider + ring, installing the
    provider in the constructor so no caller can build a client that
    panics on first use.
  - ring itself needs CC/AR per target; cargo-ndk sets only the linker.
    Added them to the container.

87 tests passing. dr-sync-nextcloud cross-compiles for aarch64-linux-android.
2026-08-09 10:10:29 +02:00
..

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.

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.