For some one-sided understanding of the Android file system

Android source code in this document are no partitions, estimated to be generated at compile time, but no proc directory in the directory out
# CAT / proc / partitions
Major Minor #blocks name
 254 zram0 0 496 040
 179 0 15.26784 million mmcblk0
 179 1 3072 mmcblk0p1
 mmcblk0p2 5120 2 179
 179 10240 mmcblk0p3. 3
 179 mmcblk0p4. 4 10240
 179 49152 mmcblk0p5. 5
 179 256 mmcblk0p6. 6
 179 384. 7 mmcblk0p7
 179 mmcblk0p8. 8 16384
 179 16384 mmcblk0p9. 9
 179 10 6144 mmcblk0p10
 179 mmcblk0p11. 11 512
 179 8192 12 is mmcblk0p12
 179 13 is 10240 mmcblk0p13
 179 14 1024 mmcblk0p14
 179 15 5120 mmcblk0p15
 179 16 5120 mmcblk0p16
 179. 17 2048 mmcblk0p17
 179 18 is 2048 mmcblk0p18
 179. 19 36 224 mmcblk0p19
 179 20 is 2.62144 million mmcblk0p20
 179 21 is 434 176 mmcblk0p21
 179 22 is 12,006,912 mmcblk0p22
 179 23 is 16384 mmcblk0p23
 179 96 4096 mmcblk0rpmb
 179 64 mmcblk0boot1 4096
 179 32 4096 mmcblk0boot0

Based on the above information, zram0 partition is used as swap, it is to be used as virtual memory, because in fact emmc belong to the external memory device.
When the memory space is not enough, will the non-application of data from memory into the foreground compression zram0, when the application is invoking again, put the data from
zram0 swapped back in, such a program will start up faster than directly kill the application.

Partition table:
Device / MediaTek / Build / Build / Tools / ptgen / MT8163 / partition_table_MT8163.xls
modify the partition size can be arranged in this document:
Device / yongyida / yyd8163_tb_m / BoardConfig.mk
look after the compilation has been generated partition size:
OUT /target/product/yyd8163_tb_m/obj/PTGEN/partition_size.mk
there are many configuration partition mounted at the file path:
Vendor / MediaTek / Proprietary / Hardware / fstab / mt8163 / fstab.in
use the following command:
LS the -l / dev / Block / Platform / MTK-msdc.0 / 11230000.MSDC0 / by-name /
lrwxrwxrwx the root Boot the root 2018-01-19 15:29 -> / dev / Block / mmcblk0p8
lrwxrwxrwx the root the root 2018-01-19 15: Cache 29 -> / dev / Block / mmcblk0p21
lrwxrwxrwx the root DKB the root 2018-01-19 15:29 -> / dev / Block / mmcblk0p18
lrwxrwxrwx root     root              2018-01-19 15:29 expdb -> /dev/block/mmcblk0p13
lrwxrwxrwx root     root              2018-01-19 15:29 flashinfo -> /dev/block/mmcblk0p2
lrwxrwxrwx root     root              2018-01-19 15:29 frp -> /dev/block/mmcblk0p14
lrwxrwxrwx root     root              2018-01-19 15:29 kb -> /dev/block/mmcblk0p17
lrwxrwxrwx root     root              2018-01-19 15:29 lk -> /dev/block/mmcblk0p7
lrwxrwxrwx root     root              2018-01-19 15:29 logo -> /dev/block/mmcblk0p12
lrwxrwxrwx root     root              2018-01-19 15:29 metadata -> /dev/block/mmcblk0p19
lrwxrwxrwx root     root              2018-01-19 15:29 nvram -> /dev/block/mmcblk0p2
lrwxrwxrwx root     root              2018-01-19 15:29 para -> /dev/block/mmcblk0p11
lrwxrwxrwx root     root              2018-01-19 15:29 persist -> /dev/block/mmcblk0p5
lrwxrwxrwx root     root              2018-01-19 15:29 proinfo -> /dev/block/mmcblk0p1
lrwxrwxrwx root     root              2018-01-19 15:29 protect1 -> /dev/block/mmcblk0p3
lrwxrwxrwx root     root              2018-01-19 15:29 protect2 -> /dev/block/mmcblk0p4
lrwxrwxrwx root     root              2018-01-19 15:29 recovery -> /dev/block/mmcblk0p9
lrwxrwxrwx root     root              2018-01-19 15:29 seccfg -> /dev/block/mmcblk0p6
lrwxrwxrwx root     root              2018-01-19 15:29 secro -> /dev/block/mmcblk0p10
lrwxrwxrwx root     root              2018-01-19 15:29 system -> /dev/block/mmcblk0p20
lrwxrwxrwx root     root              2018-01-19 15:29 tee1 -> /dev/block/mmcblk0p15
lrwxrwxrwx root     root              2018-01-19 15:29 tee2 -> /dev/block/mmcblk0p16
lrwxrwxrwx root     root              2018-01-19 15:29 userdata -> /dev/block/mmcblk0p22

root@xxx:/ # ls /dev/block/mmcblk0*
/dev/block/mmcblk0
/dev/block/mmcblk0boot0
/dev/block/mmcblk0boot1
/dev/block/mmcblk0rpmb
/dev/block/mmcblk0p1
/dev/block/mmcblk0p2
/dev/block/mmcblk0p3
/dev/block/mmcblk0p4
/dev/block/mmcblk0p5
/dev/block/mmcblk0p6
/dev/block/mmcblk0p7
/dev/block/mmcblk0p8
/dev/block/mmcblk0p9
/dev/block/mmcblk0p10
/dev/block/mmcblk0p11
/dev/block/mmcblk0p12
/dev/block/mmcblk0p13
/dev/block/mmcblk0p14
/dev/block/mmcblk0p15
/dev/block/mmcblk0p16
/dev/block/mmcblk0p17
/dev/block/mmcblk0p18
/dev/block/mmcblk0p19
/dev/block/mmcblk0p20
/dev/block/mmcblk0p21
/dev/block/mmcblk0p22
/dev/block/mmcblk0p23
/dev/block/mmcblk0p24
/dev/block/mmcblk0p25
/dev/block/mmcblk0p26
/dev/block/mmcblk0p27
/dev/block/mmcblk0p28
/dev/block/mmcblk0p29
/dev/block/mmcblk0p30
/dev/block/mmcblk0p31
/ dev / block / mmcblk0p32
want to know more you can own to the next / dev / block look.


device / mediatek / build / build / tools / ptgen / MT8163 / partition_table_MT8163.xls
partition table partition name and mount point of the corresponding table



to add a partition called Test:

USRDATA partition that any user can read and write the partition, the size can not be set size equal to emmc total capacity minus the size of other partitions.

Increasing a partition mtk see Document: Introduction and the Partition Layout Customization

mmcblk0 as eMMC block device;
mmcblk0boot0 and the corresponding two mmcblk0boot1 Area Partitions the Boot;
mmcblk0rpmb the Partition was RPMB,
mmcblk0px UDA is split up into SW Partitions;
not know Recovery. fstab and how Recover_emmc.fstab are defined, and the corresponding device mount point the partition table is not the same. The partition table
partitions are mapped to sequentially mmcblk0 soft partition, i.e. from mmcblk0p1 to mmcblk0p23
device number is the partition name, such as: / dev / block / mmcblk0p6, this file exists in the file system android.
ls -l /dev/block/platform/mtk-msdc.0/11230000.MSDC0/by-name/ command is the name of the corresponding partition function device number (formal partition name) listed
with the Android file system and partition-related VoldManager, ptgen

related command
df
CAT / proc / mtd
CAT / proc / partitions
       
OUT / target / Product / yyd8163_tb_m / obj / PTGEN / partition_size.mk look after the compilation has been generated partition size
device / mediatek / build / build / tools / ptgen /MT8163/partition_table_MT8163.xls # to see the original partition and what partition allocated


Vendor / MediaTek / Proprietary / Hardware / fstab / mt8163 / fstab.in
/devices/soc/11230000.mmc* Auto Defaults voldmanaged = vfat sdcard0: Auto, encryptable UserData =
/devices/soc/11240000.mmc* Auto vfat Defaults voldmanaged = sdcard1: Auto, encryptable = UserData



following is the reference:

eMMC partition management

Partitions the Overview

eMMC standard, the Flash Memory inside region divided into four categories, can support up to eight hardware partitions, as shown below:


Overview


In general, Boot Area Partitions RPMB Partition capacity and size are typically 4MB, chip manufacturers also provide the opportunity to partially arranged. General Purpose Partitions (GPP) by default at the factory is not supported, i.e., the partition is not present, require the user to actively enable and configure the capacity size GPP which it is to be used, the number of GPP may be 1 - 4, each GPP the capacity can be different sizes. User Data Area (UDA), compared with a total capacity of capacity size minus the size of other partitions occupied capacity. More details of the partitions will be described in subsequent sections.

Partition addressing
eMMC storage space for each partition is independent of hardware addressed, namely access address 0 - partition size. Which particular hardware partition data read and write operations actually accessed by PARTITION_CONFIG Field Extended CSD register in the eMMC Bit [2: 0]: PARTITION_ACCESS determined, the user can access the hardware switches by configuring the partition PARTITION_ACCESS. In other words, before the user access to specific partition, you need to send commands to configure PARTITION_ACCESS, then send the relevant data access request. More details related to read and write data, please refer to the section eMMC bus protocol.
eMMC each hardware partition has its own features, multiple partitions designed to provide convenience for different application scenarios.

Area Partitions the Boot

the Boot Area contains two Boot Area Partitions, mainly used for storage Bootloader, SOC support from the eMMC boot the system.
Capacity size

size two Boot Area Partitions are exactly the same, BOOT_SIZE_MULT Field decided by Extended CSD register, the size is calculated as follows:
Size = 128Kbytes X BOOT_SIZE_MULT
Generally, Boot Area Partition size are 4 MB, i.e. BOOT_SIZE_MULT 32, portions of the chip manufacturers will provide functionality to change rewritable BOOT_SIZE_MULT Boot Area Partition the capacity size. BOOT_SIZE_MULT can be up to 255, i.e., the maximum capacity of the Boot Area Partition size may be 255 x 128 KB = 32640 KB = 31.875 MB.
Area starts from the Boot

eMMC defined in the Boot State, after Power-up, HW reset or SW reset, if certain conditions are met, eMMC will enter the State. Boot State into the condition as follows:
Original the Boot Operation
the CMD signal is low for less than 74 clock cycles, triggered Original Boot Operation, into the Boot State.


Alternative Boot Operation
After 74 clock cycles, before the first CMD signal sent down the CMD1 or Host, Host COM0 0xFFFFFFFA transmission parameter when the triggered Alternative Boot Operation, into the Boot State.


In Boot State, if the configuration BOOT_ACK, eMMC will first send a "010" ACK packet, then Host eMMC will be up to 128Kbytes x BOOT_SIZE_MULT the Boot Data sent to. During transmission, Host pulled by the signal CMD (Original Boot), or Reset command is transmitted (Alternative Boot) is interrupted eMMC data transmission, Boot Data transfer is completed.
The Boot Data Bit PARTITION_CONFIG Field of the Extended CSD register [5: 3]: BOOT_PARTITION_ENABLE settings can be read from the Boot Area Partition 1, Boot Area Partition 2 or User Data Area.
Boot Data stored in Boot Area to be more secure than in the User Data Area, you can reduce accidental changes cause the system to not start, but can not update the system situation.
(Boot State more details, please refer to the bus protocol Boot State eMMC section)
write protection

by setting the Extended CSD register BOOT_WP Field, can be configured independently for the two write protect function Boot Area Partition, to prevent data from being inadvertently rewritten or clashes.
eMMC defines two Boot Area of the write-protect mode:
after Power-on write protection, enable, if eMMC power-down, write-protect function failure, you need to configure every time after Power on
the Permanent write protection, enable, even down will not fail, take the initiative to shut down will fail

RPMB Partition

RPMB(Replay Protected Memory Block)Partition 是 eMMC 中的一个具有安全特性的分区。
eMMC 在写入数据到 RPMB 时,会校验数据的合法性,只有指定的 Host 才能够写入,同时在读数据时,也提供了签名机制,保证 Host 读取到的数据是 RPMB 内部数据,而不是攻击者伪造的数据。
RPMB 在实际应用中,通常用于存储一些有防止非法篡改需求的数据,例如手机上指纹支付相关的公钥、序列号等。RPMB 可以对写入操作进行鉴权,但是读取并不需要鉴权,任何人都可以进行读取的操作,因此存储到 RPMB 的数据通常会进行加密后再存储。
容量大小

两个 RPMB Partition 的大小是由 Extended CSD register 的 BOOT_SIZE_MULT Field 决定,大小的计算公式如下:
Size = 128Kbytes x BOOT_SIZE_MULT
一般情况下,Boot Area Partition 的大小为 4 MB,即 RPMB_SIZE_MULT 为 32,部分芯片厂家会提供改写 RPMB_SIZE_MULT 的功能来改变 RPMB Partition 的容量大小。RPMB_SIZE_MULT 最大可以为 128,即 Boot Area Partition 的最大容量大小可以为 128 x 128 KB = 16384 KB = 16 MB。
Replay Protect 原理

使用 eMMC 的产品,在产线生产时,会为每一个产品生产一个唯一的 256 bits 的 Secure Key,烧写到 eMMC 的 OTP 区域(只能烧写一次的区域),同时 Host 在安全区域中(例如:TEE)也会保留该 Secure Key。
在 eMMC 内部,还有一个RPMB Write Counter。RPMB 每进行一次合法的写入操作时,Write Counter 就会自动加一 。
通过 Secure Key 和 Write Counter 的应用,RMPB 可以实现数据读取和写入的 Replay Protect。
RPMB 数据读取

RPMB 数据读取的流程如下:


Host 向 eMMC 发起读 RPMB 的请求,同时生成一个 16 bytes 的随机数,发送给 eMMC。
eMMC 将请求的数据从 RPMB 中读出,并使用 Secure Key 通过 HMAC SHA-256 算法,计算读取到的数据和接收到的随机数拼接到一起后的签名。然后,eMMC 将读取到的数据、接收到的随机数、计算得到的签名一并发送给 Host。
Host 接收到 RPMB 的数据、随机数以及签名后,首先比较随机数是否与自己发送的一致,如果一致,再用同样的 Secure Key 通过 HMAC SHA-256 算法对数据和随机数组合到一起进行签名,如果签名与 eMMC 发送的签名是一致的,那么就可以确定该数据是从 RPMB 中读取到的正确数据,而不是攻击者伪造的数据。
通过上述的读取流程,可以保证 Host 正确的读取到 RPMB 的数据。
RPMB 数据写入

RPMB 数据写入的流程如下:


Host 按照上面的读数据流程,读取 RPMB 的 Write Counter。
Host 将需要写入的数据和 Write Counter 拼接到一起并计算签名,然后将数据、Write Counter 以及签名一并发给 eMMC。
eMMC 接收到数据后,先对比 Write Counter 是否与当前的值相同,如果相同那么再对数据和 Write Counter 的组合进行签名,然后和 Host 发送过来的签名进行比较,如果签名相同则鉴权通过,将数据写入到 RPMB 中。
通过上述的写入流程,可以保证 RPMB 不会被非法篡改。
更多 RPMB 相关的细节,可以参考 eMMC RPMB 章节。

General Purpose Partitions

eMMC 提供了 General Purpose Partitions (GPP),主要用于存储系统和应用数据。在很多使用 eMMC 的产品中,GPP 都没有被启用,因为它在功能上与 UDA 类似,产品上直接使用 UDA 就可以满足需求。
容量大小

eMMC 最多可以支持 4 个 GPPs,每一个 GPP 的大小可以单独配置。用户可以通过设定 Extended CSD register 的以下三个 Field 来设 GPPx (x=1~4) 的容量大小:
GP_SIZE_MULT_x_2
GP_SIZE_MULT_x_1
GP_SIZE_MULT_x_0
GPPx 的容量计算公式如下:
Size = (GP_SIZE_MULT_x_2 * 2^16 + GP_SIZE_MULT_x_1 * 2^8 + GP_SIZE_MULT_x_0 * 2^0) * (Write protect group size)
Write protect group size = 512KB * HC_ERASE_GRP_SIZE * HC_WP_GRP_SIZE
eMMC 中,擦除和写保护都是按块进行的,上述表达式中的 HC_WP_GRP_SIZE 为写保护的操作块大小,HC_ERASE_GRP_SIZE 则为擦除操作的快的大小。
eMMC 芯片的 GPP 的配置通常是只能进行一次 (OTP),一般会在产品量产阶段,在产线上进行。
分区属性

eMMC 标准中,为 GPP 定义了两类属性,Enhanced attribute 和 Extended attribute。每个 GPP 可以设定两类属性中的一种属性,不可以同时设定多个属性。


Enhanced attribute
Default, 未设定 Enhanced attribute。
Enhanced storage media, 设定 GPP 为 Enhanced storage media。
在 eMMC 标准中,实际上并未定义设定 Enhanced attribute 后对 eMMC 的影响。Enhanced attribute 的具体作用,由芯片制造商定义。
在实际的产品中,设定 Enhanced storage media 后,一般是把该分区的存储介质从 MLC 改变为 SLC,提高该分区的读写性能、寿命以及稳定性。由于 1 个存储单元下,MLC 的容量是 SLC 的两倍,所以在总的存储单元数量一定的情况下,如果把原本为 MLC 的分区改变为 SLC,会减少 eMMC 的容量,就是说,此时 eMMC 的实际总容量比标称的总容量会小一点。(MLC 和 SLC 的细节可以参考 Flash Memory 章节内容)
Extended attribute
Default, 未设定 Extended attribute。
System code, 设定 GPP 为 System code 属性,该属性主要用在存放操作系统类的、很少进行擦写更新的分区。
Non-Persistent,设定 GPP 为 Non-Persistent 属性,该属性主要用于存储临时数据的分区,例如 tmp 目录所在分区、 swap 分区等。
在 eMMC 标准中,同样也没有定义设定 Extended attribute 后对 eMMC 的影响。Extended attribute 的具体作用,由芯片制造商定义。Extended attribute 主要是跟分区的应用场景有关,厂商可以为不用应用场景的分区做不同的优化处理。

User Data Area

User Data Area (UDA) 通常是 eMMC 中最大的一个分区,是实际产品中,最主要的存储区域。
容量大小

UDA 的容量大小不需要设置,在配置完其他分区大小后,再扣除设置 Enhanced attribute 所损耗的容量,剩下的容量就是 UDA 的容量。
软件分区

为了更合理的管理数据,满足不同的应用需求,UDA 在实际产品中,会进行软件再分区。目前主流的软件分区技术有 MBR(Master Boot Record)和 GPT(GUID Partition Table)两种。这两种分区技术的基本原理类似,如下图所示:


软件分区技术一般是将存储介质划分为多个区域,既 SW Partitions,然后通过一个 Partition Table 来维护这些 SW Partitions。在 Partition Table 中,每一个条目都保存着一个 SW Partition 的起始地址、大小等的属性信息。软件系统在启动后,会去扫描 Partition Table,获取存储介质上的各个 SW Partitions 信息,然后根据这些信息,将各个 Partitions 加载到系统中,进行数据存取。
MBR 和 GPT 此处不展开详细介绍,更多的细节可以参考 wikipedia 上 MBR 和 GPT 相关介绍。
区域属性

eMMC 标准中,支持为 UDA 中一个特定大小的区域设定 Enhanced attribute。与 GPP 中的 Enhanced attribute 相同,eMMC 标准也没有定义该区域设定 Enhanced attribute 后对 eMMC 的影响。Enhanced attribute 的具体作用,由芯片制造商定义。
Enhanced attribute
Default, 未设定 Enhanced attribute。
Enhanced storage media, 设定该区域为 Enhanced storage media。
在实际的产品中,UDA 区域设定为 Enhanced storage media 后,一般是把该区域的存储介质从 MLC 改变为 SLC。通常,产品中可以将某一个 SW Partition 设定为 Enhanced storage media,以获得更好的性能和健壮性。

 

eMMC 分区应用实例
在一个 Android 手机系统中,各个分区的呈现形式如下:
mmcblk0 为 eMMC 的块设备;
mmcblk0boot0 和 mmcblk0boot1 对应两个 Boot Area Partitions;
mmcblk0rpmb 则为 RPMB Partition,
mmcblk0px 为 UDA 划分出来的 SW Partitions;
如果存在 GPP,名称则为 mmcblk0gp1、mmcblk0gp2、mmcblk0gp3、mmcblk0gp4;
root@xxx:/ # ls /dev/block/mmcblk0*
/dev/block/mmcblk0
/dev/block/mmcblk0boot0
/dev/block/mmcblk0boot1
/dev/block/mmcblk0rpmb
/dev/block/mmcblk0p1
/dev/block/mmcblk0p2
/dev/block/mmcblk0p3
/dev/block/mmcblk0p4
/dev/block/mmcblk0p5
/dev/block/mmcblk0p6
/dev/block/mmcblk0p7
/dev/block/mmcblk0p8
/dev/block/mmcblk0p9
/dev/block/mmcblk0p10
/dev/block/mmcblk0p11
/dev/block/mmcblk0p12
/dev/block/mmcblk0p13
/dev/block/mmcblk0p14
/dev/block/mmcblk0p15
/dev/block/mmcblk0p16
/dev/block/mmcblk0p17
/dev/block/mmcblk0p18
/dev/block/mmcblk0p19
/dev/block/mmcblk0p20
/dev/block/mmcblk0p21
/dev/block/mmcblk0p22
/dev/block/mmcblk0p23
/dev/block/mmcblk0p24
/dev/block/mmcblk0p25
/dev/block/mmcblk0p26
/dev/block/mmcblk0p27
/dev/block/mmcblk0p28
/dev/block/mmcblk0p29
/dev/block/mmcblk0p30
/dev/block/mmcblk0p31
/dev/block/mmcblk0p32
每一个分区会根据实际的功能来设定名称。
root@xxx:/ # ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/
lrwxrwxrwx root root 2015-01-03 04:03 boot -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 2015-01-03 04:03 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 2015-01-03 04:03 custom -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-01-03 04:03 devinfo -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 2015-01-03 04:03 expdb -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-01-03 04:03 flashinfo -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 2015-01-03 04:03 frp -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-01-03 04:03 keystore -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 2015-01-03 04:03 lk -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2015-01-03 04:03 lk2 -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2015-01-03 04:03 logo -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 2015-01-03 04:03 md1arm7 -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2015-01-03 04:03 md1dsp -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2015-01-03 04:03 md1img -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2015-01-03 04:03 md3img -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2015-01-03 04:03 metadata -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2015-01-03 04:03 nvdata -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-01-03 04:03 nvram -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2015-01-03 04:03 oemkeystore -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2015-01-03 04:03 para -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-01-03 04:03 ppl -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-01-03 04:03 proinfo -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2015-01-03 04:03 protect1 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2015-01-03 04:03 protect2 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2015-01-03 04:03 recovery -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-01-03 04:03 rstinfo -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2015-01-03 04:03 seccfg -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2015-01-03 04:03 secro -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 2015-01-03 04:03 system -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 2015-01-03 04:03 tee1 -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 2015-01-03 04:03 tee2 -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 2015-01-03 04:03 userdata -> /dev/block/mmcblk0p31


文件系统中的文件(或者目录)的owner或者owner组,要想拥有owner组的权限,可以根据
/system/etc/permissions/platform.xml文件,在manifest中加入对应的permission

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (C) 2008 The Android Open Source Project

     Licensed under the Apache License, Version 2.0 (the "License");
     you may not use this file except in compliance with the License.
     You may obtain a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

     Unless required by applicable law or agreed to in writing, software
     distributed under the License is distributed on an "AS IS" BASIS,
     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     See the License for the specific language governing permissions and
     limitations under the License.
-->

<!-- This file is used to define the mappings between lower-level system
     user and group IDs and the higher-level permission names managed
     by the platform.

     Be VERY careful when editing this file!  Mistakes made here can open
     big security holes.
-->
<permissions>

    <!-- ================================================================== -->
    <!-- ================================================================== -->
    <!-- ================================================================== -->

    <!-- The following tags are associating low-level group IDs with
         permission names.  By specifying such a mapping, you are saying
         that any application process granted the given permission will
         also be running with the given group ID attached to its process,
         so it can perform any filesystem (read, write, execute) operations
         allowed for that group. -->

    <permission name="android.permission.BLUETOOTH_ADMIN" >
        <group gid="net_bt_admin" />
    </permission>

    <permission name="android.permission.BLUETOOTH" >
        <group gid="net_bt" />
    </permission>

    <permission name="android.permission.BLUETOOTH_STACK" >
        <group gid="net_bt_stack" />
    </permission>

    <permission name="android.permission.NET_TUNNELING" >
        <group gid="vpn" />
    </permission>

    <permission name="android.permission.INTERNET" >
        <group gid="inet" />
    </permission>

    <permission name="android.permission.READ_LOGS" >
        <group gid="log" />
    </permission>

    <permission name="android.permission.READ_EXTERNAL_STORAGE" >
        <group gid="sdcard_r" />
    </permission>

    <permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
        <group gid="sdcard_r" />
        <group gid="sdcard_rw" />
    </permission>

    <permission name="android.permission.ACCESS_ALL_EXTERNAL_STORAGE" >
        <group gid="sdcard_r" />
        <group gid="sdcard_rw" />
        <group gid="sdcard_all" />
    </permission>

    <permission name="android.permission.WRITE_MEDIA_STORAGE" >
        <group gid="media_rw" />
    </permission>

    <permission name="android.permission.ACCESS_MTP" >
        <group gid="mtp" />
    </permission>

    <permission name="android.permission.NET_ADMIN" >
        <group gid="net_admin" />
    </permission>

    <!-- The group that /cache belongs to, linked to the permission
         set on the applications that can access /cache -->
    <permission name="android.permission.ACCESS_CACHE_FILESYSTEM" >
        <group gid="cache" />
    </permission>

    <!-- RW permissions to any system resources owned by group 'diag'.
         This is for carrier and manufacture diagnostics tools that must be
         installable from the framework. Be careful. -->
    <permission name="android.permission.DIAGNOSTIC" >
        <group gid="input" />
        <group gid="diag" />
    </permission>

    <!-- Group that can read detailed network usage statistics -->
    <permission name="android.permission.READ_NETWORK_USAGE_HISTORY">
        <group gid="net_bw_stats" />
    </permission>

    <!-- Group that can modify how network statistics are accounted -->
    <permission name="android.permission.MODIFY_NETWORK_ACCOUNTING">
        <group gid="net_bw_acct" />
    </permission>

    <permission name="android.permission.LOOP_RADIO" >
        <group gid="loop_radio" />
    </permission>

    <!-- ================================================================== -->
    <!-- ================================================================== -->
    <!-- ================================================================== -->

    <!-- The following tags are assigning high-level permissions to specific
         user IDs.  These are used to allow specific core system users to
         perform the given operations with the higher-level framework.  For
         example, we give a wide variety of permissions to the shell user
         since that is the user the adb shell runs under and developers and
         others should have a fairly open environment in which to
         interact with the system. -->

    <assign-permission name="android.permission.MODIFY_AUDIO_SETTINGS" uid="media" />
    <assign-permission name="android.permission.ACCESS_SURFACE_FLINGER" uid="media" />
    <assign-permission name="android.permission.WAKE_LOCK" uid="media" />
    <assign-permission name="android.permission.UPDATE_DEVICE_STATS" uid="media" />
    <assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="media" />

    <assign-permission name="android.permission.ACCESS_SURFACE_FLINGER" uid="graphics" />

    <!-- This is a list of all the libraries available for application
         code to link against. -->

    <library name="android.test.runner"
            file="/system/framework/android.test.runner.jar" />
    <library name="javax.obex"
            file="/system/framework/javax.obex.jar"/>

    <feature name="android.software.app_widgets"/>
    <feature name="android.software.device_admin"/>

</permissions>




 

Guess you like

Origin blog.csdn.net/b1480521874/article/details/79108743