First of all, thank you for being part of our beta family! Your feedback on design, usability, and functionality is a critical part of our development process. We especially appreciate that you're willing to bear with the occasional bug and having implementation details change under your feet in order to help us test new features as we develop them. Given that we just made a significant change to our filling feature midway through development and testing, you may be wondering why, so I'll do my best to explain some of the thinking that informed this change.
In order to understand why we changed our approach to filling, it's important to first take a look at our overall goal. We want to provide you with a filling solution that offers a balanced blend of convenience and security. As we have stated publicly, we do not believe that any such solution can include using the clipboard and still make a serious claim to security.
With the goal above in mind, we originally set about to create a filling solution that would allow our customers to fill logins without using the clipboard. We evaluated a number of different approaches, but in the end there were only two that offered us the ability to fill text into other apps and browsers. We could either create a custom keyboard or we could implement an accessibility service.
Given that many Android users opt to install third-party keyboards in order to have specific functionality, our preference was to avoid creating a custom keyboard if possible. So we set about developing our filling feature using Android's accessibility service framework. This approach showed a lot of promise initially. In short order, we were able to fill logins into third-party apps and into Chrome with a moderate level of success and we were able to do it without using the clipboard.
At this point we published our first beta including the filling feature, with the intent that we would continue to incrementally improve our ability to detect and fill logins with the help of your feedback. Unfortunately, as we continued to investigate issues that you brought to our attention, we became increasingly aware that some of these issues looked to be insurmountable.
We received a lot of feedback about the fact that our filling implementation was Lollipop-only. While this was done in service of our goal of eliminating the need to use the clipboard, it meant that the majority of our current customers couldn't use it, and were thus stuck using the keyboard anyway.
This is a big deal as the group of apps that use web-based logins includes a wide variety of apps that span a number of categories including finance, gaming, and social media among several others. In fact, based on anecdotal evidence from our testing and your feedback, it seems that more apps use web-based login interfaces than native login interfaces. This meant that our customers would again be forced to use the clipboard in order to fill their login information into many of their favourite apps.
Whenever the 1Password filling interface was displayed, it would effectively interfere with normal system navigation using the home and overview (recents) buttons. Technical limitations prevented us from detecting taps on those two buttons, which in turn meant that the filling interface wasn't dismissed at the appropriate time. This created a confusing and undesirable user experience.
In addition to the major issues above, there were a number of minor issues with the previous approach. Taken together, these issues presented a major obstacle to continuing development of our filling feature. We were faced with the prospective of releasing a feature with significant limitations and little prospect of improvement. At this point, the challenges of pursuing a keyboard-based approach began to pale in comparison to the obstacles we had encountered with our accessibility service.
Changing our filling implementation to be based on a custom keyboard brings us much closer to our goal of eliminating the need to fill logins using the clipboard. In theory, this implementation should allow you to fill your logins anywhere on your device. In practice, I'm sure that there are still some bugs to work out. While these bugs may temporarily prevent filling from working in a few specific situations, this keyboard-based approach shouldn't face the kind of technical limitations that the previous approach was subject to.
The current implementation of our filling feature uses a custom keyboard that is optionally paired with an accessibility service. In addition to the usual responsibilities of typing text, our custom keyboard is responsible for launching the 1Password filling interface. This is done by tapping or long-pressing (depending on the context) on the 1Password icon to the left of the space bar in our custom keyboard. By itself, the keyboard can allow you to unlock your vault, select a login, and then manually fill that login by selecting the appropriate field and then tapping the appropriate button (either "fill username" or "fill password"). With the accessibility service, the keyboard can go a step further and identify the login fields and fill them automatically for you.
For more details on enabling and using our new filling implementation, please take a look at our super-secret filling document in the user guide.
This new filling implementation is still very much in beta. There are a number of improvements to both the keyboard and filling that we have planned and there are a few bugs to be fixed. This is where you come in. With your help in squashing the remaining bugs, we are confident that we can provide an entirely clipboard-free filling experience. Please keep the feedback coming!
The 1Password Android Team