一、为什么emulted存储要用很复杂的挂载方式

1， emulted存储是什么

android早期，手机内部flash容量比较小，为了能让手机存放更多的文件，需要通过外部存储（如SD卡）来扩展存储容量。随着技术的进步，大容量flash的价格变便宜了，手机内置大容量flash已经成常态。在大容量的flash中划出一块空间（图中绿色部分）模拟成外部存储，就可以兼容早期的flash+外置SD卡的方式了。emulated storage的容量随着用户使用动态增减，它是/data/路径下的一个目录，所以emulated storage可用空间取决于/data所在分区大小。注意，如果用户通过emulated storage占满了这个分区，那么系统启动时，一些更新、写重要系统文件的操作会因没有空间而失败，从而导致系统无法启动，所以需要限制一下emulated storage大小，解决方案可以google搜索LIMIT_SDCARD_SIZE宏。

2，为什么要用这么复杂的挂载

结论：为了实现存储的动态权限。默认情况下，应用没有权限访问共享空间，应用需要读写共享空间时，需要申请权限，征得用户同意后才能后访问文件。这就涉及到android的“运行时权限”，存储模块通过复杂的挂载来实现这个机制。大致的思想是这样的，对于共享空间，做4个bind mount，通过这几个挂载点访问共享空间的权限分别为：a无权限、b读权限、c写权限、d读写权限。应用启动的时候，按a挂载（假设没申请过权限），申请权限并经用户同意后，通过remount挂载b/c/d中的一个，比如需要写共享空间的文件，则采用“写权限”方式remount共享空间。

从android 11开始启用了分区存储（scoped storage，参考https://www.youtube.com/watch?v=UnJ3amzJM94），分区存储的目的我认为有2点：为了更好地管理外部存储空间，将同类型文件集中存储，避免各个应用在存储中乱放文件；还有就是在实现了分区存储的基础上，可以更集中统一地做权限管理。

android 11 权限设计规则如下：

不需要任何权限，应用可以自由地读写自己的专属空间。比如在/data/data/包名/files目录中创建新的文件。
不需要任何权限，应用可以自由地读共享空间（/storage/emulated/0）中的内容，也就是可以列出共享空间中的文件。
应用读共享空间中的媒体文件，需要申请READ_EXTERNAL_STORAGE 。
文件管理类应用申请MANAGE_EXTERNAL_STORAGE权限，可以读写共享存储空间中的所有文件。
非文件管理类应用，通过SAF（Storage Access Framework）访问非媒体文件或非媒体目录。

二、外部存储挂载视图

1，bind mount介绍

在正式介绍挂载视图前，需要讲一下bind mount。

绑定挂载命令：bindmount --bind olddir newdir
1）将olddir绑定到newdir。绑定后，olddir和newdir看到的都是olddir中的内容（newdir中绑定前的内容变不可见）。
2）命令中的olddir对应内核mount函数的dev_name参数，newdir对应mount的dir_name参数。
3）务必注意，mount命令查看挂载详情，是看不到olddir的，取而代之的是olddir所在的device name。

比如：

cp:/data/media/0 # touch new/this-is-newdir
cp:/data/media/0 # touch old/this-is-olddir//把/data/media/0/old绑定到/data/media/0/new
cp:/data/media/0 # mount --bind old new//绑定后，只能看到old目录中的内容
cp:/data/media/0 # ls old/
this-is-olddir
cp:/data/media/0 # ls new/
this-is-olddir//mount命令只能看到old所属的/dev/block/dm-9挂载到了/data/media/0/new
cp:/data/media/0 # mount |grep new
/dev/block/dm-9 on /data/media/0/new type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,mode=adaptive,active_logs=6,reserve_root=56683,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier

再比如：

cp:/storage/emulated/0 # mkdir old new
cp:/storage/emulated/0 # mount --bind old new//mount命令只能看到old目录所属的/dev/fuse挂载到了/data/media/0/new
cp:/storage/emulated/0 # mount |grep new
/dev/fuse on /storage/emulated/0/new type fuse (rw,lazytime,nosuid,nodev,noexec,noatime,user_id=0,group_id=0,allow_other)

注意，下文会用到这些结论：
1，newdir看到的是olddir中的内容。
2,，mount命令看不到bindmount命令的olddir。

2，挂载视图

预置条件：使能fuse、使能sdcardfs
Note：android挂载实在很复杂，图中没有完整地画出来，也没有按照mount namespace把各命名空间的挂载情况分开画出来，比如你会看到/storage有多个bind mount（③④⑤），但任何时刻一个进程只属于一个mount space，只能看到其中一个bind mount。普通的app（不是installer app、Mediaprovider类型的），通过③将/mnt/user/0 bind mount到 /storage；installer app通过⑤将/mnt/installer/0 bind mount到 /storage；MediaProvider将/mnt/pass_through/0 bind mount到 /storage。

注意：通常，→的起始端表示source（对应bindmount命令中的olddir），终端表示target（对应bindmount命令中的newdir），但是为了画图方便，图中的起始端表示bind mount的target，比如将/mnt/user/0（source）bind mount 到/storage（target），图中表示出来就是③，所以/storage看到的是/mnt/user/0中的内容，原/storage中的内容被隐藏。

app访问/sdcard的过程是这样的（内核解析路径时，lookup过程是一级一级解析路径分量名的）：
1）/sdcard是个软链接，通过①链接到/storage/self/primary，所以访问/sdcard就是访问/storage/self/primary目录。
2）启动app时，zygote 为app fork子进程，接着设置app的挂载命名空间，并通过③将/mnt/user/0目录bind mount到/storage目录（com_android_internal_os_Zygote_nativeForkSystemServer --> SpecializeCommon --> MountEmulatedStorage），所以访问/storage/self/primary就是访问/mnt/user/0/self/primary目录。
3）/mnt/user/0/self/primary是个软链接，链接到/storage/emulated/0（图中未画），所以访问/mnt/user/0/self/primary就是访问/storage/emulated/0目录。
4）从2可知，/mnt/user/0目录（olddir）bind mount到/storage目录（newdir），所以访问/storage/emulated/0目录就是访问/mnt/user/0/emulated/0目录。
5）/mnt/user/0/emulated是一个挂载点，设备是/dev/fuse，见图中⑥，所以访问/mnt/user/0/emulated开头的文件（比如上面的/mnt/user/0/emulated/0），就会交给fuse文件系统处理。
6）StorageSessionController::onVolumeMount挂载外部存储时，connection.startSession将/storage/emulated（上层目录）和/data/media（底层目录）通过/dev/fuse关联起来。StorageUserConnection: StorageUserConnection::startSession task:StorageManagerService sessionId: emulated;0 upperPath:/storage/emulated lowerPath:/data/media

对/storage/emulated/0的访问将转换成对/data/media/0的访问。/data/media/0就是底层文件系统（f2fs/ext4）上的一个目录，通过底层文件系统就可以获取真实的数据了。

上面各种链接，各种bind mount，绕来绕去了的，是为了兼容早期的版本，以用户0为例，兼容的效果是让访问外部存储的路径变成/storage/emulated/0目录。现在版本通过getExternalStorageDirectory()获取到的路径就是“/storage/emulated/0”，这个路径的解析过程，从上面4）开始，最终定向到/data/media/0目录。

3，动态权限

提交记录：https://android.googlesource.com/platform/system/core/+/f38f29c87d97cea45d04b783bddbd969234b1030%5E%21/#F1

动态权限是通过改变app的不同视图实现的（default、read、write、full）：

127|cp:/ # mount |grep runtime
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid,default_normal,unshared_obb)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid,default_normal,unshared_obb)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid,default_normal,unshared_obb)
/data/media on /mnt/runtime/full/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid,default_normal,unshared_obb)

mask：八进制表示ugo（user-group-other）权限,比如006表示other的权限掩码为0110，即可读可写无执行(rw-)。

挂载点信息			用户权限
bind mount目录	mask	gid	group用户权限	other用户权限
/mnt/runtime/default	006	AID_SDCARD_RW (1023)	group掩码0，不去任何权限。即有完整权限	other权限掩码6，去掉读写权限，即有执行
/mnt/runtime/read	023	AID_EVERYBODY (9997)	group掩码010,拿到写权限，即可读、可执行	other权限掩码3，去掉写、执行权限，即可读
/mnt/runtime/write	007	AID_EVERYBODY (9997)	group掩码0，不去任何权限，即有完整权限	other权限掩码7，去掉读、写、执行权限，即无任何权限
/mnt/runtime/full	007	AID_EVERYBODY (9997)	group掩码0，不去任何权限，即有完整权限	other权限掩码7，去掉读、写、执行权限，即无任何权限

一般的应用程序属于AID_EVERYBODY组，可对照上面表格"group用户权限"一列查看各bind mount目录视图的权限。

三、代码分析

1，app挂载命名空间的创建

启动app时，zygote通过forkAndSpecialize为app创建主线程，并通过unshare(CLONE_NEWNS)为新创建的子进程设置新的命名空间。

 forkAndSpecialize  (Zygote.java)--> nativeForkAndSpecialize--> com_android_internal_os_Zygote_nativeForkAndSpecialize (com_android_internal_os_Zygote.cpp)--> SpecializeCommon --> MountEmulatedStorage--> ensureInAppMountNamespace --> unshare(CLONE_NEWNS)

fork创建进程时，父子进程共享一些“execution context”（比如命名空间），unshare指定父子进程的“execution context”相互独立。

2，/storage的bind mount

在挂载视图一节，可以看到有很多目录bind mount到了/storage（图中的③④⑤，以及未画的/mnt/androidwritable），是不是很奇怪？其实是这样的，各app是在自己的mount name space中bind mount /storage目录的，所以对于app来说，只会挂载③④⑤中的一个，最终，各app进入/storage目录看到的内容是不一样的。

/storage挂载是这样的：

代码见MountEmulatedStorage（com_android_internal_os_Zygote.cpp）。

// Create a private mount namespace and bind mount appropriate emulated
// storage for the given user.
static void MountEmulatedStorage(uid_t uid, jint mount_mode,bool force_mount_namespace,fail_fn_t fail_fn) {/** 确认app的mount name space已经创建了。* 如果没有创建挂载命名空间，则通过unshare创建。* 如果创建失败，则通过fail_fnye（也就是ZygoteFailure）终止进程并报告错误。*/ensureInAppMountNamespace(fail_fn);/* 挂载模式指定不挂载外部存储，直接返回 */if (mount_mode == MOUNT_EXTERNAL_NONE) {return;}const userid_t user_id = multiuser_get_user_id(uid);const std::string user_source = StringPrintf("/mnt/user/%d", user_id);PrepareDir(user_source, 0710, user_id ? AID_ROOT : AID_SHELL,multiuser_get_uid(user_id, AID_EVERYBODY), fail_fn);bool isFuse = GetBoolProperty(kPropFuse, false);bool isAppDataIsolationEnabled = GetBoolProperty(kVoldAppDataIsolation, false);/* persist.sys.fuse属性是否enable了，可通过getprop persist.sys.fuse查看 */if (isFuse) {if (mount_mode == MOUNT_EXTERNAL_PASS_THROUGH) {/* MOUNT_EXTERNAL_PASS_THROUGH = 7，MediaProvider 进入此分支。* 对于MediaProvider 进程,访问 /storage 就是访问 "/mnt/pass_through/[userid]"。* 务必要记住MediaProvider访问/storage跟普通app访问/storage是不一样的，* 普通app访问/storage，经过fuse兜兜转转，交给了MediaProvider，这个时候* MediaProvider访问/storage访问的是/mnt/pass_through/%d目录了。否则如果 * MediaProvider访问跟普通app一样的/storage，那就又回头死循环了。*/const std::string pass_through_source = StringPrintf("/mnt/pass_through/%d", user_id);PrepareDir(pass_through_source, 0710, AID_ROOT, AID_MEDIA_RW, fail_fn);BindMount(pass_through_source, "/storage", fail_fn);} else if (mount_mode == MOUNT_EXTERNAL_INSTALLER) {/* MOUNT_EXTERNAL_INSTALLER = 5，packageinstall 进入此分支。* 调试的话，可通过下面方法触发执行该分支代码--------------------------------------------------------------------cp:/ # ps -AT |grep installu0_a59    1823  1823   554 5404912  55800 SyS_epoll_wait    0 S ackageinstalleru0_a168   4990  5898   555 2440460 635332 futex_wait_queue_me 0 S split_install_tu0_a60    6224  6224   554 5886452 169904 SyS_epoll_wait     0 S ageinstaller.uicp:/ # kill -9 1823这个时候logcat 可以看到自己添加的调试信息--------------------------------------------------------------------*/const std::string installer_source = StringPrintf("/mnt/installer/%d", user_id);BindMount(installer_source, "/storage", fail_fn);} else if (isAppDataIsolationEnabled && mount_mode == MOUNT_EXTERNAL_ANDROID_WRITABLE) {/** 有写权限的app走这个分支，等价于命令: mount --bind /mnt/androidwritable  /storage* mount命令看不到olddir，也即/mnt/androidwritable。前面说过原因。* nsenter -t app进程tid -m mount |grep "/storage" （nsenter进入app的命名空间）* tmpfs on /storage type tmpfs  ……(挂载参数)*/const std::string writable_source = StringPrintf("/mnt/androidwritable/%d", user_id);BindMount(writable_source, "/storage", fail_fn);} else {/** 普通app走这个分支，等价于命令: mount --bind /mnt/user/0  /storage* * mount命令看不到olddir，也即/mnt/user/0。前面说过原因。* nsenter -t app进程tid -m mount |grep "/storage" （nsenter进入app的命名空间）* tmpfs on /storage type tmpfs  ……(挂载参数)*/BindMount(user_source, "/storage", fail_fn);}} else {/* persist.sys.fuse没有enable的场景，挂载比较简单 */const std::string& storage_source = ExternalStorageViews[mount_mode];BindMount(storage_source, "/storage", fail_fn);// Mount user-specific symlink helper into placeBindMount(user_source, "/storage/self", fail_fn);}
}

3，外部存储挂载流程

上一篇文章android存储3--初始化.unlock事件的处理_geshifei的博客-CSDN博客，讲了用户解锁设备后，SystemServiceManager处理unlock事件，主要有3个存储相关的service要处理解锁事件：
1）StorageManagerService$Lifecycle.onUserUnlocking
2）mStorageSessionController.onUnlockUser
3）mStoraged.onUserStarted

但只讲了怎么触发存储相关service做各自初始化工作的，涉及到具体的emulated device的挂载就没有分析了。下图展示了mVold.onUserStarted挂载emulated device的流程（图中蓝色字体是函数）。

4，动态权限处理

4.1 没有使能fuse时的场景

app访问外部存储时，弹窗申请读写权限，点击允许，代码流程如下：

PackageManagerService::grantRuntimePermission
-> PermissionManagerService::grantRuntimePermission
-> PermissionManagerService::grantRuntimePermissionInternal
-> StorageManagerService::onExternalStoragePolicyChanged
-> StorageManagerService::remountUidExternalStorage
-> mVold.remountUid(uid, mode)，即VoldNativeService::remountUid
-> VolumeManager::remountUid

int VolumeManager::remountUid(uid_t uid, int32_t mountMode) {/* 使能fuse的情况，直接返回 */if (GetBoolProperty(android::vold::kPropFuse, false)) {// TODO(135341433): Implement fuse specific logic.return 0;}/** 遍历/proc下各个进程目录，根据uid进行查找，找到pid后，* fork子进程进行重新挂载/mnt/runtime/XX ，setns切换mount name space*/return scanProcProcesses(uid, static_cast<userid_t>(-1),forkAndRemountChild, &mountMode) ? 0 : -1;
}