[soloturn]

AI-assisted change proposal. Filed by agent driven by @soloturn via GDD.

Draft — depends on openzim/libzim#1119, not asking for a merge yet.

Summary

openzim/libzim#1119 added an already-open fd to zim::ItemDataDirectAccessInfo, populated for both fd-opened and path-opened archives, so callers can dup() it instead of reopening filename by path - a reopen that fails with EACCES for some Android content-provider descriptors (openzim/libzim#852, kiwix/kiwix-android#3636, #3628).

Item::getDirectAccessInformation() (used for direct access to large media items) already returns that fd on the C++ side. This PR wires it through the JNI boundary:

• DirectAccessInfo.java: new public int fd field, -1 when unavailable.
• utils.h: setDaiObjValue() now also sets the fd field.
• item.cpp: dup()s the native fd before handing it to Java, so the Java side owns an independent descriptor rather than one whose lifetime is tied to the underlying Item/Archive.
• test.java: asserts dai.fd >= 0 alongside the existing filename/offset checks.

Why not ready to merge

This repo's build (install_deps.sh) downloads a released libzim tarball. Until libzim#1119 lands and ships in a release, CI here won't compile clean against it - cDirectObjInfo.fd doesn't exist in the current release's ItemDataDirectAccessInfo. Opening now so the JNI-side change is visible alongside the libzim PR it depends on; happy to hold pending that.

Test plan

• ./gradlew buildHeaders succeeds (Java side compiles, DirectAccessInfo.fd field present).
• item.cpp syntax-checked with g++ -fsyntax-only against a local libzim build carrying #1119's header changes - compiles clean (confirmed the one pre-existing unrelated warning, a jlong/int64_t mismatch in utils.h's SetLongArrayRegion on macOS-hosted JNI headers, reproduces identically on the unmodified baseline).
• Full native build against a real libzim#1119 build - blocked on that landing.

Related

• fix: open fd-backed archive parts via dup() instead of reopening by path openzim/libzim#1119 (draft, this depends on it)
• Allow extern getFd() to get file descriptors from Java for Kiwix Android openzim/libzim#852
• Added file picker in play store variant kiwix-android#3636, #3628

[soloturn]

AI-assisted change proposal comment. Filed by agent driven by @soloturn via GDD.

Heads up: openzim/libzim#1119 (which this PR builds on) reworked its fd exposure after an ABI-break review finding - ItemDataDirectAccessInfo::fd doesn't exist anymore, replaced by a new Item::getDirectAccessFd() method. Updated item.cpp here to match (be46ee1) - it's actually simpler now, getDirectAccessFd() already returns an owned, dup()'d descriptor so the manual dup() this side used to do is gone too.