IssueTracker

Yoinking from triage

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?

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.

Triage: this P1 is nearly out of SLO.

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

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.

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

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

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

Downgrading is not an option for us as we need multiplatform support.

I'm not sure why the above error is happening. It seems to be expecting the file to be created first and then queried.

Is there a timing issue?

Sorry for the delay of responding to this issue, as we've seen similar issues in the other bugs and followed up there. This is hard for us to debug as it seems to be a race condition and we cannot easily reproduce it and understand the root cause. Please help us by providing more details (device populations, API levels, or anything you discover as relevant to the bug distribution) from your observation of its occurrence! Also a sample app to reproduce would be great if possible.

In the meantime, I'll try to do some more investigation with the given information. Thanks for your patience.

It does not seem to be limited to a specific API, I see logs on API 10 to 15.

These are the errors I see on Crashlytics on a Pixel 8 Pro (unfortunately I have not been able to reproduce locally):

Fatal Exception: java.io.FileNotFoundException: /data/user/0/com.myapp/files/datastore/tracked apps.preferences_pb: open failed: ENOENT (No such file or directory)
       at libcore.io.IoBridge.open(IoBridge.java:574)
       at java.io.FileInputStream.<init>(FileInputStream.java:179)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.java:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:115)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:584)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

Caused by android.system.ErrnoException: open failed: ENOENT (No such file or directory)
       at libcore.io.Linux.open(Linux.java)
       at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
       at libcore.io.BlockGuardOs.open(BlockGuardOs.java:274)
       at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
       at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:8591)
       at libcore.io.IoBridge.open(IoBridge.java:560)
       at java.io.FileInputStream.<init>(FileInputStream.java:179)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.java:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:115)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:584)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

I've also been seeing this since updating from 1.0.0 (problem exists in both 1.1.0 and 1.1.1) and so I had to downgrade to 1.0.0 to avoid these crashes.

Has anyone tried: https://developer.android.com/topic/libraries/architecture/datastore?hl=en#handle-file-corruption ? Does it help?

UPDATE: no it doesn't help

Hi there - we were able to reproduce the issue on our end, a fix is in the works. I'll update here once we have it merged & ready for release.

This issue should be fixed for the upcoming 1.1.3 release. Please let us know if the issue persists after the release.

Project: platform/frameworks/support
Branch: androidx-main
Author: elifbilgin <elifbilgin@google.com>
Link:      https://android-review.googlesource.com/3496412

Resolve FileNotFoundException issue in OkioStorage at startup.

Resolve FileNotFoundException issue in OkioStorage at startup. 
 
This change introduces a second attempt at reading a file in OkioStorage `readData()`, in case the initial read attempt failed due to a race condition caused by in the file being created by a different process. 
 
Bug: 337870543 
Test: Tested locally via aosp/3496411. 
Change-Id: I43b3fb565cc76344bc14c7dc3964ff76b2319358

still present in 1.1.2

only present on Android/JVM no problem on iOS

Thanks for the update regarding the platform specific behavior, we are still working on pinpointing the issue

kikoski@protonmail.com Could you share some info on how you are initializing/setting up your datastore?

Apologies, this issue is resolved and the fix will be available in 1.1.3