I use the OpenVPN Android app with a private key that requires a password to unlock. The key is stored in the Kee Vault app (v1.1.4, build 53).
When I click to connect to the VPN, the password prompt is shown, and the field is auto-focused, but the autofill option isn’t shown until I type something into the field. Typically this means that I have already switched to Kee Vault and copied the password manually from there.
It would be nice if the autofill option was immediately shown. I’m not sure if that’s something that can be handled on this side, or would require changes to the OpenVPN app instead.
I don’t have an openvpn file at the moment for reproducing this but I wonder if you see the same behaviour with the Password field within the “Proxies > Add Proxy” screen? (you might want to create a test entry in your vault with a fake password to test this).
I’ll be looking into a couple of recent Android autofill compatibility issues in the coming weeks so can hopefully narrow down the source of this specific problem soon.
On the Add Proxy page the behaviour is similar: the autofill prompt shows up when I manually focus a field (it is shown for every field on the page), but the first field which is auto-focused doesn’t show anything until I blur and refocus, or enter some text.
The difference between this page and the private key one is that the form has multiple fields; on the private key page I haven’t found a way to trigger the autofill without typing something, since there are no other focusable fields.
Thanks. I will investigate whether there is anything we can do to trigger the autofill sooner. I suspect the answer will be that Android does not even initiate the autofill request so there would be nothing we can do. However, there is a secret new version of Autofill in Android 13 which might behave differently. Unfortunately Google have not documented it so perhaps it is only usable by their own apps and password managers. It might take a while for me to understand if implementing support for that new API is worthwhile for this issue or as a more general improved autofill experience.
On my Android 13 phone (Samsung) using Kee Vault build 53, the autofill button occasionally pops up automatically as soon as that first form field is focussed (Proxy friendly name) and the autofill appears to work correctly when I click on it. This suggests a race condition somewhere within the interface between the OpenVPN app and Android. An early guess would be that Android starts the Autofill request procedure but OpenVPN does something soon afterwards which causes it to be cancelled before Kee Vault has had a chance to receive and process the request. Depending on “factors” Android might not always get around to starting the autofill request until after OpenVPN has completed whatever field/focus task would otherwise cause it to be cancelled.
On my phone and the Android 13 emulator (which has so far not worked automatically at any time) I find that clicking on the initially focussed field brings up the autofill button. I don’t need to unfocus and refocus the field or type anything. So if you’ve not tried tapping on the field already, give that a try.
Another thing you could try is long-pressing on the field to bring up the usual context menu and then click on the AutoFill option to force an autofill - this might be hidden behind the 3-dots overflow menu button.
On a form/screen containing a password field that should work already but in the next version of Kee Vault I will allow this manual action to perform an autofill even if no password field is present.
It does seem to be some kind of race condition, because on a few occasions it’s displayed the autofill button directly without any interaction required.
I gave this a try and I got a “toast” at the bottom of the screen “Contents can’t be auto-filled”. So I guess that the field isn’t registered as auto-fillable in time, or something like that? Completely guessing!
I’ve investigated the initial automatic behaviour some more and haven’t yet seen any evidence that Android is trying to send a request for Autofill to occur. So it looks likely that there is a problem with the OpenVPN app or Android, rather than the registered autofill service (Kee Vault). However, one possibility I can’t yet rule out is if Android is for some reason choosing not to send the autofill request because it has determined that Kee Vault has previously crashed or been so slow for an earlier autofill request that it is not worth sending the request that time. I don’t think that’s very likely but also am not sure how I can definitively rule it out. On a similar note, Android may be sending so much data that we exceed available memory and crash before being able to log the first “request received” message.
I’ve also found out that “Contents can’t be auto-filled” is the message Android displays when the registered autofill service returns null after being asked to fill a form. Quite possibly because some critical information is not reaching Kee Vault so we have to abort.
I am also trying to develop a way to log all the autofill behaviour in a way that can be shared from any device. At the moment the only way to see what is going on in that isolated thread is to connect to a device and monitor its debug log (logcat) which is entirely useless for just about everybody except me. It’ll be a while before I can be sure that this will be possible but hopefully will mean that we could eventually learn more about what is causing the service to return null when you manually request the autofill to occur. That might even shed some light on the state of the app when it first loads and therefore help confirming/reporting any related bug in OpenVPN or Android.
In the mean time, maybe try the manual request again from time to time in case it works often enough to be worth persevering.
Another potential workaround might be to manually hide the keyboard and then click on the field again.
My latest best theory is that the OpenVPN app contains some buggy asynchronous logic relating to focus (of form fields and/or the app itself, not sure which). This is leading to a situation where:
the form field that Android would typically identify as a candidate for autofill does not exist early enough, or it is removed before Android assesses which form fields exist and need to be forwarded to Kee Vault, or the change to form field components causes an internal crash in the Android autofill service such that it never gets around to notifying Kee Vault.
even if one forces the autofill process to begin (using the long-press context menu) the form field which Kee Vault decides to fill has been deleted and replaced with a different field by the time the response gets back to the app.
I’m also working on an extra approach to potentially fix this issue, or at least give us some extra data to help with further diagnosis. In the next version of Kee Vault we’ll be able to enable a slight change to how the Android Autofill system works.
Using the emulator I still find that this “autofill within your keyboard” feature introduced in Android 11 is too buggy to be useful but some early tests indicate it is a bit more reliable on real devices, at least if we ignore the show-stopping bugs in Android 11. I’ll be enabling it on Android 12+ only and including an option to disable the new behaviour if it’s too annoying with certain devices / keyboards. It requires support from your keyboard software but most common keyboards have enabled the feature by now.
Along with a new log export feature and the logging of autofill behaviour (enabled by an option) I hope that build 54 will at least tell us something new about what is going on with the OpenVPN app, and maybe offer some new workarounds or a complete fix. That version is available for Beta testing on Google Play (and iOS TestFlight) now.
Further down the line, there are a couple of additional improvements possible for Android 14. One is essentially undocumented but from the API name I guess that there is a chance that it will help in situations like the OpenVPN app where they delete autofilled fields part-way through the autofill process.
The other - Credential Manager (including Passkeys) - definitely needs support from the apps/browsers themselves but hopefully there will be a switch over to that new system in the next few years. Not really my area of expertise but hopefully OpenVPN and other VPN providers are already thinking about how they could use Passkeys to make setup and use of VPNs easier in future, although any improvements from that may need changes to the OpenVPN server as well as the client apps so I won’t hold my breath.
If you get a chance to test out the new beta version I’ll be interested to hear if any of the changes help make submitting this password to OpenVPN easier.