[PR #2359] [MERGED] fix(adb): count requested permissions that the device marks restricted #5185

New issue

Closed

opened 2026-10-31 01:04:37 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:04:37 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2359
Author: @huiq777
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @morluto

Base: main ← Head: fix/adb-restricted-permission-count

📝 Commits (1)

00d9b45 fix(adb): count requested permissions that the device marks restricted

📊 Changes

2 files changed (+33 additions, -1 deletions)

View changed files

📝 src/adb/AdbProvider.test.ts (+28 -0)
📝 src/adb/AdbShellOutput.ts (+5 -1)

📄 Description

Summary

inspect_adb_package undercounts requested_permissions_count on Android 10 and 11 devices, and still reports coverage: "complete". The count stops at the first permission the device marks as restricted.

No issue is linked: I found this while reading the dumpsys package parser, and it is an ordinary fix inside the existing ADB provider.

Problem and expected behavior

Smallest trigger: dumpsys package output in which a requested permission carries the restricted marker.

    requested permissions:
      android.permission.INTERNET
      android.permission.WRITE_EXTERNAL_STORAGE: restricted=true
      android.permission.CAMERA
    install permissions:

On Android 10 and 11, Settings.dumpPackageLPr appends : restricted=true to every hard- or soft-restricted entry of that list (android11-release Settings.java; android10-release prints it too). The android12-release, android13-release and android14-release branches no longer print it.

parseDumpsysPackageOutput accepted only bare names (/^\s{2,}[A-Za-z0-9._]+$/), so the marked line ended the section and the permissions after it were not counted. The example above gives 1; the list holds 3. The provider's own limitation text says "requested_permissions_count counts the listed requested permissions section only".

Expected: every entry of the section is counted, with or without the marker.

Change and scope

The entry pattern in src/adb/AdbShellOutput.ts now also accepts the exact : restricted=true suffix. Nothing else about section detection changes, so the following install permissions: lines (NAME: granted=true) are still outside the count.

Not included: the parser adds up every requested permissions: section it meets. I did not verify whether real output repeats that header for one package, so I left that alone.

Follow the contribution scope.
Scope decision: not applicable.

Contract and boundary impact

Semantic owner and earliest changed stage: parseDumpsysPackageOutput in src/adb/AdbShellOutput.ts.
Contribution scope fit and linked maintainer decision: parser fix within the existing ADB provider; not applicable.
CLI and MCP/tool-catalog contract: no schema change. requested_permissions_count is higher on affected devices.
Provider, bridge, target-format, or platform compatibility: ADB provider; changes results only for output that contains the marker (Android 10 and 11).
Evidence, artifact, provenance, or reconstruction contract: none.
Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated: one case in src/adb/AdbProvider.test.ts that runs the output above through inspect_adb_package with the existing adb stub and expects a count of 3.
Base reproduction or other evidence (executed): without the fix the new test gets 1. The output format is source-derived from the AOSP branches named above.
User-visible CLI/MCP output (executed with REA_ADB_PATH pointing at a stand-in adb that prints the output above), for rea inspect-adb-package emulator-5554 com.example:
```
before (4dd44dd):  requested_permissions_count: 1, coverage: complete
after:             requested_permissions_count: 3, coverage: complete
```
Remaining proof gaps: not run against a real Android 10 or 11 device; the fixture follows the AOSP printing code.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

macOS 15.6.1 arm64, Node 24.18.0, npm 11.16.0.

npm run test:local -- src/adb/AdbProvider.test.ts — 48 passed
npx vitest run src/adb — 5 files, 104 tests passed
npm run test:focused -- tests/boundary/cli/adbCli.test.ts tests/boundary/mcp/adbMcp.test.ts tests/boundary/mcp/adbStartMcp.test.ts tests/boundary/process/adbDirectoryListing.test.ts tests/boundary/providers/adb/adbBugreportPublication.test.ts — 5 files, 21 tests passed
npm run check — passed
npm run check:fast — passed

Not run: npm run check:pr, npm run docs:check (no contract or generated metadata changes), and no real-device lane.

Compatibility, safety, and release

Breaking changes or migration steps: none.
Real Hopper/Ghidra, browser, or OS coverage: not applicable.
Package or release metadata impact: none.
Security, privacy, process, or containment review: none; parsing only.

This touches src/adb/AdbProvider.test.ts like #2344 and #2354, in a different place; I will rebase whichever lands later.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

AI assistance (Claude Code, model Claude Opus 5.5) was used for investigation, implementation and running the tests locally.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2359 **Author:** [@huiq777](https://github.com/huiq777) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/adb-restricted-permission-count` --- ### 📝 Commits (1) - [`00d9b45`](https://github.com/morluto/rea/commit/00d9b45ae83ac1cd56cf7f98553897f17ca8a4c9) fix(adb): count requested permissions that the device marks restricted ### 📊 Changes **2 files changed** (+33 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/adb/AdbProvider.test.ts` (+28 -0) 📝 `src/adb/AdbShellOutput.ts` (+5 -1) </details> ### 📄 Description ## Summary `inspect_adb_package` undercounts `requested_permissions_count` on Android 10 and 11 devices, and still reports `coverage: "complete"`. The count stops at the first permission the device marks as restricted. No issue is linked: I found this while reading the `dumpsys package` parser, and it is an ordinary fix inside the existing ADB provider. ## Problem and expected behavior Smallest trigger: `dumpsys package` output in which a requested permission carries the restricted marker. ```text requested permissions: android.permission.INTERNET android.permission.WRITE_EXTERNAL_STORAGE: restricted=true android.permission.CAMERA install permissions: ``` On Android 10 and 11, `Settings.dumpPackageLPr` appends `: restricted=true` to every hard- or soft-restricted entry of that list ([android11-release `Settings.java`](https://github.com/aosp-mirror/platform_frameworks_base/blob/android11-release/services/core/java/com/android/server/pm/Settings.java#L4858-L4872); `android10-release` prints it too). The `android12-release`, `android13-release` and `android14-release` branches no longer print it. `parseDumpsysPackageOutput` accepted only bare names (`/^\s{2,}[A-Za-z0-9._]+$/`), so the marked line ended the section and the permissions after it were not counted. The example above gives 1; the list holds 3. The provider's own limitation text says "requested_permissions_count counts the listed requested permissions section only". Expected: every entry of the section is counted, with or without the marker. ## Change and scope The entry pattern in `src/adb/AdbShellOutput.ts` now also accepts the exact `: restricted=true` suffix. Nothing else about section detection changes, so the following `install permissions:` lines (`NAME: granted=true`) are still outside the count. Not included: the parser adds up every `requested permissions:` section it meets. I did not verify whether real output repeats that header for one package, so I left that alone. Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Scope decision: not applicable. ## Contract and boundary impact - Semantic owner and earliest changed stage: `parseDumpsysPackageOutput` in `src/adb/AdbShellOutput.ts`. - Contribution scope fit and linked maintainer decision: parser fix within the existing ADB provider; not applicable. - CLI and MCP/tool-catalog contract: no schema change. `requested_permissions_count` is higher on affected devices. - Provider, bridge, target-format, or platform compatibility: ADB provider; changes results only for output that contains the marker (Android 10 and 11). - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: one case in `src/adb/AdbProvider.test.ts` that runs the output above through `inspect_adb_package` with the existing adb stub and expects a count of 3. - Base reproduction or other evidence (executed): without the fix the new test gets 1. The output format is source-derived from the AOSP branches named above. - User-visible CLI/MCP output (executed with `REA_ADB_PATH` pointing at a stand-in adb that prints the output above), for `rea inspect-adb-package emulator-5554 com.example`: ```text before (4dd44dd): requested_permissions_count: 1, coverage: complete after: requested_permissions_count: 3, coverage: complete ``` - Remaining proof gaps: not run against a real Android 10 or 11 device; the fixture follows the AOSP printing code. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed macOS 15.6.1 arm64, Node 24.18.0, npm 11.16.0. - `npm run test:local -- src/adb/AdbProvider.test.ts` — 48 passed - `npx vitest run src/adb` — 5 files, 104 tests passed - `npm run test:focused -- tests/boundary/cli/adbCli.test.ts tests/boundary/mcp/adbMcp.test.ts tests/boundary/mcp/adbStartMcp.test.ts tests/boundary/process/adbDirectoryListing.test.ts tests/boundary/providers/adb/adbBugreportPublication.test.ts` — 5 files, 21 tests passed - `npm run check` — passed - `npm run check:fast` — passed Not run: `npm run check:pr`, `npm run docs:check` (no contract or generated metadata changes), and no real-device lane. ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: not applicable. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none; parsing only. This touches `src/adb/AdbProvider.test.ts` like #2344 and #2354, in a different place; I will rebase whichever lands later. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. AI assistance (Claude Code, model Claude Opus 5.5) was used for investigation, implementation and running the tests locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:04:37 +00:00