I've run into this issue a few times, but could never point my finger on it, attributing it to GDAA's latency, my buggy code, etc... I finally managed to come up with a scenario where I can safely reproduce it, so I would like to ask people who know if it is a feature I don' understand or a plain bug. If latter is the case, please point me to the place where I can nag about it.
I will discuss it on the REST API's background for simplicity.
1/ Let's have a Drive API authenticated app that runs under DRIVE_FILE scope
com.google.api.services.drive.Drive svc =
new Drive.Builder(
AndroidHttp.newCompatibleTransport(),
new GsonFactory(),
GoogleAccountCredential
.usingOAuth2( context, Collections.singletonList(DriveScopes.DRIVE_FILE))
).build();
2/ create a file (files/folders) in Google drive using
svc.files().insert([METADATA], [CONTENT]).execute();
3/ search for the objects you've created using
svc.files().list().setQ([QUERY]).setFields([FIELDS]).execute();
When the app is run, user goes through the usual Account-Pick / Drive-Authorize routine and everything works as expected. Files are created, visible, can be found ... until a user revokes the authorization by means of
Settings > Manage Apps > Disconnect From Drive
in drive.google.com.
After that, if the Android app is restarted (and re-authorized), none of the objects created prior the revocation is visible.
It may be by design, I don't know. If this is the case, I can't find a way how the Android app can get to anything it created before. I could certainly create another 'maintenance' app with DRIVE scope to fix this, but...
Now, in case of GDAA, it gets even worse. Not only GDAA does not have the DRIVE scope to fix it, but if the same sequence of steps is done and the app creates a file/folder immediately after revocation, GDAA does not complain, but the file/folder is not created at all. After a while (minutes), the re-authorization pops-up, but still, the files created meanwhile are nowhere to be found and everything pre-dating the revocation is lost to the (creator) app as well (it certainly is visible in the web app that obviously has DRIVE like scope).
Thank you for you patience.
The first issue is:
This is the expected behavior of the REST and Android APIs.
We don't think users would intuitively expect all previously authorized files to be re-authorized. The user may not remember the files that were previously authorized, and informing users that these files are going to be authorized again will likely cause confusion.
The second issue is GDAA's behavior for folder creation in this situation. We don't currently support CompletionEvents for folder creations, but this is something we'll look into.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With