Android守卫进程——Vold (Volume Daemon)

简介

介绍：Vold 是用来管理 android 体系的存储装备，如U盘、SD卡、磁盘等移动装备的热插拔、挂载、卸载、格式化
框架布局：Vold 在体系中以守卫进程存在，是一个单独的进程。处于Kernel和Framework之间，是两个层级连接的桥梁。下图是Vold在Android体系的团体架构

组成

重要模块

• NetLinkManager（简称NM）：内部建立了 socket 连接，重要作用是吸收来自 Kernel 的 Uevent 消息。例如SD卡的插拔等动作都会引起 Kernel 向 NM 发送 Uevent 消息
￮ NetlinkHandler：负责剖析内核的 Uevent ，它本质上是一个SocketListener类，它们的继续关系，即：NetlinkHandler、NetlinkListener和SocketListener继续关系如下：
• VolumeManager模块（简称VM）：Android13 中是VM处置惩罚完从NM吸收到的NetlinkEvent后，通过binder将消息通报给StorageManagerService 进行下一步处置惩罚，然后 VM 根据 StorageManagerService 返回的消息管理卷
￮ VoldNativeService模块：重要是与 StorageManagerService 进行通信，继续 BinderService 类，启动过程中重要注册了接口，使其他服务可以通过IVold可以找到，然后启动线程
• StorageManager 模块：Framework 层的API，用于APP和别的体系组件访问存储相干的功能。它是 StorageManagerService 的客户端，通过 Binder 调用 StorageManagerService 提供的 API
Vold 启动流程

与其说是Vold启动流程，更不如说是Android存储的初始化工作，Vold的重要功能，就是存储区的管理。Android 的初始化工作可以大抵分为三个阶段：

• 清理环境，由于Android是支持多用户的，启动时的可能是另一个用户，以是需要把之前的用户数据清理干净
  
• 启动存储服务，如Vold、StorageManager等等
  
• 挂载emulated存储（用于模仿SD卡，历史原因，下面章节会偏重介绍）
  

第一个用户态进程init
• init.rc 启动 Vold 进程

1. //init.rc  片段
2. service vold /system/bin/vold \
3. --blkid_context =u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \
4. --fsck_context =u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
5. class core
6. ioprio be 2
7. task_profiles ProcessCapacityHigh
8. shutdown critical
9. group root reserved_disk
10. reboot_on_failure reboot,vold-failed

复制代码

1. // adb shell -> ps -A | grep vold
2. 130|shenoo:/mnt/media_rw # ps -A | grep vold // vold 的父进程PID=1（init）
3. root           471     1 11001604  9596 binder_wait_for_work 0 S vold

复制代码

Vold 启动

动VolumeManager：

• VM 会先卸载掉对应文件夹中的所有东西，使之处于一个干净的状态；
  
• 通过VolumeBase基类智能指针new了一个EmulatedVolume对象，同时构造出内置存储目次（/data/media）；
  
• 在create函数中，执行了doCreate，doCreate是虚函数，在EmulatedVolume中并没有实现，以是终极还是调用了基类函数，也就直接返回了。之后的listener则是StorageManager服务，但是由于Vold启动较早，SystemServer还没有启动StorageManager，以是这里getListener()得到的是空，后面StorageManager启动完成后会重新触发。
  
• 设置了当前存储装备的状态为unmounted。
  
• 最后Vold会创建一个假造磁盘
  

• 启动VoldNativeService：VoldNativeService依赖的是aidl接口逻辑，连接着StorageManager和vold。它继续自BinderService，启动过程中重要注册了接口，使其他服务可以通过 IVold 可以找到，然后启动线程。
• 启动NetlinkManager：启动过程中内部建立了一个socket连接，用于吸收所有的uevent变乱，最后会new一个NetlinkHandler对象，并执行start函数。然后调用NetlinkListener父类的startListener函数去监听event。
• 总之，Vold启动完成后，后续Vold会监听kernel的uevent变乱，然后处置惩罚转发通过Callback通知到StorageManager，而Framework的服务以及App则可以通过StorageManager去使用Vold处置惩罚Command

1. int main(int argc, char** argv) {
2.     ... //忽略部分代码
3.     ATRACE_BEGIN("main");
4.     VolumeManager* vm;
5.     NetlinkManager* nm;
6.     parse_args(argc, argv); //解析传递的参数
7.     ...
8.     mkdir("/dev/block/vold", 0755);
9.     ...   
10.     //创建 VolumeManager 实例
11.     if (!(vm = VolumeManager::Instance())) {
12.         LOG(ERROR) << "Unable to create VolumeManager";
13.         exit(1);
14.     }
15.     //创建 NetlinkManager 实例
16.     if (!(nm = NetlinkManager::Instance())) {
17.         LOG(ERROR) << "Unable to create NetlinkManager";
18.         exit(1);
19.     }
21.     if (android::base::GetBoolProperty("vold.debug", false)) {
22.         vm->setDebug(true);
23.     }
24.     //启动 VolumeManager
25.     if (vm->start()) {
26.         PLOG(ERROR) << "Unable to start VolumeManager";
27.         exit(1);
28.     }
29.     ...
30.     VoldConfigs configs = {};
31.     if (process_config(vm, &configs)) {
32.         PLOG(ERROR) << "Error reading configuration... continuing anyways";
33.     }
34.     ...
35.     android::hardware::configureRpcThreadpool(1, false /* callerWillJoin */);
36.     ...
37.     //VoldNativeService它是一个binder服务，start方法会把它发布到ServiceManager中
38.     if (android::vold::VoldNativeService::start() != android::OK) {
39.         LOG(ERROR) << "Unable to start VoldNativeService";
40.         exit(1);
41.     }
42.     ...
43.     //启动 NetlinkManager
44.     if (nm->start()) {
45.         PLOG(ERROR) << "Unable to start NetlinkManager";
46.         exit(1);
47.     }
48.     ...
49.     android::IPCThreadState::self()->joinThreadPool();//加入线程池
50.     LOG(INFO) << "vold shutting down";
51.     exit(0);
52. }

复制代码

启动 storaged 服务
此外，体系还会启动与Vold息息相干的服务，比如它的上游服务——StorageManagerService，大抵流程如下：

1. init.rc  ->  Zygote  ->  SystemServer  ->  StorageManagerService

复制代码

详细：
• 开机后，安卓启动的第一个用户态进程是init，init进程会fork出zygote进程，zygote又fork出 system server
zygote fork system server

1. zygoteServer = new ZygoteServer(isPrimaryZygote);

复制代码

• SystemServer 启动函数入口
zygote 启动服务

1.      /**
2.      * The main entry point from zygote.
3.      */
4.     public static void main(String[] args) {
5.         new SystemServer().run();
6.     }
7. •        SystemServer().run()会启动各种service

复制代码

通过 run() 启动各种服务

1. 779      private void run() {
2.             .......
3. 955          // Start services.
4. 956          try {
5. 957              t.traceBegin("StartServices");
6. 958              startBootstrapServices(t);
7.                .....
8. 962          } catch (Throwable ex) {
9. 963              Slog.e("System", "******************************************");
10. 964              Slog.e("System", "************ Failure starting system services", ex);
11. 965              throw ex;
12. 966          }
13.             ........

复制代码

• 在startBootstrapServices函数里会启动 ActivityManager
StartActivityManager

1. 1073      private void startBootstrapServices(@NonNull TimingsTraceAndSlog t) {
2.             .......
3. 1144          t.traceBegin("StartActivityManager");
4. 1145          // TODO: Might need to move after migration to WM.
5. 1146          ActivityTaskManagerService atm = mSystemServiceManager.startService(
6. 1147                  ActivityTaskManagerService.Lifecycle.class).getService();
7. 1148          mActivityManagerService = ActivityManagerService.Lifecycle.startService(
8. 1149                  mSystemServiceManager, atm);
9. 1150          mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
10. 1151          mActivityManagerService.setInstaller(installer);
11. 1152          mWindowManagerGlobalLock = atm.getGlobalLock();
12. 1153          t.traceEnd();

复制代码

启动systemReady()函数

1. 2829          // We now tell the activity manager it is okay to run third party
2. 2830          // code.  It will call back into us once it has gotten to the state
3. 2831          // where third party code can really run (but before it has actually
4. 2832          // started launching the initial applications), for us to complete our
5. 2833          // initialization.
6. 2834          mActivityManagerService.systemReady(() -> {
7. 2835              Slog.i(TAG, "Making services ready");
8. 2836              t.traceBegin("StartActivityManagerReadyPhase");
9. 2837              mSystemServiceManager.startBootPhase(t, SystemService.PHASE_ACTIVITY_MANAGER_READY);
10. 2838              t.traceEnd();
11. 2839              t.traceBegin("StartObservingNativeCrashes");

复制代码

systemReady 实现

1. 8264      /**
2. 8265       * Ready. Set. Go!
3. 8266       */
4. 8267      public void systemReady(final Runnable goingCallback, @NonNull TimingsTraceAndSlog t) {
5. 8268          t.traceBegin("PhaseActivityManagerReady");
6. 8269          mSystemServiceManager.preSystemReady();
7. 8392          // On Automotive / Headless System User Mode, at this point the system user has already been
8. 8393          // started and unlocked, and some of the tasks we do here have already been done. So skip
9. 8394          // those in that case. The duplicate system user start is guarded in SystemServiceManager.
10. 8395          // TODO(b/242195409): this workaround shouldn't be necessary once we move the headless-user
11. 8396          // start logic to UserManager-land.
12. 8397          mSystemServiceManager.onUserStarting(t, currentUserId);

复制代码

处置惩罚 H_BOOT_COMPLETED 消息

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。