[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]
