Android Gradle 的 compileOptions 与 Kotlin jvmTarget 全面理解（含案例）

TL;DR（一句话版）

compileOptions.sourceCompatibility 决定"你可以写哪些 Java 语言特性"。
compileOptions.targetCompatibility 决定"编译出的 class 文件版本（字节码等级）"。
kotlinOptions.jvmTarget 决定"Kotlin 编译到哪个 JVM 字节码版本"。
它们只影响"你编译出的代码和字节码"，不改变"Android 设备上的运行时标准库有哪些 API"。
案例：ByteArrayOutputStream.toString(Charset) 在 Android 运行时不存在，即使用 JDK 11 编译，运行时仍会 NoSuchMethodError。

背景：构建工具链 vs Android 运行时

Android 构建通常使用较新的 JDK（例如 AGP 7.x 要求 JDK 11），但 APK 最终运行在 Android 设备的 ART 上，使用的是 Android 的 libcore/core-oj.jar，它并不等同于桌面 JDK 11/17 的标准库。

因此：

你用什么 JDK 编译 ≠ 设备上就有对应 JDK 的全部 API。
某些桌面 JDK 新增的库方法（例如 ByteArrayOutputStream.toString(Charset)）在 Android 运行时根本就没有。

compileOptions 两个核心配置到底管啥？

在 app/build.gradle 中：

gradle 复制代码

android {
  compileOptions {
    // 允许的 Java 语言特性（语法与编译器层面），例如 lambda、接口默认方法等
    sourceCompatibility = JavaVersion.VERSION_1_8

    // 生成的 class 文件版本（字节码等级），1.8 对应 major version 52
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}

sourceCompatibility：限定你可以使用的"语言级特性"。设置为 1.8，则可以写 Java 8 语法（lambda、方法引用、接口默认方法等）。
targetCompatibility：限定编译器产出的"字节码版本"。设置为 1.8，则编译结果是 major version 52 的 class 文件，D8/R8 可以更好地对其进行 desugar/优化，并在更广泛的 Android 版本上兼容运行。

这种配置本质是"编译约束"，不改变设备上的运行时库内容。

Kotlin 的 jvmTarget 有何不同？

gradle 复制代码

android {
  kotlinOptions {
    jvmTarget = "1.8" // Kotlin 生成的字节码版本
  }
}

kotlinOptions.jvmTarget 控制 Kotlin 编译器产出的 class 文件版本（例如 1.8 → 52）。
对于 Android，推荐保持在 1.8，兼容好且与 Java 8 desugar 配合稳定。

如果你设置为 11/17，理论上 D8 对部分语言特性也能处理，但实战中容易遇到设备兼容差异或工具链要求（具体取决于 AGP/D8 版本）。

为什么"用 JDK 11 编译"也不能让 Android 有新 API？

因为 Android 设备的运行时库是固定的（随系统版本），不是你构建时 JDK 的库。编译器只决定"你的代码长什么样、字节码是什么版本"，而设备上"有哪些类、有哪些方法"是由系统 ROM 的 libcore 决定的。

案例分析：`ByteArrayOutputStream.toString(Charset)` 崩溃

现象：

复制代码

java.lang.NoSuchMethodError: No virtual method toString(Ljava/nio/charset/Charset;)Ljava/lang/String; 
in class Ljava/io/ByteArrayOutputStream; ...

原因：

我们对 EJML 的矩阵做了字符串插值（${matrix}），触发其 toString() 内部使用 ByteArrayOutputStream.toString(Charset)。

注：EJML（Efficient Java Matrix Library）是一款纯 Java 的矩阵/线性代数库，提供易用的 SimpleMatrix 与高性能的 DMatrixRMaj 类型及 SVD/QR/Cholesky 等分解算法，适合在 Android/Java 环境进行小中规模矩阵计算。官网：https://ejml.org
Android 的 ByteArrayOutputStream 没有这个重载，于是运行时抛 NoSuchMethodError。

结论：

这类问题与 编译 JDK 无关，属于 Android 运行时库缺失该方法。
正确修复：绕过这条调用路径（不要调用库的 toString()），自己逐元素格式化输出。

示例修复（Kotlin）：

kotlin 复制代码

private fun formatSimpleMatrix(m: SimpleMatrix?): String {
  if (m == null) return "null"
  val rows = m.numRows()
  val cols = m.numCols()
  val sb = StringBuilder("SimpleMatrix[${rows}x${cols}] {")
  for (r in 0 until rows) {
    if (r > 0) sb.append("; ")
    for (c in 0 until cols) {
      if (c > 0) sb.append(", ")
      sb.append(String.format(Locale.US, "%.6f", m.get(r, c)))
    }
  }
  sb.append("}")
  return sb.toString()
}

常见报错类型与排查思路

NoSuchMethodError：运行时找不到某个方法签名。常见于"库在桌面 JDK 存在、Android 运行时不存在"的情况。
UnsupportedClassVersionError：class 文件版本过高（例如目标是 55/59），设备或 D8 无法加载。解决：降低 targetCompatibility/jvmTarget 或升级 AGP/D8。
NoClassDefFoundError：运行时缺少某个类（依赖未打包或 ABI 不匹配）。解决：检查依赖打包与 ProGuard 混淆配置。
VerifyError：字节码验证失败（方法签名、泛型桥接、继承关系异常等）。解决：检查编译器/混淆、避免非法字节码组合。

推荐 Gradle 配置（Android 项目）

gradle 复制代码

android {
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
  kotlinOptions {
    jvmTarget = "1.8"
  }
}

dependencies {
  // 如需使用 Java 8+ 的部分库 API（如 java.time、Streams），开启核心库 desugar
  // 注意：它无法"修改"Android 内置类以添加新重载方法，只是提供替代实现。
  coreLibraryDesugaring "com.android.tools:desugar_jdk_libs:2.0.3"
}

说明：

coreLibraryDesugaring 提供 java.time 等 API 的替代实现，对旧设备友好；但对 java.io.ByteArrayOutputStream 这类"内置类新增重载"的情况，无法让设备突然拥有新方法。

崩溃调用链详解：EJML SimpleMatrix.toString()

为明确"到底是谁调用了 ByteArrayOutputStream.toString(Charset)"，这里给出精确的调用链与简化代码：

触发点：在 Kotlin/Java 中写 ${rbvMatrix} 或 rbvMatrix.toString()。
调用链：
- String.format/字符串插值 → 调用 SimpleMatrix.toString()（EJML 覆盖的实现）。
- SimpleMatrix.toString() 内部：
  1. 创建 ByteArrayOutputStream baos 与 PrintStream ps；
  2. 调用 MatrixIO.print(ps, matrix, ...) 将矩阵内容按格式写入到 ps（即写入到 baos）；
  3. ps.flush()；
  4. 返回 baos.toString(StandardCharsets.UTF_8)。

简化伪代码（接近 EJML 的实现风格）：

java 复制代码

ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream ps = new PrintStream(baos);
MatrixIO.print(ps, mat /* 逐元素格式化到流 */);
ps.flush();
return baos.toString(java.nio.charset.StandardCharsets.UTF_8); // 问题点

问题根源：Android 的 ByteArrayOutputStream 没有 toString(Charset) 这个重载（桌面 JDK 才有），因此在设备上运行时会抛出 NoSuchMethodError。

关键澄清：

不是"矩阵里某个特殊数据"触发了 toString(Charset)，而是 SimpleMatrix.toString() 的实现路径固定如此；只要你调用 toString()，就会走这条链。
即使矩阵内容为空、全零或任意值，都会一样崩溃（只要走到了该重载）。

我们的修复方式：

不再调用 EJML 的 toString()，而是使用自定义的 formatSimpleMatrix(SimpleMatrix?)，通过 StringBuilder/String.format 逐元素拼接字符串，完全绕过 ByteArrayOutputStream 与其 Charset 重载。

版本选择与兼容建议

大多数应用保持在 Java/Kotlin 1.8 目标更稳妥，Android 工具链支持成熟、设备兼容广泛。
如确需更高字节码版本（11/17），要评估 AGP/D8 支持、设备兼容与依赖库编译版本，避免 UnsupportedClassVersionError。
尽量避免对第三方库对象直接 toString()（尤其是跨平台库），有兼容疑虑就用自定义格式化或最小化输出。

实战 FAQ

用 JDK 11 编译能不能解决 Android 上的 NoSuchMethodError？
- 不能。NoSuchMethodError 是 设备运行时库缺方法，不是编译器问题。
提升 targetCompatibility/jvmTarget 能不能让设备拥有新方法？
- 不能。它只改变你产出的字节码版本，设备运行时库不受影响。
coreLibraryDesugaring 能否修复 ByteArrayOutputStream.toString(Charset)？
- 不行。desugar 提供替代库实现，但不会修改 Android 内置类为其"增加新重载"。
如何快速判断 class 文件版本？
- 用 javap -verbose 看 major version（52=Java 8，55=Java 11）。
如何避免类似问题？
- 避免使用桌面 JDK 专属新 API；对第三方库的字符串输出统一走自定义格式化；在 CI 上跑仪器测试覆盖关键路径。

结语

compileOptions 与 kotlinOptions.jvmTarget 是"编译期开关"，帮助你选择语言特性与字节码版本；但 Android 的运行时库能力由设备决定。理解两者差异，可以少踩不少坑。遇到运行时 API 缺失（NoSuchMethodError），优先考虑绕开调用路径或替换库实现，而不是盲目提高编译 JDK 或字节码目标。

Android Gradle 的 compileOptions 与 Kotlin jvmTarget 全面理解（含案例）

TL;DR（一句话版）

背景：构建工具链 vs Android 运行时

compileOptions 两个核心配置到底管啥？

Kotlin 的 jvmTarget 有何不同？

为什么"用 JDK 11 编译"也不能让 Android 有新 API？

案例分析：ByteArrayOutputStream.toString(Charset) 崩溃

常见报错类型与排查思路

推荐 Gradle 配置（Android 项目）

崩溃调用链详解：EJML SimpleMatrix.toString()

版本选择与兼容建议

实战 FAQ

结语

案例分析：`ByteArrayOutputStream.toString(Charset)` 崩溃