Conversation
Play rejected versionCode 2100 under "Auto App Quality Guidelines: Visual
info on phone — your app does not disable features requiring phone
interaction while in driving mode". The review evidence is the car-screen
idle state, which read "Open FT8AF on your phone to start the FT8 engine":
the car both instructed phone interaction and left it available while
driving.
The idle template is now status only ("FT8AF is not on the air yet. QSO
status appears here once it is running."), and the one action that does
reach the phone — starting the app so it can create the engine — is
wrapped in ParkedOnlyOnClickListener, so the Auto host runs it only when
the car is parked and otherwise shows its own "not available while
driving" notice.
Template content is split out from resource lookup so the guarantee is
unit-testable: CarIdleTemplateTest pins the action as parked-only, and
checks the shipped string itself for phone-interaction wording so a later
copy edit can't quietly reintroduce the rejection.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B4bi57TiMribneqcSBddRB
Second Auto rejection in two months, so take Play's other path and stop
shipping as an Auto app rather than keep answering review findings.
versionCode 2100 was rejected under "Visual info on phone — your app does
not disable features requiring phone interaction while in driving mode";
versionCode 1327 was rejected in July under the NAVIGATION category ("does
not load map and user location"). The IOT/templates shape restored after
that first removal is what drew this one. No approved Auto category fits a
ham-radio QSO monitor well enough to be worth the review cycle right now.
- AndroidManifest.xml: drop the com.google.android.gms.car.application
descriptor, the androidx.car.app.minCarApiLevel meta-data and the
FT8AFCarAppService service. Nothing marks the app as Auto-enabled, so
Play no longer routes it through Auto app-quality review.
- Delete res/xml/automotive_app_desc.xml (dead once the descriptor is gone).
- CarAppManifestWiringTest: flip back from "AA is wired in the approved IOT
shape" to a guard asserting AA is unwired, with both rejections recorded
so a third revival is a deliberate act.
The car/ Kotlin package, its tests and the androidx.car.app:app dependency
stay in-tree (dead but compiling), as they did after the July removal, so
the feature can be revived. It carries the previous commit's driving-mode
fix, so a revival starts compliant with the finding that triggered this.
The debug-only AAOS scaffolding (src/debug CarAppActivity +
DebugInjectReceiver) is untouched; it never merges into release.
Verified: full testDebugUnitTest suite (3724 tests, 0 failures) plus
processReleaseMainManifest — the merged release manifest keeps only the
car-app library's own entries (connection provider, permission activity,
notification receiver), which carry no Auto descriptor or CarAppService.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B4bi57TiMribneqcSBddRB
…ompt Remove Android Auto from the shipping app (clears the driving-mode rejection)
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## staging #810 +/- ##
=============================================
- Coverage 42.64% 42.40% -0.24%
- Complexity 226 228 +2
=============================================
Files 267 270 +3
Lines 32068 32450 +382
Branches 3664 3735 +71
=============================================
+ Hits 13675 13761 +86
- Misses 18132 18413 +281
- Partials 261 276 +15
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
This was referenced Sep 9, 2026
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
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.
Promotes PR #809 to staging so the internal-track build carries a manifest with
no Android Auto marker.
What's in this promotion
Three commits, all one work item — clearing the Play Auto rejection.
The rejection. Play rejected the update under "Auto App Quality Guidelines:
Visual info on phone — Your app does not disable features requiring phone
interaction while in driving mode." Both evidence screenshots were the same car
screen: the Auto idle state reading "Open FT8AF on your phone to start the FT8
engine" — the fallback
QsoStatusScreen/RecentDecodesScreenrender wheneverMainViewModel.peekInstance()is null, i.e. any Auto connect before the phoneapp has been opened. The car told the driver to pick up their phone, with
nothing gating it on the car being stopped.
This is the second Auto rejection in two months (versionCode 1327 was rejected
in July under the NAVIGATION category), so #809 takes Play's other path rather
than answering findings again.
c95b4a05— made the car UI compliant. Idle message is status only(
car_engine_idle, en + pt-BR); the one phone-reaching action is wrapped inParkedOnlyOnClickListenerso the host only runs it when parked.5177c3de— unwired Auto from the shipping app. Dropped thecom.google.android.gms.car.applicationdescriptor, theandroidx.car.app.minCarApiLevelmeta-data and theFT8AFCarAppServiceservice; deleted
res/xml/automotive_app_desc.xml; flippedCarAppManifestWiringTestinto a guard asserting Auto is unwired, recordingboth rejections so a third revival is deliberate.
The
car/package, its tests and theandroidx.car.app:appdependency stayin-tree — dead but compiling — as they did after the July removal, and now carry
the compliance fix so a revival starts clean.
Verification
testDebugUnitTeston the branch: 3724 tests, 0 failures.processReleaseMainManifest: merged release manifest keeps only the car-applibrary's own entries (connection provider, permission activity, notification
receiver) — no Auto descriptor, no
CarAppService. Same state that shipped andpassed review between PR Remove Android Auto support to clear Play production rejection #600 and the restore.
tests, Build APK, codecov).
Follow-up outside the repo
Play Console → Advanced settings → Form factors still declares Android Auto.
Google requires Auto support removed from all active artifacts across tracks
before the Remove button works, so the order is: land this build on the
tracks that hold Auto artifacts (production via the manual
workflow_dispatchon the
android-v*tag; replace/halt any open or closed testing builds), thenclick Remove. Internal-track builds never trigger Auto review, but they do keep
the Remove button disabled.
🤖 Generated with Claude Code
https://claude.ai/code/session_01B4bi57TiMribneqcSBddRB