Android2.2 系统init.rc介绍

本文介绍了Android系统中的关键启动脚本init.rc。详细解释了init.rc中的Commands、Actions、Triggers、Services、Options及Properties等元素,并给出了实际示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 在 Android中使用启动脚本init.rc,可以在系统的初始化过程中进行一些简单的初始化操作。这个脚本被直接安装到目标系统的根文件系统中,被 init可执行程序解析。 init.rc是在init启动后被执行的启动脚本,其语法主要包含了以下内容:

Commands:命令
Actions: 动作
Triggers:触发条件
Services:服务
Options: 选项
Propertise:属性

(1) Commands是一些基本的操作,例如:
mkdir /sdcard 0000 system system
mkdir /system
mkdir /data 0771 system system
mkdir /cache 0770 system cache
mkdir /config 0500 root root
mkdir /sqlite_stmt_journals 01777 root root
mount tmpfs tmpfs /sqlite_stmt_journals size=4m
这些命令在init可执行程序中被解析,然后调用相关的函数来实现。

(2) Actions(动作)表示一系列的命令,通常在Triggers(触发条件)中调用,动作和触发条件的形式为:
on <trigger>
<command>
<command>
<command>

动作的使用示例如下:
on init
export PATH /sbin:/system/sbin:/system/bin:/system/xbin
mkdir /system
init表示一个触发条件,这个触发事件发生后,进行设置环境变量和建立目录的操作称为一个“动作”


(3) Services(服务)通常表示启动一个可执行程序,Options(选项)是服务的附加内容,用于配合服务使用。

service vold /system/bin/vold
socket vold stream 0660 root mount

service bootsound /system/bin/playmp3
user media
group audio
oneshot

vold和bootsound分别是两个服务的名称,/system/bin/vold和/system /bin/playmp3分别是他们所对应的可执行程序。
socket、user、group、oneshot就是配合服务使用的选项。其中oneshot选项表示该服务只启动一次,而如果没有oneshot选项,
这个可执行程序会一直存在--如果可执行程序被杀死,则会重新启动。

(4) Properties(属性)是系统中使用的一些值,可以进行设置和读取。

setprop ro.FOREGROUND_APP_MEM 1536
setprop ro.VISIBLE_APP_MEM 2048
on property:ro.kernel.qemu=1
start adbd
setprop 用于设置属性,on property可以用于判断属性,这里的属性在整个Android系统运行中都是一致的。

init脚本的关键字可以参考init进程的system/core/init/keyword.h文件。
init.rc的使用方法,可以参考说明文件system/core/init/readme.txt

如果想要修改启动过程只需要修改init.c(system/core/init)或者init.rc里的内容即可.

 

(5)如何android不能上网可以在此文件中添加如下:

 setprop net.dns1 ***.***.***.***,

<think>嗯,用户现在想了解Android系统中不同init.zygote*.rc文件的区别,以及为什么zygote进程使用Socket通信。之前用户已经问过类似的问题,关于zygote为什么用Socket而不是Binder,我之前已经回答过,现在需要结合新的引用内容来补充。 首先,用户提供的引用中提到init.rc会启动zygote进程,通过执行app_process,参数包括--zygote和--start-system-server。不同的init.zygote*.rc文件应该对应不同的架构,比如32位、64位或混合模式。我需要解释这些文件的区别,可能涉及ABI(应用程序二进制接口)的支持,比如纯32位、64位,或者32+64混合运行环境。比如,init.zygote32.rc对应纯32位,init.zygote64_32.rc可能主64位,同时支持32位应用。然后,关于zygote使用Socket的原因,之前已经讨论过Binder的线程模型与fork不兼容的问题,但现在需要结合用户提供的引用,特别是引用[1]和[2],其中提到zygote是通过init进程启动的,而Binder驱动可能还未初始化,所以使用Socket更早可用。此外,启动顺序中SystemServer由Zygote fork出来,之后才初始化Binder,所以Zygote必须用Socket。 需要注意引用中提到的app_main.cpp和参数传递,比如--zygote参数启动ZygoteInit,这可能涉及到Socket的创建过程。需要将Socket通信的原因与这些引用结合起来,强调启动顺序和依赖关系。另外,用户可能想知道这些rc文件的具体区别,比如每个文件中的service配置差异,参数的不同,比如是否启用64位支持,或者是否启动SystemServer。需要检查引用中的内容,比如引用[2]提到init.zygote32.rc的参数是-Xzygote /system/bin--zygote--start-system-server,其他文件可能有不同的参数,如是否包含--enable-64bit或类似选项。 最后,生成相关问题,可能涉及其他rc文件的作用、ABI兼容性问题,或者Socket通信的具体实现细节。</think>### init.zygote*.rc文件区别解析 #### 1. **架构差异与ABI兼容性** Android系统通过不同的`init.zygote*.rc`文件适配多种CPU架构,具体差异如下: | 文件名 | 适用场景 | 关键参数示例 | |-------------------------|--------------------------------------------------------------------------|------------------------------------------------------------------------------| | `init.zygote32.rc` | 纯32系统(armeabi-v7a等) | `--zygote`、`--start-system-server` | | `init.zygote64.rc` | 纯64位系统(arm64-v8a等) | `--zygote`、`--start-system-server`、`--enable-64bit` | | `init.zygote32_64.rc` | 混合架构(64位内核+32位用户空间),**主进程64位**,支持32位应用 | `--zygote`、`--start-system-server`、`--enable-32bit` | | `init.zygote64_32.rc` | 混合架构(32位内核+64位用户空间),**主进程32位**,支持64位应用(罕见) | `--zygote`、`--start-system-server`、`--enable-64bit` | **核心差异点**: - **二进制执行路径**:部分架构可能使用`/system/bin/app_process32`或`app_process64`[^2] - **参数标志**:如`--enable-64bit`用于开启64位支持 - **兼容层配置**:混合架构需指定多ABI库路径(如`/system/lib`和`/system/lib64`) #### 2. **zygote进程采用Socket通信的原因** 结合系统启动流程和架构设计,主要原因如下: ##### 2.1 **启动时序依赖** - **Binder驱动未就绪** Zygote由`init`进程通过`execve`启动(引用[1]),此时Binder驱动尚未初始化完成。Socket作为POSIX标准组件,可在系统启动早期直接使用。 - **SystemServer的启动顺序** Zygote通过`--start-system-server`参数fork出SystemServer进程(引用[2]),而Binder框架由SystemServer初始化。若Zygote使用Binder,将导致循环依赖。 ##### 2.2 **fork()的线程安全要求** - **单线程约束** Zygote在`fork()`前需确保仅存在主线程。Socket通信采用单线程阻塞模型(`poll`或`accept`),而Binder依赖多线程池,可能导致子进程线程状态异常[^1]。 ```c // 伪代码:zygote的Socket监听循环 while (true) { int client_fd = accept(server_fd); // 阻塞等待连接 parse_command(client_fd); // 解析启动参数 fork_and_specialize(); // 单线程安全fork } ``` ##### 2.3 **轻量化与隔离性** - **低开销通信** Socket仅需传递应用启动参数(如UID、包名),数据量极小,而Binder的序列化机制(`Parcel`)在此场景冗余。 - **资源隔离需求** Binder的共享内存机制(`mmap`)会污染子进程的初始状态,而Socket通过文件描述符隔离,更符合Zygote的"干净fork"要求。 ##### 2.4 **安全控制** - **SELinux策略限制** Zygote的Socket(`/dev/socket/zygote`)通过SELinux策略仅允许SystemServer等特权进程访问,例如: ```sepolicy allow system_server zygote_socket:sock_file { write }; ``` ### 架构对比示例 | 特性 | Socket方案 | Binder方案 | |--------------------|---------------------------|---------------------------| | 启动阶段可用性 | init阶段即可使用 | 依赖SystemServer初始化 | | 线程模型兼容性 | 单线程安全 | 多线程导致fork风险 | | 资源占用 | 文件描述符隔离 | 共享内存污染子进程 | | 安全控制 | SELinux路径限制 | Binder UID验证 |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值