先把结论放在前面：AndroidManifest 不是"配置文件"，而是应用的组件注册表 + 权限申请表 + 系统启动契约。它的核心是 package（标识）、application（全局配置与入口）、component（四类组件的注册）、uses-permission（能力申请）这四块。真正要答出层次的是"合并规则"**——最终清单是主清单与各依赖库清单合并的结果，冲突由优先级与 tools: 标记决定。
AndroidManifest 深度解析这道题，答得浅和答得深差别很大。这篇从原理讲到实战，把每一层的答法都摆出来。
清单合并：这块是分水岭
Android 构建时会把所有库的清单合并进主清单，规则有三条能直接用于排障：
一、uses-permission 是并集，不会冲突。 依赖库声明的权限都会进最终清单——这是权限膨胀的根源。你在应用里从没申请定位，但某个 SDK 声明了 ACCESS_FINE_LOCATION，用户看到的权限弹窗里就有定位。要剔除就用 tools:node="remove"：
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
tools:node="remove" />
二、application 的属性是"取优先级高者"，冲突必须显式标记。 优先级顺序：buildType（debug/release）> flavor > manifestPlaceholders > library。库与主清单冲突时用 tools:replace 指定谁生效：
<application
android:name=".App"
android:networkSecurityConfig="@xml/network_security_config"
tools:replace="android:networkSecurityConfig" />
三、组件的 exported、enabled 这类安全相关属性必须显式收敛。 Android 12 起带 intent-filter 的组件不写 exported 会直接安装失败；安全上更该关注的是"库声明了 exported=true 且无权限保护的组件"——那是外部应用可以直接调用的入口。
# 实用命令：导出最终清单
./gradlew :app:processReleaseManifest --info
# 输出位置：
# app/build/intermediates/merged_manifest/release/AndroidManifest.xml
# 或者直接看报告
open app/build/reports/manifest-merger-release-report.txt
能说出"合并规则 + 看 merged manifest 报告"这套排障方法，答案就跟只背属性的候选人分开了。
最常见的坑是
第三方 SDK 声明了多余权限与组件，最终包体权限膨胀且无法解释。
典型表现是用户投诉"没点定位却弹定位授权"，或者应用市场审核阶段要求说明某权限用途，而团队里没人知道是哪个 SDK 引入的。根因有三层：① 库的 uses-permission 无条件并入；② 库自己注册了组件（ContentProvider 尤其容易，onCreate 早于 Application 执行）；③ build.gradle 里 manifestPlaceholders 覆盖了库里的值。
排查与治理的三条动作：
先定位权限来自哪个库：
# 1) 看最终权限来源
./gradlew app:dependencies --configuration releaseRuntimeClasspath
# 逐个库看它的 AndroidManifest
再在主清单合并层做剔除（慎用整库剔除，会丢掉必要的组件声明）：
<!-- 2) 剔除库带入的非必要权限 -->
<uses-permission
android:name="android.permission.ACCESS_FINE_LOCATION"
tools:node="remove" />
最后在打包产物上核对最终权限：
# 3) 打包后核对权限
aapt2 dump permissions app/build/outputs/apk/release/app-release.apk
治理手段按优先级排：① 用 tools:node="remove" 精确剔除非必要权限；② 找 SDK 提供方要"最小权限版本"；③ 换用不采集该信息的实现；④ 兜底是补隐私政策说明，但这是补救不是治理。
还有一个更隐蔽的坑：清单里的 android:debuggable、android:allowBackup、android:usesCleartextTraffic 这三项在 release 包里的取值，必须在发版前核对。常见事故是：debuggable 忘了关（等于把应用变成可被调试）、allowBackup="true" 导致用户数据可被 adb backup 取出、usesCleartextTraffic="true" 让网络请求裸奔。这三项每一条都对应过真实的安全事件，是清单检查里优先级最高的三行。
再补三个清单相关的进阶话题，因为它们都是真实事故的高发区。
一、android:allowBackup 与 fullBackupContent / dataExtractionRules。 默认 allowBackup="true" 意味着用户数据可以被 adb backup 取出，Android 12+ 改由 dataExtractionRules 控制云备份与设备迁移。涉及登录态、支付信息、隐私数据的应用应该显式关掉备份，或用规则文件精确排除敏感文件：
<application
android:allowBackup="false"
android:dataExtractionRules="@xml/data_extraction_rules" />
二、android:usesCleartextTraffic 与网络安全配置。 从 Android 9 起默认禁止明文 HTTP，但很多项目为了兼容老接口打开了它。更稳的做法是用 networkSecurityConfig 只对特定域名放开明文，而不是全局放开——这样既兼容了遗留接口，又不让整体通信失去保护：
<application android:networkSecurityConfig="@xml/network_security_config" />
其中 res/xml/network_security_config.xml 规则文件的内容如下：
<network-security-config>
<base-config cleartextTrafficPermitted="false" />
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">legacy.internal.example.com</domain>
</domain-config>
</network-security-config>
三、组件的 process 属性与 android:isolatedProcess。 process=":name" 让组件跑在私有进程里（内存独立、崩溃隔离），isolatedProcess="true" 更是没有系统权限的沙箱进程（只在系统应用里可用）。这两个属性的代价是跨进程通信成本与数据不可共享，用之前要确认收益大于成本。
三条高频追问
问：package 和 applicationId 的区别？
package 是源码里的包名（决定 Java/Kotlin 的包结构与 R 类位置），applicationId 是构建工具注入到最终清单里的应用标识（决定系统里的唯一性与权限隔离）。多模块或不同 flavor 可以让它们不同——比如 applicationIdSuffix = ".debug"，这样 debug 版与 release 版能装在同一台设备上。面试时能讲出"源码包名不改、构建标识可变"这个设计意图，说明理解到了构建工具的职责边界。
问：launchMode 为什么放在清单里而不是代码？
因为它是系统级契约——系统需要提前知道才能处理 Intent 投递、singleTask 的任务栈行为、singleInstance 的进程独立。代码里能设的只有 FLAG_ACTIVITY_* 这类启动标记，两者是"清单声明 + 启动时传标记"的关系。另外 singleInstance 已被 singleTask + taskAffinity 基本取代。
问：meta-data 怎么用，有什么坑？
它是组件级的键值配置，Bundle 形式传给组件。坑有三个：① 名字冲突时同优先级下主清单覆盖库的，但 applicationId 不同 flavor 要小心；② 读取必须在组件内部（Activity 里 intent.getExtras() 拿 meta-data），时机错了拿不到；③ Bundle 的 key 名不能带 . 以外的特殊字符是民间说法，实际约束是 key 建议用 Java 标识符格式。
落到项目里怎么做
一条能直接落地的规则：每次打包都跑一遍清单核对，把它做成 CI 门禁。 具体做法：① 构建后用 aapt2 dump permissions 导出权限快照，与上一版 diff，出现"新增权限"就要求说明；② 用脚本 grep exported="true" 且无 permission 的组件，超过白名单数量就失败；③ 核对 debuggable / allowBackup / usesCleartextTraffic 三项 release 取值。
配套实践三条：① 把上述检查写进 gradle 的 check 任务或独立的 verify-manifest 脚本；② 第三方 SDK 引入时在 PR 模板里要求附"权限与组件影响说明"；③ 保留一份"权限来源台账"，标注每个权限对应哪个业务场景与哪个 SDK——这是过应用市场审核与回应用户隐私问询时最直接的凭证。
给正在准备面试的你
这题的答法要落到"清单是系统契约的集合"这个定位上。推荐这条线：先说清清单的四块结构（标识/全局/组件/权限）→ 然后重点讲合并规则（权限并集、application 取优先级、tools:node 干预）并给出查 merged manifest 的命令 → 再讲 package vs applicationId 的设计意图 → 最后落"三项安全配置 + 权限膨胀治理"的工程清单。能给出"看 merger report 排障"这个动作，就说明不是背的。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：Intent-与-IntentFilter：显式隐式跳转与匹配规则
下一篇预告：进程优先级与进程回收：ADJ-与查杀顺序
有任何问题欢迎在评论区留言交流。
