fix: avoid re-parenting crash for MarkerInfoWindowContent/MarkerInfoWindowComposable - #953
Open
kikoso wants to merge 1 commit into
Open
fix: avoid re-parenting crash for MarkerInfoWindowContent/MarkerInfoWindowComposable#953kikoso wants to merge 1 commit into
kikoso wants to merge 1 commit into
Conversation
…indowComposable Fixes #950 PR #931 fixed #913 (empty info window content on compose-ui 1.10+) by keeping the ComposeView permanently attached to the library's own container while the info window is shown. That works around compose-ui's attachment requirement for drawing, but it means the view handed back from getInfoContents()/getInfoWindow() already has a parent. The Maps SDK internally re-parents that view into its own default info window frame, so calling addView() on an already-parented view throws: java.lang.IllegalStateException: The specified child already has a parent. You must call removeView() on the child's parent first. This change renders the Compose content into a plain Bitmap up front (attach, measure, layout, draw, detach, the same technique already used for MarkerComposable icon bitmaps) and hands the Maps SDK a fresh, unattached ImageView wrapping that bitmap instead of the live ComposeView. This keeps the compose-ui 1.10+ fix from #931 (content is fully rendered before we let go of it) while avoiding the double parent crash, since the returned view was never attached anywhere. Verified on a physical device: reproduced the #950 crash on the previous build, confirmed it is gone after this change, and confirmed MarkerInfoWindowContent and MarkerInfoWindowComposable content still render correctly under compose-bom 2026.06.01 (compose-ui 1.10+), covering the original #913 scenario as well.
Contributor
Code Coverage
|
LoyalAbbas
self-requested a review
August 6, 2026 04:15
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.
Fixes #950
Summary
PR #931 fixed #913 (empty info window content on compose-ui 1.10+) by keeping the
ComposeViewpermanently attached to the library's own container while the info window is shown. That works around compose-ui's attachment requirement for drawing, but it means the view handed back fromgetInfoContents()/getInfoWindow()already has a parent. The Maps SDK internally re-parents that view into its own default info window frame, so callingaddView()on an already-parented view throws:This crash reproduces on device every time a
MarkerInfoWindowContentmarker is tapped, matching what is reported in #950.Fix
Render the Compose content into a plain
Bitmapup front (attach, measure, layout, draw, detach), the same technique already used and proven forMarkerComposableicon bitmaps, and hand the Maps SDK a fresh, unattachedImageViewwrapping that bitmap instead of the liveComposeView.This keeps the compose-ui 1.10+ fix from #931 (content is fully rendered before we let go of it) while avoiding the double parent crash, since the returned view was never attached anywhere for the SDK to conflict with.
MapComposeViewRender.kt: addedrenderComposableToBitmapComposeInfoWindowAdapter.kt: rewritten to use it instead of theRenderHandle/disposeForMarkerbookkeeping introduced in fix: keep ComposeView attached while info window is shown for compose-ui 1.10+ compat #931MapApplier.kt: reverted the now unneededdisposeForMarkerwiring back to its pre-fix: keep ComposeView attached while info window is shown for compose-ui 1.10+ compat #931 shapeTest plan
addViewcallMarkerInfoWindowContentandMarkerInfoWindowComposablecontent still render correctly under compose-bom 2026.06.01 (compose-ui 1.10+), covering the original MarkerInfoWindowContent not drawing content with androidx.compose:compose-bom:2026.04.01 and newer #913 scenario:maps-app:connectedDebugAndroidTestpasses on device