咨询Android Strict Mode已知错误抑制方案：类似lint-baseline的实现

Strict Mode本身并没有官方提供和lint-baseline完全一致的基线机制，但可以通过以下几种自定义方案实现“只让新违规崩溃、忽略已知无法修复错误”的需求：

1. 自定义违规监听回调，过滤已知问题 #

通过设置Strict Mode的penaltyListener（线程策略）或penaltyListener（VM策略），在回调中手动判断当前违规是否属于已知问题，仅对未知违规触发崩溃。

示例代码（Kotlin）： #

// 初始化Strict Mode线程策略
StrictMode.setThreadPolicy(
    StrictMode.ThreadPolicy.Builder()
        .detectAll() // 检测所有线程违规
        .penaltyListener { _, violation ->
            // 检查是否为已知违规
            if (!isKnownViolation(violation)) {
                // 新违规，抛出异常触发崩溃
                throw RuntimeException("Strict Mode 新违规: $violation")
            }
        }
        .build()
)

// 初始化Strict Mode VM策略
StrictMode.setVmPolicy(
    StrictMode.VmPolicy.Builder()
        .detectAll() // 检测所有VM违规
        .penaltyListener { violation ->
            if (!isKnownVmViolation(violation)) {
                throw RuntimeException("Strict Mode VM新违规: $violation")
            }
        }
        .build()
)

// 判断线程违规是否为已知问题
private fun isKnownViolation(violation: StrictMode.Violation): Boolean {
    val stackTrace = violation.stackTrace
    // 存储已知违规的特征：类名、方法名、可选行号
    val knownThreadViolations = listOf(
        Triple("com.example.LegacyUtils", "loadOldData", 123),
        Pair("com.example.OldSdkWrapper", "initSdk")
    )
    return stackTrace.any { element ->
        knownThreadViolations.any { known ->
            element.className == known.first && element.methodName == known.second &&
                    (known !is Triple<*,*,*> || element.lineNumber == known.third)
        }
    }
}

// 判断VM违规是否为已知问题
private fun isKnownVmViolation(violation: StrictMode.VmViolation): Boolean {
    // 类似线程违规的判断逻辑，可根据违规类型（比如LeakedClosableViolation）、栈信息过滤
    return when (violation) {
        is StrictMode.LeakedClosableViolation -> {
            violation.stackTrace.any {
                it.className == "com.example.LeakyManager" && it.methodName == "openResource"
            }
        }
        else -> false
    }
}

2. 自定义注解标记忽略的代码块 #

可以创建一个自定义注解，标记已知违规的方法或代码块，然后在Strict Mode的回调中通过反射检查调用栈中的元素是否带有该注解，从而跳过崩溃。

示例： #

// 自定义忽略注解
@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.FUNCTION)
annotation class SuppressStrictMode

// 在已知违规的方法上添加注解
@SuppressStrictMode
fun legacyOperation() {
    // 会触发Strict Mode违规的旧代码
}

// 在回调中检查注解
private fun isKnownViolation(violation: StrictMode.Violation): Boolean {
    return violation.stackTrace.any { element ->
        try {
            val clazz = Class.forName(element.className)
            val method = clazz.getDeclaredMethod(element.methodName)
            method.isAnnotationPresent(SuppressStrictMode::class.java)
        } catch (e: Exception) {
            false
        }
    }
}

3. 分阶段收集基线后再启用崩溃惩罚 #

先将Strict Mode的惩罚设置为日志输出（penaltyLog()），运行应用收集所有已知违规并记录下来，再将这些记录加入到上述的过滤逻辑中，最后切换为崩溃惩罚（仅对新违规生效）。

内容的提问来源于stack exchange，提问作者gowtham