google smartlockpasswords - Testing Smart Lock for Passwords app integration

Question

I’ve implemented Smart Lock for Passwords in my app. What are some common scenarios and UX flows that I should test out?

Answer 1

Here’s a guide to test Smart Lock for Passwords functionality in an app. If you have a website, associate your app and site to test those cases. Also check out the developer integration guide.

Check what's saved for the current Google Account at passwords.google.com. Entries are shown under the website domain or Android package/app name, delete any entries to start over.

1. Auto sign-in when app starts and a single saved entry exists. This is the recommended UX pattern to seamlessly transition between devices and help users complete transactions and pick up their experience where they left off last time. Sign-In UI should be disabled or hidden until the API call is complete, and do not call the API if you already have a signed-in user.

2. Sign-up with a password in the app, check for a hints dialog to help fill the sign-up form fields such as name and email, and check for a save prompt, select "Save password".

3. Auto sign-in after reinstalling app (or clearing app data). Show prompt for multiple credentials if something was already saved or auto sign-in is disabled.

4. Regular sign-in after deleting any saved passwords at passwords.google.com, save the existing account credentials when prompted.

5. Sign-out and app should call disableAutoSignIn. When user returns to the sign-in activity / UI, call the API and to help sign back in or switch between accounts easily (app should resolve an intent to show a picker dialog), without automatically signing the user back in.

6. Password update in the app should save the change (app should just call save API), but UI won't be needed for password updates). Check passwords.google.com for the updated password.

7. Multiple accounts after sign-up for a different second account on the web, reinstall app and see if both saved entries are offered for sign-in via a picker dialog.

8. Wrong stored password: You can save a wrong password in Chrome by running the following in the console on your login domain: navigator.credentials.store(new PasswordCredential({id: 'user@example.com', password: 'wrongpassword'})). Then test retrieving this in the app, which could either prompt user to correct the password and save the new one, or delete an invalid credential so user doesn't get stuck in this state.

9. Web auto-fill when visiting the https website in Chrome, check that passwords saved on Android are available to fill in the website password field (they should also should show in chrome://settings/passwords).

10. IDP sign-in after deleting saved password entries, sign in/up to the app with Facebook etc, and may prompt to "Save account". Reinstall to see auto sign-in UX (i.e., the app may automatically "click" the appropriate button for the user or customize their sign-in screen to the returning user). The same for Google Sign-In, but no save prompt is shown, will save automatically to the appropriate Google account, see example use of silentSignIn.

Keep in mind that if you tap the "Never" button on a save dialog, it will add the app to the Never save list in Settings > Google > Smart Lock for Passwords for all accounts on the device and the save prompt will not be shown again (API error message "The current app is blacklisted"). You will need to remove the app from the Never save list for all accounts on the device to see the save prompt again.

Also note that Android credentials are affiliated to the signature and package of the app in which they were saved, in case you sign your app with multiple debug or release keystores during development.