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
3/ search for the objects you've created using
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
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.