Files
clawhdf5/crates/clawhdf5-android/README.md
T
osobhandClaude Opus 5.5 b55b24b7ba docs: crate READMEs describe each crate as it is today
Every crate under crates/ now has a README (android, bench, cli, napi and
wasm had none), each saying what the crate is, its main types and
functions (names checked against the code), its cargo features with
defaults and which ones build C (checked with `cargo tree`), and links to
the top-level docs.

Corrections to the old stubs:
- clawhdf5-derive: the derive is `H5Type`, not `HDF5Type`, and it needs
  clawhdf5-format as a dependency.
- clawhdf5-filters: deflate backends only, and no library crate depends
  on it; the filter pipeline and every other codec are in -format.
- clawhdf5-gpu: vector distance compute, not I/O; not used by
  HDF5Memory::search.
- clawhdf5-io: MpiVol is root-read + broadcast, not collective MPI-IO.
- clawhdf5-ann: from_hdf5/search(q, k) did not exist; load_from_hdf5 and
  search(q, k, ef).
- clawhdf5-accel: checksum::crc32_simd did not exist; the SSE4 and wasm
  backends are reported but run the scalar kernels.
- clawhdf5-gpu: the old example called l2_distances, which does not
  exist (l2_search).
- clawhdf5-agent: it described a "vector store" with "GPU acceleration";
  it now covers HDF5Memory, search options, WAL, signing, the graph.
- crates.io/docs.rs badges removed and `cargo install <crate>` replaced:
  nothing is published; depend on git.
- fuzz: the opt-in CLAWHDF5_FUZZ_SECONDS smoke run in ci-test.sh.
- tools: the FileEditor interop tests that live in this crate.
- remote, py: license, other front ends, limits, File.mode/flush/chunks.

The Rust examples of the facade, format, filters, accel, ann, derive and
agent READMEs were compiled and run as tests (netcdf4, gpu and remote
compiled only) in a scratch crate; the CLI example was run.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
2026-09-28 11:13:30 -05:00

2.0 KiB

clawhdf5-android

A C ABI over clawhdf5-agent for Android apps: a cdylib exporting extern "C" functions (edgehdf5_*, a name kept from the project's earlier "edgehdf5" days) that manage an HDF5Memory through an opaque handle.

The functions are plain C symbols, not JNI-mangled Java_... entry points: a Kotlin/Java app calls them through a thin JNI shim or JNA of its own. No such shim, Gradle project or AAR is in this repository, and the crate is not built for an Android target in CI (only its host-side unit tests run with the workspace).

Functions

Function What
edgehdf5_create(path, agent_id, embedding_dim) / edgehdf5_open(path) a handle, or null on failure
edgehdf5_close(handle) drop the store; what is not yet checkpointed stays in its WAL, as with any HDF5Memory
edgehdf5_save(handle, ...) save one entry; the embedding length is checked against the store's dimension before the pointer is read
edgehdf5_delete, edgehdf5_count, edgehdf5_count_active
edgehdf5_hybrid_search(handle, query, len, text, vector_weight, keyword_weight, max_results, out_indices, out_scores, out_chunks) results into caller-provided arrays; returns the number written
edgehdf5_add_session, edgehdf5_get_session_summary sessions
edgehdf5_add_entity, edgehdf5_add_relation knowledge graph
edgehdf5_free_string free a string this library returned

Every function is unsafe: the caller guarantees valid, NUL-terminated strings and correctly sized buffers (see each function's # Safety section), and serialises access to a handle; separate handles are independent.

Build

cargo build --release -p clawhdf5-android   # host build; for a device, add --target aarch64-linux-android with the NDK's linker configured

It depends on clawhdf5-agent with default features off, so there is no HNSW index (the vector stage is an exact linear scan) and no rayon pool. No C is compiled.

License

MIT