Fixed
Status Update
Comments
je...@google.com <je...@google.com>
lo...@gmail.com <lo...@gmail.com> #2
Hi. Thanks for reporting this. Fixed in alpha-04
ad...@google.com <ad...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug: b/264018028
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
https://android-review.googlesource.com/2373449
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug:
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
lo...@gmail.com <lo...@gmail.com> #4
deleted
ap...@google.com <ap...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
lo...@gmail.com <lo...@gmail.com> #6
Thank you for fixing this!
I've been able to remove the workaround code I had, and it works like a charm.
All the best, Louis CAD
Description
Hello,
I found a bug that cost me one day to understand what triggers it, and I want to thank Adam Powell for helping me a bit to figure out what's going on.
TL;DR
In short, if you call
setContentView
with the same view hierarchy a second time after the initial render, the composables in the hierarchy will stop recomposing, which breaks/freezes everything in them.Jetpack Compose release version: 1.1.0-alpha02 (also reproduces with 1.0 and 1.0.1)
Android Studio Build: irrelevant
Kotlin version: irrelevant
Reproducer
I attached a self-contained Kotlin file (
MainActivity.kt
) that reproduces the issue.You can paste it in any Compose project over the existing
MainActivity
and try yourself.However, I put below reproducing steps anyway.
Steps to Reproduce:
ComposeView
that displays aState
that changes over time.setContentView
passing that instance in theonCreate
function of the hostComponentActivity
.lifecycleScope
awaitFrame()
, ordelay(1500)
setContentView
again, with the very same instance of theComposeView
created earlier.Expected outcome
The composable keeps display the updates of the
State
instance.Actual result
Once the
setContentView
is called the second time, the composable stops displaying the updates of theState
instance.The Slack thread from start to finish
If you want to see what was the process from facing the issue, to finding why it happened, you can take a look at this thread on Kotlin's Slack:
What is likely the culprit IMHO
In the Android platform, the
setContentView
method inActivity
is idempotent. Calling it a second time with the same view hierarchy while the Activity is not in the destroyed state will have no effect.However, that contract seems to have been broken by the
ComponentActivity
class from AndroidX, as it's also calling a function namedinitViewTreeOwners()
.The name of that function indicates that it's been designed for initialization, something which by definition, is supposed to happen only once. However, a setter doesn't generally have such constraints, at least, not because it's a setter (as the
setContentView
function is).I think that this
initViewTreeOwners()
function being called again is what messes upComposeView
or its underlying mechanisms, putting them in a state they should not be in.However, the issue might not be in
ComponentActivity
itself, but in the Compose runtime, or both.Thanks for reading, and have a great day!
Louis CAD