Android Q is fundamentally changing the way storage works on your phone. In every version up to Pie, Android’s storage worked like a desktop computer: you can use any app you want to read or write any file (if you grant an app permission to do so). With Q, Google is introducing (and requiring) “Scoped Storage,” which makes Android work more like an iPhone, where storage is isolated to each app. An app can only access its own files, and if it’s uninstalled, all its files are deleted.
Thankfully Android Q does still retain some of Android’s original behavior of a central filesystem. Unfortunately, it’s now cumbersome for the user to set-up apps to access it and has significantly reduced performance and capability. And developers will have to substantially recode apps to support it.
Apps that need general filesystem access, e.g. an office suite, image editor, or file manager, will now need to use an Android API called the “Storage Access Framework” (SAF), for all file operations. SAF has been available since Android 5.0 Lollipop, but developers tend to not use it unless required, as it has a difficult and poorly documented API, a poor user experience, poor performance, and poor reliability (largely in the form of device vendor-specific implementation issues). As a result of the difficulty in transitioning to SAF, Google has decided to allow apps that don’t yet indicate Android Q support to work as they used to, but this will change when the Play Store requires all apps to support Q next year.
The most obvious user-facing change with SAF is the experience of granting an app access to storage. For an app to get access, it makes a request to the OS, which then displays a directory chooser screen. On this screen the user selects the root of a folder hierarchy in which that app will be able to read and write files. The user must go through this process for each app that requires access to local files, or twice-per-app if they need to also grant it access to an external SD card.
Google did at least improve this process for Q beta 3, as prior betas did not allow an app to even suggest a location for the user to select, which required the user to do quite a bit of work to actually find their device’s primary storage.
File I/O performance takes somewhat of a hit under SAF, but the most outstanding problem lies in file directory operations, where it’s ~25 to 50 times slower than the conventional file access possible in Pie. In the case of file managers, that means it will take orders of magnitude longer to perform searches and storage usage calculations. A bug report with a demonstration app is available here.
Sample test run of SAFTest showing the performance difference between the conventional file I/O API with SAF.
An even greater performance issue is that some apps will have to copy files to their local “scoped storage” area before they are able to work with them. This can be problematic when such files are multiple gigabytes in size, e.g. in the case of video files or compressed archives. Many Android apps take advantage of the amazing number of open-source Java libraries in the developer community, and these libraries commonly require direct filesystem access to work. They are not Android-specific and would require rewriting to work with SAF. Even worse, many of Android’s own internal libraries won’t work with it, such as the package manager or the zip API. As a for-instance, a file manager won’t even be able to display the icon for an APK file (using the standard Android API) without first copying the entire APK to its own scoped storage area. Bug report.
For technically inclined folks, it’s presently possible to disable Android Q’s “Scoped Storage” on a per-app basis via ADB using an appops command. Root users can execute the commands directly on their device without a desktop computer. Such commands are described in the documentation as developer features and thus may be removed at any time.
Enable general storage access for an app:
adb shell cmd appops set your-package-name android:legacy_storage allow && \
adb shell am force-stop your-package-name
Disable general storage access for an app:
adb shell cmd appops set your-package-name android:legacy_storage default && \
adb shell am force-stop your-package-name
Google touts the security and privacy benefits of this change, but technically speaking, there is no improvement. Apps have had the ability to privately store files since Android 1.0, and almost all apps make use of this capability. When you grant an app access to the root directory of your storage via SAF, it can read, write, and send any file it wants to its nefarious developer in the exact same fashion it could when you granted an app access to storage in Pie.
The only “security improvement” comes about because it’s now a more arduous process for a user to do this. Unless of course an app only wants to steal your most personal information, like photos and videos you’ve taken, for which Google has added an alternative access solution which uses a simple pop-up click-yes security dialog.
It is not known what benefits Google hopes to achieve with this change. The official stated reason in the Android Q beta documentation is to “give users more control over their files and to limit file clutter.” Scoped storage, in its present form, is a new limitation of what the user is allowed to do, not an extension of their control. The claim of reducing clutter may be somewhat valid, but only because the change reduces the ability to use files at all. And “clutter” is increased when you consider the problem of some apps now having to duplicate files to work with them.
If Google is truly concerned about giving users more control over files and clutter, they should architect a solution that directly addresses that, rather than falsely branding the current Android Q design as such an improvement. The simplest answer would be to let users decide if they want an app to have scoped or general filesystem access, using the extant storage permission request dialog. If there is a particular concern for users making poor decisions here, it’s certainly possible to make that dialog more prominent and require additional user interaction to approve an app for full access.
The answer to how Android can give users more control of their files is to actually give users more control, not to take it away and fundamentally constrain the capabilities of the Android platform.
Editor’s Note: This is a guest article written by XDA Senior Member tliebeck, best known for his work on FX File Explorer. The contents of this article reflect his own opinion and analysis of Android Q’s Scoped Storage restrictions, with minimal input and editing from Mishaal Rahman, Editor-in-Chief of XDA-Developers. We reached out to Google to ask them about some of these concerns but have not heard back from the company by publication time.
The post The Storage Access Framework is the only way for apps to work with all your files in Android Q. And it’s terrible. appeared first on xda-developers.
0 comments:
Post a Comment