Android 6.0 dex2oat执行失败（权限拒绝），非Instant Run相关问题

嘿，结合你给出的所有细节，这个问题确实有点棘手——核心是Android 6.0.X设备上release构建的dex2oat权限拒绝，但debuggable=true就正常，还关联到Multidex从1.0.2升级到1.0.3的变更。我整理了几个排查方向和解决方案思路，你可以逐一尝试：

一、先回退Multidex版本验证根源 #

既然问题是在升级Multidex到1.0.3后出现的，第一步可以临时把Multidex版本回退到1.0.2，重新打release包测试问题设备。如果回退后安装正常，那基本可以锁定是Multidex 1.0.3和Android 6.0 ART的兼容性问题。你可以去查Multidex 1.0.3的官方变更日志，看看有没有针对dex生成逻辑的调整，或者直接给Android官方提交兼容性issue。

二、排查Release构建的签名与对齐差异 #

Debug和Release构建的签名机制完全不同：debug用的是系统默认的调试签名，而release是你自定义的正式签名。Android 6.0的ART对签名后的APK可能有特殊校验逻辑，比如签名算法、签名块的额外信息，都可能影响dex2oat的文件写入权限。你可以试试：

• 用debug签名打包release版本，安装到问题设备看是否正常
• 临时关闭release构建的zipalign对齐，测试是否能解决问题（正常来说release包需要对齐，但可以先验证是否是对齐导致的）

三、针对Android 6.0调整dex编译过滤参数 #

从日志里看到，release构建用的是--compiler-filter=speed，这会触发ART全量编译dex文件，而debug模式下默认是verify-none或者speed-profile，编译量小很多。Android 6.0的ART在全量编译时可能遇到权限或内存瓶颈，你可以尝试给Android 6.0的release构建单独调整编译过滤：
在build.gradle中添加针对API 23（Android 6.0）的配置：

android {
    buildTypes {
        release {
            // 针对Android 6.0设备调整编译过滤
            dexOptions {
                compilerFilter 'verify-none'
            }
        }
    }
}

注：如果这个配置不生效，也可以尝试通过AndroidManifest.xml的android:compilerFilter属性（不过这个属性是API 24+引入的，6.0可能不支持，所以优先用gradle配置）。另外，也可以调整dexOptions的javaMaxHeapSize，比如设置为"1g"，提升构建时的内存分配，避免dex生成不完整。

四、对比APK中dex文件的差异 #

Multidex版本升级后，可能改变了dex文件的拆分逻辑、大小或数量。Android 6.0的ART对过大的dex文件处理可能有问题，你可以对比Multidex 1.0.2和1.0.3生成的APK：

• 查看dex文件的数量（比如classes.dex、classes2.dex等）
• 检查每个dex文件的大小，看是否有单个dex超过阈值
  如果发现某个dex过大，可以调整ProGuard规则，优化代码拆分，减少单个dex的方法数。

五、排查设备dalvik-cache的权限逻辑 #

日志里的Permission denied是关键，说明dex2oat进程无法写入/data/dalvik-cache/arm64/下的对应文件。正常来说，每个应用的dalvik-cache文件属于该应用的UID，应该有权限写入，但debuggable=true时系统可能给了调试应用额外的权限。你可以试试：

• 在问题设备上，通过adb查看/data/dalvik-cache/arm64/目录下对应应用的文件权限，对比debug和release安装后的权限差异
• 尝试用正式的发布签名（比如Google Play App Signing的签名）打包，测试是否能解决权限问题

六、临时禁用Multidex验证（如果可行） #

如果你的应用方法数其实没超过65536的阈值（可以通过./gradlew app:dependencies或者Android Studio的方法数统计工具确认），可以尝试临时禁用Multidex，打release包测试。如果禁用后安装正常，那进一步说明是Multidex和Android 6.0 ART的适配问题。

内容的提问来源于stack exchange，提问作者Ben Von Handorf