fix(playscan): match Android XR by namespace instead of invented feature names - #24
Merged
Merged
Conversation
featureFormFactors mapped XR to android.software.xr.immersive and android.hardware.xr.head_tracking. Neither is a real feature constant. I made them up, so no XR app ever matched and XR packages kept getting the phone track's blocking target API finding, which is the exact false CRITICAL the form-factor work was meant to remove. The regression test used the same invented names, so it could not catch it. No XR constant appears in PackageManager's constant pool in android.jar for API 34, 35 or 36, so an exact name cannot be verified the way the other four were. Rather than swap one unverifiable guess for another, XR is now matched on its namespace: a required feature under android.software.xr. or android.hardware.xr. marks the app as XR. That covers api.spatial, api.openxr, the hardware.xr.* inputs, and anything added later. The other four names are unchanged and were confirmed by reading PackageManager's constant pool out of android.jar on all three platform versions: type.watch, type.television, software.leanback, type.automotive. Tests now use real XR feature names, and cover the namespace boundary (android.software.xrated and com.example.xr.custom stay phone) and required="false". Verified against an aapt2-linked XR APK: targetSdk 33 with a required api.spatial feature reports WARN naming Android XR, not CRITICAL. Reported by Cursor Bugbot on #22.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the issue Cursor Bugbot reported on #22, which was correct and which I merged without reading.
featureFormFactorsmapped Android XR toandroid.software.xr.immersiveandandroid.hardware.xr.head_tracking. Neither is a real feature constant, so no XR app ever matched and XR packages kept getting the phone track's blocking target API finding. That is the exact false CRITICAL the form-factor work was supposed to remove. The regression test used the same invented names, so it passed while the rule did nothing.No XR constant appears in
PackageManager's constant pool inandroid.jarfor API 34, 35 or 36, so an exact name cannot be verified the way the others were. Rather than replace one unverifiable guess with another, XR is matched on its namespace: a required feature underandroid.software.xr.orandroid.hardware.xr.marks the app as XR. That coversapi.spatial,api.openxr, thehardware.xr.*inputs, and anything added later.The other four names are unchanged and were confirmed by reading
PackageManager's constant pool out ofandroid.jaron all three platform versions:android.hardware.type.watch,android.hardware.type.television,android.software.leanback,android.hardware.type.automotive.Tests now use real XR feature names, and cover the namespace boundary (
android.software.xratedandcom.example.xr.customstay on the phone track) andrequired="false". The new test was confirmed to fail against the shipped names.Verified end to end against an aapt2-linked XR APK: targetSdk 33 with a required
android.software.xr.api.spatialfeature now reportsWARN ... this is a Android XR appinstead ofCRITICAL.Note
Low Risk
Localized playscan manifest classification fix with expanded tests; no auth, security, or data-path changes.
Overview
Fixes false CRITICAL target-API findings on real Android XR apps by detecting XR from required
<uses-feature>names underandroid.software.xr.orandroid.hardware.xr.instead of two exact strings that never appear in real manifests orandroid.jar(API 34–36).Manifest.FormFactor()now checks those prefixes after the verified Wear/TV/Automotive map, so XR apps get the non-phone WARN path inruleTargetAPILevelrather than the phone track’s blocking rule. Wear, TV, and Automotive mappings are unchanged aside from comment/formatting.Tests switch to real XR feature names, add
TestFormFactorMatchesXRByNamespace(forward-compatible names, non-matches likeandroid.software.xrated, andrequired="false").Reviewed by Cursor Bugbot for commit a5c2cf9. Bugbot is set up for automated code reviews on this repo. Configure here.