The Drive Android API is deprecated as of December 6, 2018 and will be turned down on December 6, 2019.
|Date||Drive Android API status|
|December 6, 2018||Deprecation is publicly announced. Existing clients will be able to access the API normally, but should immediately commence with migration efforts. New clients must not use the API.|
|October 21, 2019||The Drive Android API is removed from the Google Play Services SDK distribution. Apps will be unable to build until removing the Drive Android API dependency, but existing builds will be unaffected. The Drive Android API public documentation will no longer be available.|
|December 6, 2019||The Drive Android API is shut down and all connection attempts will be refused. Clients must migrate by this date.|
To ease client migration efforts, a sample app has been provided which demonstrates how to create, modify, and query for a user's Drive files via the REST API. Details for replicating the Android API's functionality are explained in the following subsections.
Accessing App Data
Support for storing and syncing in the app data folder will likely be removed from Drive in the future. Clients requiring app data storage are strongly encouraged to migrate to a non-Drive solution such as Cloud Firestore.
Accessing User-Visible Drive Data
For user-visible data (e.g. that found in "My Drive"), the REST API provides Java wrappers which seamlessly replicate the Android API's functionality. The REST API also contains features not supported in the Android API, such as Team Drives and Sharing.
The sample app demonstrates how to create, modify, and query for Drive files using the REST API Java wrappers. There are virtually no functional differences between Android and REST API calls, and for most clients the required code changes will be syntactic only.
Clients must configure their app to request access to the Drive API in the Google Cloud Console similarly to the existing Drive Android API authentication process. For most projects with Drive Android API access enabled, no changes will be required to your existing project configuration. But to avoid hard-to-debug errors down the road, please ensure that the following steps have been completed for your project:
- Enable the Drive API in the API Library.
- Create an OAuth Android client ID in the Credentials tab.
- Configure your Consent Screen and request the Drive scopes your app will require.
All Drive Android API clients receive a local database with automated metadata sync for free. This functionality is not provided by the REST API, and if your app requires an offline-first model you will need to implement it yourself.
We recommend the Room Persistence Library for local storage, which encapsulates SQL operations in a clean, object-oriented interface. To enable offline sync, we recommend creating a SyncAdapter which handles network monitoring, wakelocks, throttling, and all other troublesome details pertaining to offline sync. The existing documentation for these products is unaffected when used for Drive data obtained via the REST API.
File Picker UI
For clients that use the Android API's file picker (e.g. by calling
we recommend using
Storage Access Framework
(SAF) which accesses the Drive Android app's content provider. The
sample app demonstrates how to initiate the file picker
Intent and process the data it returns.
There are a few disadvantages of SAF compared to the Android API's file picker, and if any of the following are prohibitive you must create your own UI and populate it with results from a Drive REST API query.
- Files read using SAF cannot be modified or deleted through the same mechanism.
- SAF is supported on Android API level 21+, and virtual file support (e.g. Google Docs) is only available on 24+. The Drive Android API supports API level 14+.
- The Drive Android app must be installed for users to be able to select Drive files via SAF. Drive is bundled with the standard Android OS and cannot be uninstalled, but is not included by default on Android Go variants.
- User-visible changes will be seen when migrating to SAF due to a distinctly different UI.