Scoped Storage with Enterprise Applications

Darryn Campbell -
6 MIN READ

In Android 10, Google introduced Scoped Storage as a security enhancement, severely limiting an application’s ability to access world readable / writeable file locations.  Application file storage is now sandboxed with only a few documented exceptions for media content and writing outside of the app’s sandbox requires the end user’s manual confirmation.

Google have extensive documentation for Scoped storage in Andorid 11 which builds on the previous documentation for Android 10 and many other docs such as an FAQ and consideration of storage use cases.

The intention of this document is to provide advice and recommendations for enterprise developers to understand Scoped storage and update their applications as they move to Android 10, 11 and beyond.  If your application is currently written to consume a configuration file, write data to a folder on the SD card or needs to work with large, shared data sets then you are likely to be impacted by scoped storage.

When will your app be affected by Scoped storage?

Although Scoped Storage was introduced in Android 10, there was a flag you could specify in your manifest, requestLegacyExternalStoragewhich allowed your app to ignore Scoped Storage and work the same as it did under Oreo and Pie.  In Android 11 this flag is going away, hence why enterprise developers are now starting to consider Scoped Storage.

Target SDK of application Android version on device App has specified requestLegacyExternalStorage flag Is app subject to scoped storage?
Does not matter Oreo Does not matter No
29 A10 or A11 Yes No
29 A10 or A11 No Yes
30 A10 Yes No
30 A10 No Yes
30 A11 Does not matter Yes

The most immediate option you might consider when looking at the above chart as you transition to A11 is to continue to target SDK 29.  The biggest limitation with this approach is Google’s Play Store target API level requirements, https://developer.android.com/distribute/best-practices/develop/target-sdk.  Your application must target API level 30 (or higher) from August 2021 for new apps and November 2021 to update existing apps, this affects any Android enterprise deployment that uses the managed Play Store, which is an increasing percentage of customers.

What are your options?

The recommended option is to update your application code to handle the scoped storage changes.  Again, Google have extensive documentation on this topic which I will include links to here, but obviously a lot of the use cases will be consumer focussed:

Are there any options from Zebra, beyond the standard Google recommendations?

Yes, absolutely.  Zebra's Secure Storage manager is designed to address some of the challenges developers will encounter moving to scoped storage and please look out for future announcements on this topic.  Whilst not a ‘magic bullet’, we are working on APIs to meet enterprise customer use cases that are not met by the standard Google storage APIs.

If you need a quick fix…

There are a number of ‘quick fixes’ which I have seen our customers use and, whilst they work, many of these come with caveats that are worth discussing:

  • Continue to target API level 29.  This would allow you to opt out of Scoped Storage, provided you also specify requestLegacyExternalStorage, but is probably not a long-term solution.  You will not be able to take advantage of new APIs and, as previously mentioned, you will not be able to add your application to the Play Store from August 2021
  • Declare the preserveLegacyExternalStorage flag.  This flag was introduced by Android to enable developers to upgrade from A10 to A11.  The only use case is an application migrating its data from the legacy storage model to the scoped storage model following an app upgrade.  This flag has no effect on newly installed applications.
  • Declare the MANAGE_EXTERNAL_STORAGE permission to receive access to all files on device storage.  This approach is recommended by Google and is documented under their data storage pages but there are some caveats that must be considered:
    • MANAGE_EXTERNAL_STORAGE is not automatically granted when requested and requires additional steps. 
      • MX allows the administrator to automatically grant permission to use MANAGE_EXTERNAL_STORAGE on Zebra devices.  This is achieved through the MX Access manager and does not require any end user intervention.
      • On consumer (non-Zebra) devices, the user needs to manually grant this permission to the app through the System Settings, though Android does provide the ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION Intent to make this process more intuitive.
    • MANAGE_EXTERNAL_STORAGE is subject to additional Play Store restrictions:
      • Applications available publicly on the Google Play store will need to adhere to additional restrictions, details of which are available from Google’s Play Store support portal.  There is a separate review process and only applications which meet the ‘permitted uses’ will be able to request this permission. 
      • Private applications distributed within an organization benefit from “increased flexibility”.  This “increased flexibility” is touched on in the Google support portal and in practice means that these applications are not subject to manual checks.  Private applications can therefore make use of MANAGE_EXTERNAL_STORAGE.
      • Applications distributed to specific organizations through the managed Play Store, (for example if a software vendor has created an app that is not public, but only intended for 3 different customers) are a grey area in the documentation.  Although not subject to the same Play Store checks as public apps in the short term, it is still recommended to comply with the MANAGE_EXTERNAL_STORAGE Play Store policy for public apps .
  • Make use of one of the pre-defined folders that are still world read / writeable under Scoped storage.  I would not recommend this approach.  Some users have reported that certain folders including /sdcard/Download and /data/temp/public are still readable and writeable when the application is subject to scoped storage, provided you access them with the deprecated API, getExternalStoragePublicDirectory.  This is not a documented feature and the official behaviour of the Downloads folder is that an app can only read and write its OWN data, which is true for the recommended APIs such as MediaStore.  Another limitation of using these world read / writeable folders is that you are still subject to the security challenges that Scoped Storage was designed to address, i.e. one app reading another app’s data.

How does Scoped storage affect Zebra’s /enterprise partition?

The /enterprise partition is not affected by scoped storage. 

You can continue to read and write to the /enterprise/usr folder.

IMPORTANT NOTE: The /enterprise partition should NOT be used as an alternative storage location and quick-fix to resolve Scoped storage issues.  The /enterprise partition has a finite size and is also needed to persist a deployment across enterprise reset.

How does Scoped storage affect Zebra’s value-add products like DataWedge, Enterprise Browser, and Enterprise Keyboard?

At the time of writing, the Zebra engineering team are in the process of updating Zebra’s value-add applications to be compliant with Scoped storage.  For more information about any required changes, please see the corresponding product pages on techdocs.

How does Scoped storage affect MX features that use file paths, like the File Manager (https://techdocs.zebra.com/mx/filemgr/)

Where Zebra MX features require a file path to be provided, the relevant section of techdocs will be updated with full details.

Overview of options

The expectation is that all applications can be adapted to deal with Scoped storage through one or more of the mechanisms described above.  No single technique will be applicable to all applications however so it is important to understand which options are available to you when you consider migration to Android 11.

profile

Darryn Campbell

Please register or login to post a reply

0 Replies