[Android] Android文件系统中存储的内容有哪些？

文章目录

  • 前言
  • root 文件系统
  • /system 分区
    • 稳定性:
    • 安全性:
  • /system/bin
    • 用来提供服务的二进制可执行文件:
    • 调试工具:
    • UNIX 命令：
    • 调用 Dalvik 的脚本(upall script):
      • /system/bin中封装的app_process脚本
    • 厂商定制的二进制可执行文件:
  • /system/xbin
  • /system/lib[64]
  • /system/etc
  • /data 分区
    • /data与 Android 操作系统版本之间低合
    • 在用户需要时，/data 可以被加密起来。
    • /data 也可以被设为不可执行
  • /data/data
  • /data/misc
  • /data/system
  • /cache 分区
  • /vendor 目录
  • SD卡
  • 参考

前言

如果不考虑厂商造成的差异，Android 标准的分区还是能构成一个定义良好的文件系统层的。

纵观全文，虽然没有太多技术性和需要逻辑推理的内容，但是看完之后，相信对于Android文件系统会有更深入的理解。例如我们Android开发的时候经常需要使用到的data/data目录，例如进入shell之后看到的一些root目录，sd卡目录和其他等等一些常见的文件目录。相信无论对于Android应用开发，抑或是Android系统开发都有一定的启发性。

root 文件系统

Android的root 文件系统(/)是mount 自一个RAM Disk (initramfs)的。每次启动时，启动加载器 (fastboot)从 boot 分区中把这个文件系统的镜像加载到内存(RAM)中，并把它交给内核。

就目前的讨论而言，最关键的一点是除非知道设备被“刷机”(flashed)，否则 root 文件系统(/)是不能被修改的。这是很重要的，因为 root文件系统中含有系统最重要的组件/init，它能以 root 权限执行任何操作，并控制着系统的启动过程。

一般 Linux 在启动过程中，通常是用 initramfs(以内核模块的形式)把驱动加载到内核中，而且最终会在它被真正的文件系统取代后把它丢弃掉。

不过在 Android 中却不是这样，Android的 initramfs 还会驻留在内存中，并提供 root 文件系统(/)的功能。

initramfs（initial RAM filesystem）是一个用于在Linux启动过程中提供初始根文件系统的临时文件系统。它是一个包含一些必需工具和驱动程序的轻量级文件系统，用于引导操作系统，以便在真正的根文件系统（通常是硬盘上的文件系统）准备好之前执行一些必要的初始化和准备工作。

在Linux启动时，内核被加载到内存中并开始初始化系统。在这个过程中，内核需要访问一些必要的文件和工具，例如驱动程序、文件系统工具等。而这些文件和工具通常存储在硬盘上的根文件系统中。然而，如果根文件系统存储在某些类型的存储设备上，例如RAID、LVM、加密设备，或者在网络上，那么内核可能无法直接访问根文件系统，因为相关的驱动程序和工具可能需要在根文件系统挂载之后才能使用。

这时就引入了initramfs的概念。initramfs被挂载到内存中，并包含了一些必要的驱动程序和工具，以便内核能够继续系统初始化过程。一旦initramfs完成其任务，它就会被卸载，而真正的根文件系统会被挂载到内存中，系统将继续启动过程。

/system 分区

/system 分区是存放所有谷歌或厂商提供的 Android 组件的地方。该目录及其中存储的内容都是属于root:root的，所有的权限都是 0755(rwxr-xr-x)，但是该文件系统是以只读方式 mount的。这样做，主要是基于以下两个方面的考虑。

稳定性:

由于文件系统是以只读方式 mount 的，所以其中的内容也就不会受到破坏，即便是在设备突然断电时也是如此。这降低了因为该分区受到破坏而导致 Android 系统不能启动、使手机“变砖”的风险。

安全性:

以只读方式 mount 也是保护 Android 的系统组件不会被恶意修改的手段之一。尽管在真实情景中，只要以读-写参数重新 mount 一下这个分区就能搞定它了。

从 KitKat 开始，谷歌开始不再对/system 分区的完整性进行校验了，转而改用 Linux 内核中的dm-verity 特性保护/system分区的完整性。

/system/bin

/system/bin 目录中含有 Android 使用的各种原生可执行文件，此外，它也是存放各种调试工具的地方。具体来说，这些二进制可执行文件可以被分成 5 类。

用来提供服务的二进制可执行文件:

这类二进制可执行文件都是在系统运行过程中由/init 调用的，它们的调用路径会被写进/init 使用的rc 文件中。这类二进制可执行文件并非完全来自AOSP。部分截图：
在这里插入图片描述

调试工具:

被归入这一类的是一些用于调试的原生二进制可执行文件。
下面列出的这些二进制可执行文件在模拟器上都能找到，但是厂商(出于安全谨慎的考虑)可能会把它们从真实销售的设备中删掉。部分截图：
在这里插入图片描述

UNIX 命令：

为了让 shell 用户也能在 Android 上玩，UNIX 命令都被封装在一个单独的二进制可执行文件/system/bin/toolbox中。

busybox是嵌入式系统中常见的多合一工具集，而 toolbox 则是它在 Android 中的定制版。toolbox 和 busybox 并不是逐条提供各个UNIX命令的，它们只含有这些命令的基本功能。

toolbox中精简了 busybox 中的命令集，只提供其中的一部分常用命令，但也加上了一些 Android特有的命令(如getprop/setprop/watchprop)

调用 Dalvik 的脚本(upall script):

这些调用 Dalvik 的脚本让用户通过 shell 与 Dalvik运行时框架交互，这多半是为了进行调试。

这些脚本调用/system/bin/app_process，用它们在/system/framework 目录中的同名JAR框架，加载 Dalvik 类。

在使用时，脚本会把用户传给它的参数直接传递给 Dalvik 类。
调用Dalvik的脚本模板：
在这里插入图片描述

/system/bin中封装的app_process脚本

在这里插入图片描述
在这里插入图片描述

厂商定制的二进制可执行文件:

从本质上讲，这类二进制可执行文件可以完全由厂商控制，但是这类二进制可执行文件通常都是些提供服务的程序或调试工具。

/system/xbin

/system/xbin目录类似于UNIX 中的/sbin 目录，其中含有管理员会觉得非常有用的二进制可执行文件。但是普通用户最好还是离这个目录远一些。目录名中用的是“x”而不是原来的“s”,是为了避免与 Android 自身的/sbin (这个目录是 root 文件系统的一部分，其中含有系统操作时必须使用的二进制可执行文件)冲突。

这个目录中的二进制可执行文件是从AOSP的system/extras 目录中编译得来的。因为这个目录不是普通操作所必须的，所以这个目录是不是会出现在设备中完全取决于厂商的意愿。

有些厂商会干脆把这个目录删掉，或只保留一个 dexdump 二进制可执行文件。

/system/lib[64]

/system/lib(在64位系统中则是/system/lib64)目录中含有供/system/bin 和/system/xbin目录中的二进制可执行文件使用的共享库。

在大多数设备中，/system/lib 中有多个子目录，其中的一些是根据设备的不同而不同的，但是下面这些子目录一般都会存在:

  • drm/(提供DRM引擎)
  • egI/ (Android 版的 OpenGLES)
  • hw/(各个HAL 模块)
  • ssl/engines(含有 libkeystore.so,该共享库使得OpenSSL能使用Android的Keystore机制)

在Intel设备中，/system/lib
通常还另外含有一个名为arm/的子目录，其中含有为ARM体系结构的处理器编译的共享库的拷贝。这些共享库会被用在 Intel
的二进制执行环境转换层(binary translation layer) Houdini上，用来为要执行的ARM 的二进制可执行文件提供一个完整的运行时环境。

/system/etc

就像它在UNIX系统中的同名目录一样，Android 的/system/etc 目录中也存放着各种配置文件之类的东西。/etc 也是该目录的符号链接，这样做是为了保持兼容性，因为有些 AOSP 外部项目会到这里去查找配置文件。

在这里插入图片描述

/data 分区

/data 分区是所有用户个人数据的存放地点。为此单独提供一个分区，有这么几个重要的好处:

/data与 Android 操作系统版本之间低合

系统升级和恢复时会擦除或者重写整个/system 分区，但却不会以任何方式影响用户数据。反之，通过格式化/data 分区，也可以快速重置设备，并擦除所有用户个人数据。实际上这就是在“恢复出厂设置”过程中所做的工作。

在用户需要时，/data 可以被加密起来。

加密，不论怎么优化，由于在读写过程中分别要进行解密和加密操作，所以总会在一定程度上增加系统延迟。而在设计上，/system 分区中是没有敏感数据的，所以也就没有必要加密这个分区，因而也就规避了因加密这一分区而带来的延迟。

/data 也可以被设为不可执行

尽管到 KitKat 为止，这还不是默认选项。不过这样做，不光能使它更名副其实，还能极大地加大恶意软件的攻击难度。因为，这样恶意软件就没有一个可写又可执行的分区，让它能把恶意的可执行文件写在该分区中然后再执行了。

因为 DEX 和OAT 是运行在虚拟机里的，所以这对正常的 Dalvik/ART app 不会有任何影响。

但是对 root 可能会有一定的影响，例如，需要重新 mount /data 以及/system 分区。

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

/data目录的权限和/data/data 的一样,都被设为 chmod 771system
system。这一做法源于Android安全模型的要求:对于所有的应用而言，目录都是可执行的(即可以用 cd
命令切换)，但同时又是不可读的(这样，应用或者不受信任的进程就不能将“相邻”目录一一列出)。这也就意味着，在 uidshell
里(也就是没有 root 权限的 adb 会话中)，你可以把当前目录切换到/data
目录或者它的大多数子目录上,但没有必要让你能读取其中的内容。system子目录及其子目录(即/data/system和/data/misc)是可读的，但是/data/data
和/data 本身是拒绝执行 ls 命令的。从 KitKat 起，这一做法通过 SELinux标签被引入，你要想遍历各个子目录就得有 root
权限才行。

/data/data

/data/data 这个名字看上去有些罗嗦的目录是所有应用 (不论是系统应用还是用户安装的应用)存储它们的信息的地方。

每个应用都有一个单独的、以逆 DNS 格式命名的子目录。其权限设置为chmod 751(rwxr-x–x)，前二者为应用拥有者的 uid 和gid 的权限。

/data/data 目录本身的权限设置为chmod 771 system system，这使得所有的应用都能列出其中的子目录，但却不能读取除了 system 拥有的应用外的其他数据。

不过应用中，文件的安全防护措施的设置还是要交给每个应用自己来完成，因为尽管除了应用的拥有者外，其他人都不能读取各个应用目录中的内容，但是这些应用目录本身还是可执行的。

/data/data 下各个应用的子目录是各个应用在整个文件系统中唯一能写入数据的地方。再加上很多市面上能找到的，而且也会被装到很多手机里去的应用都能定位 GPS 位置，收发短信和打电话，这就使得这个目录中的一些地方能够成为电子取证时的“聚宝盆”。我们特别关心的一些子目录：
在这里插入图片描述

应用也可以把数据保存在 SD 卡上(如果它们有权限的话)，但是大多数与应用状态相关的数据一般还是能在/data/data
中的对应目录里找到的。如果你想手动保存和恢复应用的状态的话(比如，在游戏中作弊)，这是非常有用的。应用也可以注册 Android
的备份服务，自动进行备份(备份可以放在本地，也可以放在谷歌的云服务器上)。

/data/misc

/data/misc 目录中含有各个 Android 子系统的各种五花八门的 (miscellaneous)数据和配置目录。和它的名字所暗示的相反，该目录中也含有一些系统中最重要的文件。

在这里插入图片描述

/data/system

/data 分区中另一个重要的子目录是/data/system，因为该目录中含有对维护设备状态非常重要的文件。这个目录的访问权限也是被限制为 system:system 的。所以如果你的设备没有被 root，是看不到下表中给出的任何一个文件的：
在这里插入图片描述

/cache 分区

Android 是在系统升级的过程中使用/cache 分区的。系统升级包会被下载到这里，启动管理器(boot manager)特别是在 recovery/升级模式下启动时，会要使用这个分区。但除此之外，在正常情况下，这个分区是空的。
如果你最近下载过 OTA 升级包，在它被安装之前，你都能在这个分区里看到它。另外，recovery这个二进制可执行文件和系统(特别是android.os.RecoverySystem类)在启动到recovery(或系统升级)模式时，也会使用这个分区交换信息。

/vendor 目录

/vendor 目录是用来存储厂商对 Android 系统的修改的。这样做是为了在必要时能有效地进行系统的更新或升级操作(同时不至于把厂商对系统的修改一起抹除)。专门指定的系统组件在添加/system 路径之前时，会先去检查事先被写死在程序中的/vendor 中的路径。

SD卡

Android 最棒的一个特性就是: 它内置支持 SD 卡，这是许多 ioS 用户梦寐以求的东西。现在大多数手机已经都自带一个 SD 卡插口了 (尽管插-拔都不是很方便)，平板电脑上也已经有了插-拔都很方便的扩展插口了。

大多数 SD卡都会被格式化成 vFAT 或者 FAT32文件系统，但是这个类型的文件系统是不支持权限的。为了能强制实现权限，以及支持(从JellyBean 开始提供的) 多用户配置，Android通过 FUSE(用户态下的文件系统)模拟SD 卡的方式，算是强解决了这个问题。

FUSE 使我们能在一个用户态user mode，这也是 FUSE 的名称后半部分的由来，前面的F 表示文件系统(File system)]进程中，而不需要在内核中实现文件系统。

FUSE会在内核中安装一个用于支持通用文件系统的小模块，通过它和 VFS 对接并实现基本的注册文件系统功能。

而真正的文件系统是在一个用户态进程/system/bin/sdcard 中实现的。

在Android 的演化过程中，SD卡的 mount点被改过好几次，新版的 Android 中，该 mount 点在/storage/ext_sd。对于没有 SD卡的设备，这个mount 点通常会指向/data 分区中的某个目录，它一般是/data/media/0。

上面这些标准目录已经在androids.Environment 类中被定义为常量了。第三方应用也能(而且经常会)在SD 卡中创建它们自己的文件和目录。

Android 还提供了一个模拟 SD 卡文件系统，可以在设备中没有 SD 卡时使用，也可以和“真正的”SD 卡文件系统同时使用。使用 mount 命令，可以观察到SD卡目录结构：
在这里插入图片描述

参考

《Android最强Android书：架构大剖析》