真正影响所有组件的application属性包括android:allowbackup、android:usescleartexttraffic、android:networksecurityconfig、android:debuggable（设为true时强制生效）、android:hardwareaccelerated（仅对activity生效）；android:exported和android:enabled不继承，必须逐个组件声明。
application 标签里哪些属性真会影响所有组件？
不是所有写在 <application></application> 里的属性都会自动继承给 activity/service/receiver —— 只有明确标注“可被子元素继承”的才生效。比如 android:exported 和 android:enabled 就不会向下传递，而 android:allowBackup、android:usesCleartextTraffic、android:networkSecurityConfig 这类全局行为控制项才会。
常见误操作：把 android:exported="true" 放在 <application></application> 里，以为能省掉每个 <activity></activity> 单独声明，结果构建直接报错：error: exported attribute must be explicitly specified。这是 Android 12+ 的硬性要求，和 <application></application> 无关。
-
android:allowBackup和android:fullBackupContent确实影响全部组件的备份行为 -
android:debuggable默认为 false，但一旦设为 true，所有组件都可被调试（即使单个 activity 显式设了 false，也无效） -
android:hardwareAccelerated默认 true，对所有 activity 生效；但 service/receiver 不受影响
targetSdkVersion 升级后 application 标签突然不兼容？
从 Android 12（API 31）起，<application></application> 必须显式声明 android:exported，否则安装失败；Android 14（API 34）进一步要求 foreground service 必须声明 android:foregroundServiceType。这些不是可选配置，是 manifest 解析时的校验规则。
错误现象：升级 targetSdkVersion 后编译通过，但安装时报 INSTALL_PARSE_FAILED_MANIFEST_MALFORMED，日志里提示某个 <activity></activity> 缺少 android:exported —— 注意，这个错误和 <application></application> 本身无关，但它会暴露你之前靠默认值蒙混过关的问题。
- 不要依赖旧版默认行为，尤其
android:exported必须每个四大组件单独设 -
android:exported="false"并不等于“安全”，它只表示不接受跨应用 intent；隐式 intent 仍可能被同进程其他组件触发 - 如果用了
<intent-filter></intent-filter>，android:exported必须为 true，否则运行时报SecurityException
application 标签里路径类配置容易写错的位置
像 android:appCategory、android:dataExtractionRules、android:backupAgent 这些属性，值不是字符串字面量，而是资源引用或类名路径，拼错一个字母就导致解析失败或静默失效。
典型问题：android:dataExtractionRules="@xml/data_extraction_rules" 指向的文件若不存在或命名不匹配（比如实际是 @xml/backup_rules），系统不会报错，但备份时直接跳过该规则；android:backupAgent 若写成 .MyBackupAgent 而实际类在子包里（如 com.example.backup.MyBackupAgent），就会抛 NoClassDefFoundError。
- 所有以
@开头的值（如@xml/xxx、@drawable/xxx）必须对应 res 目录下真实存在的资源 - 类名路径必须完整，不能用相对写法；
android:name=".MyApp"是合法的，但android:backupAgent=".MyAgent"很可能出错，建议写全路径 -
android:networkSecurityConfig指向的 xml 文件必须放在res/xml/下，且根节点是<network-security-config></network-security-config>，不是<resources></resources>
多 module 项目中 application 标签的合并逻辑
manifest 合并不是简单覆盖，而是按工具链规则 merge。主 module 的 <application></application> 是 base，library module 的同名属性（如 android:allowBackup）会尝试合并 —— 但冲突时会报 merge error，而不是取后者。
比如主 module 写了 android:allowBackup="true"，library module 写了 android:allowBackup="false"，AS 会直接报错：Attribute allowBackup value=(false) from library is also present at AndroidManifest.xml:xx:yy value=(true)。这不是 bug，是 merge 工具的保护机制。
- 避免在 library module 的 manifest 里设置全局属性，除非明确需要覆盖主工程行为
- 用
tools:replace="android:allowBackup"可强制覆盖，但要清楚后果：主工程的意图被完全忽略 - 真正该由 library 控制的行为（如网络配置），应通过代码初始化（如 OkHttp 初始化）而非 manifest 声明
manifest 里最危险的不是写错什么，而是以为写了就等于生效 —— 很多属性只有在特定 API level、特定设备厂商定制系统、甚至特定安装方式（adb install vs Play Store）下才真正起作用。验证不能只看编译通过，得真机测行为。
