Skip to content

fix(playscan): correct the foregroundServiceType resource ID - #19

Merged
ethanzhoucool merged 1 commit into
mainfrom
fix/framework-attr-ids
Jul 28, 2026
Merged

fix(playscan): correct the foregroundServiceType resource ID#19
ethanzhoucool merged 1 commit into
mainfrom
fix/framework-attr-ids

Conversation

@ethanzhoucool

@ethanzhoucool ethanzhoucool commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Found by building Android apps with the real toolchain and comparing against aapt2 dump xmltree.

The bug

frameworkAttrIDs is the fallback for resolving attribute names when aapt2 omits them from the compiled string pool, which it routinely does. A wrong entry fails silently: the attribute never resolves, and every rule reading it stops firing with no error.

foregroundServiceType was recorded as 0x01010596. aapt2 assigns it 0x01010599, identically on android-34, -35 and -36.

Both foreground-service checks are CRITICAL, because the app throws SecurityException at startForeground() on Android 14+. On any manifest relying on the fallback, they reported nothing.

Proof

A real aapt2-linked manifest with the foregroundServiceType pool entry blanked, forcing resolution through the resource map:

Foreground service findings
before 0
after 2

Why tests didn't catch it

The unit fixture hand-encoded the same wrong ID, so the decoder and the fixture agreed with each other. Fixtures can only catch disagreements with themselves. Fixed to the verified value.

Hardening

Every remaining ID was read back from aapt2 dump xmltree on a manifest declaring each attribute, not recalled. TestFrameworkAttrIDsMatchAapt2 pins all nine and fails on any addition that hasn't been verified the same way.

The two networkSecurityConfig entries were both guesses and are removed; no rule reads that field.


Note

Medium Risk
Changes manifest decoding used for CRITICAL Play policy findings; the fix reduces false negatives but any remaining wrong ID would still fail silently until caught by the new tests.

Overview
Fixes silent mis-resolution of android:foregroundServiceType when aapt2 leaves the attribute name out of the compiled manifest string pool and playscan falls back to frameworkAttrIDs.

Updates foregroundServiceType from 0x01010596 to the aapt2-verified 0x01010599 (same on API 34–36), aligns the hand-built AXML test fixture, and drops two unverified networkSecurityConfig map entries that no rule reads.

Adds TestFrameworkAttrIDsMatchAapt2 to lock the nine aapt2-confirmed IDs (bidirectional: no missing or unverified table entries) and TestAttrNameFallsBackToResourceMap so empty pool + resource map still resolves foregroundServiceType, with pool names winning when present.

Reviewed by Cursor Bugbot for commit f4c9c24. Bugbot is set up for automated code reviews on this repo. Configure here.

The framework attribute ID table is the fallback used when aapt2 omits an
attribute's name from the compiled string pool, which it routinely does. A
wrong entry fails silently: the attribute never resolves, and every rule that
reads it stops firing with no error.

foregroundServiceType was recorded as 0x01010596. aapt2 assigns it 0x01010599,
identically on android-34, -35 and -36. The consequence was that both
foreground-service checks, which are CRITICAL because the app throws at
startForeground() on Android 14+, silently reported nothing on any manifest
that relied on the fallback. Verified on a real aapt2-linked manifest with the
pool entry blanked: 0 findings before, 2 after.

Every remaining ID in the table was read back from `aapt2 dump xmltree` rather
than recalled, and TestFrameworkAttrIDsMatchAapt2 now pins all nine and fails
on any unverified addition. The two networkSecurityConfig entries were both
guesses and are removed; no rule reads that field.

The unit fixture had encoded the same wrong ID, which is why the existing tests
passed. It now uses the verified value.
@ethanzhoucool
ethanzhoucool merged commit 80a5702 into main Jul 28, 2026
4 checks passed
@ethanzhoucool
ethanzhoucool deleted the fix/framework-attr-ids branch July 28, 2026 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant