10

Google has deprecated Google Drive Android API.

We are migrating over to Google Drive REST API (v3).

2 years ago, we have experience in using Google Drive REST API (v2). We know that GET_ACCOUNTS permission is required, for GoogleAuthUtil.getToken() to work correctly - Google Drive API - the name must not be empty: null (But I had passed valid account name to GoogleAccountCredential)

When we look at example of Google Drive REST API (v3) - https://github.com/gsuitedevs/android-samples/blob/master/drive/deprecation/app/src/main/AndroidManifest.xml#L5 , we notice that Google team does mention explicitly

<!-- Permissions required by GoogleAuthUtil -->
<uses-permission android:name="android.permission.GET_ACCOUNTS" />
<uses-permission android:name="android.permission.MANAGE_ACCOUNTS" />

Surprisingly, when we run the example app (https://github.com/gsuitedevs/android-samples/tree/master/drive/deprecation), there's no run-time permission dialog being pop up for Android 6 and 8. Yet, the app can work without issue.

We expect the app will fail working, as no GET_ACCOUNTS permission was granted for the app. However, it can still auth and communicate with Google Drive service, without issue.

This is what I have tested so far

I have tested in Android 5, Android 6 and Android 8. No runtime GET_ACCOUNTS permission is granted for Android 6 and Android 8.

I'm also further test, by removing GET_ACCOUNTS and MANAGE_ACCOUNTS from Manifest completely. Still, both Android 5, Android 6 and Android 8 are workable. Before running, I have clear cache and clear storage of the app.

So, is GET_ACCOUNTS runtime permission request still required for Google Drive REST API to work?

Cheok Yan Cheng
  • 47,586
  • 132
  • 466
  • 875

1 Answers1

6

according to Authorizing and Using REST APIs, it does not seem required - because the GoogleSignInApi can be used, which requests oAuth2 access-scopes and does not require direct access to on-device capabilities. it gets the user account from Play Services, which knows the logged in accounts and acts as the delegate.

just tried and the only difference is that one has to add the access-scopes as strings:

GoogleSignInOptions gso = new GoogleSignInOptions
  .Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
  .requestScopes(new Scope("https://www.googleapis.com/auth/drive.readonly"))
  .requestEmail()
  .build();

this.mGoogleSignInClient = GoogleSignIn.getClient(this, gso);
...
Martin Zeitler
  • 1
  • 19
  • 155
  • 216
  • This is very much in contrast with the information provided here : https://stackoverflow.com/questions/34639890/google-drive-api-the-name-must-not-be-empty-null-but-i-had-passed-valid-acco and here : https://github.com/gsuitedevs/android-samples/blob/master/drive/deprecation/app/src/main/AndroidManifest.xml#L5 – Cheok Yan Cheng Dec 29 '18 at 14:55
  • just tried to login with an `oAuth2` client id; could add two Google accounts on the emulator without granting any permissions - and I could also obtain the desired access-scope without issues; it really only asks for granting the application access to the requested access-scope(s). – Martin Zeitler Dec 29 '18 at 18:06
  • 1
    @CheokYanCheng I had missed the deprecation of GDAA, so thanks for the question. In support of this answer, check out https://android-developers.googleblog.com/2015/11/whats-new-in-google-play-services-83.html. There you will find "... the new Google Sign-In no longer requires the device accounts permissions..." Also check out http://lgvalle.xyz/2015/11/03/play-services-auth/. – Cheticamp Jan 02 '19 at 16:25
  • 3
    @Cheticamp Thanks for the resources. I had done careful testing for various API level, and can confirm no permission (GET_ACCOUNTS and MANAGE_ACCOUNTS) is required. Hope there isn't any/much edge cases. I think Google team should just remove permission from their sample code, to avoid further confusion. – Cheok Yan Cheng Jan 02 '19 at 16:29
  • @CheokYanCheng the only downside with `GoogleSignIn` is, that managing multiple Google account's Drive resources does not seem to work out of the box - and therefore might require custom handling of oAuth2 flows and token storage... because one can always only get a handle to the last signed in account. this appears to be an unfortunate side-effect of not accessing the `AccountManager` directly anymore. – Martin Zeitler Jan 02 '19 at 17:18