fix(playscan): close the Android scanning gaps from review

[ethanzhoucool]

The Android fixes that were meant to be in #21. That PR merged with only the README commit — the code commits had been made on a different local branch and never reached the PR head, so #21 shipped the attribution work alone. These are the same three commits, cherry-picked onto the current main and re-verified.

Five findings from a review of the Play support, all reproduced before fixing.

• preflight could not inspect an Android artifact. --ipa existed, --apk / --aab did not. Both added, and preflight now runs the source and archive scans together since they see different things.
• Artifact scans silently skipped the Gradle-backed checks. ScanArchive passes an empty GradleInfo, so Play Billing version, ads-SDK detection, and auth-SDK detection could not fire. Their absence read as a pass. The scan now reports the gap and names the three checks it skipped.
• AABs false-passed native checks. Native code was only read from base/lib/, so a misaligned library in a feature module passed the 16 KB check. Every module is scanned now. Added the missing 64-bit parity rule: a 32-bit ABI without its 64-bit counterpart is CRITICAL, skipped on config splits, which legitimately carry one ABI.
• Deadline logic ignored form factors. Play runs a separate target API schedule for Wear OS, TV, Automotive and XR, so those apps could get a CRITICAL that Play would not produce. They now get a WARN naming their own track, and android:required="false" is honoured so a phone app that also ships to TV keeps its CRITICAL.
• preflight --verify hardcoded iOS. An Android-only project ran its flows against the wrong store and had its .apk rejected. Platform now follows the artifact extension, then the project layout.

Three further defects were found while reviewing the first pass:

• The form-factor fix was inert on the artifact path: applyElement had no uses-feature case, so compiled manifests never populated it and only source scans ever saw the declaration.
• frameworkAttrIDs had no entry for android:required. aapt2 emits empty string-pool names for framework attributes, so it was dropped on both compiled paths and a phone app declaring leanback required="false" was still read as a TV app. 0x0101028e was read back from aapt2 dump xmltree against android-34, -35 and -36 rather than recalled, per the rule that every entry in that table is verified.
• A failing archive scan discarded source findings that had already succeeded.

Verified end to end against real aapt2-linked APKs: a watch app at targetSdk 33 reports WARN naming Wear OS; a phone app declaring leanback required="false" still reports CRITICAL.

Every fix has a regression test, and each test was confirmed to fail with its fix reverted. Full suite, -race, vet and gofmt pass.

Known follow-ups, deliberately not here: BundleConfig.pb PAGE_ALIGNMENT_16K, per-library rather than per-ABI 64-bit parity, and cutting a release so playscan actually ships (v0.1.0 predates it, so Homebrew and go install users still get an Apple-only binary).

---

Note

Medium Risk
Touches Play policy gating and preflight CI behavior (merged scans, incomplete runs, verify platform); changes are well covered by regression tests but could shift severity or exit-code outcomes for Wear/TV and artifact-only workflows.

Overview
Closes several Android playscan and preflight gaps so artifact scans are honest, native policy checks are complete, and runtime verify targets the right store.

preflight gains --apk / --aab (mutually exclusive) and runs source playscan plus archive scan when both apply, merging findings and keeping source results if the artifact scan fails (Incomplete). preflight --verify no longer hardcodes iOS: platform follows artifact extension (.apk / .app) then project layout.

Artifact scans always emit an INFO “Scan coverage” finding for Gradle-only checks (Play Billing, ads-SDK, auth-SDK) so a clean APK/AAB is not mistaken for a full scan. AAB native libs are collected from every module (<module>/lib/), not only base/. New 64-bit ABI parity rule (CRITICAL) skips config split manifests. Target API uses manifest form factor from required <uses-feature>: Wear/TV/Automotive/XR get a WARN on the phone schedule instead of a blocking CRITICAL; android:required="false" stays on the phone track. Archive decoders now handle uses-feature, split, and framework attr required (0x0101028e) in binary XML.

README documents complementary source vs artifact scans, 64-bit requirement, and form-factor deadlines.

^{Reviewed by Cursor Bugbot for commit 2d95f52. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2d95f52. Configure here.}

[cursor]

Wrong XR form-factor feature names

High Severity

featureFormFactors maps XR to android.software.xr.immersive and android.hardware.xr.head_tracking, but real Android XR apps declare android.software.xr.api.spatial or android.software.xr.api.openxr. XR packages never match, so they still get the phone track’s blocking target API finding — the exact false CRITICAL this change aimed to stop for form factors. The regression test uses the same incorrect names, so it cannot catch this.

Additional Locations (1)

• internal/playscan/rules_test.go#L14-L18

 

^{Reviewed by Cursor Bugbot for commit 2d95f52. Configure here.}