IssueTracker

After upgrading to kotlin 2.1.0 and bumping remaining dependencies, things seem to work as expected again. EDIT: My bad; was on the wrong branch. Those upgrades did NOT help.

I think I managed to track it down further:

In my Child composable, I'm actually hitting a TODO() statement:

@Composable
fun Child(isLoading: Boolean, items: List<MyDataClass>) {
    // ...
    if (notYetSupported) {
        TODO("This is not yet supported!")
    }
    // ...
}

It would seem that compose swallows this error and throws the above instead which is not very helpful.

The "pending composition has not been applied" error generally means that composition continued despite something in the hierarchy previously throwing an exception. Here it looks like something is continuing a subcomposition unexpectedly, possibly a LazyList.

We should see if we can improve this error messaging. Can you send over a more complete example? The snippets here aren't fleshed out enough to reproduce this swallowing behavior.

Triage notes: It feels like we're very close to having a repro case that we could run internally, but we don't know where the sub-composition is coming from.

Can you send over a more complete example?

Let's hold until we can get a stable repro case from the reporter. Could you send us a ZIP of the project that repros this issue? We'll close this out in a month if we don't get a response.

Bugjuggler: wait 1 month

This took me about an hour to extract but it reproduces the issue for me.

@file:SuppressLint("UnusedMaterialScaffoldPaddingParameter")

package com.example

import android.annotation.SuppressLint
import android.app.Application
import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.animation.AnimatedVisibility
import androidx.compose.material.MaterialTheme
import androidx.compose.material.Scaffold
import androidx.compose.material.Text
import androidx.compose.runtime.LaunchedEffect
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import kotlinx.coroutines.delay

class MyApp : Application()

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                // Scaffold is required!
                Scaffold { _ ->
                    val a = remember { mutableStateOf(true) }
                    val b = remember { mutableStateOf(true) }

                    LaunchedEffect(Unit) {
                        a.value = false
                        delay(50)
                        b.value = false
                    }

                    AnimatedVisibility(visible = a.value) { Text("Hello World") }

                    if (!b.value) {
                        TODO()
                    }
                }
            }
        }
    }
}

Thank you! I was able to reproduce locally. Will look into this. We may eventually dedupe to b/188320755, but this is immensely helpful since we haven't gotten a concrete repro for this bug yet.

One thing to note is that this is definitely related to a race condition. Device speed matters, and a slower device seems more likely to trigger this exception — My aging Pixel XL from 2016 reproduces this very consistently, unlike my local emulator which doesn't demonstrate this issue at all. We had suspected that coroutines were coming into play here, so a lot of pieces are starting to come together.

Correction: The emulator I was using had animations disabled. This seems to reproduce very consistently across devices.

It looks like our exception handling logic is try/catching Exception instead of Throwable. TODO() is breaking things because it throws a NotImplementedError, which isn't caught by our error handler and doesn't cancel pending recompositions. We'll update our code to include Errors and generic Throwable classes. It's not immediately obvious if this will fix other occurrences of this exception since we don't have other reproduction cases.

Project: platform/frameworks/support
Branch: androidx-main
Author: Andrew Bailey <anbailey@google.com>
Link:      https://android-review.googlesource.com/3443779

Fix Throwables causing unapplied composition error

Fix Throwables causing unapplied composition error 
 
The error handling logic in the Recomposer was set up to catch 
throwables that extended from Exception, which excluded Errors (like 
NotImplementedError, error(""), StackOverflowError, etc.) and 
user-defined exceptions that extend directly from Throwable. This CL 
updates the relevant pathways to switch over all Throwables. 
 
This resolves at least one pathway that leads to a "Pending composition 
has not been applied." runtime error. It's not immediately clear if this 
accounts for all of the reports since we only have one known 
reproduction case right now. 
 
Test: Manually run repro case in the linked bug 
Fixes: b/382094412 
Relnote: """ 
    Fixes an issue where raising a throwable during composition that 
    does not extend from Exception may lead to a 'Pending composition 
    has not been applied' error. 
    """ 
Change-Id: I356be5d99df41138be790275807544b2d717050c

I test the case #9 describe with 1.0.0-rc01 and 1.0.0-rc02

It turns out that it is not related to the compose_version.

If you build from gradle via command line, it will just works fine.

But run in IDE it will crash.

I don't think this is an Android Studio issue. I updated three existing projects to AGP 7.1.0-alpha04 and all of them broke. They all throw the exception listed in the original report.

If I roll each project back to AGP 7.1.0-alpha03 they all work again, even if I build from AS Bumblebee 2021.1.1 Canary 4.

It certainly seems to be an AGP issue, to me.

I'm able to reproduce, looking into it now.

The issue is that AGP passes min api level 21 to D8 causing it to remove the default methods from DefaultLifecycleObserver (make them abstract) but it does not pass desugaring classpath when rewriting invocations in AndroidComposeView.onAttachedToWindow.

Another workaround is to change the deploy option from Default APK to APK from app bundle, then we could deploy to device via Android Studio.

Current workaround is to (temporarily) increase your minSdkVersion to 24+ in build.gradle file.

This issue isn't related to Canary 4. I had this issue with Canary 4 but uninstalled it and then installed Arctic Fox (2020.3.1) RC 1 and this issue was still there. Changing the minSdkVersion to 24+ does fix the problem.

To clarify, the issue is not in Android Studio (the IDE), but it is in the Android Gradle plugin.

This is because when building from the IDE, AGP knows the API of the device which is used for deployment. This information is used to optimize the dexing pipeline (e.g avoid desugaring unless you run on device 23-). In AGP 7.1.0-alpha04 we introduced a bug where:

• the api version used for dexing is minSdkVersion e.g 21
• because we deploy to a device 24+ (e.g 30), desugaring is not requested

This means that D8 (dex compiler) will strip interface method and make them abstract, but it will not perform full rewriting, which leads to AbstractMethodError.

When building from the command line, minSdkVersion used for dexing and deciding if desugaring should be performed is the same, so that's why you see no issues.

This will be fixed in AGP 7.1.0-alpha06. Until that version is released, you can use workarounds from #21.

Change id: Ifcdc39995ff4f05c4bdfd4622127e15dd0f33d4d

This also seems to happen in Bumblebee Canary 3 with Compose 1.1.0-Beta01.

Re #24: Can you please file a separate issue with a sample project, idea.log, build output, and logcat crash info?

Re #26: This issue should be fixed in AGP 7.1.3. Can you please file a new bug with details listed in #25?

Re #30: Can you please file a separate issue with a sample project that reproduces the bug? See https://developer.android.com/studio/report-bugs for more details on information that we need.