android系统之属性系统详解

android系统之属性系统详解

1 属性系统概述 (2)

2 property数据的编译 (3)

2.1 /default.prop (3)

2.2 /system/build.prop (4)

2.3 其他属性文件 (8)

3 property的相关实现代码和流程 (9)

3.1 property服务端解析 (10)

3.1.1 Server端代码流程 (10)

3.1.1.1 init.c下的整体流程 (10)

3.1.1.2 创建共享内存区域 (10)

3.1.1.3加载根目录下的default.prop (15)

3.1.1.4加载其余4个属性文件的全部属性，并启动socket监听 (16)

3.1.1.5 property触发器执行函数加入队列 (18)

3.1.1.6 执行队列中的property任务 (19)

3.1.1.7 将property的监听socket加入待检查的socket数组 (20)

3.1.1.8 检查上层有哪些端口连接请求 (20)

3.1.1.9 property设置的响应 (20)

3.1.2 详解server端的property_set (25)

3.1.2.2 find_property (26)

3.1.2.3 prop数据二叉树存取解析 (29)

3.1.2.4 __system_property_update (30)

3.1.2.5 __system_property_add (30)

3.1.2.6 write_persistent_property (30)

3.1.2.7 property_changed (31)

3.2 property系统桥梁 (31)

3.2.1 __system_property_set (32)

3.2.2__system_property_set (33)

3.3 property客户端解析 (34)

3.3.1 客户端C层访问属性系统 (34)

3.3.2 客户端shell命令访问 (35)

3.3.3 客户端java层访问 (36)

4总结 (37)

附录一：《GCC的constructor》 (37)

1 属性系统概述

属性property系统是android的一个重要特性。它作为一个服务运行，管理系统配置和状态。所有这些配置和状态都是属性。每个属性是一个键值对（key/value pair），其类型都是字符串。

从功能上看，属性与windows系统的注册表非常相似。

属性系统的架构如下图所示。

图中有3个进程、一组永久属性文件和一块共享内存区域。共享内存区域是所有属性记录的临时存储所在。

property service:

只有该进程才可以写入共享内存区域，它负责从永久文件中加载属性记录

并将它们保存在共享内存中。

property consumer：

该进程将共享内存加载到其自身的虚拟地址空间，并直接访问这些属性。

这并不是一个特定的进程，是加载属性的read操作库的客户端统称。

property setter:

该进程同样将共享内存加载到其自身的虚拟地址空间，但其不能直接写该内存。当setter试图增加或者更新一个属性时，它将该属性通过unix domain socket发送至property service服务进程。

注意：

后两者实际并不是一个特定的进程，是加载属性的get和set操作库的客户端进程统称。

下面以海思3798MV100平台(android4.4.2)为例来分析属性系统。

2 property数据的编译

属性文件的生成依赖于build/core/Makefile文件，该文件实际上主导所有文件的编译，我们这里主要看其中的属性文件的编译引导。

2.1 /default.prop

这是根目录下的属性文件，该属性文件的主要内容是adb控制相关的属性：

编译后该文件的输出：

1)\out\target\product\i3798MV100\root\default.prop

build/core/Makefile中对default.prop的编译引导如下：

TARGET_ROOT_OUT 就是\out\target\product\i3798MV100\root\，对应设备文件系统的根目录。

可见该属性文件的内容来自于build/tools/post_process_props.py，该py文件根据环境的设定，来设置相关的adb控制属性。

2) \out\target\product\i3798MV100\recovery\root\default.prop

recovery系统是boot启动后的另外一个程序分支，所以这里面也需要一个属性文件，build/core/Makefile中对default.prop拷贝了一份到recovery\root\下，

TARGET_RECOVERY_ROOT_OUT就是

\out\target\product\i3798MV100\recovery\root\

2.2 /system/build.prop

这是system分区下的属性文件，该文件收集的属性信息较多，也是打交道最多的属性文件。主要内容是常用的版本信息，平台信息，其他设备控制信息等：

编译后该文件放在\out\target\product\i3798MV100\system\build.prop，TARGET_OUT 就是\out\target\product\i3798MV100\system\，也就是system分区在设备文件系统下的对应目录。

build/core/Makefile中对build.prop的编译引导如下：

在build.prop的编译中，定义了BUILD_FINGERPRINT，BUILD_DISPLAY_ID等变量，都在build/tools/buildinfo.sh中被引用。

由上面的mk文件片段也可以看出build.prop的生成依赖于

1)引入BUILDINFO_SH的内容

数据来源：build/tools/buildinfo.sh

BUILDINFO_SH在本文件定义，为BUILDINFO_SH := build/tools/buildinfo.sh。

最后通过bash $(BUILDINFO_SH) > $@解析得到buildinfo.sh中的全部属性。

2)引入INTERNAL_BUILD_ID_MAKEFILE的内容

数据来源：/build/core/build_id.mk

INTERNAL_BUILD_ID_MAKEFILE在./build/core/version_defaults.mk中定义:

BUILD_SYSTEM在/build/core/main.mk中定义

所以INTERNAL_BUILD_ID_MAKEFILE就是/build/core/build_id.mk。

这里的作用仅仅是引入build_id.mk 中定义的BUILD_ID变量。

3)引入(BUILD_SYSTEM)/version_defaults.mk的内容

数据来源：/build/core/ version_defaults.mk

即/build/core/ version_defaults.mk，这里也主要是引入version_defaults.mk中的多个变量。

4)引入system_prop_file的内容

数据来源：实际不存在

system_prop_file是在build.prop生成的末尾阶段以下面的方式引入的

system_prop_file自身是在该Makefile文件中定义的，如下：

经find命令搜索，TARGET_SYSTEM_PROP没有找到定义，所以走下一条路径，而TARGET_DEVICE_DIR在/build/core/config.mk中定义：

这段代码的意思TARGET_DEVICE_DIR就是Boardconfig.mk文件所在的目录，那么就应该是/device/hisilicon/Hi3798MV100

（注：经过在Makefile中打印TARGET_DEVICE_DIR：

$(warning ******TARGET_DEVICE_DIR:$(TARGET_DEVICE_DIR)******)，也确实是该目录

）。

所以这里就是要加载/device/hisilicon/Hi3798MV100下的system.prop,不过本平台在该目录下没有这个文件，所以system_prop_file的加载在这里是没有意义的

（注：经过在Makefile中打印TARGET_DEVICE_DIR：

$(foreach file,$(system_prop_file), \

warning ***********system_prop 1111 file:$(file)*************)

也确实打印不出任何目录）。

mr

5)引入ADDITIONAL_BUILD_PROPERTIES的内容

数据来源：\build\core\product_config.mk

\device\hisilicon\Hi3798MV100\下的customer.mk和device.mk

\build\core\main.mk:

ADDITIONAL_BUILD_PROPERTIES是在build.prop生成的最后阶段以下面的方式引入的

ADDITIONAL_BUILD_PROPERTIES这个变量自身是在该Makefile文件中定义的，如下：

ADDITIONAL_BUILD_PROPERTIES最主要的作用就是引入另一个变量

PRODUCT_PROPERTY_OVERRIDES，而这是在\build\core\product_config.mk中完成的：

ADDITIONAL_BUILD_PROPERTIES := \

$(ADDITIONAL_BUILD_PROPERTIES) \

$(PRODUCT_PROPERTY_OVERRIDES)

PRODUCT_PROPERTY_OVERRIDES的实际内容就很多了，它在

\device\hisilicon\Hi3798MV100\下的customer.mk和device.mk，

\build\core\main.mk等文件中都大量增加各种属性，也由此被引入到build.prop中。如\device\hisilicon\Hi3798MV100\下的customer.mk下：

2.3 其他属性文件

开机启动时，属性系统还要加载以下3个文件或目录，但是他们要么一般不使用（前2者），要么是运行时生成（后者）。

/*经验证，在3798MV100平台上并不存在*/

#define PROP_PATH_SYSTEM_DEFAULT "/system/default.prop"

#define PROP_PATH_LOCAL_OVERRIDE "/data/local.prop"

/*这是存储persist属性的目录，所有persist属性被各自写为文件存储在这里*/

#define PERSISTENT_PROPERTY_DIR "/data/property"

3 property的相关实现代码和流程

property service运行于init进程中。

init进程首先创建一个共享内存区域，该内存实际是一个虚拟文件，打开并保存其fd。init进程将该区域通过使用了MAP_SHARED标志的mmap映射至它自身的虚拟地址空间，这样，任何对于该区域的更新对于所有进程都是可见的。

fd和区域大小被存储在一个名为ANDROID_PROPERTY_WORKSPACE的变量中。任何其他进程，比如consumer和setter将使用这个变量来获得fd和尺寸，这样它们就能mmap这个区域到它们自身的虚拟地址空间中。

该共享内存区域如下图所示：

3.1 property服务端解析

3.1.1 Server端代码流程

3.1.1.1 init.c下的整体流程

代码路径：\system\core\init\init.c

整个属性系统的server端都运行在init进程中，在该文件的main函数中有简明扼要的流程线索，见下面代码截图的8个要点：

下面仔细分析这8个环节。

3.1.1.2 创建共享内存区域

经分析，实际该共享内存是通过共享文件+镜像内存看来实现的，只不过文件本身是虚拟设备文件，也活动在内存中，所以也可以理解为共享内存。

1)源头：

\system\core\init\init.c下的main函数：

2)进入\system\core\init\property_service.c：进入property_init

进入init_property_area

3)进入\bionic\libc\bionic\system_properties.c

进入函数map_prop_area_rw：

特别注意：

a、mmap实现镜像内存

将文件和内存进行映射，文件内容对内存是透明的，同时对该内存的操作也会同步修改文件内容。

b、内存共享是变相实现，是共享文件+镜像内存，并非真正的共享内存。

从上面可以看出，android属性系统的property_area本质上不是共享内存，而是共享文件，各进程只是创建了对该文件的内存镜像，且只有init进程(中的pro[erty_service)的镜像具备写入权限。（当然该文件也是内存中的虚拟文件，所以说是共享内存也说得过去，不过这是变相的，不是使用共享内存的相关API）。

4)进程间共享文件

从上面的分析可以看到：

a、这里共享内存是基于共享文件。

b、共享的文件是property_filename

\bionic\libc\include\sys\_system_properties.h下定义：

#define PROP_FILENAME "/dev/__properties__"

\bionic\libc\bionic\system_properties.c下定义：

static char property_filename[PATH_MAX] = PROP_FILENAME;

c、操作property的进程间需要共享/dev/__properties__

那么/dev/__properties__文件到底是怎么共享的就需要被搞清楚了。

d、gcc之__libc_prenit特性实现文件共享

Android利用了gcc编译中的constructor属性，这个属性指明了一个__libc_prenit 函数，当libc库被加载时，将自动调用这个__libc_prenit函数，android正是把

/dev/__properties__的共享加入到这个函数内部，并进一步完成该共享文件到本地进程的映射工作。

简而言之，哪个进程加载libc,就加入了property系统的共享文件+镜像内存机制。\bionic\libc\bionic\ libc_init_dynamic.cpp

\bionic\libc\bionic\libc_init_common.cpp

5)\bionic\libc\bionic\system_properties.c

map_prop_area和map_prop_area_rw就只有文件打开方式，文件映射镜像内存的方式等方面的区别了

关于GCC中的constructor详细描述，请参照附录一《GCC中的constructor属性》

6)返回\system\core\init\property_service.c：

继续看init_property_area函数流程，进入：

再看init_workspace：

这个地方其实就是创建init进程下操作该共享文件的句柄而已，并保存在pa_workspace.全局变量中。

3.1.1.3加载根目录下的default.prop

1)源头：

\system\core\init\init.c下的main函数：

2)进入\system\core\init\property_service.c

PROP_PATH_RAMDISK_DEFAULT 在\bionic\libc\include\sys\_system_properties.h 中定义：

#define PROP_PATH_RAMDISK_DEFAULT "/default.prop"

注意加载属性的最后一步是把解析出来的属性通过property_set直接设置到镜像内存中，该函数的具体分析我们放到后面。

3.1.1.4加载其余4个属性文件的全部属性，并启动socket监听

1)源头

\system\core\init\init.c下的main函数：

将property_service_init_action标记为property_service_init加入到执行队列，在后面的while中去执行

\bionic\libc\include\sys\_system_properties.h中定义：

#define PROP_PATH_SYSTEM_BUILD "/system/build.prop"

#define PROP_PATH_SYSTEM_DEFAULT "/system/default.prop"

#define PROP_PATH_LOCAL_OVERRIDE "/data/local.prop"

#define PERSISTENT_PROPERTY_DIR "/data/property"

下面接着看property_service_init_action到底做了些什么

2) \system\core\init\init.c下的property_service_init_action

3) 进入\system\core\init\property_service.c：

注意最后一个/data/property不是文件，是一个目录，下面每一个属性都存储为一个文件。

重点注意create_socket，这个函数要完成创建socket，绑定本地通讯端口等。

首先传入create_socket的PROP_SERVICE_NAME的定义：

\bionic\libc\include\sys\_system_properties.h中定义

#define PROP_SERVICE_NAME "property_service"

create_socket中用到的ANDROID_SOCKET_DIR的定义：

\system\core\include\cutils\ sockets.h

#define ANDROID_SOCKET_DIR "/dev/socket"

4)进入\system\core\init\ util.c

最终新创建的socket绑定到/dev/socket/ property_service文件，实际就是local socket 的进程通讯模式。

3.1.1.5 property触发器执行函数加入队列

将init.rc这里rc脚本文件解析出来的所有和property相关的触发器加入执行队列

1)源头：\system\core\init\init.c下的main函数：

2) \system\core\init\init.c下的queue_property_triggers_action

3) \system\core\init\init_parser.c中的queue_all_property_triggers

3.1.1.6 执行队列中的property任务

源头：\system\core\init\init.c下的main函数：

进入execute_one_command：

不断通过外部循环获取队列中的action来执行。

注意这里面有一个隐藏任务：

当execute_one_command执行的是请一个service进程的时候，这里面还顺带完成了将prop area内存区的pa_workspace注册到环境变量的工作，以便其他进程也可以读取该变量。

3.1.1.7 将property的监听socket加入待检查的socket数组

源头：\system\core\init\init.c下的main函数：

进入\system\core\init\property_service.c，这里get_property_set_fd返回的property_set_fd正是步骤3.1.1.4创建的监听socket。

3.1.1.8 检查上层有哪些端口连接请求

源头：\system\core\init\init.c下的main函数：

3.1.1.9 property设置的响应

1)源头：\system\core\init\init.c下的main函数：