Android 7.0 Vold工作流程

一、Vold工作机制

Vold是Volume Daemon的缩写，它是Android平台中外部存储系统的管控中心，是管理和控制Android平台外部存储设备的后台进程。其功能主要包括：SD卡的插拔事件检测、SD卡挂载、卸载、格式化等。

如上图所示，Vold中的NetlinkManager模块接收来自Linux Kernel的uevent消息。
NetlinkManager将这些消息转发给VolumeManager模块。VolumeManager会对应做一些操作，然后把相关信息通过CommandListener发送给MountService。
MountService根据收到的消息后，根据情况会利用CommandListener发送相关的处理命令给VolumeManager做进一步处理。
CommandListener模块内部封装了一个Socket用于跨进程通信。它一方面接收来自MountService的控制命令，另一方面VolumeManager通过它将消息发送给MountService。

Tips:
Netlink是Linux系统中用户空间进程和Kernel进行通信的一种机制，是基于Socket的异步通信机制。
通过这种机制，位于用户空间的进程可以接收来自Kernel的一些信息，同时用户空间进程也可以利用Netlink向Kernel发送一些控制命令。

二、Vold进程启动过程
Vold进程启动文件定义于system/vold/vold.rc文件中：

service vold /system/bin/vold \--blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \--fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0class coresocket vold stream 0660 root mountsocket cryptd stream 0660 root mountioprio be 2writepid /dev/cpuset/foreground/tasks

被init进程启动后，将调用system/vold/main.cpp中的main函数：

int main(int argc, char** argv) {.............VolumeManager *vm;CommandListener *cl;.............NetlinkManager *nm;//解析vold.rc中定义的blkid和fsck相关的参数parse_args(argc, argv);..............// Quickly throw a CLOEXEC on the socket we just inherited from init//这里的含义不是很明白//对于fcntl(fd, F_SETFD, FD_CLOEXEC)函数//FD_CLOEXEC表示当程序执行exec函数时， fd将被系统自动关闭， 不传递给exec创建的新进程，以免fd在子进程中仍然有效//但在init进程中，是先fork出子进程，然后在进程中创建出socket，才执行exec函数，有必要使用fcntl函数么？fcntl(android_get_control_socket("vold"), F_SETFD, FD_CLOEXEC);fcntl(android_get_control_socket("cryptd"), F_SETFD, FD_CLOEXEC);//创建文件夹/dev/block/voldmkdir("/dev/block/vold", 0755);.........//创建VolumeManagerif (!(vm = VolumeManager::Instance())) {LOG(ERROR) << "Unable to create VolumeManager";exit(1);}//创建NetlinkManagerif (!(nm = NetlinkManager::Instance())) {LOG(ERROR) << "Unable to create NetlinkManager";exit(1);}...................//创建CommandListenercl = new CommandListener();............vm->setBroadcaster((SocketListener *) cl);nm->setBroadcaster((SocketListener *) cl);//启动VolumeManagerif (vm->start()) {PLOG(ERROR) << "Unable to start VolumeManager";exit(1);}//根据配置文件初始化VolumeManagerif (process_config(vm)) {PLOG(ERROR) << "Error reading configuration... continuing anyways";}//启动NetlinkManagerif (nm->start()) {PLOG(ERROR) << "Unable to start NetlinkManager";exit(1);}//与ueventd进程进行冷启动类似，此处通过往/sys/block目录下对应的uevent文件写"add\n"来触发内核发送uevent消息coldboot("/sys/block");//启动CommandListenerif (cl->startListener()) {PLOG(ERROR) << "Unable to start CommandListener";exit(1);}.......// Eventually we'll become the monitoring threadwhile(1) {sleep(1000);}LOG(ERROR) << "Vold exiting";exit(0);
}

从上面的代码不难看出，Vold进程的main函数中，创建并启动其子模块VolumeManager、NetlinkManager和CommandListener后，就不再执行实际的工作了。
以后Vold进程具体的工作就会交付给子模块进行处理。

三、Vold进程中各模块分析
为了进一步了解整个Vold进程的主要工作流程，接下来我们分析一下其主要模块的工作流程。

1、NetlinkManager模块

1.1 NetlinkManager的创建和启动
在Vold的main函数中，调用NetlinkManager::Instance创建出NetlinkManager：

NetlinkManager *NetlinkManager::Instance() {if (!sInstance)sInstance = new NetlinkManager();return sInstance;
}//mBroadcaster的类型为SocketListener
NetlinkManager::NetlinkManager() {mBroadcaster = NULL;
}

从上面的代码可以看到，NetlinkManager的创建比较简单。

在创建出NetlinkManager后，Vold调用了NetlinkManager的setBroadcaster函数：

void setBroadcaster(SocketListener *sl) { mBroadcaster = sl; }

依然言简意赅。
这里唯一需要说明的是，Android这里的设计看起来比较很奇怪，虽然NetlinkManager设置了CommandListener对象，但它并没有通过CommandListener发送消息和接收命令。

配置好NetlinkManager后，Vold就调用了NetlinkManger的start函数：

int NetlinkManager::start() {//以下定义并初始化socket的地址结构struct sockaddr_nl nladdr;int sz = 64 * 1024;int on = 1;memset(&nladdr, 0, sizeof(nladdr));nladdr.nl_family = AF_NETLINK;nladdr.nl_pid = getpid();nladdr.nl_groups = 0xffffffff;//创建PF_NETLINK地址簇的socket，NETLINK_KOBJECT_UEVENT表示该socket将接收内核的Uevent事件if ((mSock = socket(PF_NETLINK, SOCK_DGRAM | SOCK_CLOEXEC,NETLINK_KOBJECT_UEVENT)) < 0) {SLOGE("Unable to create uevent socket: %s", strerror(errno));return -1;}//setsockopt设置socket的选项，此处设置socket的接收缓冲区大小为64 * 1024if (setsockopt(mSock, SOL_SOCKET, SO_RCVBUFFORCE, &sz, sizeof(sz)) < 0) {SLOGE("Unable to set uevent socket SO_RCVBUFFORCE option: %s", strerror(errno));goto out;}//此处设置允许接收凭证相关的信息if (setsockopt(mSock, SOL_SOCKET, SO_PASSCRED, &on, sizeof(on)) < 0) {SLOGE("Unable to set uevent socket SO_PASSCRED option: %s", strerror(errno));goto out;}//将创建出的socket绑定到之前的地址上，此时socket可以收到Kernel的数据了if (bind(mSock, (struct sockaddr *) &nladdr, sizeof(nladdr)) < 0) {SLOGE("Unable to bind uevent socket: %s", strerror(errno));goto out;}//创建并启动一个NetlinkHandlermHandler = new NetlinkHandler(mSock);if (mHandler->start()) {SLOGE("Unable to start NetlinkHandler: %s", strerror(errno));goto out;}return 0;out:close(mSock);return -1;
}

通过上面的代码不难看出，其实NetlinkManager启动后就是创建一个可以接收Kernel消息的socket，并以此socket构建并启动NetlinkHandler。
可以预见NetlinkHandler将用来处理socket收到的信息。

1.2 NetlinkHandler

NetlinkHandler::NetlinkHandler(int listenerSocket) :NetlinkListener(listenerSocket) {
}

NetlinkHandler初始化时，将与Kernel通信的socket描述符传入到父类NetlinkListener中。

NetlinkListener::NetlinkListener(int socket) :SocketListener(socket, false) {mFormat = NETLINK_FORMAT_ASCII;
}

NetlinkListener又进一步调用其父类SocketListener:

SocketListener::SocketListener(int socketFd, bool listen) {init(NULL, socketFd, listen, false);
}//socektName为null， listen和useCmdNum的值均为false
void SocketListener::init(const char *socketName, int socketFd, bool listen, bool useCmdNum) {mListen = listen;mSocketName = socketName;mSock = socketFd;mUseCmdNum = useCmdNum;//初始化一个mutexpthread_mutex_init(&mClientsLock, NULL);//SocketClientCollection用于存储与Socket服务端通信的客户端mClients = new SocketClientCollection();
}

从上面的代码可以看出，NetlinkHandler对应的继承体系如下图所示：

创建完NetlinkHandler后，NetlinkManager调用了NetlinkHandler的start方法：

int NetlinkHandler::start() {//根据继承体系，实际上调用了SocketListener的startListenr函数return this->startListener();
}int SocketListener::startListener() {return startListener(4);
}int SocketListener::startListener(int backlog) {//前面代码已经提及，构造NetlinkHandler时，mSocketName为null，略去部分代码................//mListen的参数也为false，表明mSocket并不是一个服务器端if (mListen && listen(mSock, backlog) < 0) {..............} else if (!mListen)//利用mSocket构造SocketClient加入到mClients中//这个SocketClient并不是真实客户端的代表，此处只是为了代码和操作的统一mClients->push_back(new SocketClient(mSock, false, mUseCmdNum));//pipe系统调用将创建一个匿名管道，mCtrlPipe是一个int类型的二元数组//其中mCtrlPipe[0]用于从管道读数据，mCtrlPipe[1]用于往管道写数据if (pipe(mCtrlPipe)) {SLOGE("pipe failed (%s)", strerror(errno));return -1;}//创建一个工作线程，线程的执行函数为threadStartif (pthread_create(&mThread, NULL, SocketListener::threadStart, this)) {SLOGE("pthread_create (%s)", strerror(errno));return -1;}return 0;
}

至此，我们知道了NetlinkHandler启动后，创建了一个工作线程，用于接收和处理数据。现在进一步看看threadStart函数：

void *SocketListener::threadStart(void *obj) {SocketListener *me = reinterpret_cast<SocketListener *>(obj);//调用SocketListener的runListener函数me->runListener();pthread_exit(NULL);return NULL;
}void SocketListener::runListener() {SocketClientCollection pendingList;//无线循环，接收socket收到的数据while(1) {SocketClientCollection::iterator it;fd_set read_fds;int rc = 0;int max = -1;//将指定的文件描述符集清空，系统分配时默认是不清空的FD_ZERO(&read_fds);..........//在文件描述符集中增加一个新的描述符FD_SET(mCtrlPipe[0], &read_fds);//max将与select函数if (mCtrlPipe[0] > max)max = mCtrlPipe[0];pthread_mutex_lock(&mClientsLock);for (it = mClients->begin(); it != mClients->end(); ++it) {// NB: calling out to an other object with mClientsLock held (safe)int fd = (*it)->getSocket();FD_SET(fd, &read_fds);if (fd > max) {max = fd;}}pthread_mutex_unlock(&mClientsLock);...............//监听是否有数据到来if ((rc = select(max + 1, &read_fds, NULL, NULL, NULL)) < 0) {............} else if (!rc) continue;//FD_ISSET用于测试指定的文件描述符是否在该集合中，前面已经加入了if (FD_ISSET(mCtrlPipe[0], &read_fds)) {char c = CtrlPipe_Shutdown;TEMP_FAILURE_RETRY(read(mCtrlPipe[0], &c, 1));//如果从管道中读出CtrlPipe_Shutdown，则退出工作线程if (c == CtrlPipe_Shutdown) {break;}continue;}//如果mSock是服务器端，进入这个分支，NetlinkHandler中的mSock并不是服务器端，此处仅作了解if (mListen && FD_ISSET(mSock, &read_fds)) {sockaddr_storage ss;sockaddr* addrp = reinterpret_cast<sockaddr*>(&ss);socklen_t alen;int c;do {alen = sizeof(ss);//服务器端接收客户端请求c = accept(mSock, addrp, &alen);SLOGV("%s got %d from accept", mSocketName, c);} while (c < 0 && errno == EINTR);if (c < 0) {SLOGE("accept failed (%s)", strerror(errno));sleep(1);continue;}fcntl(c, F_SETFD, FD_CLOEXEC);pthread_mutex_lock(&mClientsLock);//将新的客户端请求加入到mClients中mClients->push_back(new SocketClient(c, true, mUseCmdNum));pthread_mutex_unlock(&mClientsLock);}/* Add all active clients to the pending list first *///这里引入了pendingList，主要是针对服务端提出的//当mSocket是服务端的时候，上面的代码将会增加新的mClient，但在下一次循环之前，这些mClient还未被加入到read_fds中pendingList.clear();pthread_mutex_lock(&mClientsLock);//由于NetlinkHandler中的mSocket不是服务端，因此mClients中实际上只有mSocket自己（前面startListener中加入的）for (it = mClients->begin(); it != mClients->end(); ++it) {SocketClient* c = *it;// NB: calling out to an other object with mClientsLock held (safe)int fd = c->getSocket();if (FD_ISSET(fd, &read_fds)) {//待处理的SocketClient加入到pendingList中pendingList.push_back(c);c->incRef();}}pthread_mutex_unlock(&mClientsLock);while (!pendingList.empty()) {it = pendingList.begin();SocketClient* c = *it;pendingList.erase(it);//调用子类的onDataAvailable函数处理收到的数据if (!onDataAvailable(c)) {//返回false时，需要关闭该SocketClient//关闭SocketClient将直接操作mClients对象release(c, false);}c->decRef();}}
}

上面的代码看起来比较复杂，主要是因为考虑到了Socket作为服务端的情况。
在NetlinkHandler中Socket仅作为客户端接收数据，因此在上面的代码中，其实就是利用子类的onDataAvailable函数处理收到的数据而已。

bool NetlinkListener::onDataAvailable(SocketClient *cli)
{int socket = cli->getSocket();ssize_t count;uid_t uid = -1;.................//这里用uevent_kernel_recv函数，从socket中取出Uevent数据count = TEMP_FAILURE_RETRY(uevent_kernel_recv(socket,mBuffer, sizeof(mBuffer), require_group, &uid));if (count < 0) {........return false;}NetlinkEvent *evt = new NetlinkEvent();//mFormat初始化时指定为NETLINK_FORMAT_ASCII//此处将Uevent数据解码成NetlinkEvent，然后调用子类的onEvent进行处理if (evt->decode(mBuffer, count, mFormat)) {onEvent(evt);} else if (mFormat != NETLINK_FORMAT_BINARY) {..........}delete evt;return true;
}

上面的代码比较简单，其实就是从socket中的字节流中取出Uevent事件，然后将这些事件解码成NetlinkEvent，然后利用子类的onEvent做进一步处理。

void NetlinkHandler::onEvent(NetlinkEvent *evt) {VolumeManager *vm = VolumeManager::Instance();const char *subsys = evt->getSubsystem();if (!subsys) {SLOGW("No subsystem found in netlink event");return;}if (!strcmp(subsys, "block")) {//将NetlinkEvent递交给VolumeManager处理vm->handleBlockEvent(evt);}
}

最后总结一下NetlinkManager模块的工作，如上图所示：
1、NetlinkManager启动后，将创建出与Kernel通信的socket，并用此socket创建出NetlinkHandler。
2、NetlinkHandler启动后，将创建出工作线程（其父类函数完成）。
3、工作线程启动后，将负责监听socket是否有数据到来。
4、当工作线程监听到数据到来后，负责将数据递交给NetlinkHandler。
5、NetlinkHandler负责从socket中的数据中解析出Uevent，并进一步解码成NetlinkEvent，以递交给VolumeManager。

2、VolumeManager模块

2.1 VolumeManager的创建和启动
在Vold的main函数中，调用VolumeManager的instance函数创建VolumeManager：

VolumeManager *VolumeManager::Instance() {if (!sInstance)sInstance = new VolumeManager();return sInstance;
}VolumeManager::VolumeManager() {mDebug = false;mActiveContainers = new AsecIdCollection();mBroadcaster = NULL;mUmsSharingCount = 0;mSavedDirtyRatio = -1;// set dirty ratio to 0 when UMS is activemUmsDirtyRatio = 0;
}

容易看出VolumeManager也是单例模式创建的。
接着，Vold进程利用VolumeManager的setBroadcaster函数，将Commandlistener对象赋予VolumeManager。

void setBroadcaster(SocketListener *sl) { mBroadcaster = sl; }

完成VolumeManager的创建后，Vold进程调用start函数，启动VolumeManager：

int VolumeManager::start() {// Always start from a clean state by unmounting everything in// directories that we own, in case we crashed.unmountAll();// Assume that we always have an emulated volume on internal// storage; the framework will decide if it should be mounted.CHECK(mInternalEmulated == nullptr);mInternalEmulated = std::shared_ptr<android::vold::VolumeBase>(new android::vold::EmulatedVolume("/data/media"));mInternalEmulated->create();return 0;
}

从上面的代码可以看出，VolumeManager启动后就干了两件事：
1、清楚所有已挂载的设备。正如注释所说的，通过这种方式可以让VolumeManager每次都从一个确定的“干净”的状态启动，避免之前出现Vold进程出现过crash。
看看unmountAll函数：

int VolumeManager::unmountAll() {std::lock_guard<std::mutex> lock(mLock);// First, try gracefully unmounting all known devicesif (mInternalEmulated != nullptr) {mInternalEmulated->unmount();}for (auto disk : mDisks) {disk->unmountAll();}// Worst case we might have some stale mounts lurking around, so// force unmount those just to be safe.FILE* fp = setmntent("/proc/mounts", "r");if (fp == NULL) {SLOGE("Error opening /proc/mounts: %s", strerror(errno));return -errno;}// Some volumes can be stacked on each other, so force unmount in// reverse order to give us the best chance of success.std::list<std::string> toUnmount;mntent* mentry;while ((mentry = getmntent(fp)) != NULL) {if (strncmp(mentry->mnt_dir, "/mnt/", 5) == 0|| strncmp(mentry->mnt_dir, "/storage/", 9) == 0) {toUnmount.push_front(std::string(mentry->mnt_dir));}}endmntent(fp);for (auto path : toUnmount) {SLOGW("Tearing down stale mount %s", path.c_str());android::vold::ForceUnmount(path);}return 0;
}

unmountAll的内容比较简单，同时注释清晰，此处不再赘述。

2、创建一个内部的挂载设备。
mInternalEmulated是一个VolumeBase类型的对象，我们看看其create函数：

status_t VolumeBase::create() {CHECK(!mCreated);mCreated = true;//doCreate进行实际的创建status_t res = doCreate();//通过CommandListener通知框架中的MountService
    notifyEvent(ResponseCode::VolumeCreated,StringPrintf("%d \"%s\" \"%s\"", mType, mDiskId.c_str(), mPartGuid.c_str()));
    setState(State::kUnmounted);return res;
}

2.2 配置VolumeManager
当Vold创建并启动完VolumeManager后，就调用process_config函数对VolumeManager进行配置：

static int process_config(VolumeManager *vm) {//读取默认的fstab文件std::string path(android::vold::DefaultFstabPath());fstab = fs_mgr_read_fstab(path.c_str());.........../* Loop through entries looking for ones that vold manages */........for (int i = 0; i < fstab->num_entries; i++) {//是否能被被vold管理if (fs_mgr_is_voldmanaged(&fstab->recs[i])) {//根据fstab文件中设备的信息构造sysPattern、nickname和flags...........//vm->addDiskSource(std::shared_ptr<VolumeManager::DiskSource>(new VolumeManager::DiskSource(sysPattern, nickname, flags)));}}................
}

结合代码，我们知道process_config其实就是解析fstab文件，然后设置一些存储设备的挂载点。

2.3 NetlinkManager与VolumeManager之间的交互
在前面介绍NetlinkManager时，我们知道当NetlinkManager收到Kernel的事件后，将利用NetlinkHandler通知VolumeManager：

void NetlinkHandler::onEvent(NetlinkEvent *evt) {VolumeManager *vm = VolumeManager::Instance();const char *subsys = evt->getSubsystem();if (!subsys) {SLOGW("No subsystem found in netlink event");return;}if (!strcmp(subsys, "block")) {vm->handleBlockEvent(evt);}
}

我们看看VolumeManager的handleBlockeEvent：

void VolumeManager::handleBlockEvent(NetlinkEvent *evt) {..............//取出主设备号和次设备号int major = atoi(evt->findParam("MAJOR"));int minor = atoi(evt->findParam("MINOR"));dev_t device = makedev(major, minor);switch (evt->getAction()) {case NetlinkEvent::Action::kAdd: {//创建新的disk.........auto disk = new android::vold::Disk(eventPath, device,source->getNickname(), flags);disk->create();mDisks.push_back(std::shared_ptr<android::vold::Disk>(disk));break;}case NetlinkEvent::Action::kChange: {..........//改变对应的disk信息for (auto disk : mDisks) {if (disk->getDevice() == device) {disk->readMetadata();disk->readPartitions();}}break;}case NetlinkEvent::Action::kRemove: {//移除对应的diskauto i = mDisks.begin();while (i != mDisks.end()) {if ((*i)->getDevice() == device) {(*i)->destroy();i = mDisks.erase(i);} else {++i;}}break;}default: {LOG(WARNING) << "Unexpected block event action " << (int) evt->getAction();break;}}
}

至此VolumeManager的主要工作介绍完毕，从上面的代码可以看出VolumeManager使用Disk对象来抽象实际的存储设备。

我们现在可以结合上图总结一下VolumeManager的工作流程：
1、存储设备发生变化（如热插拔等），将导致Linux Kernel发出Uevent消息给NetlinkManager。
2、NetlinkManager将事件通知给VolumeManager。
3、VolumeManager根据事件的内容，判断是设备的变化情况，然后操作对应的Disk对象。例如新增存储设备，就利用事件中的内容创建出新的Disk（创建Disk时，就会进一步读取分区信息，创建出Volume对象，此处不再细分）；设备被移除了，VolumeManager就负责移除对应的Disk。

到目前为止，我们分析的流程都停留在Vold进程中，并没有与Android框架发生实际的交互。为了引出交互的实际流程，我们需要先分析一下Vold进程与框架交互的桥梁，即CommandListener。

3、CommandListener

3.1 CommandListener的创建
Vold进程在main函数中创建出了CommandListener，然后调用了CommandListener的startListener函数。
我们先看看CommandListener的构造函数：

class CommandListener : public FrameworkListener {
........
}

从定义来看CommandListener继承于FrameworkListener。

CommandListener::CommandListener() :FrameworkListener("vold", true) {//注册CommandListener支持的命令registerCmd(new DumpCmd());registerCmd(new VolumeCmd());registerCmd(new AsecCmd());registerCmd(new ObbCmd());registerCmd(new StorageCmd());registerCmd(new FstrimCmd());registerCmd(new AppFuseCmd());
}

在CommandListener的构造函数中，调用了父类的构造函数，同时利用其父类的registerCmd函数创建并注册了一些Cmd对象。

我们看看FrameworkListener：

FrameworkListener::FrameworkListener(const char *socketName, bool withSeq) :SocketListener(socketName, true, withSeq) {init(socketName, withSeq);
}void FrameworkListener::init(const char *socketName UNUSED, bool withSeq) {mCommands = new FrameworkCommandCollection();errorRate = 0;mCommandCount = 0;mWithSeq = withSeq;
}void FrameworkListener::registerCmd(FrameworkCommand *cmd) {//将注册的Command保存到列表中mCommands->push_back(cmd);
}

根据前面的代码，我们可以得到上图的继承关系。
可以看到与之前分析NetlinkManager一样，CommandListener最终继承自SocketListener。不过与NetlinkManager不同的是，CommandListener传入到SocketListener的mListen参数为true，这意味着CommandListener中的socket将作为服务端存在。
从FrameworkListener的registerCmd函数来看，FrameworkListener仅仅是保存了新创建的Cmd对象。这里采用了设计模式中的Command模式，每个命令的处理函数都是runCommand。

3.2 CommandListener启动
当Vold进程创建出CommandListener后，同样调用了CommandListener的startListener函数。
根据继承关系，我们知道最终将会调用到SocketListener的startListener函数。

在分析NetlinkManager时，我们已经分析过SocketListener的startListener函数。在startListener函数中将启动一个工作线程，以监听对应socket的数据。
此处CommandListener监听的是init进程创建出Vold进程后，Vold进程创建的名为”vold”的socket，并且该socket是作为服务端存在的。当服务端收到注册请求后，将生成对应的SocketClient对象。然后，工作线程就可以监听SocketClient是否有数据到来。

“vold”的客户端是MountService。与之前分析的一样，当工作线程收到客户端数据时，将调用子类的onDataAvailable函数进行处理。
此时SocketListener的子类是FrameworkListener：

bool FrameworkListener::onDataAvailable(SocketClient *c) {char buffer[CMD_BUF_SIZE];int len;//将socket的数据读入到buffer中len = TEMP_FAILURE_RETRY(read(c->getSocket(), buffer, sizeof(buffer)));............for (i = 0; i < len; i++) {if (buffer[i] == '\0') {/* IMPORTANT: dispatchCommand() expects a zero-terminated string */dispatchCommand(c, buffer + offset);offset = i + 1;}}return true;
}//解析并分发Command
void FrameworkListener::dispatchCommand(SocketClient *cli, char *data) {//从data中解析出Command的参数............for (i = mCommands->begin(); i != mCommands->end(); ++i) {FrameworkCommand *c = *i;//根据参数判断是否能被CommandListener中注册的命令处理if (!strcmp(argv[0], c->getCommand())) {//调用对应Command的runCommand函数if (c->runCommand(cli, argc, argv)) {SLOGW("Handler '%s' error (%s)", c->getCommand(), strerror(errno));}goto out;}}............
}

以DumpCommand举例，看看runCommand函数：

int CommandListener::DumpCmd::runCommand(SocketClient *cli,int /*argc*/, char ** /*argv*/) {cli->sendMsg(0, "Dumping loop status", false);if (Loop::dumpState(cli)) {cli->sendMsg(ResponseCode::CommandOkay, "Loop dump failed", true);}cli->sendMsg(0, "Dumping DM status", false);if (Devmapper::dumpState(cli)) {cli->sendMsg(ResponseCode::CommandOkay, "Devmapper dump failed", true);}cli->sendMsg(0, "Dumping mounted filesystems", false);FILE *fp = fopen("/proc/mounts", "r");if (fp) {char line[1024];while (fgets(line, sizeof(line), fp)) {line[strlen(line)-1] = '\0';cli->sendMsg(0, line, false);;}fclose(fp);}cli->sendMsg(ResponseCode::CommandOkay, "dump complete", false);return 0;
}

从上面的代码容易看出，DumpCmd执行相应的操作后，都是通过SocketClient的sendMsg发送结果。在SocketClient的底层，就是靠”vold” socket将数据返回给MountService。

现在我们总结一下CommandListener涉及的工作流程：

如上图所示：
1、init进程启动Vold进程时，根据vold.rc创建了”vold” socket，”vold” socket作为server端存在于Vold进程中。
2、在Vold进程的main函数中，创建出了CommandListener（部分工作尤其父类完成）；CommandListener创建一些Cmd。
3、调用CommandListener的startListener函数，尤其父类SocketListener中创建出实际的工作线程，监听”vold” socket是否有请求到来。
4、框架中的MountService启动后，间接利用socket与”vold”通信（通过NativeDaemonConnector封装）。初始时，将向”vold”发送connect请求。
5、当工作线程监听到”vold”有请求到来后，利用accept函数创建出与MountService端通信的server端，即上图的s。接下来，工作线程开始监听s上是否有数据到来。
6、当工作线程监听到s有数据到来后，将数据递交给CommandListener（实际是FrameworkListener处理）。
7、CommandListener根据数据的类型，调用对应的Command进行处理。
8、实际的Cmd根据参数进行实际的操作，然后将运行结果递交给s，s再将数据通过c递交给MountService。

接下来，我们看看运行在框架层中的MountService。

4 MountService
有些应用程序需要检测外部存储卡的插入/拔出事件，这些事件由MountService通过Intent广播发送。例如外部存储卡插入后，MountService就会发送Intent.ACTION_MEDIA_MOUNTED消息。
MountService由SystemServer启动，我们简单看看它的构造函数：

class MountService extends IMountService.Stubimplements INativeDaemonConnectorCallbacks, Watchdog.Monitor {public MountService(Context context) {.........//与NetworkManagementService一样，MountService也是靠NativeDaemonConnector与底层守护进程通信//第一个参数传入回调接口，第二参数指明通信的server端mConnector = new NativeDaemonConnector(this, "vold", MAX_CONTAINERS * 2, VOLD_TAG, 25, null);.........//创建一个线程与server socket通信mConnectorThread = new Thread(mConnector, VOLD_TAG);..........}private void start() {//NativeDaemonConnector是一个runnable对象，线程启动后将调用其run方法//在介绍Android7.0 数据业务长连接拨号过程时，我们提到过NetworkManagementService中NativeDaemonConnector连接netd的过程//MountService中的过程是一致的，只是这次连接的是voldmConnectorThread.start();.........}
}

从MountService的启动情况来看，对于Vold进程而言，我们需要关注的就是MountService利用NativeDaemonConnector建立与”vold”的连接，使得Vold进程能够与Android框架进行沟通了。

Android中的Service启动后，基本上都是靠事件驱动的，因此无法按一个有序的流程进行全面的介绍，比较好的方式还是了解整体架构后，分析一个具体的示例。
因此接下来我们以设备插入为例，分析一下MountService的主要工作。
根据上文的分析，我们知道当设备插入后，Kernel发送消息是的NetlinkManager能够收到Uevent。然后，NetlinkManager将会构造出NetlinkEvent，并通知VolumeManager进行处理。
在VolumeManager中，利用handleBlockEvent根据事件的类型进行相应的处理，我们截取设备添加时的处理代码：

void VolumeManager::handleBlockEvent(NetlinkEvent *evt) {........switch (evt->getAction()) {case NetlinkEvent::Action::kAdd: {//前文已述，DiskSource是配置VolumeManager时，读取fstab文件得到的for (auto source : mDiskSources) {if (source->matches(eventPath)) {.......//创建设备对象auto disk = new android::vold::Disk(eventPath, device,source->getNickname(), flags);disk->create();mDisks.push_back(std::shared_ptr<android::vold::Disk>(disk));break;}}break;}........
}

我们看看Disk的代码：

Disk::Disk(const std::string& eventPath, dev_t device,const std::string& nickname, int flags) :mDevice(device), mSize(-1), mNickname(nickname), mFlags(flags), mCreated(false), mJustPartitioned(false) {mId = StringPrintf("disk:%u,%u", major(device), minor(device));mEventPath = eventPath;mSysPath = StringPrintf("/sys/%s", eventPath.c_str());mDevPath = StringPrintf("/dev/block/vold/%s", mId.c_str());//在CreateDeviceNode中，利用mknod创建设备节点CreateDeviceNode(mDevPath, mDevice);
}status_t Disk::create() {CHECK(!mCreated);mCreated = true;//注意这里的notifyEventnotifyEvent(ResponseCode::DiskCreated, StringPrintf("%d", mFlags));readMetadata();readPartitions();return OK;
}status_t Disk::readMetadata() {//读取设备信息...........notifyEvent(ResponseCode::DiskSizeChanged, StringPrintf("%" PRIu64, mSize));notifyEvent(ResponseCode::DiskLabelChanged, mLabel);notifyEvent(ResponseCode::DiskSysPathChanged, mSysPath);return OK;
}status_t Disk::readPartitions() {//读取分取信息.............Table table = Table::kUnknown;bool foundParts = false;for (auto line : output) {..........if (!strcmp(token, "DISK")) {const char* type = strtok(nullptr, kSgdiskToken);if (!strcmp(type, "mbr")) {table = Table::kMbr;} else if (!strcmp(type, "gpt")) {table = Table::kGpt;}} else if (!strcmp(token, "PART")) {.........dev_t partDevice = makedev(major(mDevice), minor(mDevice) + i);if (table == Table::kMbr) {........createPublicVolume(partDevice);........} else if (table == Table::kGpt) {const char* typeGuid = strtok(nullptr, kSgdiskToken);const char* partGuid = strtok(nullptr, kSgdiskToken);if (!strcasecmp(typeGuid, kGptBasicData)) {//关注一下这个createPublicVolume(partDevice);} else if (!strcasecmp(typeGuid, kGptAndroidExpand)) {createPrivateVolume(partDevice, partGuid);}}}}...............
}void Disk::createPublicVolume(dev_t device) {auto vol = std::shared_ptr<VolumeBase>(new PublicVolume(device));if (mJustPartitioned) {LOG(DEBUG) << "Device just partitioned; silently formatting";vol->setSilent(true);vol->create();vol->format("auto");vol->destroy();vol->setSilent(false);}mVolumes.push_back(vol);vol->setDiskId(getId());vol->create();
}status_t VolumeBase::create() {CHECK(!mCreated);mCreated = true;//子类实现status_t res = doCreate();notifyEvent(ResponseCode::VolumeCreated,StringPrintf("%d \"%s\" \"%s\"", mType, mDiskId.c_str(), mPartGuid.c_str()));setState(State::kUnmounted);return res;
}

上面列举了创建Disk和Volume的代码，注意到进行实际工作后，均会调用notifyEvent函数。

我们接下来就看看notifyEvent函数的用途：

void Disk::notifyEvent(int event, const std::string& value) {//还记得么？VolumeManager初始时指定其Broadcaster为CommandListenerVolumeManager::Instance()->getBroadcaster()->sendBroadcast(event,StringPrintf("%s %s", getId().c_str(), value.c_str()).c_str(), false);
}

现在我们看看CommandListener的sendBroadcast函数（实际定义于父类的父类SocketListener中）：

void SocketListener::sendBroadcast(int code, const char *msg, bool addErrno) {SocketClientCollection safeList;/* Add all active clients to the safe list first *///这应该算一种好习惯吧safeList.clear();pthread_mutex_lock(&mClientsLock);SocketClientCollection::iterator i;//注意将SocketListener当前所有的SocketClient均加入到safeList，所以函数名才叫sendBroadcast//当然，对于Vold进程而言，它的client只有MountService对应的socketfor (i = mClients->begin(); i != mClients->end(); ++i) {SocketClient* c = *i;c->incRef();safeList.push_back(c);}pthread_mutex_unlock(&mClientsLock);while (!safeList.empty()) {/* Pop the first item from the list */i = safeList.begin();SocketClient* c = *i;safeList.erase(i);// broadcasts are unsolicited and should not include a cmd number//前面提到过SocketClient的sendMsg底层就是靠socket通信方式if (c->sendMsg(code, msg, addErrno, false)) {SLOGW("Error sending broadcast (%s)", strerror(errno));}c->decRef();}
}

从上面的代码，我们知道将由MountService来处理socket中的数据。
前面我们已经知道，MountService创建NativeDaemonConnector来封装socket相关的操作，在创建NativeDaemonConnector时需要传入回调接口。当NativeDaemonConnector收到数据后，通过回调接口进行通知。

MountService继承了INativeDaemonConnectorCallbacks，我们看看它的onEvent函数：

@Override
public boolean onEvent(int code, String raw, String[] cooked) {synchronized (mLock) {return onEventLocked(code, raw, cooked);}
}private boolean onEventLocked(int code, String raw, String[] cooked) {switch (code) {case VoldResponseCode.DISK_CREATED: {if (cooked.length != 3) break;final String id = cooked[1];int flags = Integer.parseInt(cooked[2]);if (SystemProperties.getBoolean(StorageManager.PROP_FORCE_ADOPTABLE, false)|| mForceAdoptable) {flags |= DiskInfo.FLAG_ADOPTABLE;}mDisks.put(id, new DiskInfo(id, flags));break;}...........case VoldResponseCode.VOLUME_CREATED: {final String id = cooked[1];final int type = Integer.parseInt(cooked[2]);final String diskId = TextUtils.nullIfEmpty(cooked[3]);final String partGuid = TextUtils.nullIfEmpty(cooked[4]);final DiskInfo disk = mDisks.get(diskId);final VolumeInfo vol = new VolumeInfo(id, type, disk, partGuid);mVolumes.put(id, vol);onVolumeCreatedLocked(vol);break;}...........}return true;
}

从上面的代码可以看出，MountService收到DISK_CREATED消息后，仅会记录DiskInfo；收到VOLUME_CREATED消息后，还需要调用onVolumeCreatedLocked函数作进一步地处理。

private void onVolumeCreatedLocked(VolumeInfo vol) {.........if (vol.type == VolumeInfo.TYPE_EMULATED) {.......} else if (vol.type == VolumeInfo.TYPE_PUBLIC) {//以public type为例mHandler.obtainMessage(H_VOLUME_MOUNT, vol).sendToTarget();} else if (vol.type == VolumeInfo.TYPE_PRIVATE) {........} else {.......}
}

class MountServiceHandler extends Handler {public MountServiceHandler(Looper looper) {super(looper);}@Overridepublic void handleMessage(Message msg) {switch (msg.what) {........final VolumeInfo vol = (VolumeInfo) msg.obj;if (isMountDisallowed(vol)) {Slog.i(TAG, "Ignoring mount " + vol.getId() + " due to policy");break;}try {//利用NativeDaemonConnector中socket将消息发送给CommandListenrmConnector.execute("volume", "mount", vol.id, vol.mountFlags,vol.mountUserId);} catch (NativeDaemonConnectorException ignored) {}break;........}}
}

注意消息重新发回到了CommandListener，根据前面的代码的分析我们知道，在FrameworkListener中将利用dispatchCommand根据类型，调用不同Command的runCommand方法，此处将调用volumeCommand的运行方法：

int CommandListener::VolumeCmd::runCommand(SocketClient *cli,int argc, char **argv) {//解析参数.........else if (cmd == "mount" && argc > 2) {// mount [volId] [flags] [user]std::string id(argv[2]);auto vol = vm->findVolume(id);if (vol == nullptr) {return cli->sendMsg(ResponseCode::CommandSyntaxError, "Unknown volume", false);}int mountFlags = (argc > 3) ? atoi(argv[3]) : 0;userid_t mountUserId = (argc > 4) ? atoi(argv[4]) : -1;vol->setMountFlags(mountFlags);vol->setMountUserId(mountUserId);//调用volumebase的mount方法，实际调用其子类的doMountint res = vol->mount();if (mountFlags & android::vold::VolumeBase::MountFlags::kPrimary) {vm->setPrimary(vol);}//执行成功后，将返回消息给MountServicereturn sendGenericOkFail(cli, res);}.........
}

我们跟进一下VolumeBase的mount函数：

void VolumeBase::setState(State state) {mState = state;//再次通知到MountServicenotifyEvent(ResponseCode::VolumeStateChanged, StringPrintf("%d", mState));
}

在MountService的onEvent函数中，将再次处理VolumeStateChanged事件，实际上就是发送ACTION_MEDIA_MOUNTED广播。

上述的整个过程略去了大量的细节，但看起来仍很琐碎。不过，若是理解了前面介绍CommandListener时，分析的整个通信架构，那么这些流程的大致方向是比较好理解的。

结束语
Vold进程的主要内容基本上就是这些，在实际的工作中大多数人应该不会接触到这个进程。但是它整个架构是非常具有参考意义的，很清晰地阐释了Android中的框架层、Native层以及Kernel是如何交互的。Android中还有许多重要部分也采用了类似的架构，比较明显的就是netd。因此，以Vold入手进行分析，重在理解这种通信架构。

Android 7.0 Vold工作流程相关推荐

Android 9.0 Vold 挂载流程分析
在Android 系统中所有的热插拔设备都是通过Vold 进程挂载的.通过kernel–>vold–>StorageManagerService这样的架构去逐级上报热插拔事件. 一.Vol ...
android 6.0 vold shutdown流程
这篇博客我们主要分析下vold在关机时候的流程,先看如下代码: 一.接收shutdown命令这是vold接收MountService的命令,我们主要看下shutdown命令 int CommandL ...
Android 7.0 WifiMonitor工作流程分析
2019独角兽企业重金招聘Python工程师标准>>> 在wifi启动扫描的分析过程中,出现了多次WifiMonitor的操作,在此分析一下这个函数是如何工作的. 在Android的 ...
Android 8.0 p2p搜索流程
#Android 8.0 p2p搜索流程 8.0 wifi p2p整体流程跟其他Android版本相差不大,主要还是多了HIDL一层转换而已以下是8.0 p2p的搜索流程
Android7.0 Rild工作流程
点击打开链接一.基于Rild的通信架构一般智能手机的硬件架构都是两个处理器: 一个处理器用来运行操作系统,上面运行应用程序,这个处理器称作Application Processor,简称AP:另 ...
Vold工作流程分析学习
一 Vold工作机制分析 vold进程:管理和控制Android平台外部存储设备,包括SD插拨.挂载.卸载.格式化等: vold进程接收来自内核的外部设备消息. Vold框架图如下: Vold接收来自 ...
android的构成和工作流程,分析Android中View的工作流程
8种机械键盘轴体对比本人程序员,要买一个写代码的键盘,请问红轴和茶轴怎么选? 在分析View的工作流程时,需要先分析一个很重要的类,MeasureSpec.这个类在View的测量(Measure)过 ...
android volte功能,Android 8.0 Volte开关流程 HD图标显示
android 8.0的Volte开关流程.. Volte按钮: vendor/qcom/proprietary/telephont-app/NetworkSetting/src/com/qualco ...
android 9.0关机充电流程，充电图标和电量显示百分比修改
android 9.0关机充电图标和字体修改相关源文件电量显示百分比字体替换充电图标替换相关源文件 system/core/healthd/healthd_draw.cppsystem/cor ...

Android 7.0 Vold工作流程

Android 7.0 Vold工作流程相关推荐

最新文章

热门文章