java.lang.IllegalStateException: Composition cannot be performed while another composition is in progress on ComposeView.setContent

Answer

Yes. Invoking ComposeView.setContent from a background thread is the primary cause of the intermittent IllegalStateException you see. The exception is a hard guard that the Compose runtime uses to ensure only one composition can be active per ComposerImpl instance. When a second composition starts before the first one has finished, the runtime throws the exception regardless of whether the call originates from the UI thread or elsewhere. In practice, off‑thread calls trigger a thread‑affinity violation that surfaces as the same exception.

Why the Exception Appears

• Composition stack rule: ComposerImpl.startComposition() sets a flag that is cleared only when the composition exits. Re‑entering before that flag is cleared causes IllegalStateException.
• Thread affinity: ComposeView.setContent is documented to run on the UI thread. A background thread bypasses the internal checks that would otherwise schedule the composition on the main looper.
• Lifecycle timing: If a view is attached or detached while a composition is inflight, the same guard can fire, but this is a secondary, less common path.

Steps to Verify and Fix

1. Confirm thread usage
   Wrap all setContent calls in runOnUiThread { … } or use view.post { … }.

   runOnUiThread {
       composeView.setContent { MyComposable() }
   }
   

2. Check Compose runtime version
   Print the runtime version at startup:

   Log.i("Compose", "Runtime: ${androidx.compose.runtime.version}")
   

   Compare against the latest stable release; older 1.x versions were more tolerant of off‑thread calls, but 2.0+ enforce the rule strictly.
3. Instrument composition re‑entrance
   Enable composition logging (if available) or use a simple counter:

   var compositionDepth = 0
   composeView.setContent {
       compositionDepth++
       // content
       compositionDepth--
   }
   

   If compositionDepth ever exceeds 1, you have overlapping compositions.
4. Test sequential same‑thread calls
   Invoke setContent twice on the main thread while the first composition is still inflight (e.g., by introducing a delay inside the composable). The exception should not occur; the runtime will queue the second call until the first finishes.
5. Review view attachment timing
   Ensure ComposeView is attached before calling setContent. If you call it during onCreateView before onViewCreated, the view might not have a valid window token, which can also lead to composition errors.

What to Ask Next

If you still encounter the exception after enforcing UI‑thread calls, please provide:

• The exact Compose runtime version you are using.
• Whether the exception occurs during view attachment, a background thread call, or a nested setContent during an ongoing composition.

Conclusion

The exception is a hard concurrency guard, not a transient race. The safest path is to keep setContent on the main thread and let Compose handle serialization of sequential calls. If you need to trigger recompositions from background work, post the new content to the UI thread instead of invoking setContent directly from that thread.