三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

Android分区架构深度解析:从基础概念到刷机救砖实战

Android分区架构深度解析:从基础概念到刷机救砖实战

1. 从“砖头”到“开机”:理解Android分区的必要性

如果你曾经尝试过给安卓手机刷机、救砖,或者只是好奇为什么手机存储空间总比标称的少,那么“分区”这个概念你一定绕不开。对于大多数普通用户来说,手机就是一个黑盒,点开应用就能用。但当你想要深入一点,比如想卸载系统预装的“牛皮癣”应用,或者手机卡在开机Logo不动了,你就会发现,手机内部远比你想象的要复杂。这背后,正是Android系统精密的“分区”架构在起作用。简单来说,分区就像一套精装修的房子,开发商(手机厂商)提前规划好了格局:哪里是承重墙(bootloader),哪里是卧室(system放系统),哪里是客厅(data放你的照片和应用),哪里是逃生通道(recovery)。你不能随便把承重墙拆了,也不能在消防通道里堆杂物,否则房子(手机)就可能出问题,轻则功能异常,重则变成“砖头”。

今天,我们就来彻底拆解这套“户型图”。我会结合自己多年折腾安卓设备的经验,从最基础的概念讲起,带你弄明白每个分区是干什么的、为什么需要它们、以及当你遇到“老毛桃启动分区不存在”或“你需要来自SYSTEM的权限才能删除”这类问题时,背后到底发生了什么。无论你是刚入门想了解系统原理的开发者,还是遇到了棘手问题想自救的普通用户,这篇文章都能给你一份清晰的“导航图”。

2. Android分区的核心蓝图:不只是存储空间划分

很多人会把“分区”简单理解为电脑硬盘的C盘、D盘,但在Android(尤其是现代采用A/B分区的设备)和嵌入式系统中,分区的意义要深远得多。它不仅是空间的划分,更是功能、权限和生命周期的严格隔离。这种设计源于Linux,并针对移动设备的特点进行了深度定制,核心目标是实现安全、稳定、可靠和易于更新

2.1 分区表:系统的“总规划图”

一切始于分区表。它是一张存储在存储设备(eMMC或UFS)起始位置的“地图”,告诉引导程序(bootloader)各个分区叫什么名字、从哪里开始、到哪里结束、有什么属性。常见的分区表格式有MBR(旧式)和GPT(新式,支持更大容量和更多分区)。当你使用“傲梅分区助手”或disks工具时,你操作的底层就是这份分区表。

在Android环境下,我们通常不直接操作分区表,而是通过Fastboot等工具,使用分区名(如boot,system)来指向特定分区。每个分区在编译时就被预先定义好,并写入设备的fstab(文件系统表)文件中。这就是为什么你无法像在Windows上那样随意创建、删除或调整Android系统分区的大小——它们是系统固件的一部分,牵一发而动全身。

2.2 关键分区详解:每个“房间”的职能

下面我们逐一走进Android系统里那些最重要的“房间”。为了更直观,我将它们分为三大类:引导相关系统核心用户数据

分区名称类比核心职能是否可写(正常系统下)出问题的后果
bootloader房屋地基与大门钥匙设备上电后运行的第一个程序。初始化硬件,加载并验证boot分区,决定启动到主系统还是Recovery。它还负责处理Fastboot协议。通常锁定,需解锁才能写变“砖”。提示“Device must be bootloader unlocked”或“Default boot device missing”。
boot系统启动引擎包含Linux内核(Kernel)和初始内存磁盘(initramfs/ramdisk)。内核是硬件和软件的桥梁,ramdisk负责挂载系统分区。只读(正常情况)无法进入系统,卡第一屏。Fastboot刷boot.img可救。
recovery安全模式/维修车间一个独立的、精简的Linux系统。用于安装OTA更新、清除数据、备份恢复等。可通过特定按键组合进入。只读(正常情况)无法进行系统更新和恢复操作。可刷入第三方Recovery(如TWRP)增强功能。
system精装交付的房屋主体存放Android框架、系统应用、库文件等。相当于手机的“操作系统”本身。只读(正常系统下)系统应用闪退、功能异常。提示“You need permission from SYSTEM”。
vendor品牌定制装修存放设备制造商(如华为、小米)和硬件供应商(如高通)的专用驱动、库文件和HAL(硬件抽象层)。自Android 8.0后从system分离,便于独立更新。只读硬件相关功能失效,如相机、蓝牙。
data用户的家具和私人物品存放所有用户数据:安装的应用、应用数据、照片、视频、设置等。这是占用空间最大且变化最频繁的分区。可读写数据丢失。恢复出厂设置即格式化此分区。
cache临时储物间存放系统临时文件和OTA更新包。可读写通常可自动重建。手动清空可解决一些升级故障。
misc便签贴存储一些跨引导的杂项信息,比如Recovery看到的指令(如“请执行wipe data”)。可读写可能导致Recovery模式行为异常。

注意:以上是基础分区。现代设备还可能有dtbo(设备树)、vbmeta(验证启动元数据)、super(动态分区,包含system,vendor,product等)等更复杂的分区,其核心思想都是模块化安全性

2.3 A/B(无缝)分区:实现“后台”更新的魔法

这是Android自7.0开始引入的一项重要演进,旨在实现无缝更新(Seamless Update)。其原理很简单:为bootsystemvendor等关键分区准备两套完全相同的副本,分别标记为slot Aslot B

  • 正常运行时:设备从slot A启动。
  • 系统更新时:后台将新系统下载并安装到slot B的分区中,用户完全无感知。
  • 更新完成重启时:bootloader被指示切换到slot B启动。如果slot B启动成功,则更新完成;如果失败(比如卡Logo),bootloader会自动回滚到slot A启动,设备就像什么都没发生过一样,保证了系统的可用性。

这解释了为什么新手机的可用存储空间总比标称少——有一部分空间被用于这第二套系统分区了。对于开发者,在Fastboot下刷机时需要指定--slot all或明确刷入slot_a/slot_b,否则可能只更新了当前槽位。

3. 与分区交互的实践:从日常操作到救砖

理解了分区是什么,我们来看看怎么和它们打交道。操作分区是高风险行为,务必谨慎。

3.1 常规操作中的分区“身影”

  1. 安装应用:应用APK被安装到/data/app目录下,其私有数据存放在/data/data/包名下。这就是为什么“分区卸载”系统应用通常需要Root权限——你要删除的文件在只读的system分区里。
  2. 系统更新(OTA):手机会下载更新包,重启到recovery模式,由Recovery系统验证并更新bootsystem等分区。对于A/B设备,则是更新备用槽位。
  3. 恢复出厂设置:本质上是在Recovery模式下,执行格式化data分区的操作。system分区保持不变。

3.2 开发者与高级用户的工具链

当你需要更深层次地操作分区时,会用到以下工具:

  • Fastboot:在bootloader模式下使用的协议工具。这是刷写分区镜像的最直接方式。命令如fastboot flash boot boot.img就是将boot.img镜像写入boot分区。遇到“bootloader锁”时,必须先执行fastboot flashing unlock(命令因厂商而异)。
  • ADB(Android Debug Bridge):在系统或Recovery运行时进行调试和文件操作。它通常不直接写分区,但可以推送文件到设备,再通过shell命令进行处理。例如,在已Root的设备上,你可以adb shell然后mount -o rw,remount /system来临时挂载system分区为可写。
  • 厂商专用工具:如高通平台的QFIL(QSPT),联发科的SP Flash Tool。这些是更深层的刷机工具,即使在设备“变砖”(无法进入bootloader)时,通过特定的下载模式(如高通9008端口)也能直接读写存储芯片上的分区,俗称“线刷”。qfil刷新boot分区这个搜索词指向的就是这个场景。

3.3 常见分区相关问题与排查思路

很多网络热词背后,都是分区问题引发的求救信号。下面我们来拆解几个典型场景:

场景一:提示“你需要来自SYSTEM的权限才能删除此文件”这通常发生在尝试删除/system/app/system/priv-app目录下的预装应用时。根因是:在未Root的、正常启动的系统里,system分区是以只读(ro)方式挂载的。这是Android安全模型的核心——防止系统文件被意外或恶意修改导致系统不稳定。

  • 解决方案
    1. Root后挂载为可写:获取Root权限后,在终端执行mount -o rw,remount /system。但注意,直接修改system分区可能触发系统的完整性验证(如AVB),导致无法启动。
    2. 使用Magisk模块:更安全的方法是使用Magisk的“系统化”模块来隐藏或替换应用,而不是直接修改system分区。
    3. 在Recovery中操作:刷入第三方Recovery(如TWRP),它通常会以读写方式挂载system分区,此时可以通过Recovery的文件管理器或ADB Sideload功能进行修改。

场景二:设备变砖,提示“Default boot device missing or boot failed”这是一个严重的引导失败错误。可能的原因和阶梯式排查思路如下:

  1. 检查引导顺序:类似于电脑的BIOS设置,可能是bootloader找不到有效的、可引导的分区。在Fastboot模式下,尝试使用fastboot set_active命令切换A/B槽位。
  2. 关键分区损坏bootvbmeta分区损坏。尝试从官方固件包中提取对应的镜像文件,通过Fastboot重新刷入:fastboot flash boot boot.imgfastboot flash vbmeta vbmeta.img(有时需要加--disable-verity等参数)。
  3. 分区表严重损坏:如果连Fastboot模式都无法进入,可能就需要使用前面提到的厂商底层工具(如QFIL)进行整个固件的线刷,这会重建所有分区。

场景三:更新或刷机后,卡在“reached target basic system”或类似界面这个提示本身是正常的,表示系统服务启动完成。但如果长时间卡住,通常问题出在data分区。

  • 排查思路:新的system分区(或vendor分区)可能与旧的data分区中的数据不兼容。例如,系统升级后,data分区中某个应用的旧数据或设置导致系统服务崩溃。
  • 解决方案:尝试进入Recovery模式,执行“清除缓存”和“格式化Data分区”(注意:这会丢失所有用户数据!)。这就是所谓的“双清”或“三清”操作。在操作前,如果还能通过ADB连接,可以尝试adb logcat查看具体的崩溃日志来定位问题应用。

场景四:磁盘工具报告“bitmap中有标记为已使用的未用簇”这是一个典型的文件系统错误,通常发生在data分区(因为它是可写的,且频繁操作)。Android的data分区通常使用ext4f2fs文件系统。这个错误意味着文件系统的元数据(记录哪些磁盘块被使用)出现了不一致。

  • 原因:不正常关机(如强制重启、断电)、软件BUG或存储介质本身故障都可能导致。
  • 解决方案:在Recovery模式下,对该分区执行fsck(文件系统检查)操作。在TWRP中,高级功能里通常有“修复文件系统”的选项。对于电脑上的分区工具报此错,说明你可能是将手机存储以U盘模式挂载到了电脑上,应在手机端恢复模式下修复,而非在电脑端。

4. 嵌入式视角的延伸:Bootloader的通用逻辑

网络热词中出现了stm32 bootloaderecu bootloader,这说明Bootloader的概念是通用的,不止于Android。在STM32这类微控制器或汽车ECU中,Bootloader同样是一段上电首先运行的程序,它的核心任务大同小异:

  1. 初始化:初始化时钟、内存、串口/USB等基础硬件。
  2. 检查更新:判断某个引脚电平、检查串口数据或判断某个标志位,决定是跳转到主应用程序(App)还是进入固件更新模式。
  3. 加载与跳转:如果启动App,则从Flash的特定地址(如0x08000000 + 偏移量)加载程序并跳转;如果进入更新模式,则通过某种协议(如XMODEM、YMODEM、自定义协议)接收新的固件数据,并烧写到Flash的应用程序区域。

stm32 bootloader和app跳转的关键在于中断向量表的重映射。Bootloader和App是两个独立的程序,各有自己的中断向量表。跳转前,Bootloader需要禁用所有中断重新设置堆栈指针为App区域的栈顶,然后直接将程序计数器(PC)跳转到App的复位向量地址。在App中,也需要正确初始化自己的中断向量表。如果跳转后App跑飞,最常见的原因就是中断处理或内存布局(分散加载文件)配置有误。

5. 高级话题:动态分区、虚拟A/B与系统完整性

Android的分区布局仍在不断进化,以解决更多问题。

动态分区(Dynamic Partitions):从Android 10开始引入。它不再为systemvendorproduct等划分固定大小的独立分区,而是创建一个名为super的大分区,并在其中以逻辑卷的形式动态管理这些“子分区”。这样做的好处是厂商可以动态调整各分区的大小,避免了旧方案中因system分区空间不足导致无法OTA升级的尴尬。

虚拟A/B(Virtual A/B):在Android 13及更高版本中,谷歌进一步推出了虚拟A/B。它甚至不需要两个完整的物理分区副本。其核心是使用Linux内核的dm-snapshot(设备映射快照)技术,在更新时创建system等分区的快照,并在快照上进行更新操作。这进一步节省了存储空间,同时保留了A/B分区无缝更新的核心优势。

系统完整性保护:这也是你无法随意修改system分区的深层原因。现代Android设备普遍采用Verified Boot(验证启动)AVB(Android Verified Boot 2.0)。从bootloader开始,每一级都会验证下一级加载的镜像(如boot.imgvbmeta.img)的数字签名,确保其未被篡改。vbmeta分区就存储了用于验证其他分区的公钥和哈希值。如果验证失败,设备会拒绝启动或进入受限模式。这就是为什么直接修改system分区后,即使能启动,也可能导致Google Pay等需要SafetyNet认证的应用无法使用。

6. 给开发者和极客的实操心得与避坑指南

最后,分享一些在多年与Android分区打交道中积累的、不那么容易在官方文档中找到的经验。

心得一:备份永远第一位,尤其是persistefs分区在刷机或进行任何分区操作前,如果条件允许,一定要备份两个关键分区:persist(存储传感器校准、Wi-Fi蓝牙MAC地址等)和efs(存储基带IMEI等关键射频参数)。这两个分区一旦丢失或损坏,可能导致指纹失灵、Wi-Fi打不开甚至手机无法识别SIM卡,且很难恢复。在TWRP Recovery中,备份功能通常包含它们。对于没有TWRP的设备,在解锁Bootloader后,可以尝试通过dd命令(需Root)将其备份出来:dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img

心得二:理解“擦除”与“格式化”在Fastboot下的区别在Fastboot模式下:

  • fastboot erase partition:仅擦除分区头信息或清空分区表项,速度快,但数据可能被恢复。
  • fastboot format partition:会先擦除,再创建一个新的空文件系统(如ext4),更彻底。 对于userdata分区,通常推荐使用fastboot -w命令,它等价于fastboot format userdata,能确保隐私数据被安全清除并重建文件系统。对于cache分区,简单的erase通常就够了。

心得三:解决“Could not set environment: 150: Operation not permitted while system integrity...”这个错误常出现在尝试通过fastboot修改某些环境变量或刷入非官方镜像时。其根本原因是设备的引导加载程序处于锁定(Locked)状态,并且启用了严格的完整性保护。不要尝试绕过,正确的步骤是:

  1. 在手机开发者选项中启用“OEM解锁”。
  2. 使用fastboot flashing unlock(或厂商特定命令,如fastboot oem unlock)解锁Bootloader。注意:这会触发强制清除userdata分区!
  3. 解锁后,上述操作权限错误通常就会消失。

心得四:线刷救砖时,优先使用官方原厂包当手机完全无法进入Bootloader,只能依赖高通9008或联发科SPI模式进行线刷时,务必寻找与你的设备型号、硬件版本完全一致的官方原厂线刷包。使用不匹配的包,即使能刷入,也可能导致基带丢失、摄像头无法工作等深层次硬件兼容性问题。刷机工具(如QFIL)的版本也很重要,尽量使用包内自带的或厂商推荐的版本。

折腾Android分区是一把双刃剑,它赋予了设备极高的可玩性和控制权,但也伴随着风险。最稳妥的原则是:在动手前,彻底搞明白每一步操作的意义和后果;在操作时,确保有可靠的备份和可用的救砖方案。当你真正理解了这套分区体系的精妙之处,不仅能在问题面前游刃有余,更能深刻体会到Android系统设计的哲学。

← 返回列表