[carplay] Fix background GPS leak and render crash after a wireless teardown #22

Field testing 2026年07月04日 (wireless CarPlay, TestFlight 2026年07月02日-1)
surfaced two bugs with one shared trigger. Wireless CarPlay drops the
session only after the user has walked away from the car, so the
grace-period teardown (destroy(), 2s after the scenes disconnect) now
always runs while the app is already backgrounded — an ordering a cabled
disconnect never produced, and one the teardown-debounce work had not
accounted for.
Bug 1: location never stopped after the trip ended. The blue location
indicator stayed on and the app kept consuming GPS in the background
for 16+ minutes until force-quit. keepRunningInBackground() is only
evaluated on resign-active, and at that moment the car screen still
hosts the map, so location legitimately keeps running. When destroy()
ends the hosting two seconds later, nothing re-evaluated the policy, so
started/allowsBackgroundLocationUpdates stayed YES indefinitely. Fix:
destroy() now calls the new
+[MWMLocationManager reapplyBackgroundLocationPolicy], which re-runs
the keepRunningInBackground() decision iff the app is backgrounded
(when it is foreground, applicationDidBecomeActive owns the state).
Navigation continuing on the phone and GPS track recording still keep
location on — the policy predicate is unchanged.
Bug 2: EXC_BAD_ACCESS on the drape frontend render thread, three field
crashes with the identical stack (dp::ApplyState → ApplyTexturesForMetal
under FrontendRenderer::RenderFrame; symbolicated crash 2026年07月04日
17:42:30). All three followed a destroy() that ran while backgrounded:
the phone-appearance restore (setCarScreenMode, position arrow offset,
CarPlayWindowScaleAdjuster → UpdateVisualScale) executed while rendering
was disabled, so the Metal surface/texture rebuild that normally follows
a visual-scale or style switch could not happen. The first frames
rendered after resuming — a phone foreground (2 crashes) or a CarPlay
reconnect 12s later (1 crash, mid-drive, auto-relaunched) — drew render
groups whose textures had been freed.
Fix: the host appearance work is consolidated into
applyHostAppearanceIfActive(), derived from the current mapHost. While
the app is backgrounded it only records that a refresh is due; the
appearance is applied on the next UIApplication.didBecomeActive (via a
dispatch to the next runloop turn so MapsAppDelegate's appDidActivate
has re-enabled rendering first, regardless of observer order). Because
the pending state is re-derived from mapHost at apply time, a
background bounce carplay → none → carplay collapses into applying the
final host's appearance once — the map no longer flips styles/scales
invisibly in the background. The cheap UIKit reparenting
(enable/disableCarPlayRepresentation, add/removeMapView) stays
immediate so the shared map view is never orphaned in a dead window.
setup()'s redundant car-mode/arrow-offset reassertion is routed through
the same helper, and attachMapToCarScreen loses its now-unused window
parameter.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: eisa01 <eisa01@gmail.com>