[Bug] inspect-android-jni-bindings reports complete with zero libraries for a base APK whose native libraries are in required splits #9756

Before submitting

• I searched the open and closed issues and pull requests for a related proposal. (Related but different: [Design] Android split APK sets: set identity and relationship evidence before a bundletool lane #1813 and PR feat(android): check split APK set consistency from manifest facts #3495 check split-set consistency from manifest facts; this report is about the native library inventory claiming completeness.)
• I understand the contribution scope must be reviewed before integration; open questions are welcome here.
• This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

inspect-android-jni-bindings reports library_inventory.status: "complete" with zero libraries for a base APK whose manifest requires ABI and density splits, even though the native libraries live in those splits. Nothing in the output says libraries may be elsewhere.

Reproduced on main at e9b6c87c1 (Windows 11, JDK 21, jadx-headless-mcp 0.7.1), on the base APK of a production app (9 DEX files):

library_inventory: {"status":"complete","examined_entries":2776,"selected_libraries":0,"unknowns":[]}
declarations: 136   (native method declarations in DEX)
bindings: 0
the word "split" appears 0 times in the output

In the same sweep, 4 of 5 base APKs declare requiredSplitTypes="base__abi,base__density" in their manifests. For one of them, the arm64 split APK alone contains 11 native libraries (lib/arm64-v8a/), so the base APK's zero is not "no libraries", it is "none in this file". The other results: 136 / 295 / 2,089 / 7 native declarations in four APKs, all with complete and zero libraries. (The requiredSplitTypes attribute was read by the sweep, not re-verified by me.)

Use cases

• An agent reads complete and zero libraries and concludes the app has no native code, while the 136 declarations point to JNI methods whose libraries it never looked at.

Desired outcome and success criteria

• When the manifest declares required split types (or isSplitRequired), report that native libraries may be in splits as an explicit unknown or limitation on the library inventory, instead of an unqualified complete.
• No change to behavior for APKs without required splits.
• Success: the base APK above reports an unknown naming the required split types, with declarations unchanged.

Expected interaction with targets

Read existing files or captured data.

Verification available so far

Reproduced twice on the base APKs; the complete/zero/no-"split" output is the same each time. I did not check how inspect-android-package presents the same fact.

Verification details

• Local CLI build; no APK or sample attached.
• Out of scope here: accepting a split set as input ([Design] Android split APK sets: set identity and relationship evidence before a bundletool lane #1813 / feat(android): check split APK set consistency from manifest facts #3495).