Search field into the in-app filling window

guillaumesertonguillaumeserton Junior Member
edited November 2014 in Android Beta

Hello, i'm juste playing with the in-app filling after having upgraded my nexus 7. It's an awesome feature !

But, can we have a search field into this window because on some app my correct credential is not detected and i have to search them?

Is there a kind of learning curve for the filling?
I mean for some app it's a Web Apps, so my Web credential is well recognized but when it's not the case we have to creates new credentials.



  • mverdemverde

    Team Member

    Hi @Spinacle‌,

    I'm glad that you are enjoying testing our in-app filling beta! You're not alone in requesting that we add a search field to the filling interface. I will pass this request on to our development team!

    I'm not sure what you mean by learning curve when it comes to filling. Could you give me an example of what you are referring to? Thanks!

  • guillaumesertonguillaumeserton Junior Member

    Learning curve, i thought to an artificial intelligence into 1P :smile:

  • mverdemverde

    Team Member

    While we don't implement any formal learning algorithms in 1Password, we do try to program our login filling to be as smart as possible. And of course, a lot of that smarts is informed by feedback that we get from our beta testers and customers. So in a way, it's artificial intelligence without the "artificial" :smiley:

  • johan98johan98
    edited November 2014

    It would be great if 1Password could recognize which login belongs to the current app by using the package name (for example a website named "" could have an app with package name "com.websitename.appname") and/or the app name. I haven't found any app yet where the in-app filling directly finds the correct login to use (except when using websites in the browser).

  • mverdemverde

    Team Member

    @johan98‌ You may be surprised to learn that this is precisely the approach that we take. When we identify login fields for a given app, we also obtain the package name for that app. From this package name, we apply the reverse domain name convention to try to generate a domain name by which to locate appropriate logins.

    For example, the package name for the official Twitter app on Android is Applying the reverse domain name convention to this package name to get a domain of We then strip this down to a base domain of This will then match to any logins which have for a URL domain.

    While this approach generally works well (as most developers seem to follow the reverse domain name convention), it doesn't adequately account for third-party apps. Referring back to my example of Twitter, if third-party developers follow the reverse domain name convention for package names, then the domain that we generate will not match the domain for your Twitter login.

    While this is a limitation of the current beta, our development team is aware of the issue and they are working on a couple of different approaches that will remedy the issue in future releases. Stay tuned for improvements in this area in future iterations of the beta.

  • Oh, I didn't notice that that's already how it works. I'll try with the Twitter app.

  • mverdemverde

    Team Member

    @johan98‌ Did you have any troubles with in-app filling finding the correct Twitter login with the official Twitter app? Definitely let me know if you are seeing issues here as well. Thanks for the feedback!

  • No, it worked with the Twitter app. Probably I just didn't try it before with apps that comply to the "domain name backwards" convention.

  • mverdemverde

    Team Member

    I'm glad to hear that it worked just fine for you. We're working on expanding this so that we're not as dependent upon this convention. Stay tuned for improvements in this area!

This discussion has been closed.