IssueTracker

We have some support in androidx.compose.ui.autofill

Leaving this bug open in case Ralston wants to add more info

I found an example here. One problem is that it only works with the Google autofill service. When using any other service like Microsoft Authenticator or OneKey, the following error is shown:

D/Autofill Status: Autofill popup isn't shown because autofill is not available.
    
    Did you set up autofill?
    1. Go to Settings > System > Languages&input > Advanced > Autofill Service
    2. Pick a service
    
    Did you add an account?
    1. Go to Settings > System > Languages&input > Advanced
    2. Click on the settings icon next to the Autofill Service
    3. Add your account

Is this a bug on your side or do the app developers of these password managers need to change their implementation?

Another problem I am facing with autofill is that it won't save my credentials. I tried forcing to finish the context as described here, but it won't do that either although I filled in the username with the one provided by the Google autofill service.

I setup this modifier:

@OptIn(ExperimentalComposeUiApi::class)
fun Modifier.autofill(
    autofillTypes: List<AutofillType>,
    onFill: ((String) -> Unit),
) = composed {
    val autofill = LocalAutofill.current
    val autofillNode = AutofillNode(onFill = onFill, autofillTypes = autofillTypes)
    LocalAutofillTree.current += autofillNode

    this.onGloballyPositioned {
        autofillNode.boundingBox = it.boundsInWindow()
    }.onFocusChanged { focusState ->
        autofill?.run {
            if (focusState.isFocused) {
                requestAutofillForNode(autofillNode)
            } else {
                cancelAutofillForNode(autofillNode)
            }
        }
    }
}

And use it like this:

val emailState = remember { EmailState() }
Email(
    modifier = Modifier.autofill(
        autofillTypes = listOf(
            AutofillType.Username,
            AutofillType.EmailAddress
        ),
        onFill = { emailState.text = it },
    ),
    emailState = emailState,
    onImeAction = { onForgotPasswordSubmitted(emailState.text) }
)

With these steps, autofill works for me.

@lo...@gmail.com comment#8

what version of compose are you using? I'm using latest alpha and the above doesn't work for me. 😭

Works perfectly fine on the latest stable and alpha versions. Did you check in my second comment if you enabled everything?

I believe so?

I copied the modifier and then used

modifier = Modifier.autofill(
        autofillTypes = listOf(
            AutofillType.Username,
            AutofillType.EmailAddress
        ),
        onFill = { emailState.text = it },
    )

on my text field.

The auto-filling works for me with the latest alpha version, but I'm never presented with the save dialog though.

I am having exactly same problem. Autofill works, but the Save dialog is never shown...

Any updates on this? I can't get LastPass to display at all. I can ONLY get the Google Auto-fill service to work

Same here, autofill in Jetpack Compose only works with the Google auto-fill service. When picking 1Password as the Auto-fill service in Settings, the debug log prints out:

D/Autofill Status: Autofill popup isn't shown because autofill is not available.
    
    Did you set up autofill?
    1. Go to Settings > System > Languages&input > Advanced > Autofill Service
    2. Pick a service
    
    Did you add an account?
    1. Go to Settings > System > Languages&input > Advanced
    2. Click on the settings icon next to the Autofill Service
    3. Add your account

1.3.1 won't dialog prompt to save a password for me but will prompt to autofill for google.

As a workaround, you can wrap the TextInputLayout from a layout file to an AndroidView in compose.

@Composable
fun TextFieldView(
    modifier: Modifier = Modifier,
    textState: MutableState<String>,
    @LayoutRes layoutRes: Int,
    textChanged: () -> Unit = {},
) {
    AndroidView(
        modifier = modifier
            .fillMaxWidth(),
        factory = { context ->
            val layout = LayoutInflater.from(context).inflate(layoutRes, null)
            layout.findViewById<TextInputEditText>(R.id.tilET).apply {
                doAfterTextChanged {
                    textState.value = safeText
                    textChanged.invoke()
                }
            }
            layout
        },
        update = {

        }
    )
}

val EditText?.safeText: String get() = this?.editableText?.toString().orEmpty().trim()

<?xml version="1.0" encoding="utf-8"?>
<com.google.android.material.textfield.TextInputLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/til"
    style="@style/TextInput"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:hint="Username">

    <com.google.android.material.textfield.TextInputEditText
        android:id="@+id/tilET"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:autofillHints="username"
        android:imeOptions="actionNext"
        android:inputType="textNoSuggestions"
        android:selectAllOnFocus="true" />
</com.google.android.material.textfield.TextInputLayout>

<?xml version="1.0" encoding="utf-8"?>
<com.google.android.material.textfield.TextInputLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/til"
    style="@style/TextInput"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:hint="Password"
    app:endIconMode="password_toggle">

    <com.google.android.material.textfield.TextInputEditText
        android:id="@+id/tilET"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:autofillHints="password"
        android:imeOptions="actionDone"
        android:inputType="textPassword"
        android:selectAllOnFocus="true" />
</com.google.android.material.textfield.TextInputLayout>

I tried using similar to above example. But its not working & following logs are getting printed.

getAutofillClient(): null on super, trying to find activity thread getAutofillClient(): none of the 1 activities on com.xx@8b0a7bc have focus No AutofillClient for com.xx on context com.xxn@8b0a7bc requestHideFillUi(null): anchor = null

Autofill popup isn't shown because autofill is not available. Did you set up autofill?

1. Go to Settings > System > Languages&input > Advanced > Autofill Service
2. Pick a service

Did you add an account?

1. Go to Settings > System > Languages&input > Advanced
2. Click on the settings icon next to the Autofill Service
3. Add your account

setSessionFinished(): from ACTIVE to FINISHED; autofillableIds=null

Can anyone help

Please fix 1password and compose

Any update? It would be good to fix it asap, please.

Any update on this?

It can be overlooked since it is simple but one of the important convenience feature.

Autofill is currently listed as "In Focus" on our Public Roadmap. This means we're actively working on this feature and hope to have something to share soon.

Solution from #8 works for me too but with one caveat: When detectUnsafeIntentLaunch is enabled, I can see in logs that AutofillManager launches unsafe intent:

StrictMode policy violation: android.os.strictmode.UnsafeIntentLaunchViolation: Launch of unsafe intent: Intent { (has extras) }
	at android.os.StrictMode.onUnsafeIntentLaunch(StrictMode.java:2329)
	at android.content.Intent.prepareToLeaveProcess(Intent.java:12589)
	at android.content.Intent.prepareToLeaveProcess(Intent.java:12501)
	at android.app.Activity.startIntentSenderForResultInner(Activity.java:5973)
	at android.app.Activity.startIntentSenderForResult(Activity.java:5915)
	at android.view.autofill.AutofillClientController.autofillClientAuthenticate(AutofillClientController.java:484)
	at android.view.autofill.AutofillManager.authenticate(AutofillManager.java:2433)
	at android.view.autofill.AutofillManager.-$$Nest$mauthenticate(Unknown Source:0)
	at android.view.autofill.AutofillManager$AutofillManagerClient.lambda$authenticate$3(AutofillManager.java:3821)
	at android.view.autofill.AutofillManager$AutofillManagerClient$$ExternalSyntheticLambda3.run(Unknown Source:12)
	at android.os.Handler.handleCallback(Handler.java:942)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:226)
	at android.os.Looper.loop(Looper.java:313)
	at android.app.ActivityThread.main(ActivityThread.java:8762)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:604)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

Could you please post some updates on this?

• it is one year in the roadmap: https://developer.android.com/jetpack/androidx/compose-roadmap
• one CL abandoned more than a year ago: https://android-review.googlesource.com/c/platform/frameworks/support/+/2434079
• another CL is getting silent: https://android-review.googlesource.com/c/platform/frameworks/support/+/3009614

It is sad that almost 3 years after a stable release of Compose there is still no support for Autofill.

A quick update here -

We built autofill for 1.7 and found that we need to do some substantial rework of the semantics system before it lands (this is ongoing top priority - aiming for hopefully 1.8).

Turning it on caused a large performance drop app-wide. We're working on fixing that, and then will turn autofill on.

It's currently #1 item on all of prioritization for compose feature work. Will give more update when it's getting closer to landing.

See comment #31 for the latest update from our engineering team.

The majority of autofill CLs landed this week. It seems that the next alpha should have this :) 🤞

Will the new autofill solution solve the strict mode unsafe intent violation?

mentioned above in comment #28? https://issuetracker.google.com/issues/176949051#comment28

Details here: https://developer.android.com/reference/android/os/strictmode/UnsafeIntentLaunchViolation

#36 are you only currently interested in API shape feedback, or should I be filing issues for non performance related bugs?

I would love for the api shape to be the way it was with xml - a simple one lime flag

I agree. Adoption of the flags was not high. Adoption of this will be lower. Users blame the password manager not the apps that have not implemented the simple flags.

"I would love for the api shape to be the way it was with xml - a simple one lime flag"

Personally I care less about a 1 liner and more about versatility of the API.

The 1 liner is good if it doesn't limit what can be done.

First and foremost it should be an idiomatic API.

Hi Priti,

Thanks for reaching out. The new Autofill APIs were added to 1.8 and you should be able to use them. I tested our demo App and Autofill works with Google Password Manager and LastPass. Can you verify that you try out this sample?

@Composable
fun BasicTextFieldAutofill() {
    val autofillManager = LocalAutofillManager.current

    Column {
        Text(text = "Enter your username and password below.")
        BasicTextField(
            state = remember { TextFieldState() },
            modifier = Modifier.semantics { contentType = ContentType.Username},
        )
        BasicTextField(
            state = remember { TextFieldState() },
            modifier = Modifier.semantics { contentType = ContentType.Password },
        )

        // Submit button
        Button(onClick = { autofillManager?.commit() }) { Text("Submit credentials") }
    }
}

The entire demo is here:

Source: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/autofill/TextFieldAutofillDemo.kt;drc=8e2e6368a5c20346d75e909379c2d1045ea74111;l=94

Can you try this out and report back if it does not work?

#46 Is there some mechanism in autofill to differentiate different login/password combos for the password manager? In my app they can login to different servers they own for different services and I'd like to have some ways for the password manager to only shows the credentials relevant to the current service type.

#48 Then from the docs how "For example, if a user has already signed into your app through the Chrome browser on their laptop and saved their password through a credential provider, then their credentials are served to them through Autofill." works? Or how does Chrome to tell the password manager the current website he's browsing.

Like in my case the user have saved a password in Chrome for a website with an url, and in my application he configure to connect to that same website and the same url there's really no way from Compose to have that match? All I can offer to the users is that they save again all their login/password for their servers after entering them in my app, and then they will have the list of all entries for every server they add ?

#47: Tell us more about your use case. Did this work in a view-based app but doesn't work in Compose? If it did, what are the APIs you used for views?

Is this related to using setImportantForAutofill for the "service type" Dropdown? Or did the "service type" field have an autofill hint?

#50: This is good feedback. The document meant to point to the fact that if you have stored credentials, you can long press on a textField and then select one of your stored passwords. But it the way it is worded makes it look like there is a way to connect the web version of an app with the android version of the app. That's a good idea. We don't have this right now, but if you file a feature request we can send it over to the autofill team.

That use case is specific for a Compose app from start. Will stay with the basic support then.

For the feature request can do if you point me to the proper tracker category.

Project: platform/frameworks/support
Branch: androidx-main
Author: Ralston Da Silva <ralu@google.com>
Link:      https://android-review.googlesource.com/3499897

Introduce InputText Semantics Property

Introduce InputText Semantics Property 
 
TextFields have an EditableText semantics property which 
stores the text value after output transformation. Autofill 
needs access to the text value after input transformation 
but before output transformation. Adding this semantics 
property helps send the right information to the Autofill 
service. 
 
Bug: 395911609 
Bug: 176949051 
Test: Added new tests and updated existing tests 
Relnote: "Added a new semantics property InputText that captures 
a textfield's value before output transformation is applied." 
 
Change-Id: Iae46a52e7fbb1a3558e897c5afebd125089befbb

Tried out the latest sample but I'm unable to get the store password with commit to work. There is no popup prompted with 1.8.0-beta02. I set the password manager to be the Google Password Manager. Phone is Pixel 8 running Android 15. Is the sample incomplete?

In some scenarios username and/or password may be generated. E.g in our usecase we have a unique number that serves as the account and password, and there is no additional details needed such as email. The user interaction to create an account would be just pressing a button "Create account" that generates a new account. With the current API I what would be the recommended way to implement this? I see there being 2 options:

1. Upon successful account creation, set the semantic on a hidden TextField or TextField for login, before navigating away. (Feels it could be likely to race when set the property on a textfield just before navigating away)
2. When showing the account number after a successful account creation, set it semantic NewPassword and then do a LaunchEffect to commit. However this breaks the guideline of only calling commit on a button press.

For the scenario above, it would also be nice to have an options to disable the strong password suggestion. Because as mentioned the user does not get to select their password.

Edit: I finally made it work. One have to enable the "Offer to save passwords", in Google Password Manager.

Furthermore, you have to have both NewUsername & NewPassword content type on two separate fields, and seemingly the user have to interact with both fields in-order to offer the storage of a new login. E.g settings "username" and "password" to be default text in the field and the calling "commit" will not work, nor will it to programmatically modify these strings. An interaction with the view/keyboard has to happen.

I'm looking forward to hear if there is any way of programmatically just offering this, the current flow seems very complex for a lot of usecases.

Hi Meghan! Thanks for the quick reply.

This is the sample I was looking at: https://github.com/android/snippets/blob/cfeb99f00017b6166c7c2467b050ba58dd6d9cca/compose/snippets/src/main/java/com/example/compose/snippets/text/AutofillSnippets.kt#L82-L98

Regarding strong password: I see, I assume it shows this the knowing that it has to provide a password.

When using Google Password Manager, the save dialog will only appear when there is a NewUsername and a NewPassword field.

Is this the case for just Google Password Manager or all apps interacting with the autofill? Could a autofill provider choose to offer to save a Password without any user interaction and just "NewPassword" field?

We have this scenario in with our service. All our users sign up by pressing "Create account" we generate an account number to which they use as their login, users provide no email, username or password. Since the account is a generated value, we'd like to offer to save it in the users password manager so they don't forget it and have a nicer experience when logging in on other devices. I can also imagine other apps having similar solutions or generating the password to the user automatically.

Edit: I found the solution for my scenario, the usecase is not to go by the autofill service in this case, it seems like if you want to save a password w/o user interaction or with the help of the keyboard on should use the CredentialsManager.

Thanks for your reply & help Meghan

David @ MullvadVPN

Ralston is making a large change for focus that will fix this problem. He's agreed to take this on.

I had the same type of issues, where using a LazyRow and scrolling a lot would see performance degradation to the point where the app was unusable. I can say that the fixes from this bug have definitely fixed my issue, so thank you very much! However, now I'm seeing that my derivedStateOf calculations are getting called all the time.

I have a derivedStateOf which calculates layout information based off changes to the scroll state. For example:

class LayoutProvider(
    val layoutState: State<MyLayout>
)

@Composable
fun rememberLayoutProvider(): LayoutProvider {
    val layoutState = remember {
        derivedStateOf {
            // run some big calculations to calculate a layout
            calculateLayout()
        }
    }
    return remember { LayoutProvider(layoutState) }
}

And then many different composables use my derived state to create their own derivedStateOf to get their layout information. For example:

@Composable
fun SomeTile() {
    val myLayout = remember {
        derivedStateOf {
            layoutProvider.getMyLayout()
        }
    }

    do something with myLayout
}

In compose 1.2.0, this worked really well, and when the scroll state would change, the layout provider's calculation would run once, and only composables whose specific layout changed (myLayout) would get recomposed.

Now in compose 1.3.0-beta01, the calculation in the LayoutProvider gets called a large number of times, and the composoables who have their own derivedState get recomposed even when their specific layout hasn't changed.

I noticed the change to the derivedStateOf, with the addition of a policy, but I tried writing my own and still couldn't get the results I wanted. Can you please explain how I can go about getting these calculations to get called as I'd expect and only have the composables that have their derived state changed recompose?

Thank you

To give some more information, when when calling derivedStateOf(structuralEqualityPolicy()) in both those places in the code above, it still behaves incorrectly. Basically, the composable SomeTile always gets recomposed any time the scroll state changes, and only at the call site where myLayout gets used does the derivedState calculation run (i.e. layoutProvider.getMyLayout(). Seeing the whole point of derivedState is so that we can avoid recomposing composables on state changes that can happen frequently, this now feels broken to me. Please let me know if I'm missing something.

Thank you

I was able to make it even more simple:

@Composable
fun SomeComposable(
    scrollState: LazyListState
) {
    val red by remember {
        derivedStateOf(structuralEqualityPolicy()) {
            // cause an observation on the scroll state
            scrollState.firstVisibleItemScrollOffset != 0
        }
    }

    Log.e("Test", "composing SomeComposable")
    if (red) {
        Log.e("Test", "composing a red box")
        Box(modifier = Modifier.background(Color.Red).fillMaxSize())
    }
    else {
        Log.e("Test", "composing a blue box")
        Box(modifier = Modifier.background(Color.Blue).fillMaxSize())
    }
}

With this code, red should always be true except when the scroll offset is at 0, and thus the composable should only ever recompose when the scroll offset comes to zero or leaves zero. However, it recomposes on every single scroll change.

Your last example sounds normal IMO. The scrollstate change, the SomeComposable is recomposed the state is calculated, if is called and your log is ran.

To see any benefit here you need to extract the second part to another composable that is skippable.

@Composable
fun SomeComposable(
    scrollState: LazyListState
) {
    val red by remember {
        derivedStateOf(structuralEqualityPolicy()) {
            // cause an observation on the scroll state
            scrollState.firstVisibleItemScrollOffset != 0
        }
    }

    Log.e("Test", "composing SomeComposable")
    SomeComposable2(red)
}

@Composable
fun SomeComposable2(
    red: Boolean
) {
    if (red) {
        Log.e("Test", "composing a red box")
        Box(modifier = Modifier.background(Color.Red).fillMaxSize())
    }
    else {
        Log.e("Test", "composing a blue box")
        Box(modifier = Modifier.background(Color.Blue).fillMaxSize())
    }
}

This will display the first composing log each time the scrollstate change, but the box composing will only happen when the derived state change as the SomeComposable2 is skippable.

Thanks for the response, but unfortunately, that still isn't correct IMO. I understand the concept of using a composable that is skippable, but what that would accomplish is that when red changes, SomeComposable would not recompose, while SomeComposable2 would. That is not what I'm trying to accomplish. The issue here is that red is not supposed to change unless the scrollable state crosses the zero boundary. So in your example, SomeComposable2 still recomposes every single time the scroll state changes, but it shouldn't.

The issue is that the red state only gets evaluated/calculated when it is accessed, which is in the recomposition, but at this point, it's too late, as the composable is already recomposing. So DerivedState is no longer useful. In Compose 1.2.0, the red calculation would run at the time that the scroll state changes outside the composition scope, and then would appropriately cause the composable to recompose only if the red state actually changed.

No in my example SomeComposable2 does not recompose because it's skippable and red state does not change.

SomeComposable will always recompose because the scrollstate change. It's up to you that your composable is made of skippable sub component so that they are not recomposed.

In the case of #68 the if is not a composable function so is not skippable. So if SomeComposable is recomposed the if will always be ran and so your log will run. If you had something different before then it was something else and not how compose is supposed to work.

In all case in my example the red state is read as it's a parameter to SomeComposable2 so it's up to date thanks to the derivedstate and so will properly change.

I use this pattern a lot in prod and it works like that since 1.0 and it still works the same in 1.3 alpha3 (and beta 1 but I'm not in prod with it due to the return of the mem leak).

In all cases your issue seems unrelated to this one so you might want to open another one if you want more traction from Google.

Here is sample code that describes exactly the issue:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            // A surface container using the 'background' color from the theme
            Surface(
                modifier = Modifier.fillMaxSize(),
                color = MaterialTheme.colors.background
            ) {
                OuterComposable()
            }
        }
    }
}

@Suppress("EqualsOrHashCode")
class ZeroMap(
    val zeroMap: Map<Int, Boolean>
) {
    override fun equals(other: Any?): Boolean {
        if (this === other) {
            Log.e("StateTest", "ZeroMap is the same reference")
            return true
        }
        if (javaClass != other?.javaClass) {
            Log.e("StateTest", "ZeroMap is not the same because of javaClass")
            return false
        }

        other as ZeroMap

        if (zeroMap.size != other.zeroMap.size) {
            Log.e("StateTest", "ZeroMap is not the same because trackLayouts.size (${zeroMap.size}) != other.trackLayouts.size (${other.zeroMap.size})")
            return false
        }

        val otherEntries = other.zeroMap.entries
        zeroMap.entries.forEachIndexed { index, entry ->
            val otherEntry = otherEntries.elementAt(index)
            if (entry.value != otherEntry.value) {
                Log.e("StateTest", "ZeroMap is not the same because entry.value (${entry.value}) != otherEntry.value (${otherEntry.value}) for index $index")
                return false
            }
        }

        Log.e("StateTest", "ZeroMap is the same value")
        return true
    }
}

class ZeroStateProvider(
    val scrollState: LazyListState,
    private val zeroState: State<ZeroMap>
) {
    fun isAtZero(index: Int) = zeroState.value.zeroMap[index]
}

@Composable
fun rememberZeroStateProvider(): ZeroStateProvider {
    val scrollState = rememberLazyListState()
    val zeroState = remember {
        derivedStateOf(structuralEqualityPolicy()) {
            Log.e("StateTest", "calculating zero state for scroll offset: ${scrollState.firstVisibleItemScrollOffset}")
            val zeroMap = mutableMapOf<Int, Boolean>()
            scrollState.layoutInfo.visibleItemsInfo.forEach {
                zeroMap[it.index] = it.offset == 0
            }
            ZeroMap(zeroMap)
        }
    }
    return remember {
        ZeroStateProvider(scrollState, zeroState)
    }
}

@Composable
fun OuterComposable(
    modifier: Modifier = Modifier,
) {
    Log.e("StateTest", "Composing OuterComposable")
    val zeroStateProvider = rememberZeroStateProvider()
    LazyRow(
        state = zeroStateProvider.scrollState,
        horizontalArrangement = Arrangement.spacedBy(60.dp),
        verticalAlignment = Alignment.Top,
        modifier = modifier
            .fillMaxWidth()
    ) {
        items(
            count = 100,
        ) { index ->
            InnerComposable(index, zeroStateProvider)
        }
    }
}

@Composable
private fun InnerComposable(
    index: Int,
    zeroStateProvider: ZeroStateProvider,
    modifier: Modifier = Modifier
) {
    Log.e("StateTest", "Composing InnerComposable (index=$index)")
    val color by remember {
        derivedStateOf(structuralEqualityPolicy()) {
            Log.e("StateTest", "InnerComposable: calculating color")
            when (zeroStateProvider.isAtZero(index)) {
                true -> Color.Red
                false,
                null -> Color.Blue
            }
        }
    }

    Box(
        modifier = modifier
            .background(color)
            .size(200.dp)
    )
}

The output in Compose 1.2.0 gives:

E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 1
E/StateTest: Composing InnerComposable (index=0)
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: Composing InnerComposable (index=4)
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 3
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 5
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 6
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color

and in Compose 1.3.0-beta01 gives:

E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: Composing InnerComposable (index=0)
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 4
E/StateTest: ZeroMap is the same value
E/StateTest: calculating zero state for scroll offset: 5
E/StateTest: ZeroMap is the same value

As you can see from this output, in Compose 1.2.0, calculating zero state for scroll offset only appears once every time the scroll state changes, and then the inner compositions recalculate accordingly. But in Compose 1.3.0-beta01, calculating zero state for scroll offset shows up many times every time the scroll state changes. The number of times it runs increases with the number of composables that use its state.

From the documentation of derivedStateOf, it says "The result of calculation will be cached in such a way that calling [State.value] repeatedly will not cause[calculation] to be executed multiple times". This was true prior to Compose 1.3.0-beta01, but no longer is.

Please let me know what you think. Thanks!

As said I'm not a Googler and your issue is unrelated to the original issue. You really should open another issue.

I'd say that your issue might not be related to derivedstate at all but to the compiler generation of your ZeroStateProvider class.

I'd use https://chris.banes.dev/composable-metrics/ to check if the ZeroStateProvider is seen as stable or not and if that change when you change the compose compiler. (And the impact about other composable stability / skippabe)

Yes, I'm ok with creating a new issue (which I did here: https://issuetracker.google.com/issues/244621257), but I'm sure this is a result of the changes made for this bug.

You can easily bisect the version that introduced the issue. All the fixes for this issue are in 1.2.0. AFAIR the only missing to fix all was https://github.com/androidx/androidx/commit/e82b3518094e5451dd4697f31a412c10075b28c5 but it was not opened and followed due to this issue but for https://issuetracker.google.com/issues/239603305 (But similar result)

Try 1.3 alpha 3 that I use in prod with no performance regression. Then alpha 2 then 1 ;)

It was introduced by https://github.com/androidx/androidx/commit/8bac18a341805fa63ce9190ea7a0206f052e17ee, which went into alpha02. That commit doesn't reference any tracker, nor can I find a PR for it, so not sure how to track it other than that.

Small bump on this to follow from #65

Is this planned to be backported to 1.3?

With Material 3 pinned to 1.3 we can't keep 1.3 A3 and update material. And not sure they will start an 1.1 alpha pinned to 1.4 before a final 1.3 release. (Maybe you have some info about that)

So 1.3 RC1 is cut, is it possible to have some insight on this please? On my app with tons of large lazylist this leads to very fast OOM (even faster than previous issues).

Not having a solution for 1.3 may have high impact on updating M3 / Glance and the sooner we know the easier to anticipate.

1.3-rc01 hasn't been cut yet, though the commit to bump the version to rc is in the system to ready for that build cut

So tested snapshot 9082024 that include this and it seems to be fixed.

And I also see nice scrolling performance on large lists, maybe due to other commits.

The last question is. Are there any commits in 9082024 that won't be part of the final 1.3? Or can I expect the same performance gain in the coming 1.3 releases ?

This bug was linked in a change in the following release(s):

• androidx.compose.ui:ui:1.3.0-rc01

The following release(s) address this bug:

• androidx.compose.runtime:runtime:1.3.0