Fixed

Feature

Status Update

No update yet.

Description

mg...@google.com

created issue #1

Feb 28, 2025 11:36AM

JetBrains has asked if we could support a get*OrNull() variant for our methods. The current get*OrElse() does not allow returning null, and checking isNull beforehand is both unnecessary and inefficient.

With AOSP/3500556 change to reduce excessive inlining, we plan to move from inline to non-inline functions, as benchmarks show minimal performance impact. This works well for get* functions, but get*OrElse() would allocate lambdas if we don't use inline, which we don't want to.

Here are the options before the beta:

Option 1: Do not support get*OrNull().
- Downsides: (1) checking for isNull and contains before a get runs at 60ns instead of 20ns and (2) wouldn’t be able to remove inline from get*OrElse() due to lambda allocations.
Option 2a: Support get*OrNull(), which also allows migrating get*OrElse() out of inline functions.
- The final API would look like this:

fun getOrNull(key): T?  
fun get(key): T = getOrNull() ?: throw  
fun inline getOrElse(key, else): T = getOrNull() ?: else() // avoids lambda allocation

Option 2b: Same as option 2a, but we remove get*OrElse() since users can simply call getOrNull() ?: else().
- Downside: JetBrains has already migrated their navigation fork to use get*OrElse(), so this would require extra work on their side.

getOrNull() seems useful, and Bundle always boxes primitives anyway, since everything is stored in a Map<K, V>.

Edit 03.03.25:

Option 3: Same as Option 2b (including downsides), but without the non-nullable variant. We keep only get*(), and change to return a @Nullable value.
- Advantage: (1) Consistent with Kotlin's generic collections get function (Map). (2) Reduces API surface by half.
- Downside: (1) It's disruptive, requiring changes to all usages. (2) SavedState is a specialized Map, not a general-purpose one, so if an ACTION_FOO expects EXTRA_FOO_ARG1 and EXTRA_FOO_ARG2, their absence means execution can't proceed. Throwing an error for a missing key is (arguably) reasonable, while get*OrNull()/get*OrElse() provide an explicit opt-out mechanism for cases where a null or default value is acceptable.

Comments

ku...@google.com <ku...@google.com> #2Feb 28, 2025 12:02PM

Yoinking from triage

Message last modified on Feb 28, 2025 02:16PM

ku...@google.com <ku...@google.com> #3Feb 28, 2025 12:17PM

Thanks for taking the time to file this issue!

Would you be able to provide more details about the scene and this error? I tried the following code:

@Preview
@Composable
fun AutofillTextField3() {
    var password by remember { mutableStateOf("") }
    val focusRequester = remember { FocusRequester() }

    LaunchedEffect(Unit) {
        focusRequester.requestFocus()
    }

    Column(Modifier.fillMaxWidth()) {
        Text("Enter password")
        TextField(
            value = password,
            onValueChange = { password = it },
            modifier = Modifier
                .fillMaxWidth()
                .focusRequester(focusRequester)
                .semantics { contentType = ContentType.Password },
            label = { Text("password") },
            placeholder = { Text("type your password here") }
        )
    }
}

but upon the app starting, Autofill displayed the suggestion chips along the keyboard for me. Verified that this is the case for BTF as well.

Were you specifically using the Password content type? The only way I was able to reproduce this was if the same code above instead had ContentType.NewUsername set. In that case, you’re right—when the app starts, no suggestions are displayed. Only long-pressing and triggering autofill from the textbar menu displays the suggestions. I believe that is working as intended (as that is a field marked for new users and thus should not display previously saved data).

Are there any other details in the sample above that are missing?

Message last modified on Feb 28, 2025 02:16PM

ku...@google.com <ku...@google.com> #4Mar 3, 2025 10:19AM

Hi, thanks for the quick reply.
I think what I need to add to clarify is that the password fails to autocomplete when it's on another screen than the username field is. That seems to be the culprit.

I created a minimal example project which demonstrates this and also captured a video of the app running. From it you can see that the autofill chips appear briefly when navigating to the password screen. However, they disappear a moment after when the focus is requested.

Let me know if I can help providing any other information.

ko...@jetbrains.com <ko...@jetbrains.com> #5Mar 3, 2025 12:54PM

Ah, I see what you're saying — thanks for the video and code! It seems like there’s two parts to this.

You mean that in a multi-page login, you would expect after selecting a credential chip, Autofill should fill in not only the first “username” on the first screen, but also “password” on the next screen. I believe this is working as intended. On the Compose side, it looks like we’re properly calling the autofill APIs. Looping in Kate from the autofill team to check: Kate, I double checked this with FormGen, and there’s the same behavior here (internal link) as the Compose sample here (internal link). So I assume we can’t expect filling on multi-page logins, and the user must reselect a chip for each page.

The second part is that even if the password field is not immediately filled, the chips disappear after a second of being displayed. Unfortunately I was not able to reproduce this even running the sample code locally ― but I do notice that clicking the displayed chips on the password page does not autofill. Only after clicking autofill in the text toolbar does selecting the chip actually invoke autofill. If the focusRequester is removed from the code, then autofill works fine.

Seems like Compose is still properly sending the requested information over and calling the right APIs. I see that in both instances (in the working version without focusRequester plus the one without it), Compose is calling notifyViewEntered for the password screen, and then populateViewStructure is called. But tapping onto the chip in the version with focusRequester does not trigger autofill (whereas it does without focusRequester). I glanced over the semantic properties we send, and they look identical between both text fields.

I’m attaching some logs for the working version here (internal link) vs non-working version here (internal link), plus a video of the sample with text toolbar autofill vs focus autofill to the comment. Kate, do you think you could take a quick look? We can also chat about this async.

Message last modified on Mar 3, 2025 12:54PM

mg...@google.com <mg...@google.com> #6Mar 3, 2025 10:13PM

Accepted by mg...@google.com.

Thanks, yes, the issue is only about the second part, I'm aware I can't expect a single autofill request to work across screens.

Correct, without focusRequester, tapping into the input field correctly populates the suggestion chips. With the focusRequester in place however, autofill chips appear but are immediately removed as shown on the video (probably due to the requested focus).

Thanks for looking into this.

Message last modified on Mar 4, 2025 12:18PM

ap...@google.com <ap...@google.com> #7Mar 5, 2025 11:06PM

Triage: this P1 is nearly out of SLO.

mnuzen@google.com skxu@google.com Is any of you working on it? Thanks!

ap...@google.com <ap...@google.com> #8Mar 5, 2025 11:06PM

Thanks soboleva@google.com, yes, I'm taking a look! I have a WIP CL up that I started before OOO, going to finish this this week.

ap...@google.com <ap...@google.com> #9Mar 5, 2025 11:06PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Melba Nuzen <mnuzen@google.com>
Link: https://android-review.googlesource.com/3506413

Only trigger commit when no autofillable components onscreen

Expand for full commit details

Only trigger `commit` when no autofillable components onscreen 
 
Fixes: 392539099 
Test: `autofillManager_doNotCallCommit_partialRemoval` and others 
 
Autocommit will only be invoked when there are no autofillable components currently displayed and when there were previously autofillable components onscreen. This prevents overeagerly calling `commit` in scenarios such as multipage logins. If developers need a session to be committed, they can still explicitly call `autofillManager.commit()` where needed. 
 
Change-Id: Ic9ed6f9951163da3c39f31a771435eca14a8859a

Files:

M compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/UiDemos.kt
A compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/autofill/MultiPageLoginDemo.kt
M compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/autofill/AndroidAutofillManagerTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/autofill/AndroidAutofillManager.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/autofill/AutofillUtils.android.kt

Hash: df2e791d1f2e01554961745cbb5cfcfb23b699a9
Date: Mon Feb 24 10:12:52 2025

ap...@google.com <ap...@google.com> #10Mar 5, 2025 11:06PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.compose.ui:ui:1.8.0-rc01
androidx.compose.ui:ui-android:1.8.0-rc01
androidx.compose.ui:ui-jvmstubs:1.8.0-rc01
androidx.compose.ui:ui-linuxx64stubs:1.8.0-rc01

ap...@google.com <ap...@google.com> #11Mar 5, 2025 11:06PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <mgalhardo@google.com>
Link: https://android-review.googlesource.com/3523152

Remove getOrElse in SavedStateReader

Expand for full commit details

Remove `getOrElse` in `SavedStateReader` 
 
- Because `getOrNull()` is now available, users can achieve the same behavior with `getOrNull() ?: else()`, allowing us to reduce the public API surface and the number of inline methods (as `getOrElse` takes a lambda, it cannot be removed). 
 
RelNote: "Remove `getOrElse` from `SavedStateReader` in favor of `getOrNull() ?: else()`." 
Bug: 399820614 
Test: SavedStateTest 
Change-Id: I87317b0eaa0f6d0fad334cc3f81bfcc8a90e6313

Files:

M lifecycle/lifecycle-viewmodel-savedstate/src/commonMain/kotlin/androidx/lifecycle/SavedStateHandleSupport.kt
M savedstate/savedstate/api/current.txt
M savedstate/savedstate/api/restricted_current.txt
M savedstate/savedstate/bcv/native/current.txt
M savedstate/savedstate/src/androidMain/kotlin/androidx/savedstate/Recreator.android.kt
M savedstate/savedstate/src/androidMain/kotlin/androidx/savedstate/SavedStateReader.android.kt
M savedstate/savedstate/src/androidUnitTest/kotlin/androidx/savedstate/SavedStateAndroidTest.android.kt
M savedstate/savedstate/src/commonMain/kotlin/androidx/savedstate/SavedStateReader.kt
M savedstate/savedstate/src/commonTest/kotlin/androidx/savedstate/SavedStateTest.kt
M savedstate/savedstate/src/nonAndroidMain/kotlin/androidx/savedstate/SavedStateReader.nonAndroid.kt

Hash: e04b610835745492aa66aa45be1426d57c1401b6
Date: Mon Mar 03 23:42:23 2025

ap...@google.com <ap...@google.com> #12Mar 5, 2025 11:06PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <mgalhardo@google.com>
Link: https://android-review.googlesource.com/3523155

Add non-reified get collections in SavedStateReader

Expand for full commit details

Add non-reified `get` collections in `SavedStateReader` 
 
- Previously, retrieving a typed collection required a `reified` method, restricting its usage at runtime. 
- Introducing a non-reified variant allows clients to call it with a dynamic type. 
- This change also enables code encapsulation by reducing inlined code, with the reified method simply delegating to the non-reified one. 
 
RelNote: "Add non-reified methods for `get` collections in `SavedStateReader`." 
Bug: 399820614 
Test: N/A 
Change-Id: I0b641cba421761ee41bb8dc386cbc5db7cb67066

Files:

M savedstate/savedstate/api/current.txt
M savedstate/savedstate/api/restricted_current.txt
M savedstate/savedstate/src/androidMain/kotlin/androidx/savedstate/SavedStateReader.android.kt
M savedstate/savedstate/src/androidUnitTest/kotlin/androidx/savedstate/SavedStateAndroidTest.android.kt
M savedstate/savedstate/src/nonAndroidMain/kotlin/androidx/savedstate/SavedStateReader.nonAndroid.kt

Hash: 481a2c575f9c2c3a71e99cf61f093d079d69e1bc
Date: Tue Mar 04 10:55:25 2025

ap...@google.com <ap...@google.com> #13Mar 5, 2025 11:18PM

Android API Change

This bug was referenced by a recent CL that changed the Android API surface area.

The Android API Council regularly reviews API changes for consistency and sustainability, and we've just added this bug to our hotlist of pending reviews.

We'll wait until you mark this bug as 'Fixed' before starting our review, but please reach out if you'd like us to review it sooner.

Changes to savedstate/savedstate/api/current.txt

androidx.savedstate
androidx.savedstate.SavedStateReader

http://go/agw/platform/frameworks/support/+/481a2c575f9c2c3a71e99cf61f093d079d69e1bc%5E%21
https://android-review.googlesource.com/3523155

[Gerrit:https://android-review.googlesource.com/3523155]
[API-Approvers:ilake@google.com]
[Branch:androidx-main]

[LIBRARY_API_REVIEW_TAG:savedstate/savedstate/api/current.txt]

ap...@google.com <ap...@google.com> #14Mar 5, 2025 11:18PM

Android API Change

This bug was referenced by a recent CL that changed the Android API surface area.

The Android API Council regularly reviews API changes for consistency and sustainability, and we've just added this bug to our hotlist of pending reviews.

We'll wait until you mark this bug as 'Fixed' before starting our review, but please reach out if you'd like us to review it sooner.

Changes to savedstate/savedstate/api/current.txt

androidx.savedstate
androidx.savedstate.SavedStateReader
androidx.savedstate.SavedStateWriter

http://go/agw/platform/frameworks/support/+/f09d0e201cae0bbbc77e28b0ecf6245425d65da6%5E%21
https://android-review.googlesource.com/3523153

[Gerrit:https://android-review.googlesource.com/3523153]
[API-Approvers:ilake@google.com]
[Branch:androidx-main]

[LIBRARY_API_REVIEW_TAG:savedstate/savedstate/api/current.txt]

ap...@google.com <ap...@google.com> #15Mar 5, 2025 11:18PM

Android API Change

This bug was referenced by a recent CL that changed the Android API surface area.

The Android API Council regularly reviews API changes for consistency and sustainability, and we've just added this bug to our hotlist of pending reviews.

We'll wait until you mark this bug as 'Fixed' before starting our review, but please reach out if you'd like us to review it sooner.

Changes to savedstate/savedstate/api/current.txt

androidx.savedstate
androidx.savedstate.SavedStateReader

http://go/agw/platform/frameworks/support/+/e04b610835745492aa66aa45be1426d57c1401b6%5E%21
https://android-review.googlesource.com/3523152

[Gerrit:https://android-review.googlesource.com/3523152]
[API-Approvers:ilake@google.com]
[Branch:androidx-main]

[LIBRARY_API_REVIEW_TAG:savedstate/savedstate/api/current.txt]

ap...@google.com <ap...@google.com> #16Mar 5, 2025 11:18PM

Android API Change

This bug was referenced by a recent CL that changed the Android API surface area.

The Android API Council regularly reviews API changes for consistency and sustainability, and we've just added this bug to our hotlist of pending reviews.

We'll wait until you mark this bug as 'Fixed' before starting our review, but please reach out if you'd like us to review it sooner.

Changes to savedstate/savedstate/api/current.txt

androidx.savedstate
androidx.savedstate.SavedStateReader

http://go/agw/platform/frameworks/support/+/cd71b1c721a8cf9733aed3bea5361f528011641c%5E%21
https://android-review.googlesource.com/3523151

[Gerrit:https://android-review.googlesource.com/3523151]
[API-Approvers:ilake@google.com]
[Branch:androidx-main]

[LIBRARY_API_REVIEW_TAG:savedstate/savedstate/api/current.txt]

mg...@google.com <mg...@google.com> Mar 6, 2025 02:56PM

Marked as fixed.

na...@google.com <na...@google.com> #17Mar 12, 2025 06:13PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.lifecycle:lifecycle-viewmodel-savedstate:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-android:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-desktop:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-iosarm64:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-iossimulatorarm64:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-iosx64:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-linuxarm64:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-linuxx64:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-macosarm64:2.9.0-alpha12
androidx.lifecycle:lifecycle-viewmodel-savedstate-macosx64:2.9.0-alpha12
androidx.navigation:navigation-common:2.9.0-alpha08
androidx.navigation:navigation-common-android:2.9.0-alpha08
androidx.navigation:navigation-common-desktop:2.9.0-alpha08
androidx.navigation:navigation-common-iosarm64:2.9.0-alpha08
androidx.navigation:navigation-common-iossimulatorarm64:2.9.0-alpha08
androidx.navigation:navigation-common-iosx64:2.9.0-alpha08
androidx.navigation:navigation-common-linuxarm64:2.9.0-alpha08
androidx.navigation:navigation-common-linuxx64:2.9.0-alpha08
androidx.navigation:navigation-common-macosarm64:2.9.0-alpha08
androidx.navigation:navigation-common-macosx64:2.9.0-alpha08
androidx.navigation:navigation-runtime:2.9.0-alpha08
androidx.navigation:navigation-runtime-android:2.9.0-alpha08
androidx.navigation:navigation-runtime-desktop:2.9.0-alpha08
androidx.navigation:navigation-runtime-iosarm64:2.9.0-alpha08
androidx.navigation:navigation-runtime-iossimulatorarm64:2.9.0-alpha08
androidx.navigation:navigation-runtime-iosx64:2.9.0-alpha08
androidx.navigation:navigation-runtime-linuxarm64:2.9.0-alpha08
androidx.navigation:navigation-runtime-linuxx64:2.9.0-alpha08
androidx.navigation:navigation-runtime-macosarm64:2.9.0-alpha08
androidx.navigation:navigation-runtime-macosx64:2.9.0-alpha08
androidx.savedstate:savedstate:1.3.0-alpha10
androidx.savedstate:savedstate-android:1.3.0-alpha10
androidx.savedstate:savedstate-desktop:1.3.0-alpha10
androidx.savedstate:savedstate-iosx64:1.3.0-alpha10
androidx.savedstate:savedstate-linuxarm64:1.3.0-alpha10
androidx.savedstate:savedstate-linuxx64:1.3.0-alpha10
androidx.savedstate:savedstate-macosarm64:1.3.0-alpha10
androidx.savedstate:savedstate-macosx64:1.3.0-alpha10

IssueTracker

Add `get*OrNull()` to `SavedStateReader`

Status Update

Description

Comments

ku...@google.com <ku...@google.com> #2Feb 28, 2025 12:02PM

ku...@google.com <ku...@google.com> #3Feb 28, 2025 12:17PM

ku...@google.com <ku...@google.com> #4Mar 3, 2025 10:19AM

ko...@jetbrains.com <ko...@jetbrains.com> #5Mar 3, 2025 12:54PM

mg...@google.com <mg...@google.com> #6Mar 3, 2025 10:13PM

ap...@google.com <ap...@google.com> #7Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #8Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #9Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #10Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #11Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #12Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #13Mar 5, 2025 11:18PM

Android API Change

ap...@google.com <ap...@google.com> #14Mar 5, 2025 11:18PM

Android API Change

ap...@google.com <ap...@google.com> #15Mar 5, 2025 11:18PM

Android API Change

ap...@google.com <ap...@google.com> #16Mar 5, 2025 11:18PM

Android API Change

mg...@google.com <mg...@google.com> Mar 6, 2025 02:56PM

na...@google.com <na...@google.com> #17Mar 12, 2025 06:13PM

Issue 399820614

Description

Issue summary

Comments

ku...@google.com <ku...@google.com> #2Feb 28, 2025 12:02PM

ku...@google.com <ku...@google.com> #3Feb 28, 2025 12:17PM

ku...@google.com <ku...@google.com> #4Mar 3, 2025 10:19AM

ko...@jetbrains.com <ko...@jetbrains.com> #5Mar 3, 2025 12:54PM

mg...@google.com <mg...@google.com> #6Mar 3, 2025 10:13PM

ap...@google.com <ap...@google.com> #7Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #8Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #9Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #10Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #11Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #12Mar 5, 2025 11:06PM

ap...@google.com <ap...@google.com> #13Mar 5, 2025 11:18PM

Android API Change

ap...@google.com <ap...@google.com> #14Mar 5, 2025 11:18PM

Android API Change

ap...@google.com <ap...@google.com> #15Mar 5, 2025 11:18PM

Android API Change

ap...@google.com <ap...@google.com> #16Mar 5, 2025 11:18PM

Android API Change

mg...@google.com <mg...@google.com> Mar 6, 2025 02:56PM

na...@google.com <na...@google.com> #17Mar 12, 2025 06:13PM

Add comment

Issue metadata