Error: current bounds not set yet. [371802474]

Fixed

Bug

Status Update

No update yet.

Description

mi...@perplexity.ai

created issue #1

Oct 7, 2024 09:55AM

Jetpack Compose version: 1.7.3
Jetpack Compose component used: Modifier.sharedElement

Hey! We added a shared element transition to the app, using Compose 1.7.3. We are seeing this crash in firebase, however I could not reproduce the issue locally.

Our layout hierarchy looks like this:
NavHost -> ... -> AnimatedVisibility -> ... -> BoxWithConstraints -> First layout with sharedElement
\> ... -> AnimatedVisibility -> ... -> BoxWithConstraints -> Second layout with sharedElement
With "..." I replaced series of "normal" layouts.

The crash is due to this precondition failing:

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/SharedElement.kt;l=189?q=SharedElementInternalState&ss=androidx
It seems somehow one of the elements gets drawn without having had layout before.

Any idea if I am doing something wrong, or any workarounds? Thank you!!

Stack trace:
SharedElementInternalState.drawInOverlay
java.lang.IllegalArgumentException - Error: current bounds not set yet.
androidx.compose.animation.SharedElementInternalState.drawInOverlay (SharedElementInternalState.java:196)
androidx.compose.animation.SharedTransitionScopeImpl.drawInOverlay$animation_release (SharedTransitionScopeImpl.java:1086)
androidx.compose.animation.SharedTransitionScopeKt$SharedTransitionScope$1$2$1.invoke (SharedTransitionScope.kt:161)
androidx.compose.animation.SharedTransitionScopeKt$SharedTransitionScope$1$2$1.invoke (SharedTransitionScope.kt:159)
androidx.compose.ui.draw.DrawWithContentModifier.draw (DrawModifier.kt:422)
androidx.compose.ui.node.LayoutNodeDrawScope.drawDirect-eZhPAX0$ui_release (LayoutNodeDrawScope.kt:110)
androidx.compose.ui.node.LayoutNodeDrawScope.draw-eZhPAX0$ui_release (LayoutNodeDrawScope.kt:89)
androidx.compose.ui.node.NodeCoordinator.drawContainedDrawModifiers (NodeCoordinator.kt:450)
androidx.compose.ui.node.NodeCoordinator.draw (NodeCoordinator.kt:439)
androidx.compose.ui.node.LayoutModifierNodeCoordinator.performDraw (LayoutModifierNodeCoordinator.kt:280)
androidx.compose.ui.node.NodeCoordinator.drawContainedDrawModifiers (NodeCoordinator.kt:447)
androidx.compose.ui.node.NodeCoordinator.draw (NodeCoordinator.kt:439)
androidx.compose.ui.node.LayoutNode.draw$ui_release (LayoutNode.kt:1000)
androidx.compose.ui.node.InnerNodeCoordinator.performDraw (InnerNodeCoordinator.kt:196)
androidx.compose.ui.node.LayoutNodeDrawScope.drawContent (LayoutNodeDrawScope.kt:68)
androidx.compose.foundation.BackgroundNode.draw (Background.kt:163)
androidx.compose.ui.node.LayoutNodeDrawScope.drawDirect-eZhPAX0$ui_release (LayoutNodeDrawScope.kt:110)
androidx.compose.ui.node.LayoutNodeDrawScope.draw-eZhPAX0$ui_release (LayoutNodeDrawScope.kt:89)
androidx.compose.ui.node.NodeCoordinator.drawContainedDrawModifiers (NodeCoordinator.kt:450)
androidx.compose.ui.node.NodeCoordinator.access$drawContainedDrawModifiers (NodeCoordinator.kt:58)
androidx.compose.ui.node.NodeCoordinator$drawBlock$1$1.invoke (NodeCoordinator.java:469)
androidx.compose.ui.node.NodeCoordinator$drawBlock$1$1.invoke (NodeCoordinator.java:468)
androidx.compose.runtime.snapshots.Snapshot$Companion.observe (Snapshot.java:2441)
androidx.compose.runtime.snapshots.SnapshotStateObserver$ObservedScopeMap.observe (SnapshotStateObserver.kt:502)
androidx.compose.runtime.snapshots.SnapshotStateObserver.observeReads (SnapshotStateObserver.kt:258)
androidx.compose.ui.node.OwnerSnapshotObserver.observeReads$ui_release (OwnerSnapshotObserver.kt:133)
androidx.compose.ui.node.NodeCoordinator$drawBlock$1.invoke (NodeCoordinator.java:468)
androidx.compose.ui.node.NodeCoordinator$drawBlock$1.invoke (NodeCoordinator.java:466)
androidx.compose.ui.platform.GraphicsLayerOwnerLayer$recordLambda$1.invoke (GraphicsLayerOwnerLayer.java:291)
androidx.compose.ui.platform.GraphicsLayerOwnerLayer$recordLambda$1.invoke (GraphicsLayerOwnerLayer.java:289)
androidx.compose.ui.graphics.layer.GraphicsLayerV29.record (GraphicsLayerV29.android.kt:245)
androidx.compose.ui.graphics.layer.GraphicsLayer.recordInternal (AndroidGraphicsLayer.android.kt:430)
androidx.compose.ui.graphics.layer.GraphicsLayer.record-mL-hObY (AndroidGraphicsLayer.android.kt:423)
androidx.compose.ui.platform.GraphicsLayerOwnerLayer.updateDisplayList (GraphicsLayerOwnerLayer.android.kt:284)
androidx.compose.ui.platform.GraphicsLayerOwnerLayer.drawLayer (GraphicsLayerOwnerLayer.android.kt:229)
androidx.compose.ui.node.NodeCoordinator.draw (NodeCoordinator.kt:434)
androidx.compose.ui.node.LayoutNode.draw$ui_release (LayoutNode.kt:1000)
androidx.compose.ui.node.InnerNodeCoordinator.performDraw (InnerNodeCoordinator.kt:196)
androidx.compose.ui.node.NodeCoordinator.drawContainedDrawModifiers (NodeCoordinator.kt:447)
androidx.compose.ui.node.NodeCoordinator.draw (NodeCoordinator.kt:439)
androidx.compose.ui.node.LayoutNode.draw$ui_release (LayoutNode.kt:1000)
androidx.compose.ui.platform.AndroidComposeView.dispatchDraw (AndroidComposeView.android.kt:1564)
android.view.View.draw (View.java:25180)
android.view.View.updateDisplayListIfDirty (View.java:24036)
android.view.ViewGroup.recreateChildDisplayList (ViewGroup.java:4764)
...

Comments

mi...@perplexity.ai <mi...@perplexity.ai> #2Oct 25, 2024 02:44PM

So you can do this now by doing something like:

@Suppress("UNCHECKED_CAST")
class DelegateWorker: Worker() {
companion object {
const val DELEGATE_WORKER_NAME = "DELEGATE_WORKER_NAME"
const val PERIOD = "PERIOD" // in minutes.
}

override fun doWork(): Result {
val delegateName = inputData.getString(DELEGATE_WORKER_NAME) ?: return Result.FAILURE
val delegateKlass = Class.forName(delegateName) as? Class<out Worker> ?: return Result.FAILURE
val period = inputData.getLong(PERIOD, 15)
// build your worker with the constraints you want.
val request = PeriodicWorkRequest.Builder(delegateKlass, period, TimeUnit.MINUTES)
.setInputData(inputData)
.build()
WorkManager.getInstance()
.enqueue(request)

return Result.SUCCESS
}
}

class PeriodicWorker: Worker() {
override fun doWork(): Result {
// Do some periodic work
return Result.SUCCESS
}
}

// You want to delay the PeriodicWorker. You can use initial delay on the DelegateWorker, which in
// turn enqueue's PeriodicWorker.

val data = mapOf(DelegateWorker.DELEGATE_WORKER_NAME to PeriodicWorker::

class.java.name).toWorkData()
val delayedPeriodicWorkRequest = OneTimeWorkRequestBuilder<DelegateWorker>()
.setInitialDelay(10, TimeUnit.SECONDS)
.build()

WorkManager.getInstance()
.enqueue(delayedPeriodicWorkRequest)

The idea is to create a OneTimeWorkRequest with an initial delay, which in turn calls an enqueue() on the PeriodicWorkReqeust.

ti...@google.com <ti...@google.com> #3Oct 25, 2024 05:03PM

This looks like a hack, instead of just adding setInitialDelay method on the periodic worker that will just run once.

mi...@perplexity.ai <mi...@perplexity.ai> #4Oct 25, 2024 08:50PM

I have tried going the route of the OneTimeWorkRequest with an initial delay that triggers a PeriodicWorkRequest but it doesn't seem to work. It would be much nicer to be able to add a simple delay to the first occurence.

ti...@google.com <ti...@google.com> #5Oct 28, 2024 06:21PM

#3: This is exactly what an internal implementation would look like because the backing JobScheduler does not support initial delays on periodic work. I realize that WorkManager doing it for you is nicer, which is why this feature request is still open, but it may take us some time to get to it.

#4: Please file a separate bug if that doesn't work for you.

mi...@perplexity.ai <mi...@perplexity.ai> #6Oct 28, 2024 09:16PM

#5: How could I debug the behaviour of this chain of Work?

ti...@google.com <ti...@google.com> #7Oct 29, 2024 10:15PM

Use logcat, or use the various getStatus methods to see what's going on. File a bug with a bugreport and sample code that results in the problem.

mi...@perplexity.ai <mi...@perplexity.ai> #8Oct 29, 2024 10:19PM

It would be nice to see setInitialDelay() on PeriodicWorkRequest.Builder in the next version, Thanks

ti...@google.com <ti...@google.com> Oct 29, 2024 10:25PM

Reassigned to ti...@google.com.

mi...@perplexity.ai <mi...@perplexity.ai> #9Oct 30, 2024 05:26PM

Just a "+1" "me too" to add another voice to this... would make so much sense to be able to have setInitialDelay() on PeriodicWorkRequest.Builder

mi...@perplexity.ai <mi...@perplexity.ai> #10Nov 4, 2024 12:32PM

Android must list down the challenges of Periodic Work request in there documents, I am tracking Work Manager since it was alpha.Here are the limitations of Priodic Work request:
1. Periodic work request does not support setInitialDelay.
2. Periodic Work request does not support the Chining.

ti...@google.com <ti...@google.com> #11Nov 7, 2024 01:57AM

Both of these items are listed in the official documentation for PeriodicWorkRequest:

https://developer.android.com/reference/androidx/work/PeriodicWorkRequest

"Periodic work has a minimum interval of 15 minutes and it cannot have an initial delay."
"Periodic work cannot be part of a chain or graph of work."

mi...@perplexity.ai <mi...@perplexity.ai> #12Nov 7, 2024 03:40PM

Still not supported...
I feel that many people need it...would make so much sense to be able to have setInitialDelay() on PeriodicWorkRequest.Builder

ti...@google.com <ti...@google.com> #13Nov 13, 2024 07:39PM

Setting a flex period effectively delays a PeriodicWorkRequest.

mi...@perplexity.ai <mi...@perplexity.ai> #14Nov 13, 2024 08:00PM

+1 from me too, with an extra option to limit the number of repeats, for example, run a periodic job daily for 7 days and then stop.

ap...@google.com <ap...@google.com> #15Nov 14, 2024 09:15PM

Marked as fixed.

+1 for setInitailDelay() and limitNumberOfFires() for Periodic work request!

pr...@google.com <pr...@google.com> #16Dec 11, 2024 06:27PM

What is the best solution for now to setInitailDelay() ?