9.2.6 Vold实例分析
最后更新于：2022-04-02 05:53:24
这一节将分析一个实际案例，即插入一张SD卡引发的事件及其处理过程。在分析之前，还是应先介绍MountService。
1. MountService的介绍
有些应用程序需要检测外部存储卡的插入/拔出事件，这些事件是由MountService通过Intent广播发出的，例如外部存储卡插入后，MountService就会发送ACTION_MEDIA_MOUNTED消息。从某种意义上说，可把MountService看成是Java世界的Vold。来简单认识一下这个MountService，它的代码如下所示：
**MountService.java**
~~~
class MountService extends IMountService.Stub
implements INativeDaemonConnectorCallbacks {
//MountService实现了INativeDaemonConnectorCallbacks接口
......
public MountService(Context context) {
mContext = context;
......
//创建一个HandlerThread，在第5章中曾介绍过。
mHandlerThread = new HandlerThread("MountService");
mHandlerThread.start();
/*
创建一个Handler，这个Handler使用HandlerThread的Looper,也就是说，派发给该Handler
的消息将在另外一个线程中处理。可回顾第5章的内容，以加深印象。
*/
mHandler = new MountServiceHandler(mHandlerThread.getLooper());
......
/*
NativeDaemonConnector用于Socket通信，第二个参数“vold”表示将和Vold通信，也就是
和CL模块中的那个socket建立通信连接。第一个参数为INativeDaemonConnectorCallbacks
接口。它提供两个回调函数：
onDaemonConnected：当NativeDaemonConnector连接上Vold后回调。
onEvent：当NativeDaemonConnector收到来自Vold的数据后回调。
*/
mConnector = new NativeDaemonConnector(this, "vold",
10, "VoldConnector");
mReady= false;
//再启动一个线程用于和Vold通信。
Threadthread = new Thread(mConnector,
NativeDaemonConnector.class.getName());
thread.start();
}
......
}
~~~
MountService通过NativeDaemonConnector和Vold的CL模块建立通信连接，这部分内容比较简单，读者可自行研究。下面来分析SD卡插入后所引发的一连串处理。
2. 设备插入事件的处理
（1）Vold处理Uevent事件
在插入SD卡后，Vold的NM模块接收到Uevent消息，假设此消息的内容是前面介绍Uevent知识时使用的add消息，它的内容如下所示：
**SD卡插入的Uevent消息**
~~~
add@/devices/platform/msm_sdcc.2/mmc_host/mmc1/mmc1:c9f2/block/mmcblk0
ACTION=add //add表示设备插入动作，另外还有remove和change等动作
//DEVPATH表示该设备位于/sys目录中的设备路径
DEVPATH=/devices/platform/msm_sdcc.2/mmc_host/mmc1/mmc1:c9f2/block/mmcblk0
/*
SUBSYSTEM表示该设备属于哪一类设备，block为块设备,磁盘也属于这一类设备，另外还有
character(字符)设备等类型。
*/
SUBSYSTEM=block
MAJOR=179//MAJOR和MINOR分别表示该设备的主次设备号，二者联合起来可以标识一个设备
MINOR=0
DEVNAME=mmcblk0
DEVTYPE=disk//设备Type为disk
NPARTS=3 //表示该SD卡上的分区，我的SD卡上有三块分区
SEQNUM=1357//序号
~~~
根据前文分析可知，NM模块中的NetlinkHandler会处理此消息，请回顾一下相关代码：
**NetlinkHandler.cpp**
~~~
void NetlinkHandler::onEvent(NetlinkEvent *evt){
VolumeManager *vm = VolumeManager::Instance();
constchar *subsys = evt->getSubsystem();
......
//根据上面Uevent消息的内容可知，它的subsystem对应为block，所以我们会走下面这个if分支
if (!strcmp(subsys, "block")) {
vm->handleBlockEvent(evt); //调用VM的handleBlockEvent
}
......
}
~~~
**VolumeManager.cpp**
~~~
voidVolumeManager::handleBlockEvent(NetlinkEvent *evt) {
constchar *devpath = evt->findParam("DEVPATH");
VolumeCollection::iterator it;
boolhit = false;
for(it = mVolumes->begin(); it != mVolumes->end(); ++it) {
//调用各个Volume的handleBlockEvent
if(!(*it)->handleBlockEvent(evt)) {
hit = true;
break;
}
}
......
}
~~~
我的G7手机只有一个Volume，其实际类型就是之前介绍过的DirectVolume。请看它是怎么对待这个Uevent消息的，代码如下所示：
**DirectVolume.cpp**
~~~
int DirectVolume::handleBlockEvent(NetlinkEvent*evt) {
constchar *dp = evt->findParam("DEVPATH");
PathCollection::iterator it;
for(it = mPaths->begin(); it != mPaths->end(); ++it) {
if(!strncmp(dp, *it, strlen(*it))) {
int action = evt->getAction();
const char *devtype =evt->findParam("DEVTYPE");
if (action == NetlinkEvent::NlActionAdd) {
int major = atoi(evt->findParam("MAJOR"));
int minor = atoi(evt->findParam("MINOR"));
char nodepath[255];
snprintf(nodepath,
sizeof(nodepath),"/dev/block/vold/%d:%d",
major, minor);
//内部调用mknod函数创建设备节点
if (createDeviceNode(nodepath, major, minor)) {
SLOGE("Error makingdevice node '%s' (%s)", nodepath,
strerror(errno));
}
if (!strcmp(devtype, "disk")) {
//对应Uevent消息的DEVTYPE值为disk，所以走这个分支
handleDiskAdded(dp, evt);
} else {
//处理DEVTYPE为Partition的情况
handlePartitionAdded(dp,evt);
}
} else if (action == NetlinkEvent::NlActionRemove) {
//对应Uevent的ACTION值为remove
......
} else if (action == NetlinkEvent::NlActionChange) {
//对应Uevent的ACTION值为change
......
}
......
return 0;
}
}
errno= ENODEV;
return-1;
}
~~~
插入SD卡，首先收到的Uevent消息中DEVTYPE的值是“disk”，这将导致DirectVolume的handleDiskInserted被调用。下面来看它的工作。
**DirectVolume.cpp**
~~~
void DirectVolume::handleDiskAdded(const char*devpath, NetlinkEvent *evt) {
mDiskMajor = atoi(evt->findParam("MAJOR"));
mDiskMinor = atoi(evt->findParam("MINOR"));
constchar *tmp = evt->findParam("NPARTS");
if(tmp) {
mDiskNumParts = atoi(tmp);//这个disk上的分区个数。
} else{
......
mDiskNumParts = 1;
}
charmsg[255];
intpartmask = 0;
inti;
/*
Partmask会记录这个Disk上分区加载的情况，前面曾介绍过，如果一个Disk有多个分区，
它后续则会收到多个分区的Uevent消息。
*/
for (i= 1; i <= mDiskNumParts; i++) {
partmask |= (1 << i);
}
mPendingPartMap = partmask;
if(mDiskNumParts == 0) {
......//如果没有分区，则设置Volume的状态为Idle。
setState(Volume::State_Idle);
}else {
......//如果还有分区未加载，则设置Volume状态为Pending
setState(Volume::State_Pending);
}
/*
设置通知内容，snprintf调用完毕后msg的值为：
“Volume sdcard/mnt/sdcard disk inserted (179:0)”
*/
snprintf(msg, sizeof(msg), "Volume %s %s disk inserted(%d:%d)",
getLabel(), getMountpoint(), mDiskMajor, mDiskMinor);
/*
getBroadcaster函数返回setBroadcaster函数设置的那个Broadcaster，也就是CL对象。
然后调用CL对象的sendBroadcast给MountService发送消息，注意它的第一个参数是ResponseCode::VolumeDiskInserted。
*/
mVm->getBroadcaster()->sendBroadcast(ResponseCode::VolumeDiskInserted,
msg, false);
}
~~~
handleDiskAdded把Uevent消息做一些转换后发送给了MountService，实际上可认为CL模块和MountService通信使用的是另外一套协议。那么，MountService会做什么处理呢？
（2）MountService的处理
**MountService.javaonEvent函数**
~~~
publicboolean onEvent(int code, String raw, String[] cooked) {
Intent in = null;
//关于onEvent函数，MountService的介绍中曾提过，当NativeDaemonConnector收到
//来自vold的数据后都会调用这个onEvent函数。
......
if(code == VoldResponseCode.VolumeStateChange) {
......
}else if (code == VoldResponseCode.ShareAvailabilityChange) {
......
}else if ((code == VoldResponseCode.VolumeDiskInserted) ||
(code ==VoldResponseCode.VolumeDiskRemoved) ||
(code ==VoldResponseCode.VolumeBadRemoval)) {
final String label = cooked[2]; //label值为”sdcard”
final String path = cooked[3]; //path值为”/mnt/sdcard”
int major = -1;
int minor = -1;
try {
String devComp = cooked[6].substring(1, cooked[6].length() -1);
String[] devTok = devComp.split(":");
major = Integer.parseInt(devTok[0]);
minor = Integer.parseInt(devTok[1]);
} catch (Exception ex) {
......
}
if (code == VoldResponseCode.VolumeDiskInserted) {
//收到handleDiskAdded发送的VolumeDiskInserted消息了
//然后单独启动一个线程来处理这个消息。
new Thread() {
public void run() {
try {
int rc;
//调用doMountVolume处理。
if ((rc =doMountVolume(path)) !=
StorageResultCode.OperationSucceeded) {
}
} catch (Exception ex){
......
}
}
}.start();
}
~~~
doMountVolume函数的代码如下所示：
**MountService.java**
~~~
private int doMountVolume(String path) {
int rc = StorageResultCode.OperationSucceeded;
try {
//通过NativeDaemonConnector给Vold发送请求，请求内容为：
//volume mount /mnt/sdcard
mConnector.doCommand(String.format("volume mount %s", path));
}catch (NativeDaemonConnectorException e) {
......//异常处理
}
~~~
走了一大圈，最后又回到Vold了。CL模块将收到这个来自MountService的请求，请求的内容为字符串“volume mount/mnt/sdcard”，其中的volume表示命令的名字，CL会根据这个名字找到VolumeCmd对象，并交给它处理这个命令。
（3）Vold处理MountService的命令
Vold处理MountService命令的代码如下所示：
**CommandListener.cppVolumeCmd类**
~~~
intCommandListener::VolumeCmd::runCommand(SocketClient *cli,
int argc, char **argv) {
......
VolumeManager *vm = VolumeManager::Instance();
int rc= 0;
if(!strcmp(argv[1], "list")) {
return vm->listVolumes(cli);
} elseif (!strcmp(argv[1], "debug")) {
......
} elseif (!strcmp(argv[1], "mount")) {
......//调用VM模块的mountVolume来处理mount命令，参数是“/mnt/sdcard”
rc= vm->mountVolume(argv[2]);
} elseif (!strcmp(argv[1], "unmount")) {
......
rc= vm->unmountVolume(argv[2], force);
} elseif (!strcmp(argv[1], "format")) {
......
rc = vm->formatVolume(argv[2]);
} elseif (!strcmp(argv[1], "share")) {
......
rc= vm->shareVolume(argv[2], argv[3]);
} elseif (!strcmp(argv[1], "unshare")) {
......
rc= vm->unshareVolume(argv[2], argv[3]);
}
......
if(!rc) {
//发送处理结果给MountService
cli->sendMsg(ResponseCode::CommandOkay, "volume operationsucceeded", false);
}
......
return0;
}
~~~
看mountVolume函数：
**VolumeManager.cpp**
~~~
int VolumeManager::mountVolume(const char*label) {
/*
根据label找到对应的Volume。label这个参数的名字含义上有些歧义，根据loopupVolume
的实现来看，它其实比较的是Volume的挂载路径，也就是vold.fstab中指定的那个
/mnt/sdcard。而vold.fstab中指定的label叫sdcard。
*/
Volume*v = lookupVolume(label);
......
returnv->mountVol();//mountVol由Volume类实现。
}
~~~
找到对应的DirectVolume后，也就找到了代表真实存储卡的对象。它是如何处理这个命令的呢？代码如下所示：
**Volume.cpp**
~~~
int Volume::mountVol() {
dev_tdeviceNodes[4];
int n,i, rc = 0;
charerrmsg[255];
......
//getMountpoint返回挂载路径，即/mnt/sdcard
//isMountpointMounted判断这个路径是不是已经被mount了
if(isMountpointMounted(getMountpoint())) {
setState(Volume::State_Mounted);//设置状态为State_Mounted
return 0;//如果已经被mount了，则直接返回
}
n =getDeviceNodes((dev_t *) &deviceNodes, 4);
......
for (i= 0; i < n; i++) {
char devicePath[255];
sprintf(devicePath, "/dev/block/vold/%d:%d",MAJOR(deviceNodes[i]),
MINOR(deviceNodes[i]));
......
errno = 0;
setState(Volume::State_Checking);
//默认SD卡为FAT分区，只有这样，当加载为磁盘的时候才能被Windows识别。
if(Fat::check(devicePath)) {
......
return -1;
}
/*
先把设备mount到/mnt/secure/staging，这样/mnt/secure/staging下的内容
就是该设备的存储内容了
*/
errno = 0;
if(Fat::doMount(devicePath, "/mnt/secure/staging", false, false, 1000,
1015, 0702,true)) {
......
continue;
}
/*
下面这个函数会把存储卡中的autorun.inf文件找出来并删掉，这个文件就是“臭名昭著”的
自动运行文件，在Windows系统上，把SD卡挂载为磁盘后，双击这个磁盘就会自动运行
这个文件，很多病毒和木马都是通过它传播的。为了安全起见，要把这个文件删掉。
*/
protectFromAutorunStupidity();
//①下面这个函数比较有意思，需要看看：
if(createBindMounts()) {
......
return -1;
}
//将存储卡mount路径从/mnt/secure/staging移到/mnt/sdcard
if(doMoveMount("/mnt/secure/staging", getMountpoint(), false)) {
......
return -1;
}
//②设置状态为State_Mounted，这个函数将发送状态信息给MountService
setState(Volume::State_Mounted);
mCurrentlyMountedKdev = deviceNodes[i];
return 0;
}
......
setState(Volume::State_Idle);
return-1;
}
~~~
上面代码中有个比较有意思的函数，就是createBindMounts，其代码如下所示：
**Volume.cpp**
~~~
int Volume::createBindMounts() {
unsigned long flags;
/*‘
将/mnt/secure/staging/android_secure目录名改成
/mnt/secure/staging/.android_secure，SEC_STG_SECIMGDIR的值就是
/mnt/secure/staging/.android_secure，也就是把它变成Linux平台上的隐藏目录
*/
if(!access("/mnt/secure/staging/android_secure", R_OK | X_OK)&&
access(SEC_STG_SECIMGDIR, R_OK | X_OK)) {
if(rename("/mnt/secure/staging/android_secure", SEC_STG_SECIMGDIR)) {
SLOGE("Failed to rename legacy asec dir (%s)",strerror(errno));
}
}
......
/*
使用mount命令的bind选项，可将/mnt/secure/staging/.android_secure这个目录
挂载到/mnt/secure/asec目录下。/mnt/secure/asec目录是一个secure container，
目前主要用来保存一些安装在SD卡上的APP信息。APP2SD是Android 2.2引入的新机制，它
支持将APP安装在SD卡上，这样可以节约内部的存储空间。
mount的bind选项允许将文件系统的一个目录挂载到另外一个目录下。读者可以通过man mount
查询具体信息。
*/
if(mount(SEC_STG_SECIMGDIR, SEC_ASECDIR, "", MS_BIND, NULL)) {
......
return -1;
}
......
/*
将tempfs设备挂载到/mnt/secure/staging/.android_secure目录，这样之前
.android_secure目录中的内容就只能通过/mnt/secure/asec访问了。由于那个目录只能
由root访问，所以可以起到安全和保护的作用。
*/
if(mount("tmpfs", SEC_STG_SECIMGDIR, "tmpfs", MS_RDONLY,"size=0,mode=000,uid=0,gid=0")){
......
umount("/mnt/asec_secure");
return -1;
}
return0;
}
~~~
createBindMounts的作用就是将存储卡上的.android_secure目录挂载到/mnt/secure/asec目录下，同时对.android_secure进行一些特殊处理，这样，没有权限的用户就不能更改或破坏.android_secure目录中的内容了，因此它起到了一定的保护作用。
在手机上，受保护的目录内容，只能在用adb shell登录后，进入/mnt/secure/asec目录来查看。注意，这个asec目录的内容就是.android_secure未挂载tmpfs时的内容（亦即它保存着那些安装在存储卡上的应用程序的信息）。另外，可把SD卡拔出来，通过读卡器直接插到台式机上，此时，这些信息就能在.android_secure目录中被直接看到了。
（4）MountService处理状态通知
volume的mountVol完成相关工作后，就通过下面的函数，发送信息给MountService：
~~~
setState(Volume::State_Mounted); //感兴趣的读者可自行分析此函数的实现。
~~~
MountService依然会在onEvent函数中收到这个消息。
**MountService.java**
~~~
public boolean onEvent(int code, String raw,String[] cooked) {
Intent in = null;
......
if(code == VoldResponseCode.VolumeStateChange) {
/*
状态变化由notifyVolumeStateChange函数处理，由于Volume的状态
被置成Mounted，所以下面这个notifyVolumeStateChange会发送
ACTION_MEDIA_MOUNTED这个广播。我们就不再分析这个函数了，读者
可自行研究。
*/
notifyVolumeStateChange(
cooked[2], cooked[3],Integer.parseInt(cooked[7]),
Integer.parseInt(cooked[10]));
}
~~~
实例分析就到这里。中间略去了一些处理内容，例如对分区的处理等，读者可自行研读，相信已没有太大难度了。另外，在上述处理过程中，稍微难懂的是mountVol这个函数在挂载方面的处理过程。用图9-6来总结一下这个处理过程：
:-: 
图9-6 SD卡插入事件处理流程图
由上图可知，Vold在安全性上还是做了一定考虑的。如果没有特殊需要，读者了解上面这些知识也就够了。
';