android存储4--初始化.emulated设备的挂载

android版本：android-11.0.0_r21
http://aospxref.com/android-11.0.0_r21

android手机的挂载非常复杂。这篇文章针对emulated存储，介绍它的挂载过程。

一、为什么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 install
		u0_a59    1823  1823   554 5404912  55800 SyS_epoll_wait    0 S ackageinstaller
		u0_a168   4990  5898   555 2440460 635332 futex_wait_queue_me 0 S split_install_t
		u0_a60    6224  6224   554 5886452 169904 SyS_epoll_wait     0 S ageinstaller.ui
		cp:/ # 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 place
    BindMount(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;
}

4.2 使能fuse时的场景

待补充。