[MUSIC PLAYING]
ROXANNA ALIABADI: Hi.
I'm Roxanna.
And I'm a product manager on Android.
Today I'll be discussing storage access on Android 11.
Modern storage devices are the keepers
of so many of our personal memories and information.
This includes photos of our loved ones and videos
of our most memorable days.
And with so many of us now conducting business
with our phones and tablets, often important files
are stored on our devices, including
financial and legal documents.
Android's amazing app developer community
has created countless apps to help us share our memories,
edit our documents, and listen to our music.
But until recently, storage access on Android
hadn't evolved to ensure that apps
could get exactly the information users
want to share and no more.
Today we'll quickly go over the storage changes introduced
with Android 10.
And then we'll discuss in detail the new modifications
we've added to improve the developer experience in Android
11.
And we'll finish with some tips on migrating your app
to use modern storage.
Last year with Android 10, we introduced
the concept of scoped storage.
The idea is to organize shared storage
into specific collections, and limit access to broad storage.
These are the changes introduced for apps targeting Android 10.
First, apps have unrestricted access to their own storage,
both on internal memory and external volumes.
Second, shared storage is divided into four organized
collections--
pictures, videos, music, and downloads.
And apps can contribute files to these organized collections
without any permission.
The storage runtime permission now only
gives read access to shared pictures, videos, and music
files.
To access downloads or unorganized files
the user must give specific access via the Document Picker.
Deleting or modifying media files
that were not created by your app
now requires user confirmation.
And lastly, apps must request a new permission
to access photo location metadata.
While many apps have successfully
migrated to scoped storage on Android 10,
we recognized that we didn't sufficiently
satisfy all of the use cases in that release.
Therefore, for apps targeting Android 10,
we included the option to opt out
of scoped storage with a flag in the manifest called
requestLegacyExternalStorage.
Over the past year, we've heard feedback about the storage
update from all kinds of developers.
We know this change isn't easy for many apps.
And we recognize the challenges involved with adapting
to modern storage.
In response, my team focused all our efforts in this release
on adding improvements to Android 11,
specifically to make the transition easier.
And because we've made these changes,
we now feel comfortable making scoped storage
mandatory for all apps targeting Android 11.
There won't be an option to opt out.
So here's what's new on Android 11.
As an alternative to MediaStore APIs,
apps can choose to use other APIs which
rely on local file paths.
This is likely to reduce or eliminate the amount of code
you have to change when upgrading to target Android 11.
We've created new, easier to use APIs for modifying media files,
and added the ability to make changes in bulk.
For specific apps that can verify that they require
the ability to read more broadly we
created a new special app access called All Files Access.
App storage is now private from other apps, including
external app directories.
Let's go through each of these in more detail.
With scoped storage enabled on Android 10,
apps were only able to access shared files using MediaStore
APIs, a collection of APIs specifically designed
for working with index files and shared storage.
These APIs identify files using file descriptors,
rather than local file paths.
MediaStore is a rich, efficient, and useful set of APIs
that we will continue to innovate.
So for most apps, this is still the best solution
for working with shared files.
However, your feedback showed us that disallowing APIs that use
file paths, like Java Files API, or native C and C++ libraries
caused significant compatibility issues between Android Pi
and Android 10.
Compatibility is important to us,
because we want to make it easy for apps
to take advantage of each new Android release.
So we decided the best thing we could
do to help app developers migrate to scoped storage
was to find a way to allow them to use file path APIs,
while keeping the new privacy requirements.
By leveraging FUSE, File system and User Space,
we were able to re-enable these APIs with scoped storage.
For example, now apps can successfully
use FFMPEG, a popular multimedia framework.
Under the hood, I/O requests using file paths
are actually delegated to the MediaStore API.
You can think of file path APIs in Android 11
as convenience API to the MediaStore.
You do not get any additional access
to files you would have gotten by using MediaStore APIs.
This is simply a different way to implement your app
functionality if you choose to.
You can get the file path of a file in MediaStore
by looking in the data column.
Because file path APIs now directly link
to MediaStore, anytime you create a new file, such as save
a new photo using a file path API,
it will be immediately added to the MediaStore.
This is helpful, because then there is never delay
as there might have been an older versions of Android
between contributing files in shared
storage and another app's ability to access them.
However, this could cause some unexpected behavior
if your app was previously operating under the assumption
that the new file would not be indexed right away.
So keep this in mind as you test your app on Android 11.
The team has worked diligently to ensure
there is minimal performance impact to using file path APIs,
but if performance is vital to your app,
we recommend testing both options to see what
works best for your situation.
So while MediaStore APIs are still
most likely to be the best way for you to access shared
files on Android, you're now free to decide
if you would like to use any other API or library instead.
As I mentioned, MediaStore is the richest set
of APIs for accessing shared files.
With Android 11, we've added three significant new features.
First, as part of scoped storage in the last release,
we introduced a new requirement in which
apps needed to get user consent before modifying or deleting
a file it does not own.
For Android 11, we created new, easier to use
APIs to get this consent.
One is called Create Write Request
and Create Delete Request.
With these, apps can request consent
for modifying several media files at once.
If you already own the files that you want to modify,
you don't need to request user consent to modify them.
We created a new MediaStore concept with trash.
You can think of this like the recycle bin on a PC.
Apps can now choose to trash a file instead of deleting it.
This gives the user a chance to recover the file later.
Trash files will be hidden by default,
but then can be displayed if an app wants to.
A trashed item will be automatically deleted by the OS
after 30 days.
Trashed files can be untrashed at any time
before its expiration by an app that
has edit access to it, or with user consent.
We also created a new file status called favorite.
For example, in your gallery app,
you may be accustomed to starring
a photo you like so you can find it again more easily.
Now this can work across apps.
If your app has a user experience
of picking from a list of all available photos,
you now can choose to list the favorited photos first
or highlight them differently.
Similar to modifying files, apps must get user consent
before trashing or favoring files it does not own.
However, the default gallery app on the device
will never be required to prompt the user
for any of these modifications.
I am super excited to see how apps will take advantage
of these new features.
Most apps that work with shared files
will have everything they need with the read external storage
permission, which grants access to photos, videos, and music.
And apps like PDF editors or document readers
can use the storage access framework
to request access to specific documents and downloads.
However, there are some apps that
truly require read and write permissions for all files
and shared storage to carry out their primary purpose.
Some apps are file managers and backup apps.
Apps like these, which users rely on
to move and modify all kinds of files,
now have the option to request a new permission called
All Files Access or Manage External Storage in code.
Manage External Storage grants write access to all files,
except those in foreign app directories.
Because this is quite sensitive, it's not a runtime permission,
but instead, a special app access.
This means it must be enabled by the user in settings,
similar to notification listening or usage access.
Apps that request all files access
and publish to Google Play will need
to be verified manually to ensure
they have a legitimate purpose to request it.
This is to protect users from inadvertently
granting overreaching access to an app that might be malicious.
The access will not be limited to specific categories of apps.
Developers are so creative that we cannot list all the possible
use cases.
Instead, each app will be independently evaluated
to check that there is truly no other reasonable way
for the app to work without this permission.
It has never been best practice to directly access
files saved in another app's external storage directory.
The best way for apps to share files
are by using shared storage, or content providers.
To formalize this on Android 11, no app
will be able to access another app's external app storage.
This includes all methods of reading files--
MediaStore, file path APIs, and the storage access framework.
This is the one storage change that's not gated on target SDK.
So if your app is accessing another app's data,
or you are allowing apps to access your storage,
you will need to update to one of the approved methods
in order to run as expected on Android R.
To end, I will share some useful tips
for migrating your app that we have
learned by responding to your feedback
and talking to our partners.
First, if your app will be using file paths or All Files Access,
which I discussed today, you will
need to keep the legacy storage flag in your app's manifest.
This is to ensure compatibility with users
running your app on Android 10.
If your app has a custom picking experience
for selecting non media files, like documents,
you should redesign it to use a storage access
framework instead.
This does not require any permissions.
Remember, now modifying or deleting media
files you do not own requires user consent.
So use the new MediaStore consent APIs.
It is no longer advisable for your app
to save files in a custom, top level directory.
Doing so requires the storage access framework,
which is not the best experience for users.
And if your app is uninstalled and then reinstalled,
it would lose access to those files.
We suggest using organized media collections or your private app
storage instead.
If you use a top level directory today,
you should migrate those files before upgrading your app.
We've created a new manifest flag to help with this.
If you want to share data with other specific apps,
set up content providers.
This is the most secure way to share files.
I hope these changes will make it easier
for you to update your app for scoped storage.
To help you with your migration, the Android documentation
has been updated to reflect all of these changes.
So check them out to get more details
on everything I've discussed.
We truly believe that this change will significantly
protect our users from malicious apps,
and we hope the ability to contribute media
without requiring a runtime permission
is a welcome change to streamline your app's user
experience.
I hope you and your loved ones are staying safe
and stress free.
Happy developing.
[MUSIC PLAYING]