拿到一台手机上电第一屏的Logo还没显示完你可能就感受到这套系统跟原生Android不太一样——通知栏多了快捷开关设置菜单里藏了一堆“厂商功能”桌面上还预装了几个删不掉的App。很多朋友管这叫“魔改”或者“UI套壳”但作为干了多年系统定制的工程师我想说这层壳下面真正藏着的是厂商对Android系统一整套的增删改查。从内核驱动到Framework从权限配置到文件访问规则每一个细节都可能被厂商用定制工具动过。如果你刷过机、折腾过第三方ROM或者只是好奇为什么行车记录仪、收银台里的安卓设备看不到原生设置这篇文章就是写给你的。我会从底层一路讲到上层把厂商定制系统的分层思路、核心手段、实际编译流程以及我踩过的一些坑全部摊开。内容偏工程向但我会尽量把每个概念说得让没用过AOSP的朋友也能跟上。1. 系统定制的整体盘子一个安卓版本究竟由哪几层拼起来1.1 内核与HAL硬件适配的起点厂商定制一个安卓系统第一个要动的往往不是界面而是Linux内核。不同芯片平台高通、MTK、展锐等都会维护自己的内核分支里面塞满了驱动补丁——屏幕、触摸、闪存、Wi-Fi、蓝牙、指纹还有电源管理。你要是下载一台手机的内核源码来看会发现大量跟“mainline”不一样的代码这就是厂商定制的第一层。在这之上是HAL硬件抽象层和VINTFVendor Interface。简单说AOSP里的框架层不会直接去操作硬件寄存器而是通过HAL接口跟驱动打交道。厂商要做的是写一套符合Android接口定义的HAL实现比如相机HAL、音频HAL、传感器HAL。这也是为什么你换了第三方内核之后相机打不开、指纹失效通常就是HAL不匹配。我见过太多人把高通平台的HAL一股脑换成AOSP默认版本结果相机黑屏、音频无声折腾到最后才发现问题根本不在App而在HAL层。定制系统的时候这一层决定了“系统能不能在这个硬件上跑起来”。它不提供任何你肉眼看到的定制效果但它是所有上层定制的物理前提。这也是为什么厂商的固件包喜欢分成boot、vendor、system好几段来升级——内核和硬件库跟系统应用是解耦的上层更新不需要重新适配硬件。1.2 Framework与系统应用绝大多数“定制感”的来源Framework层通俗讲就是操作系统提供给上层App用的那些API和管理服务。比如ActivityManagerService管着应用进程、WindowManagerService管着窗口、PackageManagerService管着APK的安装和权限。厂商在这里插入自己的逻辑效果就非常“系统级”。像某些ROM里的一键清理、后台纯净模式、应用冻结本质就是把AMS或者PowerManagerService的默认行为改写了一遍。这一层最常用的定制手法有三种直接改AOSP源码、加系统服务、用资源覆盖。直接改源码最狠可以连系统弹窗的样子都换掉加系统服务则用于扩展比如厂商做一个自己的“电池医生”后台服务跟系统电量和通知管理深度绑定资源覆盖最轻量只改界面文案、布局和部分配置不碰逻辑。再往上就是系统应用层也就是你看到的设置、SystemUI状态栏和通知栏、Launcher桌面、电话、短信、相机这些。厂商在这层的定制是最直白的换桌面布局、改设置菜单的分组、自定义通知栏快捷开关都是这一层的活。你注意观察很多定制ROM的“设置”里根本没有“开发者选项”或者入口藏得很深这正是厂商在设置应用里改了逻辑甚至直接把入口删了的结果。1.3 分区与编译产物镜像文件不是单个“Android”一个安卓设备的固件在磁盘上被切成多个分区专门给系统分区起了名字system、vendor、product、odm。每个分区都有自己的职责范围也都要单独编译、单独打包。system放通用Android系统和内置应用vendor放厂商硬件相关库product放跟品牌强相关的界面和预装。分区之间还会有进程通信与SELinux策略限制互相不能乱访问。这个拆分的逻辑很像是把一套房子分成承重墙和室内装修承重墙要是乱拆整个结构就不稳装修怎么改都行只要不动结构。vendor分区相当于承重墙需要跟着硬件走system和product分区的改动相对自由升级频率也可以更高。正因为有这个分区结构厂商才有能力在同一个Android大版本上做出很多不同的细分产品而不用为每台手机从头移植。2. 厂商定制的核心手段那些藏在源码和配置里的“后门”2.1 产品配置与资源覆盖不写代码也能定制的“软开关”AOSP的构建体系里有一套非常灵活的机制叫产品配置文件常见的是device目录下的.mk或者Android.bp。厂商只要在产品配置里声明几行就能控制最终镜像里包含哪些应用、启用哪些服务、默认的开关状态是什么。比如PRODUCT_PACKAGES变量用来追加预装应用PRODUCT_OVERRIDE_ACTIVITIES还可以把某些开源应用的默认行为替换掉。资源覆盖RRORuntime Resource Overlay是我个人最喜欢的一招。它不需要改任何Java/Kotlin代码只需要把对应应用的资源文件复制一份过来改掉颜色、文本、尺寸放进一个overlay包编译时让系统使用这个覆盖包。最典型的例子是设置App里那些“关于手机”界面不同品牌的文案和Logo就是通过这么玩的。你想想如果不靠资源覆盖厂商给几百台机型定制不同的UI文案得维护多少套源码产品配置文件还能控制“最终用户能不能看到原生设置”。不少厂商在定制的时候会把设置里的某些子页面从导航列表里移除只是因为你并不需要这些入口。这个东西不是什么高深魔法就是一个配置项。但前提是系统所有组件都要遵守这个配置一旦某个第三方App直接拉起原生设置的Activity还是会露出马脚——这也是为什么在定制机上偶尔能看到“本来应该被隐藏”的原生页面。2.2 系统应用特权与平台签名为什么厂商预装App删不掉你手机上那些删不掉的App技术上说它们多半不是普通应用而是带系统特权的特权应用priv-app。在Android分区结构里普通应用放在/system/app或者/product/app特权应用放在/system/priv-app。放在priv-app目录里的应用可以拿到一些普通应用拿不到的高危权限比如修改系统设置、强制停止别的应用、访问所有文件。光放到priv-app目录还不够Android有一个严格的校验机制“特权应用权限白名单”privapp-permissions。系统会检查/etc/permissions目录下的XML文件里面列出了每个特权应用可以声明的权限。如果声明了不在白名单里的权限系统在启动时会拒绝赋予甚至导致应用崩溃。这就是厂商定制的时候经常遇到的一个问题把App编进priv-app了权限也加了但一运行就报错翻了半天logcat才发现是忘了加白名单。特权应用往往还会搭配平台签名。应用在编译时用platform证书签名APK的签名就跟系统框架一样系统会把它当成“自己人”。到这一步这个应用就真的删不掉了因为它已经被系统视为不可分割的一部分。这里我想多提一句平台签名不是拿来做安全炫耀的它是一把双刃剑。普通应用能正常用的图片选择器、文件访问、权限申请到了特权应用手里机制会完全不同。你在改别人的App或者给机器预装应用的时候签名策略稍微弄错就会留下一堆安全隐患。2.3 分区存储与FileProviderandroid/data目录为何成了“禁区”从Android 11开始大家应该能明显感觉到连系统自带的文件管理器都很难访问/sdcard/Android/data目录了。用Android手机的朋友一定看过类似的路径/storage/emulated/0/Android/data/com.xxx.yyy/files/...。这是Google为了用户隐私搞的分区存储机制App只能访问自己的专属目录没有权限翻别人的。但很多行业定制设备比如行车记录仪、工业平板就是要跨应用读文件怎么办厂商在定制系统里通常会用两条路绕过一是自己写一个系统级文件管理服务拥有系统权限后帮你读写二是通过FileProvider暴露一个内容URI让另一个应用通过content://协议间接访问。你在日志里见到的content://com.tencent.wework.fileprovider/external_path/android/data/com...就是这类做法的参数痕迹。我对这个机制的判断是限制文件访问是为了让普通用户的隐私更有保障但厂商“开洞”也是有实际需求的。开车记录仪的视频要给App看工控设备的数据要做备份这些场景没法一刀切。关键问题在于“开洞”这个行为本身是否安全。好的定制厂商会把FileProvider的授权范围限定在固定应用、固定目录并配合权限验证和签名校验偷懒的厂商直接给个MANAGE_EXTERNAL_STORAGE权限等于把整块用户存储空间都敞开这就不太像话了。2.4 SELinux与系统属性看不见的“安全围墙”厂商定制最容易被新手忽视的一层是SELinux策略。每次应用想访问某个文件、读某个设备节点Android内核都会在SELinux层做一次“安检”。如果策略不允许就算你是root用户也可能被拦截。定制系统最头疼的就是应用明明拥有权限却总是打不开文件一看logcat唰唰唰都是avc: denied的日志。定制团队写系统的时候要为每个新增的应用或服务编写对应的SE策略。比如给某个系统应用颁一个自己的安全域domain再把文件的安全上下文file_contexts分配给对应的目录。这里面的门道很深策略写松了起不到安全隔离作用写严了应用又是各种崩溃。我见过有团队图省事直接把某几个应用的SELinux策略union到platform_app域结果整个系统权限体系形同虚设。后来出过问题才老老实实按域隔离。所以别以为SELinux只在服务器上用安卓系统上它天天在干活。3. 动手实操自己把定制组件打进系统镜像3.1 准备一套可编译的AOSP工程这一章的实操默认你已经能下载并编译AOSP或厂商开源的系统源码。条件允许的话最好用与目标设备配套的vendor源码这样会把驱动、HAL、库目录都预先配置好。真机调试时尽量选择userdebug或者eng版本的编译类型这样能用adb root来做系统级操作。不要上来就编译user版本否则后面你连调试权限都要花大力气。工程目录结构上常用的定制目录是device/vendor/device/厂商自己的应用目录一般放在packages/apps/下。新建一个属于自己的系统应用最直观的目录就是packages/apps/MySystemApp/。注意这不是简单的“把APK拖进去”就行你需要用Android构建系统识别这个模块并在产品配置里声明它。3.2 通过Android.bp把应用加入构建AOSP现在的默认构建系统是Soong配置文件是Android.bp。如果你在一个源码工程里写一个系统应用最简配置可以这样写android_app { name: MySystemApp, srcs: [src/**/*.java], resource_dirs: [res], certificate: platform, privileged: true, dex_preopt: { enabled: true, }, sdk_version: system_current, }这段配置里最关键的两个字段是certificate: platform和privileged: true。前者意味着应用要拿平台签名后者表示编出来的APK会放到priv-app目录。如果你的应用还需要一些特权权限那还得在/etc/permissions目录下准备一个对应的XML白名单文件并把文件路径通过PRODUCT_COPY_FILES加入镜像。写完之后在源码根目录执行source build/envsetup.sh再执行lunch device-userdebug选择你对应的设备配置然后mmm packages/apps/MySystemApp增量编译单个模块。如果编译通过再make systemimage把整个system分区镜像打包出来。我这里刻意省略了很多细节比如JDK版本、代码签名配置因为不同Android版本差异较大但这套大流程是稳定的。3.3 配置FileProvider向其他应用暴露指定文件现在很多行业定制设备要解决的问题是让别的非特权App也能读取系统应用生成的数据目录。FileProvider是官方推荐的方案下面是一个常见配置示例。先在AndroidManifest.xml里注册Providerprovider android:nameandroidx.core.content.FileProvider android:authoritiescom.mysystem.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider然后准备res/xml/file_paths.xml告诉FileProvider哪些路径可以被暴露paths external-path nameexternal_data pathAndroid/data/com.mysystem/files/ / files-path nameinternal_files pathdownloads/ / /paths当系统应用需要把文件分享给其他App时先生成一个content://com.mysystem.fileprovider/external_data/xxx.log这样的URI再配合Intent的FLAG_GRANT_READ_URI_PERMISSION授权出去。另一个应用收到的就是content URI不再直接操作绝对路径。这个做法在厂商定制系统里非常常见因为它既尊重了分区存储规则又实现跨应用文件交换。3.4 让SELinux放行你的定制应用编译好、装进系统分区离真正跑起来还有一道关要过那就是SELinux。在userdebug版本下你可以先临时把SELinux设为permissive模式测试adb shell setenforce 0。但千万别以为生产环境也能这样干permissive只是定位问题用的正式镜像必须恢复enforcing。先在logcat里抓avc: denied日志然后根据“源域(source context)”“目标上下文(target context)”“访问类别(class)”去写对应的te策略。比如你的应用被分配platform_app域想访问某个vendor目录下的文件就要在vendor的sepolicy目录下加allow platform_app vendor_custom_file:dir { read search open }; allow platform_app vendor_custom_file:file { read open getattr };写好后在有file_contexts的地方为你的文件配置一个安全上下文。最常见的问题是忘了给/vendor/custom/*文件打上对应的上下文标签导致SELinux只看到默认的vendor_file类型权限怎么放行都没用。这个坑我踩了不止一次建议新手在写sepolicy时先把目录的file_contexts配好再回头写allow规则。4. 真实翻车现场四个高频问题与排查思路4.1 应用明明有root权限文件为什么还是读不了这是我在群里被问得最多的问题。很多人做了平台签名、把应用放进去、也给了root但还是被SELinux挡住。排查思路其实不复杂先adb shell dmesg | grep avc或者adb logcat -b events | grep avc看到avc: denied { read }就说明被SELinux拦了。这时候不要先想着关SELinux而是去补策略。如果只是调试可以adb root adb shell setenforce 0临时验证。但从生产角度看把SELinux关掉等于让系统大门敞开不可取。我还遇到过一个更隐蔽的问题权限白名单漏配。应用已经在priv-app目录里AndroidManifest.xml也声明了PACKAGE_USAGE_STATS权限但系统日志一直报权限拒绝。查了半天才发现是privapp-permissions.xml没有把这条权限加进去。这个问题很典型因为新权限经常在应用升级时被加入但白名单XML不是跟着App走的很容易被忽略。4.2 行车记录仪这类定制机上开发者选项怎么都打不开现在很多行业设备比如行车记录仪、广告屏、点餐机厂商直接把原生设置隐藏了界面里根本没有“开发者选项”的入口。想打开USB调试或者查看日志通常可以从“关于设备/关于本机”这个入口入手连续点击版本号或型号信息几次看会不会弹出开发者选项。如果厂商连这个入口都删了那就只能用工程模式通道或者直接连接ADB执行adb shell settings put global development_settings_enabled 1 adb shell am start -a android.settings.APPLICATION_DEVELOPMENT_SETTINGS需要注意这不是一条万能命令。定制系统如果彻底移除了开发者选项相关的页面第二条am start就不会有响应。碰到这种机器更靠谱的做法是查厂商发布的技术文档看他们有没有保留工程口。归根结底定制机隐藏原生设置不是单纯为了防小白乱点还是为了保障设备的稳定和业务安全。你硬要把它打开还可能因为驱动或权限不匹配导致设备运行异常。4.3 系统自带文件管理器进不去Android/data这是不是Bug这个问题不算Bug而是Android 11以后分区存储的常规表现。就算你是系统应用如果走的是普通文件访问路径一样会被外部存储沙箱机制挡住。厂商在定制系统里如果希望文件管理器能“看到”Android/data通常会在ROM里保留旧的存储访问方式或者自己对接一个专用的存储访问框架。你可以观察一下你手机自带文件管理器进不去Android/data但同一个品牌的另一个版本又能进这往往就是系统定制策略不同。普通用户如果只是想备份某App的存档或者日志我建议用对应App自带的备份导出功能不要硬去翻Android/data。那些教你用电脑端工具或畸形手段强行进目录的教程大多数要依赖ADB特殊命令不同系统版本差异巨大而且很容易改坏目录权限。厂商对这个目录的限制是有意的不是“忘了给你开”。4.4 常见问题速查表现象最可能的原因排查手段常规解法预装App运行闪退报权限拒绝privapp权限白名单缺失或系统权限冲突查看logcat中Privileged permission相关日志补全/etc/permissions下privapp白名单应用拥有权限但文件访问失败SELinux avc denied拦截dmesg或logcat搜avc增加sepolicy allow规则定制机找不到开发者选项设置界面被厂商改写或入口被隐藏检查“关于设备”中版本号是否可连点尝试ADB命令或厂商工程模式Android/data目录无法浏览分区存储机制在生效观察文件管理器是否走SAF接口使用系统应用自己的备份导出功能打好的镜像刷入后设备无限重启file_contexts或SELinux策略导致init无法访问关键文件抓取内核串口日志分析修复文件上下文或回退策略5. 定制系统的边界感做减法和做加法同样重要5.1 预装应用和服务的膨胀代价系统定制做到后面最考验人的不是怎么加功能而是怎么控制体积和资源占用。每一行Framework改动、每一个后台常驻服务、每多一个预装应用都会直接影响开机速度、内存占用和待机功耗。我见过某款低成本定制设备厂商为了功能丰富一口气预装了四十多个应用结果开机进程启动顺序全是乱的第三方应用频繁被杀。做定制的正确思路应该先想清楚“这层设备的核心业务是什么”如果是扫码设备那就把扫码相关的服务做成系统级、把无关App全部剪掉如果是行车记录仪那就优先保证录像和存储稳定减少后台联网通信。厂商工具箱里的秘密其实更多时候是“知道什么不该往里塞”。5.2 系统升级和维护永远是定制项目的最大深水区很多定制项目在出厂时看起来完美一进入系统升级就暴雷。最大原因是Framework被改得太深升级大版本时Merge冲突裂开。AOSP每个大版本对于权限模型、分区结构、SELinux策略的调整都非常多你在旧版本里魔改的那部分很可能在新版本里已经不复存在。所以经验丰富的团队在改Framework时都会圈出一个“定制代码区域”尽量用公开接口或配置来完成需求把对源码的侵入控制在最小范围。这背后反映的其实是工程管理问题。我入职很多年后才明白厂商定制系统的最大资产不是某个炫技功能而是“升级迁移能力”。那些用配置文件和标准接口实现的定制到了新版本只用做增量适配那些靠修改Framework核心逻辑实现的定制每一次升级都要重新走一遍适配甚至要回到当初的原型重新解一次冲突。这也是我为什么全文都在强调“方法”而不是“改某行代码”方法对了迁移才轻松。5.3 安全底线请留在你定制系统的每一行代码里最后想认真说一句定制权限这件事本质上是在给系统“凿洞”。凿洞没有错错的是把洞凿得四处漏风。前面说的platform签名、priv-app权限、SELinux放行每一项都是为了解决某一个具体问题而存在的但如果你因为“这样方便”、“省事”就随手把这些机制放大那这套定制系统从诞生那天起就像建在沙地上的楼。我建议每个做定制开发的朋友在每次给应用提权限之前先问自己三个问题这个权限是否可以换成更小范围的接口这个允许规则是否能限定到具体的目录或文件SDK的导出是否真的需要全部开放而不是只开放某个子目录这三个问题想明白定制系统的安全和稳定都会高一大截。至少从我自己的经历来看真正优秀的系统定制项目从来不是功能最花哨的那个而是“改了那么多却让你感觉不到被改过”的那一个。把这句体会放在最后希望对准备动手做定制系统的你有点用。
Android系统定制全解析：从内核到Framework的增删改查
拿到一台手机上电第一屏的Logo还没显示完你可能就感受到这套系统跟原生Android不太一样——通知栏多了快捷开关设置菜单里藏了一堆“厂商功能”桌面上还预装了几个删不掉的App。很多朋友管这叫“魔改”或者“UI套壳”但作为干了多年系统定制的工程师我想说这层壳下面真正藏着的是厂商对Android系统一整套的增删改查。从内核驱动到Framework从权限配置到文件访问规则每一个细节都可能被厂商用定制工具动过。如果你刷过机、折腾过第三方ROM或者只是好奇为什么行车记录仪、收银台里的安卓设备看不到原生设置这篇文章就是写给你的。我会从底层一路讲到上层把厂商定制系统的分层思路、核心手段、实际编译流程以及我踩过的一些坑全部摊开。内容偏工程向但我会尽量把每个概念说得让没用过AOSP的朋友也能跟上。1. 系统定制的整体盘子一个安卓版本究竟由哪几层拼起来1.1 内核与HAL硬件适配的起点厂商定制一个安卓系统第一个要动的往往不是界面而是Linux内核。不同芯片平台高通、MTK、展锐等都会维护自己的内核分支里面塞满了驱动补丁——屏幕、触摸、闪存、Wi-Fi、蓝牙、指纹还有电源管理。你要是下载一台手机的内核源码来看会发现大量跟“mainline”不一样的代码这就是厂商定制的第一层。在这之上是HAL硬件抽象层和VINTFVendor Interface。简单说AOSP里的框架层不会直接去操作硬件寄存器而是通过HAL接口跟驱动打交道。厂商要做的是写一套符合Android接口定义的HAL实现比如相机HAL、音频HAL、传感器HAL。这也是为什么你换了第三方内核之后相机打不开、指纹失效通常就是HAL不匹配。我见过太多人把高通平台的HAL一股脑换成AOSP默认版本结果相机黑屏、音频无声折腾到最后才发现问题根本不在App而在HAL层。定制系统的时候这一层决定了“系统能不能在这个硬件上跑起来”。它不提供任何你肉眼看到的定制效果但它是所有上层定制的物理前提。这也是为什么厂商的固件包喜欢分成boot、vendor、system好几段来升级——内核和硬件库跟系统应用是解耦的上层更新不需要重新适配硬件。1.2 Framework与系统应用绝大多数“定制感”的来源Framework层通俗讲就是操作系统提供给上层App用的那些API和管理服务。比如ActivityManagerService管着应用进程、WindowManagerService管着窗口、PackageManagerService管着APK的安装和权限。厂商在这里插入自己的逻辑效果就非常“系统级”。像某些ROM里的一键清理、后台纯净模式、应用冻结本质就是把AMS或者PowerManagerService的默认行为改写了一遍。这一层最常用的定制手法有三种直接改AOSP源码、加系统服务、用资源覆盖。直接改源码最狠可以连系统弹窗的样子都换掉加系统服务则用于扩展比如厂商做一个自己的“电池医生”后台服务跟系统电量和通知管理深度绑定资源覆盖最轻量只改界面文案、布局和部分配置不碰逻辑。再往上就是系统应用层也就是你看到的设置、SystemUI状态栏和通知栏、Launcher桌面、电话、短信、相机这些。厂商在这层的定制是最直白的换桌面布局、改设置菜单的分组、自定义通知栏快捷开关都是这一层的活。你注意观察很多定制ROM的“设置”里根本没有“开发者选项”或者入口藏得很深这正是厂商在设置应用里改了逻辑甚至直接把入口删了的结果。1.3 分区与编译产物镜像文件不是单个“Android”一个安卓设备的固件在磁盘上被切成多个分区专门给系统分区起了名字system、vendor、product、odm。每个分区都有自己的职责范围也都要单独编译、单独打包。system放通用Android系统和内置应用vendor放厂商硬件相关库product放跟品牌强相关的界面和预装。分区之间还会有进程通信与SELinux策略限制互相不能乱访问。这个拆分的逻辑很像是把一套房子分成承重墙和室内装修承重墙要是乱拆整个结构就不稳装修怎么改都行只要不动结构。vendor分区相当于承重墙需要跟着硬件走system和product分区的改动相对自由升级频率也可以更高。正因为有这个分区结构厂商才有能力在同一个Android大版本上做出很多不同的细分产品而不用为每台手机从头移植。2. 厂商定制的核心手段那些藏在源码和配置里的“后门”2.1 产品配置与资源覆盖不写代码也能定制的“软开关”AOSP的构建体系里有一套非常灵活的机制叫产品配置文件常见的是device目录下的.mk或者Android.bp。厂商只要在产品配置里声明几行就能控制最终镜像里包含哪些应用、启用哪些服务、默认的开关状态是什么。比如PRODUCT_PACKAGES变量用来追加预装应用PRODUCT_OVERRIDE_ACTIVITIES还可以把某些开源应用的默认行为替换掉。资源覆盖RRORuntime Resource Overlay是我个人最喜欢的一招。它不需要改任何Java/Kotlin代码只需要把对应应用的资源文件复制一份过来改掉颜色、文本、尺寸放进一个overlay包编译时让系统使用这个覆盖包。最典型的例子是设置App里那些“关于手机”界面不同品牌的文案和Logo就是通过这么玩的。你想想如果不靠资源覆盖厂商给几百台机型定制不同的UI文案得维护多少套源码产品配置文件还能控制“最终用户能不能看到原生设置”。不少厂商在定制的时候会把设置里的某些子页面从导航列表里移除只是因为你并不需要这些入口。这个东西不是什么高深魔法就是一个配置项。但前提是系统所有组件都要遵守这个配置一旦某个第三方App直接拉起原生设置的Activity还是会露出马脚——这也是为什么在定制机上偶尔能看到“本来应该被隐藏”的原生页面。2.2 系统应用特权与平台签名为什么厂商预装App删不掉你手机上那些删不掉的App技术上说它们多半不是普通应用而是带系统特权的特权应用priv-app。在Android分区结构里普通应用放在/system/app或者/product/app特权应用放在/system/priv-app。放在priv-app目录里的应用可以拿到一些普通应用拿不到的高危权限比如修改系统设置、强制停止别的应用、访问所有文件。光放到priv-app目录还不够Android有一个严格的校验机制“特权应用权限白名单”privapp-permissions。系统会检查/etc/permissions目录下的XML文件里面列出了每个特权应用可以声明的权限。如果声明了不在白名单里的权限系统在启动时会拒绝赋予甚至导致应用崩溃。这就是厂商定制的时候经常遇到的一个问题把App编进priv-app了权限也加了但一运行就报错翻了半天logcat才发现是忘了加白名单。特权应用往往还会搭配平台签名。应用在编译时用platform证书签名APK的签名就跟系统框架一样系统会把它当成“自己人”。到这一步这个应用就真的删不掉了因为它已经被系统视为不可分割的一部分。这里我想多提一句平台签名不是拿来做安全炫耀的它是一把双刃剑。普通应用能正常用的图片选择器、文件访问、权限申请到了特权应用手里机制会完全不同。你在改别人的App或者给机器预装应用的时候签名策略稍微弄错就会留下一堆安全隐患。2.3 分区存储与FileProviderandroid/data目录为何成了“禁区”从Android 11开始大家应该能明显感觉到连系统自带的文件管理器都很难访问/sdcard/Android/data目录了。用Android手机的朋友一定看过类似的路径/storage/emulated/0/Android/data/com.xxx.yyy/files/...。这是Google为了用户隐私搞的分区存储机制App只能访问自己的专属目录没有权限翻别人的。但很多行业定制设备比如行车记录仪、工业平板就是要跨应用读文件怎么办厂商在定制系统里通常会用两条路绕过一是自己写一个系统级文件管理服务拥有系统权限后帮你读写二是通过FileProvider暴露一个内容URI让另一个应用通过content://协议间接访问。你在日志里见到的content://com.tencent.wework.fileprovider/external_path/android/data/com...就是这类做法的参数痕迹。我对这个机制的判断是限制文件访问是为了让普通用户的隐私更有保障但厂商“开洞”也是有实际需求的。开车记录仪的视频要给App看工控设备的数据要做备份这些场景没法一刀切。关键问题在于“开洞”这个行为本身是否安全。好的定制厂商会把FileProvider的授权范围限定在固定应用、固定目录并配合权限验证和签名校验偷懒的厂商直接给个MANAGE_EXTERNAL_STORAGE权限等于把整块用户存储空间都敞开这就不太像话了。2.4 SELinux与系统属性看不见的“安全围墙”厂商定制最容易被新手忽视的一层是SELinux策略。每次应用想访问某个文件、读某个设备节点Android内核都会在SELinux层做一次“安检”。如果策略不允许就算你是root用户也可能被拦截。定制系统最头疼的就是应用明明拥有权限却总是打不开文件一看logcat唰唰唰都是avc: denied的日志。定制团队写系统的时候要为每个新增的应用或服务编写对应的SE策略。比如给某个系统应用颁一个自己的安全域domain再把文件的安全上下文file_contexts分配给对应的目录。这里面的门道很深策略写松了起不到安全隔离作用写严了应用又是各种崩溃。我见过有团队图省事直接把某几个应用的SELinux策略union到platform_app域结果整个系统权限体系形同虚设。后来出过问题才老老实实按域隔离。所以别以为SELinux只在服务器上用安卓系统上它天天在干活。3. 动手实操自己把定制组件打进系统镜像3.1 准备一套可编译的AOSP工程这一章的实操默认你已经能下载并编译AOSP或厂商开源的系统源码。条件允许的话最好用与目标设备配套的vendor源码这样会把驱动、HAL、库目录都预先配置好。真机调试时尽量选择userdebug或者eng版本的编译类型这样能用adb root来做系统级操作。不要上来就编译user版本否则后面你连调试权限都要花大力气。工程目录结构上常用的定制目录是device/vendor/device/厂商自己的应用目录一般放在packages/apps/下。新建一个属于自己的系统应用最直观的目录就是packages/apps/MySystemApp/。注意这不是简单的“把APK拖进去”就行你需要用Android构建系统识别这个模块并在产品配置里声明它。3.2 通过Android.bp把应用加入构建AOSP现在的默认构建系统是Soong配置文件是Android.bp。如果你在一个源码工程里写一个系统应用最简配置可以这样写android_app { name: MySystemApp, srcs: [src/**/*.java], resource_dirs: [res], certificate: platform, privileged: true, dex_preopt: { enabled: true, }, sdk_version: system_current, }这段配置里最关键的两个字段是certificate: platform和privileged: true。前者意味着应用要拿平台签名后者表示编出来的APK会放到priv-app目录。如果你的应用还需要一些特权权限那还得在/etc/permissions目录下准备一个对应的XML白名单文件并把文件路径通过PRODUCT_COPY_FILES加入镜像。写完之后在源码根目录执行source build/envsetup.sh再执行lunch device-userdebug选择你对应的设备配置然后mmm packages/apps/MySystemApp增量编译单个模块。如果编译通过再make systemimage把整个system分区镜像打包出来。我这里刻意省略了很多细节比如JDK版本、代码签名配置因为不同Android版本差异较大但这套大流程是稳定的。3.3 配置FileProvider向其他应用暴露指定文件现在很多行业定制设备要解决的问题是让别的非特权App也能读取系统应用生成的数据目录。FileProvider是官方推荐的方案下面是一个常见配置示例。先在AndroidManifest.xml里注册Providerprovider android:nameandroidx.core.content.FileProvider android:authoritiescom.mysystem.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider然后准备res/xml/file_paths.xml告诉FileProvider哪些路径可以被暴露paths external-path nameexternal_data pathAndroid/data/com.mysystem/files/ / files-path nameinternal_files pathdownloads/ / /paths当系统应用需要把文件分享给其他App时先生成一个content://com.mysystem.fileprovider/external_data/xxx.log这样的URI再配合Intent的FLAG_GRANT_READ_URI_PERMISSION授权出去。另一个应用收到的就是content URI不再直接操作绝对路径。这个做法在厂商定制系统里非常常见因为它既尊重了分区存储规则又实现跨应用文件交换。3.4 让SELinux放行你的定制应用编译好、装进系统分区离真正跑起来还有一道关要过那就是SELinux。在userdebug版本下你可以先临时把SELinux设为permissive模式测试adb shell setenforce 0。但千万别以为生产环境也能这样干permissive只是定位问题用的正式镜像必须恢复enforcing。先在logcat里抓avc: denied日志然后根据“源域(source context)”“目标上下文(target context)”“访问类别(class)”去写对应的te策略。比如你的应用被分配platform_app域想访问某个vendor目录下的文件就要在vendor的sepolicy目录下加allow platform_app vendor_custom_file:dir { read search open }; allow platform_app vendor_custom_file:file { read open getattr };写好后在有file_contexts的地方为你的文件配置一个安全上下文。最常见的问题是忘了给/vendor/custom/*文件打上对应的上下文标签导致SELinux只看到默认的vendor_file类型权限怎么放行都没用。这个坑我踩了不止一次建议新手在写sepolicy时先把目录的file_contexts配好再回头写allow规则。4. 真实翻车现场四个高频问题与排查思路4.1 应用明明有root权限文件为什么还是读不了这是我在群里被问得最多的问题。很多人做了平台签名、把应用放进去、也给了root但还是被SELinux挡住。排查思路其实不复杂先adb shell dmesg | grep avc或者adb logcat -b events | grep avc看到avc: denied { read }就说明被SELinux拦了。这时候不要先想着关SELinux而是去补策略。如果只是调试可以adb root adb shell setenforce 0临时验证。但从生产角度看把SELinux关掉等于让系统大门敞开不可取。我还遇到过一个更隐蔽的问题权限白名单漏配。应用已经在priv-app目录里AndroidManifest.xml也声明了PACKAGE_USAGE_STATS权限但系统日志一直报权限拒绝。查了半天才发现是privapp-permissions.xml没有把这条权限加进去。这个问题很典型因为新权限经常在应用升级时被加入但白名单XML不是跟着App走的很容易被忽略。4.2 行车记录仪这类定制机上开发者选项怎么都打不开现在很多行业设备比如行车记录仪、广告屏、点餐机厂商直接把原生设置隐藏了界面里根本没有“开发者选项”的入口。想打开USB调试或者查看日志通常可以从“关于设备/关于本机”这个入口入手连续点击版本号或型号信息几次看会不会弹出开发者选项。如果厂商连这个入口都删了那就只能用工程模式通道或者直接连接ADB执行adb shell settings put global development_settings_enabled 1 adb shell am start -a android.settings.APPLICATION_DEVELOPMENT_SETTINGS需要注意这不是一条万能命令。定制系统如果彻底移除了开发者选项相关的页面第二条am start就不会有响应。碰到这种机器更靠谱的做法是查厂商发布的技术文档看他们有没有保留工程口。归根结底定制机隐藏原生设置不是单纯为了防小白乱点还是为了保障设备的稳定和业务安全。你硬要把它打开还可能因为驱动或权限不匹配导致设备运行异常。4.3 系统自带文件管理器进不去Android/data这是不是Bug这个问题不算Bug而是Android 11以后分区存储的常规表现。就算你是系统应用如果走的是普通文件访问路径一样会被外部存储沙箱机制挡住。厂商在定制系统里如果希望文件管理器能“看到”Android/data通常会在ROM里保留旧的存储访问方式或者自己对接一个专用的存储访问框架。你可以观察一下你手机自带文件管理器进不去Android/data但同一个品牌的另一个版本又能进这往往就是系统定制策略不同。普通用户如果只是想备份某App的存档或者日志我建议用对应App自带的备份导出功能不要硬去翻Android/data。那些教你用电脑端工具或畸形手段强行进目录的教程大多数要依赖ADB特殊命令不同系统版本差异巨大而且很容易改坏目录权限。厂商对这个目录的限制是有意的不是“忘了给你开”。4.4 常见问题速查表现象最可能的原因排查手段常规解法预装App运行闪退报权限拒绝privapp权限白名单缺失或系统权限冲突查看logcat中Privileged permission相关日志补全/etc/permissions下privapp白名单应用拥有权限但文件访问失败SELinux avc denied拦截dmesg或logcat搜avc增加sepolicy allow规则定制机找不到开发者选项设置界面被厂商改写或入口被隐藏检查“关于设备”中版本号是否可连点尝试ADB命令或厂商工程模式Android/data目录无法浏览分区存储机制在生效观察文件管理器是否走SAF接口使用系统应用自己的备份导出功能打好的镜像刷入后设备无限重启file_contexts或SELinux策略导致init无法访问关键文件抓取内核串口日志分析修复文件上下文或回退策略5. 定制系统的边界感做减法和做加法同样重要5.1 预装应用和服务的膨胀代价系统定制做到后面最考验人的不是怎么加功能而是怎么控制体积和资源占用。每一行Framework改动、每一个后台常驻服务、每多一个预装应用都会直接影响开机速度、内存占用和待机功耗。我见过某款低成本定制设备厂商为了功能丰富一口气预装了四十多个应用结果开机进程启动顺序全是乱的第三方应用频繁被杀。做定制的正确思路应该先想清楚“这层设备的核心业务是什么”如果是扫码设备那就把扫码相关的服务做成系统级、把无关App全部剪掉如果是行车记录仪那就优先保证录像和存储稳定减少后台联网通信。厂商工具箱里的秘密其实更多时候是“知道什么不该往里塞”。5.2 系统升级和维护永远是定制项目的最大深水区很多定制项目在出厂时看起来完美一进入系统升级就暴雷。最大原因是Framework被改得太深升级大版本时Merge冲突裂开。AOSP每个大版本对于权限模型、分区结构、SELinux策略的调整都非常多你在旧版本里魔改的那部分很可能在新版本里已经不复存在。所以经验丰富的团队在改Framework时都会圈出一个“定制代码区域”尽量用公开接口或配置来完成需求把对源码的侵入控制在最小范围。这背后反映的其实是工程管理问题。我入职很多年后才明白厂商定制系统的最大资产不是某个炫技功能而是“升级迁移能力”。那些用配置文件和标准接口实现的定制到了新版本只用做增量适配那些靠修改Framework核心逻辑实现的定制每一次升级都要重新走一遍适配甚至要回到当初的原型重新解一次冲突。这也是我为什么全文都在强调“方法”而不是“改某行代码”方法对了迁移才轻松。5.3 安全底线请留在你定制系统的每一行代码里最后想认真说一句定制权限这件事本质上是在给系统“凿洞”。凿洞没有错错的是把洞凿得四处漏风。前面说的platform签名、priv-app权限、SELinux放行每一项都是为了解决某一个具体问题而存在的但如果你因为“这样方便”、“省事”就随手把这些机制放大那这套定制系统从诞生那天起就像建在沙地上的楼。我建议每个做定制开发的朋友在每次给应用提权限之前先问自己三个问题这个权限是否可以换成更小范围的接口这个允许规则是否能限定到具体的目录或文件SDK的导出是否真的需要全部开放而不是只开放某个子目录这三个问题想明白定制系统的安全和稳定都会高一大截。至少从我自己的经历来看真正优秀的系统定制项目从来不是功能最花哨的那个而是“改了那么多却让你感觉不到被改过”的那一个。把这句体会放在最后希望对准备动手做定制系统的你有点用。
