Storage access with Android 11

44 Likes comments off




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


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


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


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


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,

  Developing for Android Things Using Android Studio

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.

  Build an Android app to recognize flowers

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.

  Hilt - Android Dependency Injection

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


I hope you and your loved
ones are staying safe

and stress free.

Happy developing.




You might like

About the Author: admin

You cannot copy content of this page