[Bug]: androidx.compose.runtime.SlotWriter.moveGroupGapTo ANR triggered by slow operations in main thread

[cxqq123]

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

Is this an issue related to one of the samples?

• Yes, this is a specific issue related to this samples repo.

Sample app

Crane

What happened?

  main (runnable):tid=1 systid=23334 
   at androidx.compose.runtime.SlotWriter.moveGroupGapTo(SlotTable.kt:2937)
   at androidx.compose.runtime.SlotWriter.removeGroups(SlotTable.kt:3155)
   at androidx.compose.runtime.SlotWriter.removeGroup(SlotTable.kt:2265)
   at androidx.compose.runtime.ComposerKt.removeCurrentGroup(Composer.kt:4182)
   at androidx.compose.runtime.changelist.Operation$RemoveCurrentGroup.execute(Operation.kt:361)
   at androidx.compose.runtime.changelist.Operations.executeAndFlushAllPendingOperations(Operations.kt:310)
   at androidx.compose.runtime.changelist.ChangeList.executeAndFlushAllPendingChanges(ChangeList.kt:81)
   at androidx.compose.runtime.CompositionImpl.applyChangesInLocked(Composition.kt:984)
   at androidx.compose.runtime.CompositionImpl.applyChanges(Composition.kt:1013)
   at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke(Recomposer.kt:685)
   at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke(Recomposer.kt:585)
   at androidx.compose.ui.platform.AndroidUiFrameClock$withFrameNanos$2$callback$1.doFrame(AndroidUiFrameClock.android.kt:41)
   at androidx.compose.ui.platform.AndroidUiDispatcher.performFrameDispatch(AndroidUiDispatcher.android.kt:109)
   at androidx.compose.ui.platform.AndroidUiDispatcher.access$setScheduledFrameDispatch$p(AndroidUiDispatcher.android.kt:41)
   at androidx.compose.ui.platform.AndroidUiDispatcher.access$performFrameDispatch(AndroidUiDispatcher.android.kt:41)
   at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame(AndroidUiDispatcher.android.kt:69)
   at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1039)
   at android.view.Choreographer.doCallbacks(Choreographer.java:864)
   at android.view.Choreographer.doFrame(Choreographer.java:787)
   at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1026)
   at android.os.Handler.handleCallback(Handler.java:938)
   at android.os.Handler.dispatchMessage(Handler.java:99)
   at android.os.Looper.loop(Looper.java:255)
   at android.app.ActivityThread.main(ActivityThread.java:8224)
   at java.lang.reflect.Method.invoke(Native method)
   at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:632)
   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)
    A bug happened!

Relevant logcat output

Code of Conduct

• I agree to follow this project's Code of Conduct

[manikmani306-netizen]

Chime how to login my device

[merenyimiklos]

Hey! I’ve seen similar ANR traces caused by long operations running inside composition or recomposition.
You might try moving the heavy logic (like data loading or expensive calculations) out of the composable and into a LaunchedEffect or rememberCoroutineScope.
Also check if you’re triggering recompositions too frequently — for example, passing changing states directly into remember blocks or modifiers.

In the Crane sample, this often happens if you run suspend functions directly in a @composable.
Try wrapping that call like this:

LaunchedEffect(Unit) { // your suspend call here }

If that stabilizes the UI thread, the ANR should go away.
Let me know if this helps — I can dig deeper into the specific call stack.