Google Drive API queryChildren returns no files from App folder across devices

I’m working with Google Drive API in my Android app to handle backup and restore functionality using the App folder. Everything works fine on a single device, but I’m having issues when switching devices or reinstalling the app.

Problem 1: When I backup data on Device A and then try to restore it on Device B, the queryChildren method returns an empty result even though I can see the app data exists in Google Drive settings.

Problem 2: After backing up data and then uninstalling/reinstalling the same app, the restore process finds no files in the App folder.

I’ve tested both approaches:

DriveFolder appFolder = Drive.DriveApi.getAppFolder(googleApiClient);
MetadataBufferResult result = appFolder.queryChildren(googleApiClient, searchQuery).await();

and

DriveFolder folder = Drive.DriveApi.getAppFolder(apiClient);
MetadataBufferResult files = folder.listChildren(apiClient).await();

Both methods return empty results in cross-device scenarios. Has anyone encountered this issue with Google Drive App folder synchronization?

Yeah, this is how the App folder is designed to work. Each app installation gets its own separate data space, so Device B can’t see files backed up from Device A. It’s a Google security feature, not a bug. I ran into the same thing and ended up switching to a dedicated folder in the user’s Google Drive instead. You’ll need broader Drive API permissions, but then your backup files work across all devices once authorized. There’s more manual folder management involved, but being able to access files from any device is worth it.

This App folder limitation destroyed me when I built a data sync system for our mobile app. The per-install isolation makes any decent backup solution impossible.

Everyone’s pushing manual Drive folder management, but there’s a better approach. Use automated workflows that handle the entire backup/restore process without writing endless boilerplate.

I built automated sequences for Google Drive auth, folder creation, file uploads/downloads, and version conflicts across multiple devices. The automation handles OAuth, folder permissions, and errors automatically.

Skip the Drive API headaches and custom sync nightmares. You’ll get reliable cross-device backup that actually works - no more empty queries or data loss after reinstalls.

Latenode makes this stupid easy with built-in Google Drive integrations and visual workflow builders. Get a solid backup system running in minutes instead of debugging APIs for weeks.

Yeah, that App folder behavior is unfortunately by design. Each app install gets its own isolated scope, so backups from one install won’t show up in another - even for the same app on different devices. I hit this exact problem building a note-taking app that needed cross-device sync. Had to ditch App folders and switch to regular Drive folders with proper OAuth scopes instead. You’ll need drive.file or drive.appdata scope rather than just App folder access. Create a dedicated folder in the user’s Drive using the regular API folder methods. This way your data sticks around regardless of app installs and works across devices as long as they’re logged into the same Google account. Downside is you’ll need to handle user permissions and folder management yourself, but it’s the only reliable way to get true cross-device backup with Google Drive.

Had this exact frustration building a document scanner app that needed reliable backup. The App folder looked perfect at first but became a nightmare when users expected their data to sync between phone and tablet. Google’s docs don’t make this isolation behavior clear enough - I spent weeks debugging what I thought was an API bug before realizing it’s intentional design. My fix was creating a hidden folder structure in the user’s main Drive space with consistent naming. The key insight: you need proper conflict resolution when users modify data on multiple devices before syncing. Without this, you’ll get data corruption or lost changes. UX tip - some users get confused seeing backup files in their Drive, so clear naming and maybe organizing everything under one parent folder helps. The extra permission complexity is definitely worth it for real cross-device functionality.

yep, faced that too! drive only links app data to each install, so if ya reinstall, ya lose access. movin to regular drive folders is def the way to go, just be ready for some extra management since users will see those files.

The Problem: You’re experiencing issues with Google Drive API backup and restore functionality using the App folder, specifically when switching devices or reinstalling your Android app. The queryChildren and listChildren methods return empty results, even though the app data is visible in Google Drive settings. This indicates that the App folder’s design is causing the problem, not an error in your code.

:thinking: Understanding the “Why” (The Root Cause):

The Google Drive App folder is designed with per-installation isolation. Each time you install your app on a new device or reinstall it on the same device, a new, separate App folder is created. Data stored in the App folder of one installation is completely invisible to other installations, even if it’s the same app on a different device. This is a security measure, not a bug. Your original approach of using the App folder is fundamentally flawed for cross-device or post-reinstallation backups.

:gear: Step-by-Step Guide:

  1. Migrate to a User-Specific Folder in Google Drive: Instead of relying on the App folder, create a dedicated folder within the user’s Google Drive to store your backup data. This folder will be persistent across device changes and app reinstalls, as long as the user is logged into the same Google account. You will need to request appropriate Drive API permissions.

  2. Modify Your Backup and Restore Logic: Update your Java code to use a user-specific folder instead of Drive.DriveApi.getAppFolder(googleApiClient). You’ll need to obtain the ID of the designated folder (created in the previous step) and use it in your API calls:

// Obtain the folder ID of your dedicated Google Drive folder.  This ID must be stored securely and retrieved appropriately, perhaps via shared preferences.
String userSpecificFolderId = "YOUR_USER_SPECIFIC_FOLDER_ID";

DriveFolder userFolder = Drive.DriveApi.getFile(googleApiClient, userSpecificFolderId).asDriveFolder().await();

// Use userFolder for all subsequent operations (queryChildren, listChildren, etc).
MetadataBufferResult result = userFolder.queryChildren(googleApiClient, searchQuery).await();
  1. Handle Permissions and Error Conditions: Ensure your app requests the necessary Google Drive API scopes to read and write to the user’s Google Drive. Implement robust error handling to gracefully manage cases where the folder is not found, the user lacks permissions, or network connectivity issues occur. Consider using try-catch blocks to handle potential exceptions.

  2. Testing: Thoroughly test your updated backup and restore functionality across multiple devices and after reinstalling the app. Pay close attention to the permissions granted to your app and ensure that you handle potential errors appropriately.

:mag: Common Pitfalls & What to Check Next:

  • Incorrect Folder ID: Double-check that you are using the correct userSpecificFolderId in your code. Any typo or incorrect ID will cause the API calls to fail.
  • Insufficient Permissions: Verify that your app has the necessary Google Drive API scopes (drive.file scope at least).
  • Quota Issues: While less likely than permission problems, ensure the user has sufficient storage space in their Google Drive.

:speech_balloon: Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.