Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #2
Yoinking from triage
go...@passmail.net <go...@passmail.net> #3
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?
go...@passmail.net <go...@passmail.net> #4
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.
ap...@gmail.com <ap...@gmail.com> #5
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
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
Description
When the VPN lockdown is enabled, the
addDisallowedApplication
method has the side effect of causing all the disallowed app traffic to be blocked. This may be unexpected, as one may assume that the disallowed app would be able to normally access the underlying network as it would do in non-lockdown mode. The ability to exclude apps from the VPN is important as some apps are not able to discover local services or detect the LAN IP address when a VPN is in use.Digging into the implementation of the VpnManagerService, I can see that in the context of the VPN lockdown there is the possibility to specify an exemption list, different from the disallowed application list, which allows some apps traffic to ignore the locked-down VPN and access the underlying network. The exemption list can be provided as the
lockdownAllowlist
parameter of theVpnManagerService.setAlwaysOnVpnPackage
method. However, such method can only be accessed via theDevicePolicyManager.setAlwaysOnVpnPackage
API, which requires the app to be a device or profile owner.Assuming that the behavior of
addDisallowedApplication
with the VPN lockdown mode cannot be changed, I propose to add a new API method to the VpnService to allow VPN apps to specify an exemption list of package names which should not go into the VPN but should still be able to access the underlying network and communicate over the Internet.