[GH-ISSUE #4489] [Feature] Harmony graph: use `pkgContextInfo.json` `isSO` declarations for N-API candidates, and report inventoried entries outside every component category #1778

New issue

Open

opened 2026-10-16 21:10:09 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:10:09 +00:00

Owner

Originally created by @Rinkia on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4489

Before submitting

I searched the open and closed issues for a related report (pkgContextInfo, harmony napi, harmony bridge, harmony module.json). Related: #1431 (roadmap), #3349 and #3830 (component classification), #3350 (JavaScript hints). I found nothing on pkgContextInfo.json or on dropped entries.
I understand the contribution scope; this stays within static, path- and file-level evidence.
This report contains no credentials or private target samples.

Area

Android or mobile analysis

Current limitation

For a real Stage-model HAP with native code, karing-harmony-1.11.0.hap, project_harmony_application_graph is accurate in what it lists:

26 components (2 manifests, 1 bytecode, 20 resources, 3 native libraries); every path and SHA-256 matches the archive;
packaging model stage, families ark and native, coverage complete-within-inventory.

Two things could be better.

1. N-API candidates ignore a declaration that is in the package. The bridge candidates are the path-based product ets/modules.abc × libs/arm64-v8a/{libc++_shared.so, libentry.so, libkaringbox.so}. But the build output pkgContextInfo.json (586 bytes) declares which native library ArkTS imports:

"libentry.so":{"isSO":true,"moduleName":"","bundleName":"","dependencyAlias":"","packageName":"libentry.so","entryPath":"Index","version":""}

Only libentry.so is marked isSO. libc++_shared.so is the C++ runtime, and libkaringbox.so is presumably loaded by native code rather than imported from ArkTS. The same file lists the package's ArkTS dependencies (@ohos/hypium 1.0.25, @ohos/hamock 1.0.0) with their versions.

2. Inventoried entries outside every category disappear. inspect_artifact inventories pkgContextInfo.json and .pages.info (as artifact_kind: "resource"), but the projection puts them in no component list, and nothing records that they were left out. Coverage still reads complete-within-inventory. A caller can't tell, from the projection alone, that 2 of the 28 entries weren't classified.

Desired outcome and success criteria

Parse pkgContextInfo.json when it is present and valid JSON within a size bound. Report each isSO: true entry as a declared N-API module: a basis such as pkg-context-declared, with the source path and digest, matched to libs/<abi>/<name> where that file exists. Keep the path-based candidates, but mark the declared one distinctly, or make the path-based basis say that it wasn't narrowed. A malformed or missing file keeps today's behaviour, with a limitation.
Optionally report the declared package dependencies and versions as declarations, not as resolved code.
List entries that fall in no category, or count them in coverage, so complete-within-inventory can't be read as "every entry classified".

Expected interaction with targets

Read the package only. No execution.

Verification available so far

Target: https://github.com/ks-lm-kf/harmony-kslmkf-karing-hap/releases/tag/v1.11.0 → karing-harmony-1.11.0.hap, 48,441,498 bytes, sha256 8fcd80e44114421ca57808add801575cbe3fd9b964c230b36c979cfd07139eed (matches the GitHub asset digest). I did not check the repository's license or provenance beyond the release.
Reference: unzip plus sha256sum of every member (28 files).
rea-agents@6.5.0: inspect-artifact → project-harmony-application-graph.

Originally created by @Rinkia on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4489 ### Before submitting - [x] I searched the open and closed issues for a related report (pkgContextInfo, harmony napi, harmony bridge, harmony module.json). Related: #1431 (roadmap), #3349 and #3830 (component classification), #3350 (JavaScript hints). I found nothing on `pkgContextInfo.json` or on dropped entries. - [x] I understand the contribution scope; this stays within static, path- and file-level evidence. - [x] This report contains no credentials or private target samples. ### Area Android or mobile analysis ### Current limitation For a real Stage-model HAP with native code, `karing-harmony-1.11.0.hap`, `project_harmony_application_graph` is accurate in what it lists: - 26 components (2 manifests, 1 bytecode, 20 resources, 3 native libraries); every path and SHA-256 matches the archive; - packaging model `stage`, families `ark` and `native`, coverage `complete-within-inventory`. Two things could be better. **1. N-API candidates ignore a declaration that is in the package.** The bridge candidates are the path-based product `ets/modules.abc` × `libs/arm64-v8a/{libc++_shared.so, libentry.so, libkaringbox.so}`. But the build output `pkgContextInfo.json` (586 bytes) declares which native library ArkTS imports: ```json "libentry.so":{"isSO":true,"moduleName":"","bundleName":"","dependencyAlias":"","packageName":"libentry.so","entryPath":"Index","version":""} ``` Only `libentry.so` is marked `isSO`. `libc++_shared.so` is the C++ runtime, and `libkaringbox.so` is presumably loaded by native code rather than imported from ArkTS. The same file lists the package's ArkTS dependencies (`@ohos/hypium 1.0.25`, `@ohos/hamock 1.0.0`) with their versions. **2. Inventoried entries outside every category disappear.** `inspect_artifact` inventories `pkgContextInfo.json` and `.pages.info` (as `artifact_kind: "resource"`), but the projection puts them in no component list, and nothing records that they were left out. Coverage still reads `complete-within-inventory`. A caller can't tell, from the projection alone, that 2 of the 28 entries weren't classified. ### Desired outcome and success criteria - Parse `pkgContextInfo.json` when it is present and valid JSON within a size bound. Report each `isSO: true` entry as a declared N-API module: a `basis` such as `pkg-context-declared`, with the source path and digest, matched to `libs/<abi>/<name>` where that file exists. Keep the path-based candidates, but mark the declared one distinctly, or make the path-based basis say that it wasn't narrowed. A malformed or missing file keeps today's behaviour, with a limitation. - Optionally report the declared package dependencies and versions as declarations, not as resolved code. - List entries that fall in no category, or count them in coverage, so `complete-within-inventory` can't be read as "every entry classified". ### Expected interaction with targets Read the package only. No execution. ### Verification available so far - Target: https://github.com/ks-lm-kf/harmony-kslmkf-karing-hap/releases/tag/v1.11.0 → `karing-harmony-1.11.0.hap`, 48,441,498 bytes, sha256 `8fcd80e44114421ca57808add801575cbe3fd9b964c230b36c979cfd07139eed` (matches the GitHub asset digest). I did not check the repository's license or provenance beyond the release. - Reference: `unzip` plus `sha256sum` of every member (28 files). - `rea-agents@6.5.0`: `inspect-artifact` → `project-harmony-application-graph`.

bsakaguchi referenced this issue

2026-10-31 00:55:19 +00:00

[PR #1778] [MERGED] fix(ida): wait out a transient busy worker health in headless sessions #4811

bsakaguchi referenced this issue

2026-10-31 00:55:20 +00:00

[PR #1785] [MERGED] fix(ida): report a procedure IDA cannot resolve as invalid input #4815