fix: release GoogleMap listeners and dispose subcomposition when showing/hiding map

[dkhawk]

Summary

Fixes memory retention and teardown ordering issues when GoogleMap is repeatedly shown/hidden (if (showMap) { GoogleMap(...) }) or deactivated/reused via ReusableContentHost / LazyColumn:

1. Detach GoogleMap Listeners and InfoWindowAdapter on Clear:
   • MapApplier.attachClickListeners() registers 9 click/drag listeners and ComposeInfoWindowAdapter(mapView, ...) on GoogleMap (wrapped in Binder stubs that hold strong references to MapApplier and MapView), but MapApplier.onClear() never detached them. Added MapApplier.detachClickListeners() and invoked it from onClear().
   • MapPropertiesNode.onRemoved() and onCleared() now clear the 4 camera listeners (setOnCameraIdleListener(null), setOnCameraMoveCanceledListener(null), setOnCameraMoveStartedListener(null), setOnCameraMoveListener(null)) and setLocationSource(null) in addition to cameraPositionState.setMap(null).
   • TileOverlayNode.onRemoved() and onCleared() now clear tileOverlayState.tileOverlay = null.
2. Synchronous Subcomposition Disposal & MapView Teardown:
   • Scoped subcompositionJob and subcomposition (Composition) to MapTagData on the MapView instance so onReset and onRelease dispose the map subcomposition synchronously before lifecycleObserver.moveToDestroyedState() (mapView.onDestroy()) is invoked, and so update cleanly re-launches the subcomposition when a deactivated MapView is reused.
   • Switched launchSubcomposition to Dispatchers.Main.immediate and guarded after mapView.awaitMap() (if (!isActive || mapView.tagDataOrNull !== tagData) return@launch) so rapid show/hide cycles where onRelease runs before getMapAsync completes do not throw a NullPointerException on mapView.tag or create an orphaned Composition.
   • Cleaned up removeOnAttachStateChangeListener, lifecycle observer registration, setViewTreeLifecycleOwner(null), setViewTreeSavedStateRegistryOwner(null), and removeAllViews() in onRelease.

Testing

• Added unit tests in MapApplierCleanupTest verifying that MapApplier.onClear(), MapPropertiesNode, TileOverlayNode, and MarkerNode detach all listeners, InfoWindowAdapter, LocationSource, and state references.
• Added instrumentation tests testShowingHidingMapRepeatedlyReleasesMapViews and testReusableContentHostResetAndReuse in GoogleMapViewTests.
• Verified with heap dump (hprof) analysis across 30 show/hide cycles that 0 GoogleMap / MapApplier / ComposeInfoWindowAdapter instances remain in the heap.

Fixes #581

[github-actions]

Coverage (unit tests)

Compared against cdf8b7f on main (#1044).

Module	Line %	Change	Branch %	Change
maps-compose	12.41%	🔺 +12.41	2.25%	🔺 +2.25
maps-compose-utils	2.17%	no change	0.94%	no change
maps-compose-widgets	0.00%	no change	0.00%	no change
TOTAL	9.64%	🔺 +9.19	1.94%	🔺 +1.77

_{Line and branch coverage from unit test reports. History is recorded on the coverage-history branch after each merge to main.}

[googlemaps-bot]

Coverage (instrumentation tests)

Overall Project	44.77% -0.06%	🍏
Files changed	91.54%	🍏

Module	Coverage
maps-app	63.91% -0.16%	🍏

Files

Module	File	Coverage
maps-app	MapUpdater.kt	81.62% -0.44%	🍏
	GoogleMap.kt	80.47% -0.55%	🍏
	MapApplier.kt	41.21%	🍏
	TileOverlay.kt	0% -2.52%	❌

[kikoso]

Minor comments @dkhawk , but looks good!

[kikoso]

Just to understand it: in which case do we get here without a lifecycle owner? Before, the !! failed loudly, and now the map would silently never receive lifecycle events (so it never renders). If it's only the released view case I am fine with it, but should we at least log a warning, or do I miss anything?

[dkhawk]

Good catch! Since factory and update pin lifecycleOwner onto mapView via setViewTreeLifecycleOwner(lifecycleOwner) and onRelease() removes the OnAttachStateChangeListener before clearing the view-tree owner, findViewTreeLifecycleOwner() should never be null when onViewAttachedToWindow fires.

In 82565df, replaced the silent ?. with an explicit defensive check (MapAttachStateChangeListener) that logs an error (Log.e) and throws a descriptive IllegalStateException (error(...)) if findViewTreeLifecycleOwner() is ever null, along with a unit test covering this case.

[kikoso]

nit: this sits right next to onAttachStateChangeListener and it is really the cleanup, so the names are easy to mix up. What about something like this (plus the two call sites)?

Suggested change

	val onAttachStateListener: () -> Unit,
	val detachLifecycleObserver: () -> Unit,

[dkhawk]

Done in 82565df — renamed onAttachStateListener to detachLifecycleObserver in MapTagData and updated all call sites.

[kikoso]

Could we assert that the map comes back after each reactivation? Right now the test passes as long as nothing crashes. Something like composeTestRule.waitUntil(5_000) { cameraPositionState.projection != null } instead of the sleep would also verify that update re-launches the subcomposition.

[dkhawk]

Done in 82565df — replaced both Thread.sleep(100) calls in testReusableContentHostResetAndReuse with composeTestRule.waitUntil(timeoutMillis = 5_000) { cameraPositionState.projection != null } to verify that initial composition and each reactivation re-launch the subcomposition.

[kikoso]

I wonder if this can be flaky on CI, since it depends on the GC actually collecting the views. Did it pass consistently over several runs on the emulator?

[dkhawk]

Great point! While it passed consistently across multiple local emulator runs (and 30-cycle HPROF heap dumps confirmed 0 GoogleMap / MapApplier instances retained), relying on Runtime.getRuntime().gc() in an instrumentation test can be non-deterministic on CI emulators.

In 82565df, updated testShowingHidingMapRepeatedlyReleasesMapViews to assert the deterministic post-onRelease() state on every created MapView (mapView.tag == null, mapView.childCount == 0, mapView.findViewTreeLifecycleOwner() == null, mapView.findViewTreeSavedStateRegistryOwner() == null, and cameraPositionState.projection == null) without depending on GC timing.