Android External Storage Permissions Analysis

I don't know if you have any discoveries, from the rookie's growth history: http://blog.csdn.net/zjbpku/article/details/25161131,

The KitKat version no longer supports the user's SDcard (secondary Storage) write operations. If the user wants to copy the files to the phone, they can only

stored in internal storage and cannot be stored in an external sdcard, and new folders cannot be created, which can be inconvenient for both users and developers. of the

In order to be unable to operate the external sdcard in the KitKat version, it is because Google has changed the permissions of this module, previously we can directly obtain Write_external_storage

and Read_external_storage permissions to operate the SDcard directly, it is not now, its purpose is to uninstall the software can be created by the software to delete all the files. According to Google

Employee Jeff SharKey, a developer of this module, introduced a new API to access secondary External Storage since KitKat, but this is not the focus of this article,

The focus of this paper is to analyze how external storage permissions work.

The Android version prior to KitKat will separate an external storage space (external storage) for the application, which may be sdcard

(pluggable external Sdcaard) may also be on the inside of the device only on the flash, we want to get Write_external_storage permissions on this block

Space for access, and does not require permissions if it is just reading content. In the 4.4 KitKat and later versions, Google made two changes: 1, need to read

Read_external_storage permissions, 2. Access to the directory under which the application belongs (e.g. Android/data/[package name])

The right.

In KitKat, external storage (external storage) is divided into parts: a "primary" section, one or more "secondary" sections. Before the KitKat.

API can be used to manipulate primary external storage,secondary external storage is a slight modification to the Write permission, as described above, in the application of the

The directory to which it belongs (for example, Android/data/[package name]) has all the permissions on the file, and the app does not have a write if it can manage it beyond the directory.

Permission to perform any write operation. This brings out the focus of this article. Ps:google does not require vendors to add additional permissions on SDcard operations, but

It is mandatory to require the manufacturer to restrict the secondary external storage. If you have questions about internal storage and external storage, you can look at the text

Document Https://developer.android.com/guide/topics/data/data-storage.html#filesInternal

According to Jeff SharKey, the current version of the Android system, KitKat, uses fuse (Filesysgem in userspace) to external storage

Management of the line. In order to obtain the necessary permissions during file creation, to dynamically accept or deny individual requests from users/groups, an Android daemon is involved with the fuse core

Driven interactions. This is only part of Android's use of Linux on removable volumes formatted with the Fat File System, and in the kernel it allows the use of more than basic

Multilevel permission control performed by the Owner/gouper/user. Check out Jeff Sharkey's explanation below:

Https://android.googlesource.com/platform/system/core/+/master/sdcard/sdcard.c

Before 4.4, the framework API did not change much to the operation of the storage volume (storage volumes), and the device manufacturer could create a single "primary" volume or multiple "secondary"

Volumes, and these different volumes can be managed by System services StorageManager and Mountservice, in which case accessing the "PRIMARY" section is like accessing a single external storage.

Many devices have SD cards, but they are not treated as external storage, which is actually the "secondary volume" of these devices. Samsung's Galaxy series, for example, is part of this

, in terms of permissions, the SD card is actually managed like an external storage volume, but as the "secondary external storage" of the device, there is no API to write.

The following code is from AOSP device storage conf iguration Example:

On initmkdir/mnt/shell/emulated 0700 shell shellmkdir/storage/emulated 0555 root Rootmkdir/mnt/media_rw/sdcard1 0700 Me DIA_RW Media_rwmkdir/storage/sdcard1 0700 root rootexport external_storage/storage/emulated/legacyexport EMULATED_ Storage_source/mnt/shell/emulatedexport Emulated_storage_target/storage/emulatedexport Secondary_storage/storage /sdcard1

Applications within the system can access any part of the secondary storage, which is almost impossible for third-party applications (Currently, ES Fileexplore, Airdroid, FX, and several other file applications through

A special workaround is to implement the operation of storing files externally on some models. (You can refer to the storage Options for how to manipulate files on 4.4.) Since the beginning of 4.4, Google has introduced

SAF Framework ( Storage Access Framework), it may be necessary for developers to familiarize themselves with the SAF framework if Google does not change its current operating rights to the 4.4 system's external SD.

another, in 4.4 system applications, you will find an apk called Documentui, which is used to handle some of the SAF's interfaces. )

The directory file under external storage has the same permissions as the following:

4.4 Devices:

[Email Protected]:/storage/sdcard # LLD---rwxr-x system sdcard_rw 2014-05-06 13:20 ALARMSD---rwxr-x system SDCARD_RW 2014 -05-06 13:21 Androidd---rwxr-x system sdcard_rw 2014-05-06 13:20 DCIMD---rwxr-x system sdcard_rw 2014-05-06 13:20 Download D---rwxr-x system sdcard_rw 2014-05-06 13:18 LOST.  Dird---rwxr-x system sdcard_rw 2014-05-06 13:20 moviesd---rwxr-x system sdcard_rw 2014-05-06 13:20 MUSICD---rwxr-x system  SDCARD_RW 2014-05-06 13:20 NOTIFICATIONSD---rwxr-x system sdcard_rw 2014-05-06 13:20 picturesd---rwxr-x system sdcard_rw 2014-05-06 13:20 PODCASTSD---rwxr-x system sdcard_rw 2014-05-06 13:20 ringtones[email Protected]:/storage/sdcard # ll and ROID/DATA/DRWXRWX---system sdcard_rw 2014-05-06 13:21 Com.google.android.apps.maps

4.4 Devices:

[Email Protected]:/storage/sdcard # lldrwxrwx---root sdcard_r 2013-11-27 23:35 alarmsdrwxrwx--x root Sdcard_r 2013-11-27 23:36 androiddrwxrwx---Root sdcard_r 2014-05-06 01:33 dcimdrwxrwx---root sdcard_r 2013-11-27 23:35 Downloaddrwxrwx---R Oot sdcard_r 2013-11-28 04:33 LOST.  dirdrwxrwx---root sdcard_r 2013-11-27 23:35 moviesdrwxrwx---root sdcard_r 2013-11-27 23:35 musicdrwxrwx---root sdcard_r  2013-11-27 23:35 notificationsdrwxrwx---root sdcard_r 2013-11-27 23:35 picturesdrwxrwx---root sdcard_r 2013-11-27 23:35 podcastsdrwxrwx---root sdcard_r 2013-11-27 23:35 ringtones[email Protected]:/storage/sdcard # ll Android/data/ DRWXRWX---u0_a33 sdcard_r 2013-11-27 23:36 com.google.android.apps.maps[email Protected]:/storage/sdcard # ll Android/ DATA/COM.GOOGLE.ANDROID.APPS.MAPS/DRWXRWX---u0_a33 sdcard_r 2013-11-27 23:36 cachedrwxrwx---u0_a33 sdcard_r 2013-11-27 23:36 TestData

Note: In 4.3, the SDCARD_RW group has full read and write permissions, in KitKat, the Sdcard_r group has +rwx all permissions, in fact, this is obviously wrong. Does not wait for all to be said,

Because the fuse daemon actively participates in modifying the permissions of the app at run time. This has a large impact on the execution of file APIs canWrite (), CanRead (), and CanExecute ().

, the values returned by these methods are recorded separately in the kernel file system, so they all return true even if attempting to open the file with POSIX will fail. (in 4.4 of the external SD

Card, it is not possible to write files in the folder, but when you try to call the CanWrite () method to determine if the folder is writable, it will still return a true value, so this method is not available)

Android.permission.WRITE_EXTERNAL_STORAGE permissions are granted to members of the Sdcard_r and SDCARD_RW groups, but authentication of write permissions in KitKat requires some

The fuse daemon is used to supplement the file system's permissions, and the fuse daemon enforces each permission (that is, the number of access

According to the directory stored android/data/pack-agename ... and some public directories). The fuse daemon is also strong for non-default owners configured with the-W flag in the SDCARD_RW group

To give write-protected permission to the system.

Service sdcard/system/bin/sdcard-u 1023-g 1023-l/data/media/mnt/shell/emulated    class Late_startservice FUSE_SDC Ard1/system/bin/sdcard-u 1023-g 1023-w 1023-d/mnt/media_rw/sdcard1/storage/sdcard1    class Late_start    disabl Ed

From the above two sentences can be seen, fuse daemon Force control GID 1023 (MEDIA_RW, System application only) to Secondar storage write operation. Re-Introduction

A problem, in 4.4, external storage is divided into primary and secondary, in the primary section (built-in sdcard) is writable, while in the secondary section

(external SDcard) is not allowed, that fuse daemon how to distinguish between control? According to Jeff, "-W 2013" indicates the mandatory use of MEDIA_RW GID to

The secondary section has write permissions.

Let's comb this out, what can and cannot be done for developers if you are working on a KitKat device that has an external SD card? Given that the developer will try to

Some of the actions and results:

Summing up, since the beginning of 4.4 Google Secondary volume restrictions, not only for the user inconvenience, but also for equipment manufacturers and developers to bring a lot of inconvenience, Huawei

To this end, we sent a notice to the developers: Android4.4 on the application of the external card compatibility issues and solutions. Today, in addition to some of the OEM's own permission to modify the ROM

No restrictions on third-party applications, Daniel also for the user of the root of the device to modify the Platform.xml file to modify the permissions (specific method Baidu) so that third-party applications can operate

External SD card, and some of the file management tools mentioned above can also operate an external SD card. Regardless of what Google is doing to limit its intentions, we want Google to think about it from a user's perspective,

Make the better of the Android system. Thank you for the help of the developer of the FX file management tool Tod Liebeck in g+ on my questions, and thanks for giving

Tod Liebeck is a developer of X-plore that solves the KitKat external SD file operation scheme.