User disconnecting app in Drive causes loss of data under FILE scope -

i've run issue few times, never point finger on it, attributing gdaa's latency, buggy code, etc... managed come scenario can safely reproduce it, ask people know if feature don' understand or plain bug. if latter case, please point me place can nag it.

i discuss on rest api's background simplicity.

1/ let's have drive api authenticated app 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 file (files/folders) in google drive using

svc.files().insert([metadata], [content]).execute(); 

3/ search objects you've created using

svc.files().list().setq([query]).setfields([fields]).execute(); 

when app run, user goes through usual account-pick / drive-authorize routine , works expected. files created, visible, can found ... until user revokes authorization means of

settings > manage apps > disconnect drive

in drive.google.com.

after that, if android app restarted (and re-authorized), none of objects created prior revocation visible.

it may design, don't know. if case, can't find way how android app can created before. create 'maintenance' app drive scope fix this, but...

now, in case of gdaa, gets worse. not gdaa not have drive scope fix it, if same sequence of steps done , app creates file/folder after revocation, gdaa not complain, file/folder not created @ all. after while (minutes), re-authorization pops-up, still, files created meanwhile found , pre-dating revocation lost (creator) app (it visible in web app has drive scope).

thank you patience.

the first issue is:

1. a user revokes authorization via: settings > manage apps > disconnect drive
2. then reauthorizes app
3. files app authorized see drive_file scope no longer authorized.

this expected behavior of rest , android apis.

we don't think users intuitively expect authorized files re-authorized. user may not remember files authorized, , informing users these files going authorized again cause confusion.

the second issue gdaa's behavior folder creation in situation. don't support completionevents folder creations, we'll into.