[GH-ISSUE #4448] [Feature] inspect_android_package: return a structured component inventory (exported, permission, intent actions, foreground-service type) #1766

New issue

Closed

opened 2026-10-16 21:10:01 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues for a related report (manifest exported components, services receivers, inspect_android_package components, defpackage). Related: #717 (APK roadmap), #3489 (method access flags). I found nothing for a component inventory or for the default-package naming below.
I understand the contribution scope; this is a static projection of the manifest that REA already decodes.
This report contains no credentials or private target samples.

Area

Android or mobile analysis

Current limitation

inspect_android_package returns package, SDK and permission declarations as structured fields, but components only as raw text: normalized_result.manifest has just status, text and reported_total_bytes. To answer common questions, I had to regex the decoded XML myself:

which components are exported;
which service is the VpnService or CallScreeningService, and what permission guards it (BIND_VPN_SERVICE, BIND_SCREENING_SERVICE, BROADCAST_SMS);
which receivers listen for SMS_RECEIVED or BOOT_COMPLETED;
which foreground-service types are declared.

These are attack-surface and privacy questions, the first thing an analyst asks of an APK. A regex is easy to get wrong: mine attached a neighbouring element's intent actions to the wrong receiver until I checked the XML by hand.

Public example: Element X 26.09.1 (io.element.android.x, F-Droid arm64 build, sha256 ceb07656…5bf3). Its decoded manifest declares 7 activities, 8 services, 10 receivers and 7 providers. Of these, 2 activities, 2 services and 4 receivers are explicitly exported="true", 3 components carry an android:permission, and the foreground-service types are shortService, location and microphone. None of that is in the structured result.

Desired outcome and success criteria

A components array next to permissions. Each entry would have:

kind (activity/activity-alias/service/receiver/provider) and the exact name as declared, plus the resolved class name;
exported, with the source: explicit attribute or implicit (intent-filter default before targetSdk 31), or unknown;
permission, enabled, process, foregroundServiceType, and the provider's authorities/grantUriPermissions;
intent_filters: actions, categories, data scheme/host/path, and priority;
meta_data names, with values only if non-sensitive by the existing rules;
the location in the decoded manifest, so each entry can be checked against text.

It should be complete within the decoded manifest, with explicit unknowns for merged or overlay values.

For R8 apps with classes in the default package, REA's output names a type sb (field P0 of de.markusfisch.android.binaryeye.activity.AutomatedActionsActivity, Binary Eye versionCode 180 from F-Droid, sha256 568cec65…44f1). But inspect_android_class sb fails with Exact class not found: sb; use search_android_classes…. Only JADX's alias defpackage.sb works. 2,542 of Binary Eye's 2,800 classes are in that package, so this comes up all the time. Accepting the bare DEX name, or naming defpackage.sb in the error, would remove a round trip.

Expected interaction with targets

Read the APK only. No execution.

Verification available so far

rea-agents@6.5.0 in Docker, JADX headless MCP 0.7.1: inspect-android-package, inspect-android-class and search-android-classes as above. The counts come from the decoded manifest in REA's own output.

Originally created by @Rinkia on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4448 ### Before submitting - [x] I searched the open and closed issues for a related report (manifest exported components, services receivers, inspect_android_package components, defpackage). Related: #717 (APK roadmap), #3489 (method access flags). I found nothing for a component inventory or for the default-package naming below. - [x] I understand the contribution scope; this is a static projection of the manifest that REA already decodes. - [x] This report contains no credentials or private target samples. ### Area Android or mobile analysis ### Current limitation `inspect_android_package` returns package, SDK and permission declarations as structured fields, but components only as raw text: `normalized_result.manifest` has just `status`, `text` and `reported_total_bytes`. To answer common questions, I had to regex the decoded XML myself: - which components are exported; - which service is the `VpnService` or `CallScreeningService`, and what permission guards it (`BIND_VPN_SERVICE`, `BIND_SCREENING_SERVICE`, `BROADCAST_SMS`); - which receivers listen for `SMS_RECEIVED` or `BOOT_COMPLETED`; - which foreground-service types are declared. These are attack-surface and privacy questions, the first thing an analyst asks of an APK. A regex is easy to get wrong: mine attached a neighbouring element's intent actions to the wrong receiver until I checked the XML by hand. Public example: Element X 26.09.1 (`io.element.android.x`, F-Droid arm64 build, sha256 `ceb07656…5bf3`). Its decoded manifest declares 7 activities, 8 services, 10 receivers and 7 providers. Of these, 2 activities, 2 services and 4 receivers are explicitly `exported="true"`, 3 components carry an `android:permission`, and the foreground-service types are `shortService`, `location` and `microphone`. None of that is in the structured result. ### Desired outcome and success criteria A `components` array next to `permissions`. Each entry would have: - `kind` (`activity`/`activity-alias`/`service`/`receiver`/`provider`) and the exact `name` as declared, plus the resolved class name; - `exported`, with the source: `explicit` attribute or `implicit` (intent-filter default before targetSdk 31), or unknown; - `permission`, `enabled`, `process`, `foregroundServiceType`, and the provider's `authorities`/`grantUriPermissions`; - `intent_filters`: actions, categories, data scheme/host/path, and priority; - `meta_data` names, with values only if non-sensitive by the existing rules; - the location in the decoded manifest, so each entry can be checked against `text`. It should be complete within the decoded manifest, with explicit unknowns for merged or overlay values. ### Related, smaller: default-package class names For R8 apps with classes in the default package, REA's output names a type `sb` (field `P0` of `de.markusfisch.android.binaryeye.activity.AutomatedActionsActivity`, Binary Eye versionCode 180 from F-Droid, sha256 `568cec65…44f1`). But `inspect_android_class sb` fails with `Exact class not found: sb; use search_android_classes…`. Only JADX's alias `defpackage.sb` works. 2,542 of Binary Eye's 2,800 classes are in that package, so this comes up all the time. Accepting the bare DEX name, or naming `defpackage.sb` in the error, would remove a round trip. ### Expected interaction with targets Read the APK only. No execution. ### Verification available so far `rea-agents@6.5.0` in Docker, JADX headless MCP 0.7.1: `inspect-android-package`, `inspect-android-class` and `search-android-classes` as above. The counts come from the decoded manifest in REA's own output.

bsakaguchi closed this issue

2026-10-31 00:32:39 +00:00

bsakaguchi commented

2026-10-31 00:32:39 +00:00

Author

Owner

@ranmori commented on GitHub (Oct 26, 2026):

Status check against main (b3818bbba), for whoever picks up the rest: #5025 (merged 2026-10-24, in rea-agents@6.8.0) added the structured components inventory to inspect_android_package, and its description says this issue stays open for the remaining requirements. Comparing the request with AndroidManifestComponent in src/android/AndroidManifestComponents.ts:

Covered by #5025:

kind for activity, activity-alias, service, receiver and provider
declared name and resolved class name
exported, plus exported_default for the intent-filter and target-SDK rules
permission, with permission_source (component, application, none, unknown)
intent-filter actions and categories, and intent_filter_count
foreground_service_type
provider authorities
target_activity for aliases

Not in the inventory yet (source-derived; I did not run it against an APK):

enabled, process, and the provider's grantUriPermissions
intent-filter <data> (scheme, host, path) and priority. Actions and categories are flattened per component rather than kept per filter.
meta_data names
a location in the decoded manifest for each entry
the separate default-package naming item: no defpackage handling exists in src/, so inspect_android_class sb presumably still needs defpackage.sb. I did not re-run that.

Splitting the remaining items into their own issues might make them easier to pick up.

@ranmori commented on GitHub (Oct 26, 2026): Status check against `main` (b3818bbba), for whoever picks up the rest: #5025 (merged 2026-10-24, in `rea-agents@6.8.0`) added the structured `components` inventory to `inspect_android_package`, and its description says this issue stays open for the remaining requirements. Comparing the request with `AndroidManifestComponent` in `src/android/AndroidManifestComponents.ts`: Covered by #5025: - `kind` for activity, activity-alias, service, receiver and provider - declared `name` and resolved class `name` - `exported`, plus `exported_default` for the intent-filter and target-SDK rules - `permission`, with `permission_source` (component, application, none, unknown) - intent-filter `actions` and `categories`, and `intent_filter_count` - `foreground_service_type` - provider `authorities` - `target_activity` for aliases Not in the inventory yet (source-derived; I did not run it against an APK): - `enabled`, `process`, and the provider's `grantUriPermissions` - intent-filter `<data>` (scheme, host, path) and `priority`. Actions and categories are flattened per component rather than kept per filter. - `meta_data` names - a location in the decoded manifest for each entry - the separate default-package naming item: no `defpackage` handling exists in `src/`, so `inspect_android_class sb` presumably still needs `defpackage.sb`. I did not re-run that. Splitting the remaining items into their own issues might make them easier to pick up.

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