简介介绍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模块简称VMAndroid13 中是VM处理完从NM接收到的NetlinkEvent后通过binder将消息传递给StorageManagerService 进行下一步处理然后 VM 根据 StorageManagerService 返回的消息管理卷VoldNativeService模块主要是与 StorageManagerService 进行通信继承 BinderService 类启动过程中主要注册了接口使其他服务可以通过IVold可以找到然后启动线程•StorageManager 模块Framework 层的API用于APP和其它系统组件访问存储相关的功能。它是 StorageManagerService 的客户端通过 Binder 调用 StorageManagerService 提供的 APIVold 启动流程与其说是Vold启动流程更不如说是Android存储的初始化工作Vold的主要功能就是存储区的管理。Android 的初始化工作可以大致分为三个阶段清理环境因为Android是支持多用户的启动时的可能是另一个用户所以需要把之前的用户数据清理干净启动存储服务如Vold、StorageManager等等挂载emulated存储用于模拟SD卡历史原因下面章节会着重介绍第一个用户态进程init• init.rc 启动 Vold 进程//init.rc 片段 service vold /system/bin/vold \ --blkid_context u:r:blkid:s0 --blkid_untrusted_contextu:r:blkid_untrusted:s0 \ --fsck_context u:r:fsck:s0 --fsck_untrusted_contextu:r:fsck_untrusted:s0 class core ioprio be 2 task_profiles ProcessCapacityHigh shutdown critical group root reserved_disk reboot_on_failure reboot,vold-failed// adb shell -ps-A|grepvold130|shenoo:/mnt/media_rw# ps -A | grep vold // vold 的父进程PID1initroot4711110016049596binder_wait_for_work0S voldVold 启动动VolumeManagerVM 会先卸载掉对应文件夹中的所有东西使之处于一个干净的状态通过VolumeBase基类智能指针new了一个EmulatedVolume对象同时构造出内置存储目录/data/media在create函数中执行了doCreatedoCreate是虚函数在EmulatedVolume中并没有实现所以最终还是调用了基类函数也就直接返回了。之后的listener则是StorageManager服务但是由于Vold启动较早SystemServer还没有启动StorageManager所以这里getListener()得到的是空后面StorageManager启动完成后会重新触发。设置了当前存储设备的状态为unmounted。最后Vold会创建一个虚拟磁盘• 启动VoldNativeServiceVoldNativeService依赖的是aidl接口逻辑连接着StorageManager和vold。它继承自BinderService启动过程中主要注册了接口使其他服务可以通过 IVold 可以找到然后启动线程。• 启动NetlinkManager启动过程中内部建立了一个socket连接用于接收所有的uevent事件最后会new一个NetlinkHandler对象并执行start函数。然后调用NetlinkListener父类的startListener函数去监听event。• 总之Vold启动完成后后续Vold会监听kernel的uevent事件然后处理转发通过Callback通知到StorageManager而Framework的服务以及App则可以通过StorageManager去使用Vold处理Commandintmain(intargc,char**argv){...//忽略部分代码ATRACE_BEGIN(main);VolumeManager*vm;NetlinkManager*nm;parse_args(argc,argv);//解析传递的参数...mkdir(/dev/block/vold,0755);...//创建 VolumeManager 实例if(!(vmVolumeManager::Instance())){LOG(ERROR)Unable to create VolumeManager;exit(1);}//创建 NetlinkManager 实例if(!(nmNetlinkManager::Instance())){LOG(ERROR)Unable to create NetlinkManager;exit(1);}if(android::base::GetBoolProperty(vold.debug,false)){vm-setDebug(true);}//启动 VolumeManagerif(vm-start()){PLOG(ERROR)Unable to start VolumeManager;exit(1);}...VoldConfigs configs{};if(process_config(vm,configs)){PLOG(ERROR)Error reading configuration... continuing anyways;}...android::hardware::configureRpcThreadpool(1,false/* callerWillJoin */);...//VoldNativeService它是一个binder服务start方法会把它发布到ServiceManager中if(android::vold::VoldNativeService::start()!android::OK){LOG(ERROR)Unable to start VoldNativeService;exit(1);}...//启动 NetlinkManagerif(nm-start()){PLOG(ERROR)Unable to start NetlinkManager;exit(1);}...android::IPCThreadState::self()-joinThreadPool();//加入线程池LOG(INFO)vold shutting down;exit(0);}启动 storaged 服务此外系统还会启动与Vold息息相关的服务比如它的上游服务——StorageManagerService大致流程如下init.rc - Zygote - SystemServer - StorageManagerService具体• 开机后安卓启动的第一个用户态进程是initinit进程会fork出zygote进程zygote又fork出 system serverzygote fork system serverzygoteServer new ZygoteServer(isPrimaryZygote);• SystemServer 启动函数入口zygote 启动服务/** * The main entry point from zygote. */ public static void main(String[] args) { new SystemServer().run(); } • SystemServer().run()会启动各种service通过 run() 启动各种服务779 private void run() { ....... 955 // Start services. 956 try { 957 t.traceBegin(StartServices); 958 startBootstrapServices(t); ..... 962 } catch (Throwable ex) { 963 Slog.e(System, ******************************************); 964 Slog.e(System, ************ Failure starting system services, ex); 965 throw ex; 966 } ........• 在startBootstrapServices函数里会启动 ActivityManagerStartActivityManager1073 private void startBootstrapServices(NonNull TimingsTraceAndSlog t) { ....... 1144 t.traceBegin(StartActivityManager); 1145 // TODO: Might need to move after migration to WM. 1146 ActivityTaskManagerService atm mSystemServiceManager.startService( 1147 ActivityTaskManagerService.Lifecycle.class).getService(); 1148 mActivityManagerService ActivityManagerService.Lifecycle.startService( 1149 mSystemServiceManager, atm); 1150 mActivityManagerService.setSystemServiceManager(mSystemServiceManager); 1151 mActivityManagerService.setInstaller(installer); 1152 mWindowManagerGlobalLock atm.getGlobalLock(); 1153 t.traceEnd();启动systemReady()函数2829 // We now tell the activity manager it is okay to run third party 2830 // code. It will call back into us once it has gotten to the state 2831 // where third party code can really run (but before it has actually 2832 // started launching the initial applications), for us to complete our 2833 // initialization. 2834 mActivityManagerService.systemReady(() - { 2835 Slog.i(TAG, Making services ready); 2836 t.traceBegin(StartActivityManagerReadyPhase); 2837 mSystemServiceManager.startBootPhase(t, SystemService.PHASE_ACTIVITY_MANAGER_READY); 2838 t.traceEnd(); 2839 t.traceBegin(StartObservingNativeCrashes);systemReady 实现8264 /** 8265 * Ready. Set. Go! 8266 */ 8267 public void systemReady(final Runnable goingCallback, NonNull TimingsTraceAndSlog t) { 8268 t.traceBegin(PhaseActivityManagerReady); 8269 mSystemServiceManager.preSystemReady(); 8392 // On Automotive / Headless System User Mode, at this point the system user has already been 8393 // started and unlocked, and some of the tasks we do here have already been done. So skip 8394 // those in that case. The duplicate system user start is guarded in SystemServiceManager. 8395 // TODO(b/242195409): this workaround shouldnt be necessary once we move the headless-user 8396 // start logic to UserManager-land. 8397 mSystemServiceManager.onUserStarting(t, currentUserId);处理 H_BOOT_COMPLETED 消息