feat(android): package the bindings as an AAR and test them on a device

[andiwand]

🤖 Generated with Claude Code

Two android-only failure modes shipped in a row: #628, a compile error in jni/src that only the NDK sees, and #621, a java.lang.ref.Cleaner that exists on the JDK and not on android's class library. Both were found by OpenDocument.droid, because it was the only thing that ever cross compiled this — the build_test matrix's single android entry only configured conan for one ABI, it never built the bindings, let alone ran them.

This adds android/, a gradle library module packaging the JNI bindings as app.opendocument:odr-core-android, and .github/workflows/android.yml, which on every push:

1. cross compiles all four ABIs (armv7, armv8, x86, x86_64) — catches the first outright;
2. lints NewApi over ../jni/java against minSdk 26 — catches android.* and the java.* APIs core library desugaring cannot backport (Cleaner), but not the desugarable ones, so it is a filter, not a proof;
3. assembles + lints the AAR, and runs an instrumented suite on an API 26 emulator (the floor OpenDocument.droid ships to) and on API 36 — the only check that sees what a device sees.

A binding is only covered once something in src/androidTest calls it; the suite currently decodes and renders documents, reads the bundled assets, drives a java log sink from native code, and serves a document over HTTP.

The artifact

odr-core-android.aar
├── classes.jar                        app.opendocument.core (../jni/java) + OdrAndroid
├── jni/<abi>/libodr_jni.so            the bindings with the core linked in
├── jni/<abi>/libc++_shared.so         the c++ runtime they were built against
├── assets/core/odrcore/*              css/js of the html renderer
├── assets/core/libmagic/magic.mgc     libmagic database
└── proguard.txt                       keeps the classes JNI resolves by name

main compiles ../jni/java verbatim, so the AAR and the maven jar are the same classes and cannot drift. The only android-specific production code is OdrAndroid.init(context): an APK holds the runtime data as assets and the renderer wants files, so it unpacks them into no-backup storage keyed by Odr.commitHash() and registers them with GlobalParams. build_native.py drives conan + cmake per ABI into native/prebuilt, where the gradle build reads them; CI runs it as one job per ABI and hands the results to the AAR and emulator jobs as artifacts.

OdrAndroid and the instrumented suite are Kotlin, matching OpenDocument.droid. What the module borrows stays Java and has to: ../jni/java and ../jni/testfixtures are compiled by CMake's add_jar for the maven jar and the host junit suite, neither of which has a Kotlin toolchain. The public surface keeps its Java shape — OdrAndroid is an object with @JvmStatic init and @Throws(IOException::class), so OdrAndroid.init(context) is still a static call throwing a checked exception. The one cost: the AAR's POM now declares kotlin-stdlib where it previously had no dependencies. odr-core-java is unaffected — still pure Java, still dependency-free. Formatting is spotless + ktfmt 0.64 kotlinlang, the same version droid runs, checked in the format workflow.

For now this is a second packaging of the same build, not a new path. OpenDocument.droid keeps building odrcore from the conan package (with_jni=True), which keeps the two halves in lockstep by construction. The intent is for the AAR to become droid's base, but that needs Maven Central first: GitHub Packages demands read:packages even to read a public artifact, and f-droid builds from source with no credentials. Verifying the app.opendocument namespace and signing the artifacts is separate work, not in this PR.

Along the way

• The four android-<arch> conan profiles replace android-35-x86_64 and share one android.jinja body. API level drops 35 → 26 to match the java floor — it is baked into the target triple, so a higher value produces libraries older devices refuse to load — and the NDK toolchain path is resolved per host, so the profiles work on macOS too. scripts/conan_lock locks each of them against the linux build profile.
• jni/CMakeLists.txt builds odr_jni without a JDK when targeting android: the NDK sysroot ships jni.h and the symbols come from the runtime. A JDK found there still builds the jar, which is what the conan package deploys next to the library. The junit suite stays host-only.
• TestFiles moves to jni/testfixtures, compiled by both suites, so it is limited to what API 26 offers — String.formatted, Path.of and Files.writeString are gone from it.
• Color.toString formats with Locale.ROOT; a device set to a locale with its own digits rendered it unparseable.

Verification

Built and run locally on an API 31 arm64 emulator: 16/16 instrumented tests pass, lint is clean against minSdk 26 with warningsAsErrors, and the release AAR assembles with all its assets and both prebuilt ABIs. CI is the first exercise of the four-ABI cross build and the API 26 emulator.

Docs: android/README.md (usage, building, testing) and android/AGENTS.md.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 228cc0dbfe

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".