Android Storage Manager 处理

原文地址：

http://blog.chinaunix.net/uid-26281173-id-3761483.html

Storage Manager

前言

在Android系统中，常用的存储介质是Nand Flash；系统的二进制镜像、Android的文件系统等通常都保存在Nand Flash 中。通常使用的Micro-SD卡的管理则是由卷守护进程(Volume Daemon ,vold)去完成的，包括SD卡的插拔事件检测、挂载、卸载、格式化等。这里会从Volume的原理和机制去分析Android对于UMS的管理；并通过一个SD Card的挂载过程详细说明。当热插拔SD Card的时候所引起的Linux Kernel的变化，如如何发出uevent消息等没深入研究，Vold接收这些uevent消息也仅仅是提到而已；因此这几着重介绍Vold、syslibutils以及MountService。

1、Vold的原理与机制

  有关Vold的架构可以用图1-1来表示



图1-1 Vold架构

从图1-1Vold架构，可以大致的了解Android针对外部存储的管理流程。

1、外部存储插入的时候，Linux Kernel会发出uevent事件给Vold

2、Vold守护进程通过Socket机制从Linux Kernel获取相应的uevent，并解析成不同的状态；

3、然后在由MountService来获取这些由Vold解析出的相应状态决定发出什么样的广播、给Vold作出什么样的反应。

4、进而Vold依据MountService的反应稍加处理交由Kernel处理。

这里需要走出一个误区：当插入SD卡的时候Kernel发出uevent、Vold处理event，MountService从Vold获取相应信息发出广播，app在接收到广播之后会作出相应的处理；其实到这里SD卡并没有真正的被挂载到系统中，仅仅是触发了相应的uevent，而真正的挂载并没有执行。实际情况是如图1-1Vold架构所示，先得到Uevent在交由Vold进行解析，然后由MountService获取信息发出mount、unmount等命令给Vold，在由Kernel进行针对存储设备的挂载、卸载、格式化等操作。

1.1 Vold针对不同信息的处理

上面有讲到，Vold不仅仅要处理来自Kernel的Uevent等信息，还得处理来自MountService的信息。那么到底Vold是如何获取到Kernel发上来的Uevent信息？Vold又是如何从MountService获取到上层要发给Kernel的命令的呢？

在这里拥有一个重要的基类SocketListener。不仅对kernel发出的uevent进行监听还对MountService想kernel发出的命令进行监听。其常用类之间的结构关系如图1-2 Vold重要类关系图



图1-2 Vold重要类关系图

通过类图，我们可以大致的了解到Vold的工作流程、工作原理：Vold是Android平台中外部存储系统的管理中心；从kernel来的相关event以及从frameworks来的commond都要通过Vold来进行通信。这里Kernel和Frameworks不仅仅是从Vold获取东西也会想Vold发出命令。下图我们将会更加详细的介绍存储设备的挂载流程。

如图1-2 处理流程，更加清晰的说明了Android针对Storage Manager的处理流程。就更加凸显了SocketListener这个类的重要性；并且Vold和MountService之间在进行进程间通信的时候并没有用到复杂Binder，而是直接的使用了Socket；这样就是的本身简单的Vold系统更加易懂。



图1-2 处理流程

2、Vold工作过程

2.1处理Kernel信息

当外部存储SD Card插入之后，Kernel会发出相应的Uevent消息；而这时Vold也正在监听，所以会有Vold当中的NetLinkManager接受到消息。当然在这消息的接受-在发送过程中肯定是有消息的解析并针对解析出的相关信息在作出动作。设计到的主要类如下图所示



图2-1Sock相关类

在能否获取Kernel的Uevent之前，SocketListener便会启动一个线程去针对Kernel的event进行监听；同时还会创建一个用于传输数据的pipe。当Kernel有event抵达，也就是有数据通过Socket发送过来，就会调用SocketListener自己的onDataAvailable对数据进行处理。而这里SocketListener的onDataAvailable是一个纯虚函数，其真正的实现在NetlinkListener中，所以数据的真正解析在NetlinkListener中。如果解析event OK，那么这个时候就该发出一个event给Volume Manager了。

其实通过这里，我们也可以看出Vold这个较小的进程也分为两个部分：一个同Kernel接触，一个桶Framework接触。

2.2向Framework发出通知

几乎所有从Kernel上来的mount信息以及从Frameworks到Kernel的mount消息都需要经过DirectVolume.cpp的handleBlockEvent来进行处理。

点击(此处)折叠或打开

int DirectVolume::handleBlockEvent(NetlinkEvent
*evt)
{

    const char
*dp = evt->findParam("DEVPATH");

    PathCollection::iterator it;

    for (it
= mPaths->begin(); it
!= mPaths->end();
++it)
{

        if (!strncmp(dp,
*it, strlen(*it)))
{

            /* We can handle this disk
*/

            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];

                /*获得当前node的信息*/

                snprintf(nodepath,

                         sizeof(nodepath),
"/dev/block/vold/%d:%d",

                         major, minor);

                /*创建node mknod*/

                if
(createDeviceNode(nodepath, major, minor))
{

                    SLOGE("Error making device node '%s' (%s)", nodepath,

                                                           strerror(errno));

                }

                /*是否有分区，disk 没有分区*/

                if
(!strcmp(devtype,
"disk"))
{

                    handleDiskAdded(dp, evt);

                }
else {

                    handlePartitionAdded(dp, evt);

                }

                /* Send notification iff disk
is ready (ie all partitions found)
*/

                /*开始给Frameworks发广播了。。*/

                if
(getState()
== Volume::State_Idle)
{

                    char msg[255];

                    snprintf(msg, sizeof(msg),

                             "Volume %s %s disk inserted (%d:%d)", getLabel(),

                             getMountpoint(), mDiskMajor, mDiskMinor);

                    mVm->getBroadcaster()->sendBroadcast(

ResponseCode::VolumeDiskInserted, msg,
false);

                }

            /*下面的两个不注释了。。。*/

            }
else if (action
== NetlinkEvent::NlActionRemove)
{

                if
(!strcmp(devtype,
"disk"))
{

                    handleDiskRemoved(dp, evt);

                }
else {

                    handlePartitionRemoved(dp, evt);

                }

            }
else if (action
== NetlinkEvent::NlActionChange)
{

                if
(!strcmp(devtype,
"disk"))
{

                    handleDiskChanged(dp, evt);

                }
else {

                    handlePartitionChanged(dp, evt);

                }

            }
else {

               SLOGW("Ignoring non add/remove/change event");

            }

            return 0;

        }

    }

    errno = ENODEV;

    return -1;

}

在调用handleDiskAdded(dp, evt);完成之后，便会从系统中获取该存储设备的相关信息；准备发广播给Frameworks了。

点击(此处)折叠或打开

snprintf(msg, sizeof(msg),
"Volume %s %s disk inserted (%d:%d)", getLabel(),

                    getMountpoint(), mDiskMajor, mDiskMinor);

mVm->getBroadcaster()->sendBroadcast(ResponseCode::VolumeDiskInserted,
msg, false);

这里需要注意一点：在handleDiskAdded中，处理完成了之后，会更新当前磁盘的状态

setState(Volume::State_Idle);这个函数需要重点关注

这样Frameworks就收到了有存储设备的消息；下面来看看Framew是如何处理这样的信息的。

点击(此处)折叠或打开

public
boolean onEvent(int code,
String raw,
String[] cooked)
{

/*……………*/

} else
if ((code
== VoldResponseCode.VolumeDiskInserted)
||

(code == VoldResponseCode.VolumeDiskRemoved)
||

  (code == VoldResponseCode.VolumeBadRemoval))
{

    // FMT: NNN Volume <label> <mountpoint> disk inserted (<major>:<minor>)

    // FMT: NNN Volume <label> <mountpoint> disk removed (<major>:<minor>)

    // FMT: NNN Volume <label> <mountpoint> bad removal (<major>:<minor>)

final String path
= cooked[3];

/*这里是见证奇迹的时刻之一。。哈哈*/

    if (code
== VoldResponseCode.VolumeDiskInserted)
{

      if ((rc
= doMountVolume(path))
!= StorageResultCode.OperationSucceeded)
{

这个onEvent目前先看到这里，去看看doMountVolume

点击(此处)折叠或打开

private
int doMountVolume(String path)
{

mConnector.execute("volume",
"mount", path);

这里mConnector 是一个 NativeDaemonConnector对象，算是一个守护程序吧，跟守护进程差不多，专门用来处理 libsysutils中通过FrameworkListener协议来进行信息传递。

这里转了一大圈又回到了Vold。接下来继续回到Vold进行查看。在这其中会经过libsysutils的一些转换，这里直接去Volume.cpp 中的mountVol查看。首先会检测是否已经被mount了。

点击(此处)折叠或打开

if
(isMountpointMounted(getMountpoint()))
{

        setState(Volume::State_Mounted);

        // mCurrentlyMountedKdev
= XXX

        return 0;

    }

到这里，setState() 的作用，我觉得可以这么来理解，他同Activity的生命周期相同，只不过这里是“显示”的去修改各个状态，而Activity Android系统本身已经做好了。这里假设目前还没有被mount，接着往下看：

点击(此处)折叠或打开

/* We
now have the new sysfs path
for the decrypted block device,
and the

* majore and minor numbers
for it. So, create the device, update the

* path to the new sysfs path,
and continue.

*/

 snprintf(nodepath, sizeof(nodepath),
"/dev/block/vold/%d:%d",

                 new_major, new_minor);

 if (createDeviceNode(nodepath, new_major, new_minor))
{

    SLOGE("Error making device node '%s' (%s)", nodepath, strerror(errno));

 }

// Todo: Either create sys filename from nodepath,
or pass in bogus path so

// vold ignores state changes
on this internal device.

 updateDeviceInfo(nodepath, new_major, new_minor);

/*
Get the device nodes again, because they just changed
*/

n = getDeviceNodes((dev_t
*)
&deviceNodes, 4);

。。。。

sprintf(devicePath,
"/dev/block/vold/%d:%d", MAJOR(deviceNodes[i]),

                MINOR(deviceNodes[i]));

setState(Volume::State_Checking);

。。。。。。

if (Fat::doMount(devicePath,
"/mnt/secure/staging",
false,
false, false,

                AID_SYSTEM, gid, 0702,
true))
{

    continue;

}

/*。。。。*/

/*删除autorun.inf
.为啥？？不为啥?就是要删！！*/

protectFromAutorunStupidity();

        /*

         * Now that the bindmount trickery
is done, atomically move the

         * whole subtree
to expose it to non priviledged users.
*/

        if (doMoveMount("/mnt/secure/staging", getMountpoint(),
false))
{

            SLOGE("Failed to move mount (%s)", strerror(errno));

            umount("/mnt/secure/staging");

            setState(Volume::State_Idle);

            return -1;

        }

        /* 又是这个神一样的函数，setState，这次可是设置了State_Mounted，

         * 很明显，这里要发广播了，给Frameworks发！告诉Frameworks，

         * 我这儿已经mounted完成了，剩下就是你的事儿了

*/

        setState(Volume::State_Mounted);

        mCurrentlyMountedKdev = deviceNodes[i];

        return 0;

    }

从现在开始，磁盘的大部分操作同Vold、Kernel基本上没什么关系了，继续来看看MountService对消息的处理。

点击(此处)折叠或打开

if
(code == VoldResponseCode.VolumeStateChange)
{

 /*

　* One of the volumes we're managing has changed state.

 * Format: "NNN Volume <label> <path> state changed

 * from <old_#> (<old_str>) to <new_#> (<new_str>)"

 */

 notifyVolumeStateChange(cooked[2], cooked[3],

　　　　　　　　　　　　Integer.parseInt(cooked[7]),
Integer.parseInt(cooked[10]));

notifyVolumeStateChange函数基本上就干了一件事儿：发ACTION_MEDIA_* 各种广播。。这就不多说了。到这儿所有APP，该接受的接受，该处理的处理，干干啥的干啥。

Over，完了 

名词解释

UMS ：    USB Mass Storage                    USB大容量存储

Vold  :     Volume Daemon                      卷守护进程

MTD ：    Memory Technology Device            内存技术设备

EMMC：   Embedded MultiMedia Card             内嵌式多媒体卡

Volume 状态

    static const int State_Init       = -1;

    static const int State_NoMedia    = 0;

    static const int State_Idle       = 1;

    static const int State_Pending    = 2;

    static const int State_Checking   = 3;

    static const int State_Mounted    = 4;

    static const int State_Unmounting = 5;

    static const int State_Formatting = 6;

    static const int State_Shared     = 7;

static const int State_SharedMnt  = 8;

阅读(620) | 评论(1) | 转发(3) |

0
上一篇：Android 按键消息处理

下一篇：将博客搬至CSDN

相关热门文章
android开发---解压system.img...

www.christianlouboutinsaleso...

不用vs和cygwin！Eclipse+cdt...

CU博客频道3月技术图书有奖试...

让ProgressDialog在setCancela...

求教Linux 终端自动执行脚本的...

以下描述的关于apache和PHP关...

求教学习有关于linux 驱动方面...

【趣味题】 发疯的机器人...

如何安装java环境和tomcat（ub...





CU博客助理2013-08-13 11:04:12
嘉宾点评：这是一篇非常细腻的技术博文，详细阐述了Android外存管理的Vold架构及其处理过程。结构清晰、层次明确，大有论文风范，文内插图制作精良，足见作者的用心，最后还附上了名词解释及Volume状态参数说明。此文对于想要了解Android外存管理及优化的博友而言，是很不错的参考。（感谢您参与“原创博文评选”获奖结果即将公布）
回复 |
举报

评论热议