Vold使用VM模块的流程是:
- 调用Instance创建一个VM对象。
- 调用setBroadcaster设置CL对象,这个函数和NM的setBroadcaster一样,所以本节不再介绍它。
- 调用start启动VM。
- 调用process_config配置VM。
现在来看除setBroadcaster之外的三个函数。
1. 创建VM和start的分析
VM的创建及start函数都非常简单,代码如下所示。
**VolumeManager.cpp**
~~~
VolumeManager *VolumeManager::Instance() {
if(!sInstance)
sInstance = new VolumeManager();
returnsInstance;
}
~~~
可以看到,VM也采用了单例的模式,所以全进程只会存在一个VM对象。
下面看VM的start:
**VolumeManager.cpp**
~~~
int VolumeManager::start() {
return 0;
}
~~~
start很简单,没有任何操作。
2. process_config的分析
process_config函数会根据配置文件配置VM对象,其代码如下所示:
**Main.cpp**
~~~
static int process_config(VolumeManager *vm) {
FILE*fp;
int n= 0;
charline[255];
//读取/etc/vold.fstab文件
if(!(fp = fopen("/etc/vold.fstab", "r"))) {
return -1;
}
while(fgets(line, sizeof(line), fp)) {
char *next = line;
char *type, *label, *mount_point;
n++;
line[strlen(line)-1] = '\0';
if(line[0] == '#' || line[0] == '\0')
continue;
if(!(type = strsep(&next, " \t"))) {
goto out_syntax;
}
if(!(label = strsep(&next, " \t"))) {
goto out_syntax;
}
if(!(mount_point = strsep(&next, " \t"))) {
goto out_syntax;
}
if(!strcmp(type, "dev_mount")) {
DirectVolume *dv = NULL;
char *part, *sysfs_path;
if (!(part = strsep(&next, " \t"))) {
......
goto out_syntax;
}
if (strcmp(part, "auto") && atoi(part) == 0) {
goto out_syntax;
}
if (!strcmp(part, "auto")) {
//①构造一个DirectVolume对象
dv = new DirectVolume(vm, label, mount_point, -1);
} else {
dv = new DirectVolume(vm, label, mount_point, atoi(part));
}
while((sysfs_path = strsep(&next, " \t"))) {
//②添加设备路径
if (dv->addPath(sysfs_path)) {
......
goto out_fail;
}
}
//为VolumeManager对象增加一个DirectVolume对象
vm->addVolume(dv);
}
......
}
......
return-1;
}
~~~
从上面代码中发现,process_config的主要功能就是解析/etc/vold.fstab。这个文件的作用和Linux系统中的fstab文件很类似,就是设置一些存储设备的挂载点,我的HTC G7手机上这个文件的内容如图9-3所示:
:-: ![](http://img.blog.csdn.net/20150802164336050?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
图9-3 我的手机上vold.fstab内容
从上图的红框中可知:
- sdcard为volume的名字。
- /mnt/sdcard表示mount的位置。
- 1表示使用存储卡上的第一个分区,auto表示没有分区。现在有很多定制的ROM要求SD卡上存在多个分区。
- /devices/xxxx等内容表示MMC设备在sysfs中的位置。
根据G7的vold.fstab文件,可以构造一个DirectVolume对象。
注意,根据手机刷的ROM的不同,vold.fstab文件会有较大差异。
3. DirectVolume的分析
DirectVolume从Volume类派生,可把它看成是一个外部存储卡(例如一张SD卡)在代码中的代表物。它封装了对外部存储卡的操作,例如加载/卸载存储卡、格式化存储卡等。
下面是process_config函数中和DirectVolume相关的地方:
- 一个是创建DirectVolume。
- 另一个是调用DirectVolume的addpath函数。
它们的代码如下所示:
**DirectVolume.cpp**
~~~
DirectVolume::DirectVolume(VolumeManager *vm,const char *label,
const char*mount_point, int partIdx) :
Volume(vm, label, mount_point) {//初始化基类
/*
注意其中的参数:
label为”sdcard”,mount_point为”/mnt/sdcard”,partIdx为1
*/
mPartIdx = partIdx;
//PathCollection定义为typedef android::List<char *> PathCollection
//其实就是一个字符串list
mPaths= new PathCollection();
for(int i = 0; i < MAX_PARTITIONS; i++)
mPartMinors[i] = -1;
mPendingPartMap = 0;
mDiskMajor = -1; //存储设备的主设备号
mDiskMinor = -1; //存储设备的次设备号,一个存储设备将由主次两个设备号标识。
mDiskNumParts = 0;
//设置状态为NoMedia
setState(Volume::State_NoMedia);
}
//再来看addPath函数,它主要目的是添加设备在sysfs中的路径,G7的vold.fstab上有两个路
//径,见图9-3中的最后一行。
int DirectVolume::addPath(const char *path) {
mPaths->push_back(strdup(path));
return0;
}
~~~
这里简单介绍一下addPath的作用。addPath把和某个存储卡接口相关的设备路径与这个DirectVolume绑定到一起,并且这个设备路径和Uevent中的DEVPATH是对应的,这样就可以根据Uevent的DEVPATH找到是哪个存储卡的DirectVolume发生了变动。当然手机上目前只有一个存储卡接口,所以Vold也只有一个DirectVolume。
4. NM和VM交互
在分析NM模块的数据处理时发现,NM模块接收到Uevent事件后,会调用VM模块进行处理,下面来看这块的内容。
先回顾一下NM调用VM模块的地方,代码如下所示:
**NetlinkHandler.cpp**
~~~
void NetlinkHandler::onEvent(NetlinkEvent *evt){
VolumeManager *vm = VolumeManager::Instance();
constchar *subsys = evt->getSubsystem();
......
if (!strcmp(subsys, "block")) {
vm->handleBlockEvent(evt); //调用VM的handleBlockEvent
} elseif (!strcmp(subsys, "switch")) {
vm->handleSwitchEvent(evt);//调用VM的handleSwitchEvent
}
......
}
~~~
在上面代码中,如果Uevent是block子系统,则调用handleBlockEvent;如果是switch,则调用handleSwitchEvent。handleSwitchEvent主要处理SD卡挂载磁盘的通知,比较简单。这里只分析handleBlockEvent事件。
**VolumeManager.cpp**
~~~
void VolumeManager::handleBlockEvent(NetlinkEvent*evt) {
constchar *devpath = evt->findParam("DEVPATH");
/*
前面在process_config中构造的DirectVolume对象保存在了mVolumes中,它的定义如下:
typedef android::List<Volume *>VolumeCollection,也是一个列表。
注意它保存的是Volume指针,而我们的DirectVolume是从Volume派生的
*/
VolumeCollection::iterator it;
boolhit = false;
for (it = mVolumes->begin(); it !=mVolumes->end(); ++it) {
//调用每个Volume的handleBlockEvent事件,就我的G7手机而言,实际上将调用
//DirectVolume的handleBlockEvent函数。
if(!(*it)->handleBlockEvent(evt)) {
hit = true;
break;
}
}
}
~~~
NM收到Uevent消息后,DirectVolume也将应声而动,它的handleBlockEvent的处理是:
**DirectVolume.cpp**
~~~
int DirectVolume::handleBlockEvent(NetlinkEvent*evt) {
constchar *dp = evt->findParam("DEVPATH");
PathCollection::iterator it;
//将Uevent的DEVPATH和addPath添加的路径进行对比,判断属不属于自己管理的范围。
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);
//创建设备节点
if (createDeviceNode(nodepath, major, minor)) {
......
}
if (!strcmp(devtype, "disk")) {
handleDiskAdded(dp, evt);//添加一个磁盘
} else {
/*
对于有分区的SD卡,先收到上面的“disk”消息,然后每个分区就会收到
一个分区添加消息。
*/
handlePartitionAdded(dp,evt);
}
} else if (action == NetlinkEvent::NlActionRemove) {
......
} else if (action == NetlinkEvent::NlActionChange) {
......
}
......
return 0;
}
}
errno= ENODEV;
return-1;
}
~~~
关于DirectVolume针对不同Uevent的具体处理方式,后面将通过一个SD卡插入案例来分析。
5. VM模块的总结
从前面的代码分析中可知,VM模块的主要功能是管理Android系统中的外部存储设备。图9-4描述了VM模块的功能:
:-: ![](http://img.blog.csdn.net/20150802164353303?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
图9-4 VM模块的职责
通过对上图和前面代码的分析可知:
- SD卡的变动(例如热插拔)将导致Kernel发送Uevent消息给NM模块。
- NM模块调用VM模块处理这些Uevent消息。
- VM模块遍历它所持有的Volume对象,Volume对象根据addPath添加的DEVPATH和Uevent消息中的DEVPATH来判断,自己是否可以处理这个消息。
至于Volume到底如何处理Uevent消息,将通过一个实例来分析。
- 前言
- 第1章 阅读前的准备工作
- 1.1 系统架构
- 1.1.1 Android系统架构
- 1.1.2 本书的架构
- 1.2 搭建开发环境
- 1.2.1 下载源码
- 1.2.2 编译源码
- 1.3 工具介绍
- 1.3.1 Source Insight介绍
- 1.3.2 Busybox的使用
- 1.4 本章小结
- 第2章 深入理解JNI
- 2.1 JNI概述
- 2.2 学习JNI的实例:MediaScanner
- 2.3 Java层的MediaScanner分析
- 2.3.1 加载JNI库
- 2.3.2 Java的native函数和总结
- 2.4 JNI层MediaScanner的分析
- 2.4.1 注册JNI函数
- 2.4.2 数据类型转换
- 2.4.3 JNIEnv介绍
- 2.4.4 通过JNIEnv操作jobject
- 2.4.5 jstring介绍
- 2.4.6 JNI类型签名介绍
- 2.4.7 垃圾回收
- 2.4.8 JNI中的异常处理
- 2.5 本章小结
- 第3章 深入理解init
- 3.1 概述
- 3.2 init分析
- 3.2.1 解析配置文件
- 3.2.2 解析service
- 3.2.3 init控制service
- 3.2.4 属性服务
- 3.3 本章小结
- 第4章 深入理解zygote
- 4.1 概述
- 4.2 zygote分析
- 4.2.1 AppRuntime分析
- 4.2.2 Welcome to Java World
- 4.2.3 关于zygote的总结
- 4.3 SystemServer分析
- 4.3.1 SystemServer的诞生
- 4.3.2 SystemServer的重要使命
- 4.3.3 关于 SystemServer的总结
- 4.4 zygote的分裂
- 4.4.1 ActivityManagerService发送请求
- 4.4.2 有求必应之响应请求
- 4.4.3 关于zygote分裂的总结
- 4.5 拓展思考
- 4.5.1 虚拟机heapsize的限制
- 4.5.2 开机速度优化
- 4.5.3 Watchdog分析
- 4.6 本章小结
- 第5章 深入理解常见类
- 5.1 概述
- 5.2 以“三板斧”揭秘RefBase、sp和wp
- 5.2.1 第一板斧--初识影子对象
- 5.2.2 第二板斧--由弱生强
- 5.2.3 第三板斧--破解生死魔咒
- 5.2.4 轻量级的引用计数控制类LightRefBase
- 5.2.5 题外话-三板斧的来历
- 5.3 Thread类及常用同步类分析
- 5.3.1 一个变量引发的思考
- 5.3.2 常用同步类
- 5.4 Looper和Handler类分析
- 5.4.1 Looper类分析
- 5.4.2 Handler分析
- 5.4.3 Looper和Handler的同步关系
- 5.4.4 HandlerThread介绍
- 5.5 本章小结
- 第6章 深入理解Binder
- 6.1 概述
- 6.2 庖丁解MediaServer
- 6.2.1 MediaServer的入口函数
- 6.2.2 独一无二的ProcessState
- 6.2.3 时空穿越魔术-defaultServiceManager
- 6.2.4 注册MediaPlayerService
- 6.2.5 秋风扫落叶-StartThread Pool和join Thread Pool分析
- 6.2.6 你彻底明白了吗
- 6.3 服务总管ServiceManager
- 6.3.1 ServiceManager的原理
- 6.3.2 服务的注册
- 6.3.3 ServiceManager存在的意义
- 6.4 MediaPlayerService和它的Client
- 6.4.1 查询ServiceManager
- 6.4.2 子承父业
- 6.5 拓展思考
- 6.5.1 Binder和线程的关系
- 6.5.2 有人情味的讣告
- 6.5.3 匿名Service
- 6.6 学以致用
- 6.6.1 纯Native的Service
- 6.6.2 扶得起的“阿斗”(aidl)
- 6.7 本章小结
- 第7章 深入理解Audio系统
- 7.1 概述
- 7.2 AudioTrack的破解
- 7.2.1 用例介绍
- 7.2.2 AudioTrack(Java空间)分析
- 7.2.3 AudioTrack(Native空间)分析
- 7.2.4 关于AudioTrack的总结
- 7.3 AudioFlinger的破解
- 7.3.1 AudioFlinger的诞生
- 7.3.2 通过流程分析AudioFlinger
- 7.3.3 audio_track_cblk_t分析
- 7.3.4 关于AudioFlinger的总结
- 7.4 AudioPolicyService的破解
- 7.4.1 AudioPolicyService的创建
- 7.4.2 重回AudioTrack
- 7.4.3 声音路由切换实例分析
- 7.4.4 关于AudioPolicy的总结
- 7.5 拓展思考
- 7.5.1 DuplicatingThread破解
- 7.5.2 题外话
- 7.6 本章小结
- 第8章 深入理解Surface系统
- 8.1 概述
- 8.2 一个Activity的显示
- 8.2.1 Activity的创建
- 8.2.2 Activity的UI绘制
- 8.2.3 关于Activity的总结
- 8.3 初识Surface
- 8.3.1 和Surface有关的流程总结
- 8.3.2 Surface之乾坤大挪移
- 8.3.3 乾坤大挪移的JNI层分析
- 8.3.4 Surface和画图
- 8.3.5 初识Surface小结
- 8.4 深入分析Surface
- 8.4.1 与Surface相关的基础知识介绍
- 8.4.2 SurfaceComposerClient分析
- 8.4.3 SurfaceControl分析
- 8.4.4 writeToParcel和Surface对象的创建
- 8.4.5 lockCanvas和unlockCanvasAndPost分析
- 8.4.6 GraphicBuffer介绍
- 8.4.7 深入分析Surface的总结
- 8.5 SurfaceFlinger分析
- 8.5.1 SurfaceFlinger的诞生
- 8.5.2 SF工作线程分析
- 8.5.3 Transaction分析
- 8.5.4 关于SurfaceFlinger的总结
- 8.6 拓展思考
- 8.6.1 Surface系统的CB对象分析
- 8.6.2 ViewRoot的你问我答
- 8.6.3 LayerBuffer分析
- 8.7 本章小结
- 第9章 深入理解Vold和Rild
- 9.1 概述
- 9.2 Vold的原理与机制分析
- 9.2.1 Netlink和Uevent介绍
- 9.2.2 初识Vold
- 9.2.3 NetlinkManager模块分析
- 9.2.4 VolumeManager模块分析
- 9.2.5 CommandListener模块分析
- 9.2.6 Vold实例分析
- 9.2.7 关于Vold的总结
- 9.3 Rild的原理与机制分析
- 9.3.1 初识Rild
- 9.3.2 RIL_startEventLoop分析
- 9.3.3 RIL_Init分析
- 9.3.4 RIL_register分析
- 9.3.5 关于Rild main函数的总结
- 9.3.6 Rild实例分析
- 9.3.7 关于Rild的总结
- 9.4 拓展思考
- 9.4.1 嵌入式系统的存储知识介绍
- 9.4.2 Rild和Phone的改进探讨
- 9.5 本章小结
- 第10章 深入理解MediaScanner
- 10.1 概述
- 10.2 android.process.media分析
- 10.2.1 MSR模块分析
- 10.2.2 MSS模块分析
- 10.2.3 android.process.media媒体扫描工作的流程总结
- 10.3 MediaScanner分析
- 10.3.1 Java层分析
- 10.3.2 JNI层分析
- 10.3.3 PVMediaScanner分析
- 10.3.4 关于MediaScanner的总结
- 10.4 拓展思考
- 10.4.1 MediaScannerConnection介绍
- 10.4.2 我问你答
- 10.5 本章小结