11

I recently integrated GoogleSmartLock with my app. Somehow the save dialog is not coming up in Android O devices and the API is throwing following error.

The Credentials API's save confirmation dialog has been disabled to avoid conflicts with the Android Autofill feature. This choice may be overridden via AuthCredentialsOptions.Builder.forceEnableSaveDialog()., resolution=null}

I checked the latest release notes of the playservices and found out that following API can fix this problem.

Auth.AuthCredentialsOptions.Builder forceEnableSaveDialog ()

But I am not sure how to use this api with GoogleApIClient as it does not have build method that technically should return AuthCredentialOptions instance. Please let me know if anyone is facing the same problem.

Aman Mahajan
  • 115
  • 1
  • 5

3 Answers3

10

Update 1: This issue is resolved in the latest release (Version 11.8.0):

Code examples (as well as further documentation on using .forceEnableSaveDialog) are available in the "Targeting Android O and above" section of the overview documentation and have been updated to use the new options class.

David
  • 442
  • 3
  • 8
  • 3
    Thanks for the answer David. Somehow that code is giving me the compilation error. It is saying that it can't find build() method. The problem I am facing is the method forceEnableSaveDialog() should return AuthCredentialOptions instance but instead, it is returning AuthCredentialOptions.Builder instance and this instance does not have build method. Please correct me if I am wrong. I am using 11.6.0 playservices version. – Aman Mahajan Nov 08 '17 at 18:22
  • Yeah, I am seeing the same thins with the 11.6.0 version. – ariets Nov 11 '17 at 19:37
  • 1
    There is a bug that has been filed: https://issuetracker.google.com/issues/69001533 – ariets Nov 11 '17 at 19:55
  • Yes, I have filed that same bug. No response from them till now. – Aman Mahajan Nov 13 '17 at 19:21
  • Hey Aman, thanks for raising this. I will look into this issue, and get back to this thread. – David Nov 13 '17 at 23:19
  • 2
    Hey Aman, this issue has been fixed and will be available in a future release. I will update this bug once the release is out. – David Nov 21 '17 at 16:59
  • Thanks so much David. I hope new release is coming out soon. Meanwhile, can you share any workaround for this? I really appreciate it. – Aman Mahajan Nov 22 '17 at 15:27
  • 1
    Also, just to clarify: the Autofill with Google save dialog will record the data in the same Smart Lock datastore as the dialog triggered via the API, so if the Autofill dialog shows, you really don't need to worry about forcing the other one (unless you'd prefer to suppress the Autofill dialog or it doesn't show). So in the interim, you can just use the Autofill dialog and not worry about this. – Steven Nov 29 '17 at 21:36
4

The build() method was missing from the public SDK for AuthCredentialsOptions.Builder and we fixed it (see the accepted answer)

But a more important clarification: Autofill with Google save dialog stores passwords to the same Smart Lock database, so if the Autofill dialog shows, then you don't need to worry about using the API to force the other dialog to show (in fact, if you force the dialog via the API, then make sure to suppress the Autofill one ... user should not see two dialogs). Data saved via either dialog will be available for Smart Lock auto sign-in (and vice versa for Autofill) and the data is sync'ed via Google Account with Chrome (autofill and API).

Since the dialogs store data to the same place, we opted to show the Autofill with Google one when user uses Google as their autofill manager because it will provide a consistent experience across all apps on Oreo devices. Working on improving error message, documentation, and branding to clarify this. Sorry for the confusion.

Steven
  • 3,812
  • 23
  • 38
1

I managed to use reflection for this workaround:

Auth.AuthCredentialsOptions authCredentialsOptions = null;
try {
    Constructor<Auth.AuthCredentialsOptions> constructor = Auth.AuthCredentialsOptions.class.getDeclaredConstructor(Auth.AuthCredentialsOptions.Builder.class);
    constructor.setAccessible(true);
    authCredentialsOptions = constructor.newInstance(new Auth.AuthCredentialsOptions.Builder().forceEnableSaveDialog());
} catch (Exception e) {
    e.printStackTrace();
}
GoogleApiClient.Builder builder = new GoogleApiClient.Builder(this)
        .addConnectionCallbacks(this)
        .enableAutoManage(this, 0, this);
if (authCredentialsOptions != null) {
    builder.addApi(Auth.CREDENTIALS_API, authCredentialsOptions);
} else {
    builder.addApi(Auth.CREDENTIALS_API);
}
mGoogleApiClient = builder.build();
loredan13
  • 114
  • 1
  • 9
  • I would not recommend doing this. Given the build method was never part of the API's public contract it very possible that it may be changed in the future. Instead I would advocate waiting for the upcoming release with a proper fix. – David Nov 30 '17 at 17:23
  • @David True, but it's been almost a month without a fix, and some people need to get it working as soon as possible. It is by no means a permanent solution – loredan13 Nov 30 '17 at 17:26
  • It's fixed now, can we take this down? – Steven Dec 19 '17 at 23:16
  • @StevenSoneff Sure – loredan13 Dec 19 '17 at 23:17
  • @loredan13 GoogleApiClient is deprecated so what I should use? – Bhavin Patel Jan 29 '20 at 05:27