Preparing for Scoped Storage (Android Dev Summit '19)
[Music] hi my name is Roxana and I'm a product manager on the android framework team and i'm joined by sim and AC so last year we introduced a new way of thinking about storage on android with android 10 we call this change scope storage and so today we're
going to talk more about those changes and we're going to talk about some new things that we're thinking about to make these changes easier for developers to adopt and at the end da scene is going to go through some practical examples and best practices so first I want
to clarify what's meant by shared storage every app has their own private directory in internal storage this is what you find on android /data /resource is considered shared storage this includes the media collections and external app directories on the SD card we find that about half of apps
today request the storage permission but in fact the majority of these apps don't really need such a broad view of absorb storage so trying to do simple things like select an image file for a user to pick a profile picture for a social app or maybe to download
an image or of a document from an email attachment we also find that when apps have such broad writing power they tend to leave files scattered on the disk and when the app is uninstalled those files are left behind taking up space and when so many users are
suffering from low disk space they can take all the space they can get so we we thought about how we can reimagine storage on Android so the apps can get this specific access they need without getting such a broad broad writing reading and writing power that they don't
actually need so Scott scope storage which we introduced with Android 10 the idea is to compartmentalize storage into specified collections and to limit the access to broad storage so as we were designing it we thought of three basic principles that we wanted to follow the first is better
attribution this means that the system knows which apps created which files this helps the user better manage their storage it also makes sure that when app is uninstalled all of its content is also removed unless the user explicitly wants it kept the next is protecting app data so
as I mentioned before internal app directories have been private we also want make sure that the external app directories that are created on an SD card are also not not being able to easily be read by other apps and of course we want to protect our users data
because when you download an image from a private message or a PDF of your tax return you probably don't want every other app on the device with the storage permission to be able to read those files so as we consider these principles here are some of the key
features that we added to scope storage in android 10 the first is that every app has unrestricted access to their own app directories now this is going to be both internal app directories and external app directories so with Android 10 you don't need to request the storage permission
to be able to write your write files through your own app directory on the X on the SD card the next is that whip you have unrestricted access to contribute files to media collections and to downloads we created a new downloads collection it also with Android 10 so
this way if you want to save an image music file video or any other document you can do so without any permission as long as it's saved in the organized media collections the next change we made is that the storage permission is redefined so instead of giving broad
access to shared storage you actually just get access to organized media collections image video and audio collections we also believe that app location or selling media location metadata is private to the user or sensitive to the user so we created a new permission called access media location the
apps will need to declare if they want to see that location metadata on the image if they don't request this that location metadata will be stripped when the Apple reads the image file so in order to in order to read any other type of file like a PDF
or a document apps no need to use the system picker so this is or this is accessed using the storage access framework also writing any files outside of the organized media collections or your app directories also requires using the system picker this makes sure that users can choose
exactly where on the disk they want the file stored so what happened in Android 10 we introduced scope storage and one of the early beta releases of Android 10 and we impose those changes for all apps regardless of target SDK however we had significant developer feedback that these
changes were very dramatic and very difficult to make it to make in such a short period of time so we introduced a flag that you could declare in your manifest file it's called rugged request legacy external storage if an app declares this flag in their manifest then the
storage permission works as it did on previous versions of Android despite some of the concerns that we heard we're really happy to see that of all of the apps that are currently targeting Android 10 98% of them don't request this flag this shows us that this changes we
introduced withstood scope storage are are acceptable to most developers however we also understand that a lot of apps have not started targeting Android 10 yet and we also are very conscious about the experience of these 2% and we want to really think about how we can improve scope
storage and add features so that these changes are easier for you for developers to adapt we're actually going to talk about some of the developer feedback feedback that we got and some of the basic themes the first is that the changes that we introduced with Android 10 have
a lack of support for using file paths or native libraries next there are specific categories of apps that really need access to broad storage for example you can think of file managers or backup and restore apps so these apps attempted to use the storage access framework api's to
get a broad view of sorts of shared storage however the problem is that those api's were not intended to be used to group to get access to so many nested files so those users so those developers reported performance issues and also they complained about some of the UI
difficulty of having the user go and select root folders in order to get this level of storage and also now that we've sort of changed the what the storage permission means the definition has become muddled so for some apps are updated the storage permission actually means that they're
getting access to media and for other apps that are not updated it means they have broadened access to the storage and that can be confusing so we actually want to talk about some of the things that we're thinking about in the next release and that's not something we
normally talk about this event but I think it's really important to announce to developers what we're working on so that as you're making changes to a first for Android 10 you don't make any changes that you'll need to reverse as we read next a release the next version
of Android so the first thing is we're doing an update to the permissions UI so that so we felt would be fix the problem before where apps they're actually only getting access to media seem like they're getting access to all of shared storage we're going to differentiate this
to the user so the user will see a different permission UI based on if that app is updated and using scope storage or not the next we're working really hard to enable file paths and native libraries for reading media and Zim's going to talk more about that we're
also updating the api's for modifying and Media files that the app didn't create itself all right and that includes that we're creating a bulk option the next big change that we're making is we're adding a special app access permission this is specifically for apps that can demonstrate a
need for broad access to shared storage and it'll be white listed by Google Play we're also taking a step further and protector protecting those external app directories and making sure that users can't select those directories with the storage access framework api's and a big change that we're making
is that we're gonna be enforcing this based on target SDK last year we did say that we would be enforcing this regardless of target SDK for all apps on the next release of Android but really we think that the best thing for the users is to introduce these
changes gradually and we also want to make sure that developers can really take the time to design their apps to make sure that they're making the changes for scope storage in a responsible way now I'll hand it over to Zim who will talk more about the changes introduced
with Android 10 and some of the new features that we're working on Thank You Roxy now I'm going to dive into some more detail about the changes we launched in Android 10 as well the changes I expect in the next Android release from the earliest versions of Android
we've always had the audio the images and the video collections these collections are intended for sharing media files with other apps in Android 10 made a big change to allow contributing to these collections without any permissions likewise you can edit and delete media files you contributed without any
permissions this was to reduce the number of apps requesting unnecessarily these storage permissions to read media files not created by your app you will need the read external storage permission the right external storage permission will be deprecated in the next Android release and requesting it will really only
give you read access to media files editing or deleting media files not contributed by your app is just not possible without explicit user consent this is to give users full control over when apps want to edit or delete media files like their important pictures in the next Android
release when you request the storage permission at runtime users will see two different permission strings depending on the target SDK version of your app if your target in the next Android release users will see a new media permission string requesting just access to media files and external storage
however if your target in any other release uses will continue to see the old storage permission string requesting broad access to external storage this way our users will understand how much access your app is requesting so in Android 10 we launched a brand-new downloads collection for sharing non
media files with other apps like the media collections contributing to this collection and editing or deleting media non media files you contributed doesn't require any permissions however unlike the however unlike the media the media the media collection the read external storage permission does not give you any access
to non media files contributed by other apps to gain access you will need to launch the system picker with storage access framework api's this will allow the user to explicitly select what files or directories you can have access to you I need the user grants you access to
a file this will be a full access so you can read edit or delete non media media files or non media files as you please without any additional consent this is to give our users full control over when apps want to access non media files that are sensitive
so for instance their bank statements protecting user data is our top priority on Android which is why in Android 10 we started restricting access – sensitive metadata contained in media files primarily location we can transparent this tripley's metadata when your app is reading media files contributed by other
apps to access this sensitive metadata you can request the access media location permission this is the run this permission is not user visible in the settings UI however it is a run-time permission so you have to declare it in your manifest and request it at runtime alongside the
read external storage permission since this is the runtime permission there is no guarantee that you will always have access to this permission even if you have to read external storage permission this is especially true on enterprise devices where a device policy client can you know modify or change
permissions requested by other apps if it is absolutely important for your app that you always have the exact bytes of the file on disk you can use the media store set require original API this will ensure that you always have the exact bytes of the file on disk
or receive an exception if reduction would have otherwise occurred in Android 10 we lockdown file path access to the common directories this any Buddhist deliver on our privacy objectives of protecting the user however after going through the developer feedback we saw that this required a lot of effort
from you to add up straightaway under the next Android release we would like to do this work for you I must emphasize that all apps should still use the media store whenever possible however we understand that there are a lot of apps dependent on libraries written in C
and C++ but only accept file paths this really is the only case where we expect you to write new code that uses file paths a useful implementation detail that may help understand the trade-offs between file paths and the media store is that under the hood foul Pat requests
or are you requests using file paths are delegated to the media store you can think of the file of file passes as a convenience API to the media store this means that there is some performance impact of using file paths and there's really no feature feature benefits hence
have a strong recommendation to use the media store directly additionally all the media story enforcement's also apply here media must be created in the appropriate media directories so no music in the pictures directory for instance to access media files created by other apps you will need to request
the read external storage permission location reduction while reading media files contributed by other apps will still occur so if you do not have the access media location permission granted also creating non media files must happen in the Downloads directory so you must create non media files like PDFs
in the Downloads directory and also reading non media files created by other apps will require the storage access framework api's files created by your app will be attributed correctly so this will count towards your app disk usage on the device the team has run lots of benchmarks on
sequential random read and write workloads the conclusion here is that there is certainly some performance impact to use an implementing file path requests and delegation into the media store however this is negligible in most cases especially at lower your rates if you really care about performance you shouldn't
measure your use cases to see how much impact file part access has on your apps performance alternatively you can just use the media store API select Li and this is guaranteed to give you the best performance in all cases and a bit more detail if you really insist
on using file paths opens and the first reads after opening the file are fairly expensive so if you are going to use file paths please try to avoid opening and closing the same file multiple times we have seen some apps in the world doing this and this can
noticeably degrade io throughput and battery performance if you are building an app that does heavy i/o so in the order of say 300 megabytes per second we would really love to hear from you so please come say hi at the sandbox in Android 10 required user consent to
edit or delete media not contributed by your app to do this you must use the media store api's to trigger a dialog to request user consent if the user accepts you will get a callback into your app and you can proceed to access the file either with file
paths or with the media story api's note that you will not get a prompt with just the file path access so without the prior explicit user grant within media store api's trying to edit or delete delete files contributed by other apps so media files contributed by other apps
will just fail in the next Android release we are improving the user consent flow for editing or deleting media introduced in Android 10 so now you can bat multiple edit orders requests in one dialogue instead of pop in one dialogue per request as it was wasn't the case
in Android 10 this just significantly improve the UX in your app and was a popular request in the last release and we are very thrilled to deliver this to you you always have the option to copy and edit to copy files to your apps directory on external storage
and edit the copy or we would only recommend this for one of edits and small sized files since we do not want to clutter our users disk and the copied file will count against your the apps disk usage now I will hand back to Roxy to talk about
more storage changes in the next Android release thanks them so as we mentioned in order to read edit or delete files that were not created by your app that aren't media files you're going to need to use the storage access framework api's so the way it so storage
access framework api is have we saw we're used by some apps that need that wanted to you get broad access to shared storage and as I mentioned that's not the intent of those api's so in order to prevent this we made some changes to the UX when and
when the intent action open documentary is launched so action open document tree is an intent specifically for an app to request an entire directory that it wants to read and write access to in the next version of Android apps will not be able to ask the user to
select the route anything under Android slash data or the Downloads directory apps can still select individual files from the Downloads directory it just can't select the entire directory we're also adding a special app access for apps that can truly demonstrate a need to four broads for broad access
to start to shared storage their unlimited number of use cases that we believe can demonstrate this need a couple examples that we know of our file manager and backup and restore apps only apps that can prove this need will be granted this access in order to demonstrate it
you'll need to submit a declaration form to Google Play the Google Play Developer console and only if waitlisted your will your app be able to be submitted and then you can ask the user for this special app access if you are white listed and the user grants through
your app this access you'll get an unfiltered view of milner of media store that includes non media files however these apps will not get access to external app directories this is like we mentioned before which we believe that these these directories should be more protected I want to
emphasize that this access will not be granted for apps that simply want to create their own file picking experience those apps should use the system picker now we created the request legacy storage request external legacy storage flag in android 10 as a response to developer feedback for apps
that need more time to adapt to scope storage however in future versions of Android this flag will no longer be available so only apps that have this special app access will be able to get a broad view of shared storage I also hope that we've demonstrated in this
in this talk that we're really responsive to developer feedback on this topic so we I really encourage you even though we're not enforcing this until the future version of Android that you try out all the scope storage changes and you let us know about use cases that you
feel are not supported and should be I also want to remind developers that as you move to target Android 10 if you have any files that are in shared storage like PDFs or media files that are outside the organized directories you'll need to move them into your app
and your app storage otherwise as if you target Android 10 you will lose access to these files so now let's recap some of the some of the features of scope storage mandroid 10 and some of the new features that we've talked about first media can be contributed without
permission now also non media files can be contributed to the Downloads directory however non media files reading those files will require using the system picker and the storage access framework api's apps now need to request permission to see location metadata of images and videos access media location and
the next version of android will be introducing file path access for reading media in the next version we'll be updating the media modification api is including a bulk option and we'll be restricting the storage access framework so that app so that users cannot select specific broad access directories
that will give broad access to shared storage or sensitive directories and there will be a special app access for select use cases whitelisted by google play and all this will be enforced by target SDK now handed over ta scene we'll go through some practical examples thanks Roxy so
as Roxy and Xia mentioned we're simplifying the developer experience on scape storage but with all these api's it may not be easy to figure out which one you should use in your application so let me sum up all of that with code sample like that you can have
an idea of what you use imagine a media player app it needs to get all the videos on the on the phone device and be able to display and play them whenever the user wants it for this we will use the media story pi the advantage of it
is to have all the files indexed so it helps in terms of performance of discoverability we can get the files through the content resolver API and we can use advanced query parameters like size duration or resolution finally because we're accessing files created by other applications we need to
add the raid external storage permission in our manifest so the media store API is a contract between the media provider and the application that is it week we read through the content resolver which is has a similar API to an SQL query which is the data we want
with a projection filter it with with some selected argument an order it based on the selected columns for our query in this case we want to have the ID column the display name duration and size those columns are part of the media store video columns contract you can
have the full list on the website on our documentation so for our selections argument we want to filter on videos equal to five minutes or longer and as the duration column is in millisecond we need to convert it to the right unit we're touched all of those elements
to our query with the right media store video content URI we also want to order it by their duration the query returns us a cursor to go through all the results we need to get we need to sorry my bad we need to get each columns index to
be able to get the content if the column doesn't exist we get an exception we're caching the indexes here to avoid having to fetch them whenever for each result for each row we loop through our cursor and get data for each column based on itself since we're accessing
the external content here right from the media store video collection we need to use the base URI and happen the idea of the video at the end of it like that we get our content here right and we can use it finally we get all the data we
can add that to our list and display it to the user now for a second use case let's imagine a photo filter app you can create images as well as editing or deleting images created by other applications for this we will use again the media story API because
as mentioned we're possibly editing images from other applications we will need the read external storage permission whenever we will edit or delete an image the OS will prompt a dialect to the user to get that content from the next Android release you will be able to bulk all
of those requests within a single dialogue lastly if you want to provide that enhance experienced based on the location of where the photos was taken you need to add the access media allocation to be able to get all the exit data of any file remember that you have
to double check if you still have access to this media location you should not assume having it all the time to be able to prompt the dialogue to the user we need first to open a file descriptor on the write mode which had the first time initially it
will throw us an exception a recoverable security exception within that exception data there is a pending intent that we need to send to the system to be able to get the dialogue once the user constant given we can open again the file descriptor and have finally access to
it now let's imagine another use case a Productivity application something like Gmail for example we may want to write an email and attach a file to it any type of it can be a PDF a zip file or something else for this we will use the storage access
framework whenever you need it you don't actually have to ask for permission you can use any files available on the user device as well as using content from other content providers like Google Drive locally or remotely the API is abstracting all the complexity for you so you just
consume it in the same way whether it's on device or remotely the UI is handled by an intent so here we need to use a specific intent to be able to have the file picker to select a file we need to use the action open document intent and
to select a folder we need to use action open document tree the access on the file is not granted all the time until the user reboot you still have access to it if you want to persist it you need to use take persistable you write permission method with
it you will have always access to well to that file but you also need to check that this fight hasn't been deleted in the meantime inside that will productivity app the first thing we will do is to use that action open document in this case we will set
the category to category Epona ball which means we will get the operable entities means the files to avoid not having the calendar of contact entries for example we set the right mind type in this case we just want to have the application PDF which means the PDF at
this point we can render the PDF for example in our draft email just to show a preview to the user using PDF render API for example and lastly we can just send the email and having our whole experience a second example within our gmail app is the ability
to save any attached files to an email wherever the user want on device for this we will use action create document intent it has similar parameters to the previous action we just created with an extra one here extra title where we can put a default file name the
user can still change that within the fine saver UI lastly we can open find the scripture on it and just edit it on the write mode and add the content there we want our ecosystem of applications to thrive with a privacy first approach if you provide backup or
file management features you can get an unfiltered view of the media story API it requires a special access permission which needs to be approved in the play console like SMS and call permissions we're here to help you getting ready for scope storage if you have any question come
to talk to us at our sandbox booth we'll have the experts answering all your questions but among our recommendations one of them is do not use hard-coded paths the paths may change between different versions or the fine may be deleted or moved to a different folder you should
not assume having that the main thing we advise you to use is to mix the content URI with a pendant ID in the same way I presented earlier you can check out all our code sample on our github which highlights all the possible use cases with scope storage
and you can already test and return SDK by targeting it on Android studio we shape the features on scape storage based on your feedback if you have a specific use case that our API is not covering yet please find a bud or an issue on our bug tracker
to help us making a better scape storage for you if you have any questions again come to our sandbox booth it's an opportunity for you to have access to so many engineers from the product team also to understand more you or your own use age of scope storage
and trying to understand how can we shape better the API please you please fill the survey a line available there you can take a pictures I will wait a quick moment there I want to see phones thank you everyone [Music]
Nhận xét
Đăng nhận xét