Android 15 下 CameraX 拍照返回崩溃的适配与边到边兼容实践

一、背景：Android 15 升级带来的两类典型问题

近期在将项目目标版本升级到 Android 15 后，客户端出现了两类比较集中的兼容问题。一类是界面层面的边到边强制适配，原先基于系统栏颜色、固定状态栏高度的布局方式普遍失效；另一类是调用系统相机拍照后返回时发生崩溃，异常堆栈指向 _data 字段不允许被修改。

这两类问题虽然表现不同，但本质都源于 Android 15 在窗口行为、媒体权限以及系统组件交互上收紧了约束。尤其是相机拍照返回的崩溃问题，如果只修崩溃而不理清数据返回链路，后续在相册选择、裁剪、分享等场景中仍可能反复踩坑。

本文将以一次实际的 CameraX 升级过程为主线，结合边到边适配和拍照返回异常两大部分，梳理现象、原因与修复方案，形成一套可以复用的升级检查清单。

二、边到边显示：从可选行为变为强制约束

2.1 行为变化

在 Android 15 设备上，当应用的 targetSdkVersion 大于等于 35 时，系统会强制应用以边到边方式展示内容。状态栏和导航栏不再为应用预留独立区域，窗口内容默认延伸到系统栏后方。

对于 targetSdkVersion 小于 35 的应用，系统通常仍保持传统布局方式，应用内容被限制在状态栏与导航栏之间。因此，升级目标版本后，原本看似正常的页面会在新系统上出现内容顶到状态栏、底部按钮与导航栏重叠等问题。

2.2 旧 API 失效

此前常用于调整系统栏颜色的接口，例如设置导航栏颜色、状态栏颜色的方法，在 Android 15 上逐渐失去实际效果。即使代码中仍然调用这些方法，系统也可能忽略设置，或者仅作为兼容处理，最终仍呈现沉浸式效果。

这就意味着，过去通过“给状态栏设置一个背景色、给导航栏设置一个背景色”来规避适配的思路已经不可靠。更合理的做法是让布局监听窗口 Insets，显式处理内容与系统栏之间的安全区域。

2.3 基础适配示例

在 Activity 初始化阶段，可以先调用边到边相关接口，再设置布局内容：

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    enableEdgeToEdge()
    setContentView(R.layout.activity_main)
    WindowCompat.setDecorFitsSystemWindows(window, false)
    ViewCompat.setOnApplyWindowInsetsListener(rootView) { view, insets ->
        val statusBars = insets.getInsets(WindowInsetsCompat.Type.statusBars())
        val navigationBars = insets.getInsets(WindowInsetsCompat.Type.navigationBars())
        view.setPadding(
            statusBars.left,
            statusBars.top,
            statusBars.right,
            navigationBars.bottom
        )
        insets
    }
}

上述代码的核心思路是：

1. 关闭系统默认的“内容避让系统栏”行为；
2. 由业务侧自行接收窗口 Insets；
3. 根据状态栏和导航栏的实际尺寸设置安全边距。

不过这种方案只适合布局结构简单的页面。对于包含顶部导航栏、底部操作栏、列表首尾项、全屏视频播放等复杂场景，还需要根据 Insets 类型分别处理。

三、CameraX 基础集成链路回顾

在进入崩溃分析之前，先简要回顾 CameraX 的常见拍照调用方式。通常业务侧会通过 ActivityResult 启动系统相机，并在回调中获取返回的图片地址：

private val takePictureLauncher =
    registerForActivityResult(ActivityResultContracts.TakePicture()) { success ->
        if (success) {
            // 读取并展示图片
        } else {
            // 用户取消
        }
    }

调用时传入一个用于保存图片的 Uri：

val uri = createImageUri()
takePictureLauncher.launch(uri)

在 Android 15 设备上，系统相机返回后，应用可能立即崩溃，崩溃信息的关键片段如下：

java.lang.IllegalArgumentException: Mutation of _data is not allowed.

该异常发生在结果分发阶段，说明系统在回传 Activity Result 时，尝试修改某个 MediaStore 记录中的 _data 字段，但被系统拒绝。

四、崩溃原因分析：_data 字段写入限制

4.1 _data 字段的定位

在 MediaStore 中，_data 字段用于表示媒体文件在设备文件系统中的实际路径。过去不少应用会直接读取或修改这个字段，例如通过路径拼出图片地址，或者移动文件后更新记录。

但随着新版系统对隐私和存储访问权限的收紧，系统逐渐限制应用对 _data 字段的直接操作。尤其是通过系统相机、系统相册等组件生成或返回的媒体记录，已经不再允许应用侧随意修改 _data。

4.2 崩溃链路

当应用通过 ActivityResultContracts.TakePicture 启动系统相机时，系统会向 MediaStore 插入一条图片记录，并把对应的 Uri 交给相机应用写入。相机应用完成拍摄后，系统需要更新这条媒体记录。

在 Android 15 的某些设备与系统版本上，如果应用在创建图片 Uri 时使用了过时的创建方式，或者使用了不符合新规范的 ContentValues，系统相机返回后可能尝试通过 _data 字段回写路径，最终触发 Mutation of _data is not allowed。

换句话说，崩溃并不一定发生在业务侧自己的数据库操作中，而可能发生在系统相机结果回传的系统中。

4.3 与 URi 创建方式的关联

高版本系统更推荐使用 MediaStore.Images.Media.getContentUri 或 MediaStore.Images.Media.EXTERNAL_CONTENT_URI 配合 ContentResolver.insert 创建图片记录，而不是直接使用 FileProvider 或私有目录路径生成 Uri。

其中 ActivityResultContracts.TakePicture 对输入 Uri 的要求较为明确：它应当是一个可由外部相机应用写入的 content:// 地址。如果传入的是 file:// 地址，或者无法被系统相机正确写入的 Uri，在旧版本中可能只是拍照失败，但在新版本中则可能在结果处理阶段出现异常。

五、修复方案：规范图片 Uri 创建与结果处理

5.1 使用 MediaStore 创建图片记录

推荐在调用相机前，通过 MediaStore 创建一条新的图片记录，并将返回的 Uri 传给相机应用：

private fun createImageUri(): Uri? {
    val resolver = contentResolver
    val values = ContentValues().apply {
        put(MediaStore.Images.Media.DISPLAY_NAME, "IMG_${System.currentTimeMillis()}.jpg")
        put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg")
    }
    return resolver.insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, values)
}

这种方式的好处包括：

• 生成的 Uri 符合系统相机可写入的规范；
• 图片元数据由系统管理，不需要业务侧维护绝对路径；
• 减少对 _data 字段的直接依赖；
• 与 Android 10 及以上版本的分区存储策略一致。

5.2 避免在结果回调中立即修改媒体记录

部分业务在拍照返回后会立即修改图片名称、路径或其他字段。建议将这类操作延后，或优先使用 ContentValues 更新非 _data 字段，例如 DISPLAY_NAME、DATE_TAKEN 等。

对于确实需要移动文件或重命名的场景，应使用 ContentResolver 的更新接口，而不是直接修改 _data，并避免在多线程中并发操作同一条媒体记录。

5.3 对拍照结果做保护性处理

即使创建 Uri 的方式正确，也可能因为设备差异、系统组件实现不同而出现偶发异常。建议在结果回调中增加保护逻辑：

private val takePictureLauncher =
    registerForActivityResult(ActivityResultContracts.TakePicture()) { success ->
        try {
            if (success) {
                handleCapturedImage()
            }
        } catch (e: Exception) {
            // 记录异常，避免将系统返回阶段的错误直接抛给用户
        }
    }

不过需要注意，如果崩溃发生在结果分发阶段，ActivityResult 回调中的 try-catch 可能无法完全捕获，因为在结果投递到回调之前，系统可能已经抛出异常。因此根本方案仍然是保证输入 Uri 和媒体记录创建方式符合规范。

六、边到边适配的进一步细化

6.1 根布局 Padding 与子组件 Padding 的区别

很多页面会在根布局直接设置 Padding。但如果页面内部存在可滑动列表，简单的根布局 Padding 可能导致列表滚动到顶部时标题与状态栏重叠，滚动到底部时底部按钮与导航栏重叠。

更稳妥的方式是：

• 顶部安全区域交给顶部栏或内容头部处理；
• 底部安全区域交给底部操作栏或列表尾部处理；
• 对于全屏页面，分别处理状态栏 Insets 与导航栏 Insets。

6.2 键盘弹出与 Insets 重叠

当输入框弹出时，系统会分发 IME Insets。如果页面只处理了状态栏和导航栏，可能会忽略键盘高度，导致输入框被遮挡。

建议在 setOnApplyWindowInsetsListener 中同时处理系统栏与 IME：

ViewCompat.setOnApplyWindowInsetsListener(rootView) { view, insets ->
    val statusBars = insets.getInsets(WindowInsetsCompat.Type.statusBars())
    val navigationBars = insets.getInsets(WindowInsetsCompat.Type.navigationBars())
    val ime = insets.getInsets(WindowInsetsCompat.Type.ime())
    view.setPadding(
        statusBars.left,
        statusBars.top,
        statusBars.right,
        maxOf(navigationBars.bottom, ime.bottom)
    )
    insets
}

这样可以在键盘弹出与收起时保持布局稳定。

七、升级检查清单

结合本次 Android 15 升级经验，建议在发布前逐项检查以下内容：

1. targetSdkVersion 是否已经适配边到边强制行为；
2. 所有页面是否移除对状态栏、导航栏固定高度的计算；
3. 是否仍依赖系统栏颜色设置接口来维持视觉样式；
4. 页面根布局是否能够正确处理状态栏、导航栏和 IME Insets；
5. 调用系统相机时，是否使用 MediaStore 创建图片 Uri；
6. 是否在媒体结果处理中直接读取或修改 _data 字段；
7. 是否对 ActivityResult 回调中的异常具有兜底方案；
8. 是否在真机 Android 15 设备上覆盖了拍照、相册、裁剪等关键路径。

八、总结

Android 15 的升级并不仅仅是版本号变化，它同时带来了窗口行为和媒体记录管理方式的明显调整。边到边显示强调应用对 Insets 的主动处理，而拍照返回崩溃则提醒开发者必须遵循新的媒体 Uri 创建与更新规范。

与其逐点修补，不如将边到边适配、系统相机交互、媒体记录更新作为升级前的基础治理项。建立统一的 Insets 处理工具和图片 Uri 创建入口，可以显著减少页面级和业务级重复适配。对于已经出现 _data 突变异常的模块，应优先排查图片 Uri 来源，并从数据创建方式上完成根治。