Google states in the documentation that "when the user signs out, call CredentialsApi.disableAutoSignIn() to prevent the user from being immediately signed back in (...)".
This is what happens:
User only has 1 credential stored. When he enters the app, he is automatically signed in;
User signs out, and CredentialsApi.disableAutoSignIn() is invoked;
Now, every time the user enters the app, instead of being automatically signed in, he is presented with a chooser, although the chooser only has 1 option, for the only credential stored.
This is very, very annoying. If the user logs out, he shouldn't be bothered every time to login again. Even if he has more than 1 credential. But, for the time being, let's focus on the case where he only has 1 credential.
Is this the expected behavior? I'm pretty sure that when I tested this feature in January, it wasn't like this. Now I'm putting this feature into production, and if this is the expected behavior, maybe I have to
store a flag in the shared preferences for detecting when the user logged out.
The request credential feature is in the main activity of the app, and every time I go there, the dialog chooser appears to request the login.
Unfortunately, you'll have to maintain user state in your app (we haven't made any changes to this behaviour recently, it's always been like this).
If sign-in is optional for your app, here's what we've seen some apps implement:
keep track of whether this is the first run on the device (e.g. in shared preferences), if so, trigger sign-in automatically and show the picker, allowing the user to sign in with one tap if the auto sign-in is disabled or they have multiple accounts
on subsequent app starts, you can still try for automatic sign-in (e.g. after user signs up on web or another device and then opens app), but don't resolve the result if it's not the first run (i.e. don't show the picker, just discard the Intent for resolution or hold it for later)
if the user explicit triggers the sign-in action (i.e. clicks a sign-in button), you can use the intent, or call the API again to help them sign back in to their account, or switch between accounts
Sorry, this requires a bit of state on your side; the CredentialsApi.disableAutoSignIn() sets the sign-in disabled state, but does not track the user's signed-in state to the app (which is dependent on the application developer's logic and has to be managed by the app).
Hope that helps / makes sense, feel free to leave comments. Will see if we can add some guidance to the docs for this!
Related
I integrated the In-app Review provided by Google. I followed the documentation exactly as it is written. I hosted the app on Play store for testing, the prompt shows up the first time correctly. But when I click on Not now or Cancel, the prompt didn't show up again on that device.
I tried every possible way of re-installing or by clear cache but no luck.
Can anyone tell me is it the default behavior of In-App review prompt and when it will be visible next in this scenario?
To provide a great user experience, Google Play enforces a time-bound quota on how often a user can be shown the review dialog. Because of this quota, calling the launchReviewFlow method more than once during a short period of time (for example, less than a month) might not always display a dialog.
Because the quota is subject to change, it's important to apply your own logic and target the best possible moment to request a review. For example, you should not have a call-to-action option (such as a button) to trigger the API, as a user might have already hit their quota and the flow won’t be shown, presenting a broken experience to the user. For this use case, redirect the user to the Play Store instead.
Note: The specific value of the quota is an implementation detail, and it can be changed by Google Play without any notice.
Source
I'm working on an app that will be published on the Google Play store when finished. However, my company doesn't want everyone to be able to use the app, so they've requested that I protect it with a password so only our employees can use it. How do I make it so that my app requires a password the first time it starts only?
You could store a shared preference that shows whether the app has been opened or not. The first time the user puts the password in set the flag and then check it in your onCreate method.
Authentication is a very wide subject and I would suggest you start familiarizing yourself with it before starting implementing anything. (just a starting point...)
As for the general idea, You can use Shared Preferences to save a flag that the user has authenticated. Every time your application starts, you check this flag. If the user has never authenticated himself, you present a Login screen.
Once the user gives the proper credentials, you update the flag and indicate that the application shouldn't prompt the user with the Login screen anymore.
The Smart Lock popup dialog just has two buttons, one is "never", and other is "save password". if a user accidentally click "never", the SmartLock will be disabled until he use a chrome app to delete the "never saved password" item, which is way too many steps for a "lazy user" , and it is very likely that this user may not use the SmartLock like forever
In our opinion , if a user doesnt want to save his password to SmartLock just once, its very likely that he will click "never" since the Dialog just has two buttons.... Few of them know if they click anywhere else in the screen they can just dismiss the Dialog.... and once they click never, they lose the chance to enjoy SmartLock ;( So we suggest if google can offer 3 buttons for the Dialog, "never", "no"," save password ", which will be easier for user to understand what they are doing.
I work on the Smart Lock team at Google and we debated the wording of this dialog for months and extensively studied user interaction very carefully in the lab and have sampled millions of user actions on the dialog in live apps and websites to monitor save, decline, and cancel rates. Note that the Never selection is only an opt-out for the app in question and does not affect other unrelated apps.
A few of the findings from user research and feedback:
When asking users in the lab what they might do if they did not want to select either option (Never or Save password), most noted that they would tap outside or tap the back button, which are the established cancel actions in Android UI design patterns. So we did not find an issue with discoverability of the cancel action if strongly preferred.
Adding a third option to the dialog significantly complicates the dialog (both visually and cognitively) and adds substantial confusion and indecision for the user, in that they have to process the difference between Never and No thanks, rather than making a simpler decision between two options.
In practice, we found that user preference to save a password very rarely changed: if user declined once, they would overwhelming choose to decline again if prompted again later, even after some time. In practice, this means that a No thanks (not now) option presented the worst possible outcome: user does not get into the saved credential state (with auto sign-in) and was also repeatedly prompted and interrupted whenever they sign in to the app again.
Thus, the current implementation only presents the two options (Never / Save password, or Save account for non-password credentials) to steer the user toward a decision putting them in a better state, where they are not prompted again for this app, or opt in to benefit from saved information. From the data we've see, the benefit of not continually prompting a user in the common decline case greatly outweighs the lost opportunity to save easily after having declined previously.
But the question does raise a good point that removing an app from the "Never save" list is a lot of steps (it can be done in Chrome settings, passwords.google.com, or Android Google Settings) and might be worth revisiting, especially in the event it was accidentally selected, as noted in question. And if some change in user affinity for saving password data is detected (e.g. user starts opting in to save data for other apps), it might be appropriate to prompt the user to review the apps for which they've opted out.
(Note: one other variation we considered was having "Never save" apply to just the username in question, but that also added a lot of complexity and confusion, and in the studies, the majority intent from users in declining was not to save any password information with Google at all for the app, it was rare that user would have multiple accounts and only want to save one, but not another)
I'm implementing Google Smart Lock into my app. I've got it logging the user in automatically with a single account and it works well.
However, once I add a second account to the mix it always shows the resolution dialog to pick which account I want. This continues to show even after I have selected and account and restarted the app.
This dialog shouldn't show anymore once I have selected the account I want smart lock to use, so what are some possible reasons for it still showing?
-Thank you
I work on the Smart Lock team at Google, hopefully this answers your question:
as you note, if the CredentialsApi.request() API method is called and there are multiple saved accounts for the app, stored in either one or multiple Google Accounts on the device (or auto sign-in has been disabled by the user for one of their accounts or by the developer by calling CredentialsApi.disableAutoSignIn()) then the API will call back with a CredentialRequestResult with getStatusCode() of RESOLUTION_REQUIRED, meaning that UI must be shown for the user to pick a credential to continue. startResolutionForResult() will show the dialog, as described in the API overview.
once the app has a credential, either from auto sign-in or after the user has selected one from the dialog, most apps will use this credential to sign the user in to a backend service and establish a session with a cookie or token for the app and manage this independent of the Smart Lock API. Thus, most apps won't call the API again after the user has signed in and a current session exists, hence the dialog won't be shown again after the initial sign-in.
when the user signs out, calling CredentialsApi.disableAutoSignIn() will prevent the user from being automatically signed back in when the authentication activity is started again, and the disabled state is automatically managed and cleared when the user selects an entry from the credential picker UI or a successful CredentialsApi.save() call is made, and at this point, a user session is established and there is no need to call the API again until a sign-out event.
I think the confusion in this question stems from calling the API after the user has signed in and they might already have an active session. Was that your intent? If you need to manage credentials of the app on the device after a password has been retrieved or input by the user, you can use the Account Manager on Android, which is independent of any Google accounts or APIs (whereas Smart Lock is geared toward saving sign-in info in the cloud for use across platforms on new or separate devices to bootstrap the auth process).
In the future, we are considering remembering a user preference if multiple accounts are stored and the same one is always picked, thereby allowing automatic sign-in, but right now, user action is always required when there are multiple saved accounts available.
Do leave a comment with any questions or feedback if you need more info or clarification or if this doesn't answer your question!
When you have multiple account, you will always show this resolution dialog.
Look this :
from : https://developers.google.com/identity/smartlock-passwords/android/overview
I have incorporated the newer google play game services into my app, and I can see that upon start up of my app, there is an automatic sign in. I was wondering if this could be disabled as I would like to give that option to the user. I have searched the code provided by BaseGameUtils, but I cant see any sign in functions being called anywhere.
Any help would be appreciated!
Thanks :)
As per this issue, auto sign on is the recommended pattern as stated in their best practices video. As they point out in the FAQ (questions 4 and 5):
[4] Why is GameHelper/BaseGameActivity attempting to sign in on
application startup?
The default behavior of BaseGameActivity and GameHelper is to show the user
the sign-in flow (consent dialogs, etc) as soon as your application starts.
Naturally, once the user signs in for the first time, they won't see the
consent flow again, so it will be a seamless experience. It is important
for the user to sign in as early as possible so your application can take
advantage of the Google Play Games API right away (for example, saving the
user's progress using Cloud Save, unlocking achievements, etc). If the user
cancels the sign-in flow, BaseGameAcitivity/GameHelper will remember that
cancellation. If the total number of cancellations reaches a predefined
maximum (by default, 3), the user will no longer be prompted to sign in on
application startup. If that happens, they can still sign in by clicking
your application's Sign In button, if you provide one.
[5] I don't like the new "auto sign in" feature of GameHelper. How can
I disable it?
To disable this feature and return to the old behavior, you can edit
GameHelper.java and set the DEFAULT_MAX_SIGN_IN_ATTEMPTS constant to 0, or
call GameHelper.setMaxAutoSignInAttempts(0) at runtime, before calling
GameHelper.setup() (or, correspondingly, from your Activity's onCreate
method).
Yes it is possible. I know it is an old question, but I was searching for an answer and I couldn't find easily (Thanks Google). This question pops up the first, so from another question, the answer is to use getGameHelper().setMaxAutoSignInAttempts(0);. As mentioned here.