## Android 平台变更问题

Android 平台变更这次不按普通故障排查稿展开，而是专门盯厂商 ROM 适配、权限回归和灰度放量三条线。真正拖慢升级节奏的通常不是 API 文档，而是不同 ROM 对前台服务、后台启动和权限弹窗的行为差异。如果这三条线没有在灰度前被锁住，Android 平台变更就会在正式量里放大成成批回归。

## 方案

我会先拉一张升级清单，把 targetSdk、通知权限、前台服务类型、隐私弹窗和多 ROM 验证拆给 owner。然后按“先做 smoke case，再做灰度验证，最后做上线前回归”这个顺序推进。这样 Android 平台变更的问题不会混成一句“应该没事”，而是每一项都能拿到验证证据。

## 示例代码

1. 升级清单模型

data class UpgradeChecklist(
    val feature: String,
    val owner: String,
    val risk: String,
    val fallback: String
)

val checklist = listOf(
    UpgradeChecklist("通知权限", "client", "新增拒绝路径", "保留站内信兜底"),
    UpgradeChecklist("前台服务类型", "infra", "任务被系统终止", "拆到 WorkManager")
)

2. 设备侧检查

adb shell device_config list namespace activity_manager
adb shell dumpsys activity service com.example.app/.SyncService

3. 回归结果结构

data class PlatformRegression(
    val rom: String,
    val item: String,
    val passed: Boolean
)

## 注意点

Android 平台变更最怕只在单一机型上验证通过。灰度前至少要拆 Pixel、三星、小米、OPPO 四条验证线，每条只看一个最关键行为：后台恢复、权限弹窗、通知送达、前台服务存活。只要这四类信号清楚，升级风险就会比“全链路都测了一遍”更可控。

## 报错与排查

1. 前台服务被系统拦截

adb shell cmd activity get-uid-state com.example.app
adb shell dumpsys activity services | grep SyncService -n

2. 权限弹窗路径错乱

fun shouldShowPermissionRationale(deniedOnce: Boolean, permanentlyDenied: Boolean): Boolean {
    return deniedOnce && !permanentlyDenied
}

## 可运行片段

1. 最小 smoke 记录

data class PlatformSmokeResult(
    val rom: String,
    val feature: String,
    val passed: Boolean
)

2. 最小执行入口

fun runPlatformSmoke() {
    val result = PlatformSmokeResult("pixel", "notification-permission", true)
    println(result)
}

3. 上线前复核命令

adb shell getprop ro.build.version.release
adb shell dumpsys package com.example.app | grep targetSdk -n
adb logcat -d | findstr /I "ForegroundService permission denied"