Android—— 4.2 Vold挂载管理_DirectVolume/Volume (五)

本文深入解析了Android系统中Vold如何管理挂载操作,包括DirectVolume与Volume类的作用及其实现细节,并探讨了挂载流程中的状态管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 在前文Android—— 4.2 Vold挂载管理_VolumeManager (三) 中解析了VolumeManager是怎么样抽取Volume实例以及DirectVolume与Volume之间的关系,在上篇Android—— 4.2 Vold挂载管理_NetlinkManager (四)中从kernel开始调用到handleBlockEvent,这里解析一下Vold挂载的真正操作,也就是Volume的操作!


                                                       撰写不易,转载请注明出处:http://blog.youkuaiyun.com/jscese/article/details/38736481



一.DirectVolume抽象

源码位置:/system/vold/DirectVolume.cpp ,这个类是作为真正的Volume的一个抽象操作类,先看构造:

DirectVolume::DirectVolume(VolumeManager *vm, const char *label,
                           const char *mount_point, int partIdx) :
              Volume(vm, label, mount_point) {//同时构造父类实例
    mPartIdx = partIdx;//记录分区索引

    mPaths = new PathCollection();//路径容器
    for (int i = 0; i < MAX_PARTITIONS; i++) //google默认最多分区数为4
        mPartMinors[i] = -1;
    mPendingPartMap = 0;
    mDiskMajor = -1;
    mDiskMinor = -1;
    mDiskNumParts = 0;

    setState(Volume::State_NoMedia);//初始设置状态
}

上一篇有解析到DirectVolume的handleBlockEvent:

 

int DirectVolume::handleBlockEvent(NetlinkEvent *evt) {
    const char *dp = evt->findParam("DEVPATH"); //获取事件的设备路径

    PathCollection::iterator  it; //这个DirectVolume的Path容器,容器在构建时初始化,在VolumeManager中根据vold.fstab添加path
    for (it = mPaths->begin(); it != mPaths->end(); ++it) {
        if (!strncmp(dp, *it, strlen(*it))) { //筛选符合此次事件的Path,如果没有匹配的就退出这个DirectVolume实例的处理,在VolumeManager中交由下一个DirectVolume来处理,依次类推
            /* We can handle this disk */
            int action = evt->getAction();
            const char *devtype = evt->findParam("DEVTYPE");

            if (action == NetlinkEvent::NlActionAdd) { //事件类型有好几种,这里单以Add 添加来分析
                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)) { //创建节点
                    SLOGE("Error making device node '%s' (%s)", nodepath,
                                                               strerror(errno));
                }
                if (!strcmp(devtype, "disk")) {
                    handleDiskAdded(dp, evt); //处理型号为disk的事件,当插入一个移动设备,不管有多少个分区,首先第一个事件的类型就是disk,收集设备的相关信息,比如分区总数mDiskNumParts
                } else {
                    handlePartitionAdded(dp, evt); //处理设备的分区事件信息
                }
                /* Send notification iff disk is ready (ie all partitions found) */
                if (getState() == Volume::State_Idle) { //通过上面的handle ,代表已经准备就绪
                    char msg[255];

                    snprintf(msg, sizeof(msg),
                             "Volume %s %s disk inserted (%d:%d)", getLabel(),
                             getMountpoint(), mDiskMajor, mDiskMinor);
                    mVm->getBroadcaster()->sendBroadcast(ResponseCode::VolumeDiskInserted, //发送广播,调用的是SocketListener的sendBroadcast
                                                         msg, false);
                }
            }

         ...

       }

   }

}

在handlePartitionAdded中有收集分区的节点信息  mPartMinors[part_num -1] = minor; 并且设置Volume的状态到 Volume::State_Idle ,最后调用VolumeManager的实例发送广播

实际调用的是SocketListener的sendBroadcast,在Android—— 4.2 Vold挂载管理_CommandListener (二)中有分析!

void SocketListener::sendBroadcast(int code, const char *msg, bool addErrno) {
    pthread_mutex_lock(&mClientsLock); //加锁
    SocketClientCollection::iterator i;

    for (i = mClients->begin(); i != mClients->end(); ++i) { //遍历在SocketListener时创建的Client 依次发送广播
        // broadcasts are unsolicited and should not include a cmd number
        if ((*i)->sendMsg(code, msg, addErrno, false)) {
            SLOGW("Error sending broadcast (%s)", strerror(errno));
        }
    }
    pthread_mutex_unlock(&mClientsLock);
}

发送过程源码位于:/system/core/libsysutils/src/SocketClient.cpp中最终调用到:

int SocketClient::sendDataLocked(const void *data, int len) {
    int rc = 0;

    while (brtw > 0) {
        rc = send(mSocket, p, brtw, MSG_NOSIGNAL);

 ...

  }

}


这里的mSocket 为 "vold" 这个socket的表述符!


二.Volume处理:

  在上面DirectVolume中发送出去广播之后,会到上层的MountService.java中,再通过"vold"socket 到Vold中,在SocketListener 中会接收到,依次会调用到FrameworkListener.cpp中的onDataAvailable,dispatchCommand

再到CommandListener.cpp中的runCommand,VolumeManager.cpp中的mountVolume   Android—— 4.2 Vold挂载管理_CommandListener (二)中有分析!

int VolumeManager::mountVolume(const char *label) {
    Volume *v = lookupVolume(label);

    if (!v) {
        errno = ENOENT;
        return -1;
    }

    return v->mountVol(); //调用到Volume的mountVol
}


看Volume.cpp中:

int Volume::mountVol() {
    dev_t deviceNodes[4];
    int n, i, rc = 0;
    char errmsg[255];
    const char* externalStorage = getenv("EXTERNAL_STORAGE");
    bool primaryStorage = externalStorage && !strcmp(getMountpoint(), externalStorage);
    char decrypt_state[PROPERTY_VALUE_MAX];
    char crypto_state[PROPERTY_VALUE_MAX];
    char encrypt_progress[PROPERTY_VALUE_MAX];
    int flags;

    property_get("vold.decrypt", decrypt_state, "");
    property_get("vold.encrypt_progress", encrypt_progress, "");

    /* Don't try to mount the volumes if we have not yet entered the disk password
     * or are in the process of encrypting.
     */
    if ((getState() == Volume::State_NoMedia) ||
        ((!strcmp(decrypt_state, "1") || encrypt_progress[0]) && primaryStorage)) { //Volume的状态不对或者是加密的
        snprintf(errmsg, sizeof(errmsg),
                 "Volume %s %s mount failed - no media",
                 getLabel(), getMountpoint());
        mVm->getBroadcaster()->sendBroadcast(
                                         ResponseCode::VolumeMountFailedNoMedia,
                                         errmsg, false);
        errno = ENODEV;
        return -1;
    } else if (getState() != Volume::State_Idle) {// 正常的逻辑到这里的时候,该Volume的state应为State_Idle
        errno = EBUSY;
        if (getState() == Volume::State_Pending) {
            mRetryMount = true;
        }
        return -1;
    }
    ...

    for (i = 0; i < n; i++) {
        char devicePath[255];

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

        SLOGI("%s being considered for volume %s\n", devicePath, getLabel());

        errno = 0;
        setState(Volume::State_Checking);

        if (Fat::check(devicePath)) { //调用Fat的check,检查是否为Fat的文件系统
            if (errno == ENODATA) {
                SLOGW("%s does not contain a FAT filesystem\n", devicePath);
                continue;
            }

        ...

             if (primaryStorage) {//是否为指定的external storage 以不同的gid挂载
            // Special case the primary SD card.
            // For this we grant write access to the SDCARD_RW group.
            gid = AID_SDCARD_RW;
        } else {
            // For secondary external storage we keep things locked up.
            gid = AID_MEDIA_RW;
        }
        if (Fat::doMount(devicePath, "/mnt/secure/staging", false, false, false,  //这里就是整个Vold 里面真正的挂载
                AID_SYSTEM, gid, 0702, true)) {
            SLOGE("%s failed to mount via VFAT (%s)\n", devicePath, strerror(errno));
            continue;
        }

     ...

     setState(Volume::State_Mounted);

     ...

  }

}


在整个挂载流程中state至关重要,通过state对挂载流程进行管控:

Volume.h中定义:

    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;

同时各个state的设置都向上层发送:


void Volume::setState(int state) {
    char msg[255];
    int oldState = mState;

    if (oldState == state) {
        SLOGW("Duplicate state (%d)\n", state);
        return;
    }

    if ((oldState == Volume::State_Pending) && (state != Volume::State_Idle)) {
        mRetryMount = false;
    }

    mState = state;

    SLOGD("Volume %s state changing %d (%s) -> %d (%s)", mLabel,
         oldState, stateToStr(oldState), mState, stateToStr(mState));
    snprintf(msg, sizeof(msg),
             "Volume %s %s state changed from %d (%s) to %d (%s)", getLabel(),
             getMountpoint(), oldState, stateToStr(oldState), mState,
             stateToStr(mState));

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



简单画了一张功能流程图:

                              


DirectVolume/Volume的大体运作就是这样,后续分析与上层Framework层的交互。




<think>嗯,用户之前问过关于voldsdcardfs和FUSE的区别和关系,现在又提出了一个具体的问题,涉及到挂载选项中的ro(只读)和后续的sdcardfs和FUSE显示为rw(读写)的情况。用户可能是在实际使用中遇到了存储设备无法写入的问题,或者在查看mount命令输出时发现了不一致的地方,想要确认这种情况下是否实际还是只读的。 首先,我需要回忆之前的回答,确认vold负责挂载物理设备到/mnt/media_rw,而sdcardfs和FUSE则处理权限和用户空间的映射。用户提到vold挂载时用了ro,但后续的挂载显示为rw,这可能引起混淆,因为用户可能认为即使底层是只读的,上层显示读写是否有效。 接下来,我需要考虑用户可能的误解点。用户可能认为如果底层挂载为只读,那么上层即使显示rw也无法实际写入。但实际情况可能更复杂,因为sdcardfs和FUSE可能有自己的处理方式,比如模拟写入操作但实际无法写入物理设备。需要解释清楚权限和实际可操作性的区别。 然后,我需要检查技术细节。当vold以ro挂载时,任何上层文件系统(如sdcardfs或FUSE)的rw挂载实际上会受到底层只读的限制。这意味着用户空间的应用程序可能会看到可读写权限,但实际尝试写入时会失败,因为底层设备是只读的。 此外,用户可能是在调试或配置存储设备时遇到了问题,例如SD卡被挂载为只读,但系统界面显示可读写,导致困惑。需要解释这种不一致的原因,并说明如何正确诊断存储设备的实际挂载状态。 最后,确保回答结构清晰,分步骤解释每个组件的作用,以及ro和rw在不同层级的表现,帮助用户理解即使上层显示rw,底层限制仍然存在。同时,提供验证方法,如直接写入底层目录或检查dmesg日志,帮助用户自行确认实际情况。</think>以下是逐步解释: --- ### **关键结论** **不完全正确**,具体取决于实际挂载层级和权限控制,但存在以下核心逻辑: --- ### **1. vold的`ro`挂载是物理层限制** - **现象**:若vold挂载物理设备到`/mnt/media_rw/[UUID]`时指定了`ro`(只读),例如: ```bash /dev/block/vold/public:8,17 on /mnt/media_rw/1474AA4874AA2D04 type exfat (ro, ...) ``` **此时底层存储设备的物理挂载点已强制只读**,所有上层操作均受此限制。 --- ### **2. sdcardfs/FUSE的`rw`挂载是虚拟层权限** - **现象**:sdcardfs或FUSE可能以`rw`(读写)挂载到上层路径(如`/storage/[UUID]`): ```bash /mnt/media_rw/1474AA4874AA2D04 on /storage/1474AA4874AA2D04 type fuse (rw, ...) ``` **这仅表示“虚拟层允许读写操作”,但实际写入时仍会受底层物理挂载的`ro`限制**。 --- ### **3. 写入行为的最终结果** - **尝试写入**:当应用向`/storage/[UUID]`写入文件时: 1. FUSE/sdcardfs接受操作(因挂载为`rw`)。 2. 操作传递到底层物理挂载点`/mnt/media_rw/[UUID]`。 3. **因物理层为`ro`,内核会拒绝写入,返回`EROFS`(只读文件系统错误)**。 - **用户感知**: - 文件管理器可能显示存储为“可读写”(因FUSE层挂载参数为`rw`)。 - 实际写入时会弹出错误(如“存储设备只读”)。 --- ### **验证方法** 1. **直接测试底层物理路径**: ```bash # 尝试向物理挂载点写入(需root) echo "test" > /mnt/media_rw/[UUID]/test.txt # 提示错误:Read-only file system ``` 2. **检查内核日志**: ```bash dmesg | grep "EROFS" # 会显示因只读文件系统导致的写入失败记录 ``` --- ### **特殊场景:sdcardfs的“伪写入”** - **Android的权限隔离机制**:若sdcardfs配置了写权限掩码(如`mask=7`),可能允许应用**在自己的沙盒目录内“看似”写入**,但实际数据: - 存储在应用私有目录(如`/data/media`)。 - **不会真正写入物理只读设备**。 - **用户感知**:文件管理器显示文件已创建,但重启后文件消失(因未持久化到物理设备)。 --- ### **总结** | 层级 | 挂载参数 | 实际效果 | |-------------|----------|--------------------------------------------------------------------------| | **vold物理层** | `ro` | **绝对只读**,所有写入被内核拦截 | | **sdcardfs/FUSE虚拟层** | `rw` | 接受读写操作,但受物理层限制(最终失败)或重定向到沙盒(数据不持久化) | --- ### **修复建议** 若需真正实现读写: 1. 检查物理设备是否损坏(只读模式可能是硬件保护或文件系统错误)。 2. 重新挂载物理设备为`rw`: ```bash mount -o remount,rw /mnt/media_rw/[UUID] ``` 3. 确保vold配置未强制设置`ro`(如检查`/system/etc/vold.fstab`)。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值