HarmonyOS 6.1 / API 24: authorized HAP acquisition and Ark/DataShare analysis boundaries

[3482539802-maker]

I am evaluating REA for a read-only integration with Huawei Notes on my own MatePad. I found the existing HarmonyOS roadmap in #1431 and the newer main-branch package inventory documentation, so this is a question rather than a duplicate feature request.

Reproduced locally: npm rea-agents@6.4.0, Node 24.19.0, Windows. inspect-artifact succeeds on my own API 24 HAP, inventories its entries and labels the root as generic ZIP. That release's CLI help does not list project-harmony-application-graph; main describes a path-based Harmony inventory projection with Ark decoding and manifest semantics still out of scope. I have not analyzed Huawei Notes with REA.

Target and acquisition blocker: MatePad 11.5S / TGR-W10, HarmonyOS 6.1.0.135 SP9 (API 24), Huawei Notes com.huawei.hmos.hinote 15.0.14.348. Authorized HDC USB/wireless shell works, but the release application's installed HAP and private files are not readable by shell uid2000. Official root mode is rejected by this production firmware, and release Notes rejects aa attach with 10106002. The declared Notes DataShare URI exists, but the ordinary signed app's helper creation returns 202 / not system app, before any query. Public .hinote exports are readable snapshots, not a live data source.

Questions for maintainers/community:

1. Is there a documented, owner-authorized HDC/package acquisition route or supported public distribution artifact for commercial HarmonyOS release apps that REA users have successfully used? If REA assumes an already-readable local HAP, please confirm that boundary.
2. For an API 24 / HarmonyOS 6.1 Ark target, is there a tested bytecode-version/toolchain combination with ArkDecompiler, ABCDE or the official SDK ark_disasm? Which versions and limitations should we check before attempting to inspect a DataShare provider's schema and native bridge calls?
3. Are there public examples of reconstructing a HarmonyOS DataShare provider contract (profile URI rules, query fields, change notifications) from an authorized package, while keeping interface discovery separate from the runtime system-app/provider permission checks?

The goal is current document/page identity and structured pen-object changes for a personal study assistant, preserving Huawei Notes as the writing app. Static reverse engineering may reveal a contract, but does not itself grant system identity or access. No private notes, firmware dump, device IDs or signing materials are attached. References to existing work or confirmation that this currently requires OEM collaboration would be useful.

[deuxdoom]

Reading the current HarmonyOS guide, the workflow starts with an already-readable local package and covers package/component inventory only. Ark decoding and manifest semantics are explicitly outside that scope. The guide doesn't document an HDC acquisition route or a verified API 24 decoding toolchain, so that inventory support wouldn't resolve the Notes access blocker you described.

[konlue]

I think your boundary read is correct: REA assumes a locally readable package. Today the HarmonyOS lane is static package inventory only — per docs/harmony-analysis.md, it's the first increment of #1431: package identification + component inventory.

1. HDC / acquisition: none. No HarmonyOS device channel, no hdc references; only Android via caller-supplied adb. Start from an existing local .hap/.hsp/.app:

rea inspect-artifact /path/to/Example.hap --format json
rea project-harmony-application-graph projection-input.json --format json

CLI and MCP share project_harmony_application_graph; MCP input is inventory_evidence. App Pack children are path-only; .har is not classified by suffix.

2. Ark toolchain: not shipped, verified, or documented. Ark bytecode contents/versions are out of scope and land in limitations until a dedicated provider exists. Verification does not verify Ark decoding/signatures or complete the pinned [Feature] HarmonyOS/OpenHarmony package and Ark bytecode analysis (ArkDecompiler evaluation) #1431 toolchain acceptance. Bring your own ArkDecompiler/ABCDE/ark_disasm. The pinned real-provider fixture is an old 1.0.1 HAP, not API 24.

3. DataShare contract reconstruction: not possible from REA output alone. Manifest semantics are out of scope; native-side claims are path-based N-API bridge hypotheses, not observed boundaries. You'd need external Ark decoding plus manual semantic work.

Version: the projection landed in 6.5.0 via #1447, so 6.4.0 won't show project-harmony-application-graph. Use a main build or the next release.

Access blocker: the 202 / "not system app" response is a runtime system-identity check — static analysis can't grant it. Public .hinote exports remain the sanctioned read path for your own notes; live access needs OEM cooperation. Your split between interface discovery and runtime system-app/provider permission checks matches how the roadmap separates increments.