Android2.2源码属性服务分析
属性服务property service
大家都知道，在windows中有个注册表，里面存储的是一些键值对。注册表的作用就是：系统或者应用程序将自己的一些属性存储在注册表中，即使系统或应用程序重启，它还能够根据之前在注册表中设置的属性，进行相应的初始化工作。Android平台也提供了类似的机制，那就是“属性服务”。我们可以使用adb shell登录真机或模拟器后，使用getprop命令来查看当前系统中有哪些属性。
在init.c中与属性服务有关的代码有：
①Property_init();
②if (!is_charger)
property_load_boot_defaults();
③queue_builtin_action(property_service_init_action, "property_service_init");
3.1 属性服务的初始化
1、创建属性空间
|
static int init_property_area(void) { if (property_area_inited) //先判断是否已经初始化过属性 return -1; if(__system_property_area_init()) //★初始化系统属性区域 return -1; if(init_workspace(&pa_workspace, 0)) //将工作空间绑定到系统属性区域上 return -1; fcntl(pa_workspace.fd, F_SETFD, FD_CLOEXEC); property_area_inited = 1; return 0; } |
这里详细分析一下__system_property_area_init()函数的功能。
这个函数调用了map_prop_area_rw()函数：
|
static int map_prop_area_rw() { /*设备是一个临时文件系统，所以我们可以在其中挖出一块区域 * 用作共享内存。 */ const int fd = open(property_filename, O_RDWR | O_CREAT | O_NOFOLLOW | O_CLOEXEC | O_EXCL, 0444); //创建or打开属性文件
if (fd < 0) { if (errno == EACCES) { /* for consistency with the case where the process has already * mapped the page in and segfaults when trying to write to it */ abort(); } return -1; }
// TODO: Is this really required ? Does android run on any kernels that // don't support O_CLOEXEC ? const int ret = fcntl(fd, F_SETFD, FD_CLOEXEC); //表示在调用exec相关函数时，文件会关闭。 if (ret < 0) { close(fd); return -1; }
if (ftruncate(fd, PA_SIZE) < 0) { //改变文件的大小为PA_SIZE close(fd); return -1; } pa_size = PA_SIZE; pa_data_size = pa_size - sizeof(prop_area); compat_mode = false;
void *const memory_area = mmap(NULL, pa_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); //★使用mmap将刚创建的属性文件映射为共享内存，该内存可读可写。 if (memory_area == MAP_FAILED) { close(fd); return -1; }
prop_area *pa = new(memory_area) prop_area(PROP_AREA_MAGIC, PROP_AREA_VERSION);
/* 将我们创建的属性区域嵌入到系统库函数属性中*/ __system_property_area__ = pa;
close(fd); return 0; } |
当init进程创建完属性文件后，就会根据设备是否处于充电状态来决定是否加载属性表。如果不处于充电状态，那么就调用函数：
property_load_boot_defaults(); //加载default.prop文件
到这里属性服务的初始化工作就做完了。不过上面的有一条代码__system_property_area__ = pa; 并不像它看起来那么简单！
__system_property_area__ 是bionic libc库中输出的一个变量，那么这里为什么要给它赋值呢？原来，虽然属性区域是由init进程创建的，但是Android系统希望其他进程也能访问这个区域，所以它做了如下两个工作：
①把属性区域创建在共享内存上，这样就可以跨进程访问了。
②如何让其他进程知道这个共享内存呢？Android利用了gcc的constructor属性，这个属性指明了一个__libc_prenit函数，当bionic libc库被加载时，将自动调用这个__libc_prenit函数，在这个函数里面完成共享内存到本地进程的映射工作。详细内容请看下面。
2、客户端进程获取属性空间
在Libc_init_dynamic.c中定义了__libc_prenit函数，这个函数调用了__libc_init_common(KernelArgumentBlock& args)函数。具体代码如下：
|
__attribute__((constructor)) static void __libc_preinit() { // Read the kernel argument block pointer from TLS. void** tls = __get_tls(); KernelArgumentBlock** args_slot = &reinterpret_cast<KernelArgumentBlock**>(tls)[TLS_SLOT_BIONIC_PREINIT]; KernelArgumentBlock* args = *args_slot;
// Clear the slot so no other initializer sees its value. // __libc_init_common() will change the TLS area so the old one won't be accessible anyway. *args_slot = NULL;
__libc_init_common(*args);
// Hooks for the debug malloc and pthread libraries to let them know that we're starting up. pthread_debug_init(); malloc_debug_init(); } |
__libc_init_common函数代码如下：
|
void __libc_init_common(KernelArgumentBlock& args) { // Initialize various globals. environ = args.envp; errno = 0; __libc_auxv = args.auxv; __progname = args.argv[0] ? args.argv[0] : "<unknown>"; __abort_message_ptr = args.abort_message_ptr;
// AT_RANDOM is a pointer to 16 bytes of randomness on the stack. __stack_chk_guard = *reinterpret_cast<uintptr_t*>(getauxval(AT_RANDOM)); //在TLS(安全套阶层协议)中获取主线程，并将其加入到线程列表中 pthread_internal_t* main_thread = __get_thread(); _pthread_internal_add(main_thread); //初始化客户端的属性存储区域，关联到前面的系统属性存储区域上！这就实现了客户端进程直接读取系统属性存储区域的数据。但我这里有一个问题：实现关联过后，客户端进程对属性区域是拥有读写权限的，但在2.0的代码里却只有读的权限，这是为什么呢？ __system_properties_init(); // Requires 'environ'. } |
3.2 属性服务器的分析
1、启动属性服务器
属性服务器的启动由init进程完成，就是前面提及的queue_builtin_action(property_service_init_action, "property_service_init");
它其实就是执行start_property_service函数：
|
void start_property_service(void) { int fd; /*加载三个属性文件。Android系统共提供了4中属性文件： * PROP_PATH_SYSTEM_BUILD: “/system/build/prop” * PROP_PATH_SYSTEM_DEFAULT: “/system/default.prop” * PROP_PATH_FACTORY: ？ * PROP_PATH_LOCAL_OVERRIDE: “/data/local.prop” *如果属性文件以ro.开头，表示只读；以persist开头，表示永久; *如果属性名称以“net.”开头，当设置这个属性时，“net.change”属性将会自*动设置，以加入到最后修改的属性名。 */ load_properties_from_file(PROP_PATH_SYSTEM_BUILD, NULL); load_properties_from_file(PROP_PATH_SYSTEM_DEFAULT, NULL); load_properties_from_file(PROP_PATH_FACTORY, "ro."); load_override_properties(); //加载/data/local.prop属性文件 /* Read persistent properties after all default values have been loaded. */ /*这个函数就是加载在/data/property目录下的永久属性文件，这些文件的 *文件名均为persist开头的。 */ load_persistent_properties(); //创建socket用于IPC通信 fd = create_socket(PROP_SERVICE_NAME, SOCK_STREAM, 0666, 0, 0, NULL); if(fd < 0) return; fcntl(fd, F_SETFD, FD_CLOEXEC); fcntl(fd, F_SETFL, O_NONBLOCK); //设置为非阻塞模式 //开始监听，最多同时监听8个socket listen(fd, 8); property_set_fd = fd; } |
总结：属性服务在加载了一些属性文件之后，就创建了一个用来接收请求的socket。那么这个socket是用来干什么的呢？或者说，它是如何处理这个socket的呢？
在上面的最后一行代码中，将该socket号赋给了property_set_fd。我们在init进程的for循环中找到了处理这个socket号的代码：
|
handle_property_set_fd(); //具体代码如下： void handle_property_set_fd() { prop_msg msg; int s; int r; int res; struct ucred cr; struct sockaddr_un addr; socklen_t addr_size = sizeof(addr); socklen_t cr_size = sizeof(cr); char * source_ctx = NULL;
if ((s = accept(property_set_fd, (struct sockaddr *) &addr, &addr_size)) < 0) { return; } ……. r = TEMP_FAILURE_RETRY(recv(s, &msg, sizeof(msg), 0)); if(r != sizeof(prop_msg)) { ERROR("sys_prop: mis-match msg size received: %d expected: %zu errno: %d\n", r, sizeof(prop_msg), errno); close(s); return; } //根据消息cmd的种类来分类处理socket请求，目前就一种 switch(msg.cmd) { case PROP_MSG_SETPROP: //设置属性 msg.name[PROP_NAME_MAX-1] = 0; msg.value[PROP_VALUE_MAX-1] = 0;
if (!is_legal_property_name(msg.name, strlen(msg.name))) { ERROR("sys_prop: illegal property name. Got: \"%s\"\n", msg.name); close(s); return; }
getpeercon(s, &source_ctx); //得到一个peersocket的上下文 /*如果是以ctl开头的消息，则认为是控制消息，控制消息用来执行一些命令。如使用adb shell登录手机后，输入setprop ctl.start bootanim就可以查看开机动画了。 */ if(memcmp(msg.name,"ctl.",4) == 0) { // Keep the old close-socket-early behavior when handling // ctl.* properties. close(s); if (check_control_perms(msg.value, cr.uid, cr.gid, source_ctx)) { handle_control_message((char*) msg.name + 4, (char*) msg.value); //handle msg其实就是去全局services_list列表中找到msg中提及的service，然后进行操作~ } else { ERROR("sys_prop: Unable to %s service ctl [%s] uid:%d gid:%d pid:%d\n", msg.name + 4, msg.value, cr.uid, cr.gid, cr.pid); } } else { //检查客户端进程是否有足够的权限 if (check_perms(msg.name, cr.uid, cr.gid, source_ctx)) { //★满足权限，就调用此函数设置属性值。后面会详细分析 property_set((char*) msg.name, (char*) msg.value); } else { ERROR("sys_prop: permission denied uid:%d name:%s\n", cr.uid, msg.name); }
// Note: bionic's property client code assumes that the // property server will not close the socket until *AFTER* // the property is written to memory. close(s); } freecon(source_ctx); //释放该上下文 break;
default: close(s); break; } } |
从上面看出当init进程接收到客户端关于属性服务的socket请求时，就会根据请求的种类进行区别处理。在满足权限检测后，就调用property_set函数进行相应处理，该函数的详细代码如下：
|
int property_set(const char *name, const char *value) { prop_info *pi; int ret;
size_t namelen = strlen(name); size_t valuelen = strlen(value); //格式检测 if (!is_legal_property_name(name, namelen)) return -1; if (valuelen >= PROP_VALUE_MAX) return -1; //从属性存储空间中找到该项属性 pi = (prop_info*) __system_property_find(name);
if(pi != 0) { //表示该项属性已经存在，需要更新操作 /* ro.* properties may NEVER be modified once set */ if(!strncmp(name, "ro.", 3)) return -1; //完成属性键值对的更新 __system_property_update(pi, value, valuelen); } else { //表示属性不存在，需要创建该属性 ret = __system_property_add(name, namelen, value, valuelen); if (ret < 0) { ERROR("Failed to set '%s'='%s'\n", name, value); return ret; } } /* If name starts with "net." treat as a DNS property. */ if (strncmp("net.", name, strlen("net.")) == 0) { if (strcmp("net.change", name) == 0) { return 0; } /* * The 'net.change' property is a special property used track when any * 'net.*' property name is updated. It is _ONLY_ updated here. Its value * contains the last updated 'net.*' property. */ property_set("net.change", name); } else if (persistent_properties_loaded && strncmp("persist.", name, strlen("persist.")) == 0) { /* * Don't write properties to disk until after we have read all default properties * to prevent them from being overwritten by default values. */ write_persistent_property(name, value); //如果是persist，就需要写入文件 } else if (strcmp("selinux.reload_policy", name) == 0 && strcmp("1", value) == 0) { selinux_reload_policy(); } /*调用此函数，完成属性的更改。其实就是将此次动作加入到全局property队列中，等待系统处理。这里提个问题，系统什么时候会处理全局队列中的动作呢？(答案参考init进程分析)*/ property_changed(name, value); return 0; } |
到此，属性服务端的工作就分析完了。下面看看客户端是如何设置属性的。
3、客户端发送属性服务请求
客户端通过properties.c文件中的property_set函数发送请求。需要注意的是，在该文件中，根据预定义情况，分别定义了3种不同的property_set函数。在Android手机中，使用的是第一种：
|
int property_set(const char *key, const char *value) { return __system_property_set(key, value); }
int __system_property_set(const char *key, const char *value) { if (key == 0) return -1; if (value == 0) value = ""; if (strlen(key) >= PROP_NAME_MAX) return -1; if (strlen(value) >= PROP_VALUE_MAX) return -1;
prop_msg msg; memset(&msg, 0, sizeof msg); msg.cmd = PROP_MSG_SETPROP; strlcpy(msg.name, key, sizeof msg.name); strlcpy(msg.value, value, sizeof msg.value);
const int err = send_prop_msg(&msg); //★调用此函数向init进程发送请求 if (err < 0) { return err; }
return 0; }
static int send_prop_msg(const prop_msg *msg) { const int fd = socket(AF_LOCAL, SOCK_STREAM, 0); if (fd < 0) { return -1; }
const size_t namelen = strlen(property_service_socket);
sockaddr_un addr; memset(&addr, 0, sizeof(addr)); strlcpy(addr.sun_path, property_service_socket, sizeof(addr.sun_path)); addr.sun_family = AF_LOCAL; socklen_t alen = namelen + offsetof(sockaddr_un, sun_path) + 1; if (TEMP_FAILURE_RETRY(connect(fd, reinterpret_cast<sockaddr*>(&addr), alen)) < 0) { //建立连接 close(fd); return -1; }
const int num_bytes = TEMP_FAILURE_RETRY(send(fd, msg, sizeof(prop_msg), 0)); //发送msg
int result = -1; if (num_bytes == sizeof(prop_msg)) { // We successfully wrote to the property server but now we // wait for the property server to finish its work. It // acknowledges its completion by closing the socket so we // poll here (on nothing), waiting for the socket to close. // If you 'adb shell setprop foo bar' you'll see the POLLHUP // once the socket closes. Out of paranoia we cap our poll // at 250 ms. pollfd pollfds[1]; pollfds[0].fd = fd; pollfds[0].events = 0; const int poll_result = TEMP_FAILURE_RETRY(poll(pollfds, 1, 250 /* ms */)); if (poll_result == 1 && (pollfds[0].revents & POLLHUP) != 0) { result = 0; } else { // Ignore the timeout and treat it like a success anyway. // The init process is single-threaded and its property // service is sometimes slow to respond (perhaps it's off // starting a child process or something) and thus this // times out and the caller thinks it failed, even though // it's still getting around to it. So we fake it here, // mostly for ctl.* properties, but we do try and wait 250 // ms so callers who do read-after-write can reliably see // what they've written. Most of the time. // TODO: fix the system properties design. result = 0; } }
close(fd); return result; } |
这里对num_bytes的处理进行说明：如果send函数返回的数值等于我们发送的msg的大小，那么就表示我们发送“成功”了。不过，“发送属性msg”成功并不意味着“属性修改”成功了。为什么呢？因为Init进程是单线程的，它接收我们的msg后，可能还在忙于处理其他的事务，而不能立即完成属性的更改。所以，我们需要等待它一段时间，让init进程真正地完成属性修改服务。那么什么时候才能确定它完成了呢？根据属性服务的设定，一旦init完成属性更改，就会关闭客户端本次请求socket，所以我们在客户端添加了poll函数来接收init进程的返回信息(此函数轮询250ms)。这里比较有趣的是，无论poll的返回信息是什么，系统都假设它成功地完成了属性更改——系统设计员在说了一大堆理由后，最后说了一句：系统属性设计还需完善~~。
至此整个属性服务就分析完毕了。相对来说，比init.rc的分析要简单多了！
