Use odrcore's own JNI bindings instead of the hand-written wrapper

[andiwand]

🤖 Generated with Claude Code

odrcore ships JNI bindings as of 5.7.0: a java API under app.opendocument.core and the matching libodr_jni.so, both built behind the recipe's with_jni option. This replaces the hand-written wrapper with them, pinned to 5.7.1.

What goes away

• app/src/main/cpp/ in full (core_wrapper.{cpp,hpp}, tmpfile_hack.{cpp,hpp}), app/CMakeLists.txt, and the externalNativeBuild blocks. The app compiles no native code at all now.
• CoreWrapper. It existed to flatten native failures into integer error codes (-2 encrypted, -5 unexpected format, …) and mirror them back into Core*Exception types; the bindings raise typed OdrExceptions directly, so both halves are dead. Its remaining job was process-wide state, which moves into CoreLoader: the one-time core setup, the single http server that RawLoader also publishes text files on, and the open Document that retranslate edits. LoaderService hands RawLoader the CoreLoader exactly as it already does for OnlineLoader, and MetadataLoader calls Odr.mimetype directly.
• The tmpfile() interposition. It only ever worked because the app linked the core into a library it compiled itself, and libodr_jni.so is a prebuilt. Nothing in the android option set calls tmpfile() anymore either — only wvWare did, and it is compiled out — so what remains is core resolving std::filesystem::temp_directory_path(), which falls back to a /tmp that does not exist on android. Setting TMPDIR before the first native call covers it.

Shipping both halves

with_jni=True in conanfile.txt produces libodr_jni.so per architecture and conandeployer.py copies it into build/conan/<arch>/jniLibs/<abi>, together with the libc++_shared.so it links — nothing else pulls the c++ runtime into the apk now that there is no externalNativeBuild. Verified in the apk:

lib/arm64-v8a/libc++_shared.so     lib/arm64-v8a/libodr_jni.so
lib/armeabi-v7a/libc++_shared.so   lib/armeabi-v7a/libodr_jni.so
lib/x86/libc++_shared.so           lib/x86/libodr_jni.so
lib/x86_64/libc++_shared.so        lib/x86_64/libodr_jni.so

The java half comes out of that same package: it sits in share/java/odr-core-java.jar, and the deployer puts it in build/conan/<arch>/libs while still skipping it when copying assets, so it is not shipped twice. app/build.gradle depends on the armv8 copy as a file, builtBy the conan install task.

No repository and no credentials are involved. The jar is also published to GitHub Packages, but that needs authentication even though the package is public — which F-Droid, who build this app from source in a clean environment, cannot supply. Taking it from the conan package keeps ./gradlew working with nothing configured, and closes a version-skew hole as a side effect: the classes and the .so are one ABI with no version negotiation, and they used to be pinned separately in libs.versions.toml and conanfile.txt with only a comment holding them together.

The 5.7.1 pin

The bindings as first released referenced java.lang.ref.Cleaner (android API 33) in NativeResource's static initializer and List.of (API 34) in Html; minSdk here is 26, so every core object died with NoClassDefFoundError on device — API 34 emulators passed and every older one failed. There is no consumer-side fix: core library desugaring does not cover java.lang.ref (verified on device, not just from the docs), and an app cannot ship a java.* class. opendocument-app/OpenDocument.core#621 fixes it upstream and is released in 5.7.1.

Two things move together: odrcore/5.7.1 in app/conanfile.txt, and the conan-odr-index submodule moved to the commit that adds the 5.7.1 recipe. The java half needs no separate bump — it comes out of the pinned package.

Verification

Everything below ran against the #621 bindings that 5.7.1 releases:

• ./gradlew assembleProDebug, testProDebugUnitTest, lintProDebug, spotlessCheck — all green, from a clean and with GITHUB_ACTOR/GITHUB_TOKEN unset, which is the F-Droid case. The 100 binding classes land in the apk dex and the jar stays out of the assets.
• ./gradlew connectedProDebugAndroidTest — 12/12 on a Pixel 6 Pro AVD (API 31), covering odt/docx/xlsx/pdf loading, password-protected documents (absent, wrong and correct password) and both edit-mode paths.

One regression was caught by that suite and is worth noting, because it is not obvious from the diff: serving pages from http://127.0.0.1:… instead of http://localhost:… silently breaks the WebView, since network_security_config.xml permits cleartext for the domain localhost only. The server binds to the loopback address and the URLs stay on localhost; both constants are now named and commented.

Notes for review

• CoreLoader.host() is the one entry point for translating and publishing a file. RawLoader uses it for text files with keepDocument = false; it previously reached the core with a cachePath that was never set, which arrived native-side as a null path.
• The proguard keeps move from CoreWrapper to app.opendocument.core.** — libodr_jni.so resolves HtmlConfig and friends by name via FindClass/GetFieldID and constructs the OdrException subclasses itself.
• CoreTest drives a real CoreLoader rather than statics, and asserts on thrown OdrExceptions where it used to assert on error codes.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 28a3e173be

ℹ️ 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".