您所看到的，是的 GDAA ，可如果你看一下接近，说明一个驱动文件的生命周期图。（警告：我从来没有见过源$ C ​​$ C，从我观察到的只是假设）

看，GDAA，不像 REST 的API，创建会尽力创建图层缓存和网络通信优化。所以，当你操纵从外部（如Web应用程序），该GDAA层的文件/文件夹没有，直到它启动同步，由它自己的逻辑控制的事实知识。我自己原来假设GooDrive具有此控制下通过调度某种通知回GDAA，但它显然不是这样。此外，一些Google员工提到的'requestSync()'作为一个治愈，但我从来没有成功地使其工作。

你认为你正在做的，什么是轮询GooDrive。但实际上，你是轮询GDAA（本地GooPlaySvcs），其驱动器Id仍然有效（未更新），不像一个已经消失的真正GooDrive对象。

这是一件事，没有明确的文档说明。 GDAA并不是适用于所有应用程序***阿比。它的缓存机制，是伟大的透明管理在线/离线状态，网络流量优化。电池寿命，......但在你的​​情况，你的可能的是通过使用REST API，因为你得到的回应反映了当前GooDrive状态更好。

我自己也面临着类似的情况，不得不从GDAA切换回REST（带私人GCM基于通知系统取代轮询）。不用说，通过使用REST API，应用程序越来越复杂，通常需要同步适配器/服务做数据同步，管理网络状态，......所有的东西GDAA为您提供免费的）。结果
如果你想用2 API来发挥并排有两个相同的CRUD实现，你可以使用（ GDAA ， REST ）。

好运

Running the code below, I create a folder with Google Drive Android API on a tablet. After a few seconds, delete that folder from a remote location on a PC. When I re-run the code, the API still thinks 'MyFolder' exists, even though it was deleted and not visible in the Google Drive app on the tablet. The folder persistance finally disappears after a while and the code works as expected. Is this expected behavior for Cloud drives?

Query query = new Query.Builder()
        .addFilter(Filters.and(Filters.eq(
                SearchableField.TITLE, "MyFolder"),
                Filters.eq(SearchableField.TRASHED, false)))
        .build();
Drive.DriveApi.query(getGoogleApiClient(), query)
        .setResultCallback(new ResultCallback<DriveApi.MetadataBufferResult>() {
    @Override
    public void onResult(DriveApi.MetadataBufferResult result) {
        if (!result.getStatus().isSuccess()) {
            showMessage("Cannot create folder in the root.");
        } else {
            boolean isFound = false;
            for(Metadata m : result.getMetadataBuffer()) {
                if(!isFound) {
                    if (m.getTitle().equals("MyFolder")) {
                        showMessage("Folder exists");
                        isFound = true;
                    }
                }
            }
            if(!isFound) {
                showMessage("Folder not found; creating it.");
                MetadataChangeSet changeSet = new MetadataChangeSet.Builder()
                        .setTitle("MyFolder")
                        .build();
                Drive.DriveApi.getRootFolder(getGoogleApiClient())
                        .createFolder(getGoogleApiClient(), changeSet)
                        .setResultCallback(new ResultCallback<DriveFolder.DriveFolderResult>() {
                    @Override
                    public void onResult(DriveFolder.DriveFolderResult result) {
                        if (!result.getStatus().isSuccess()) {
                            showMessage("Error while trying to create the folder");
                        } else {
                            mThwingAlbertFolderId = result.getDriveFolder().getDriveId();
                            showMessage("Created a folder: " + mThwingAlbertFolderId);
                        }
                    }
                });
            }
        }
    }
});

What you are seeing, is a 'normal' behavior of the GDAA, that can be explained if you look closer at the 'Lifecycle of a Drive file' diagram (warning: I've never seen the source code, just assuming from what I observed).

See, the GDAA, unlike the REST Api, creates a layer that does its best to create caching and network traffic optimization. So, when you manipulate the file/folder from the 'outside' (like the web app), the GDAA layer has no knowledge of the fact until it initiates synchronization, controlled by it's own logic. I myself originally assumed that GooDrive has this under control by dispatching some kind of notification back to the GDAA, but it apparently is not the case. Also, some Googlers mentioned 'requestSync()' as a cure, but I never succeeded to make it work.

What you think you're doing, is polling the GooDrive. But effectively, you're polling the GDAA (local GooPlaySvcs) whose DriveId is still valid (not updated), unlike the real GooDrive object that is already gone.

This is one thing that is not clearly stated in the docs. GDAA is not the best Api for EVERY application. It's caching mechanism is great for transparently managing online/offline states, network traffic optimization. battery life, ... But in your situation, you may be better off by using the REST Api, since the response you get reflects the current GooDrive state.

I myself faced a similar situation and had to switch from the GDAA back to the REST (and replaced polling with a private GCM based notification system). Needless to say, by using the REST Api, your app gets more complex, usually requiring sync adapter / service to do the data synchronization, managing network states, ... all the stuff GDAA gives you for free).
In case you want to play with the 2 apis side-by side, there are two identical CRUD implementation you can use (GDAA, REST) on Github.

Good Luck