Is your GIS data ready for scoped storage in August? Google’s long-hinted (and delayed) changes to local storage will have to be in place for apps hosted on the Google Play store. In this post I'll tell you what we’ve learned about the changes and how we handled them on the Android samples team.
GIS is fundamentally a data driven science. The ArcGIS Runtime SDK provides the tools you need to manage, analyze and access GIS data in your apps. For mobile devices, that can mean accessing data services over mobile networks, from service endpoints hosted on ArcGIS Online or ArcGIS Enterprise. It can also mean accessing local data on the device, whether that’s because the dataset in question is very large or because user workflows mean devices are likely to be used in areas of poor mobile network coverage.
Google has fired the final warning shot that developers will need to move to the new scoped storage model for handling data locally on the device, for any apps targeting Android 10. This means any of your apps using the older model, with wide access to the file system exposed through getExternalStorageDirectory on the Environment class, will have to change. Instead, your app will be expected to use the app-specific directory, a dedicated space on the device for persistent files that the application owns.
This directory is divided into internal, external and shared storage directories. Internal storage is accessed with a call to getFilesDir and is for data which will not be available to any other apps (and will be encrypted from Android 10 onwards). External storage, accessed with a call to getExternalFilesDir, is for data which can be accessed by other apps (and critically, ADB). Both of these storage directories are scoped to the app and will be deleted on uninstallation of the app itself. A third directory, shared storage, is more similar to the old storage format, but is for specific media files and of less relevance to GIS data.
With ArcGIS Runtime, your decision on whether to use internal or external storage should be driven by the intended workflow of your app. If your app is downloading sensitive client map data as a MobileMapPackage with the OfflineMapTask, that data is probably best stored in the internal storage of the app which will use that data. However, a user downloading a mobile map package with the offline map task, or sideloading an .mmpk file onto a device with ADB, may wish to store the data in a place which allows for access by other apps. They might want to use the data in different ArcGIS Runtime apps or simply be able to manipulate those files from a file manager app. If those were expected workflows, external storage would be the best option.
In the ArcGIS Runtime sample apps repo, we recently migrated just over 30 samples to use the new scoped storage model. We decided to place our data in external storage for easy side-loading of data with ADB. Here’s an example with a point cloud dataset in a scene layer package.
The right kind of scoped storage solution will ultimately be up to you, the developer. Whichever option you decide, you should have your app ready for scoped storage soon, as it’ll be required for apps targeting Android 10 (API 29). New apps distributed on the Google Play store need to target Android 10 by August of this year. Updates to existing apps will have a little more breathing room though, with Android 10 target requirements by November.
In the event that you don’t think you’ll have time to get your app ready by then, there’s one final “get out of jail free card”. Adding the line `=true` to your app’s AndroidManifest.xml file will allow your Android 10 app to use the old storage model. But with plans for Android 11 well under way, it’s best to make the change to the new scoped storage model sooner rather than later!