我不知道如何解决这个错误，你能帮我吗？
任务“:app:processDebugMainManifest”执行失败。
<块引用>无法使字段私有 final java.lang.String java.io.File.path 可访问：模块 java.base 不会“打开 java.io”到未命名的模块 @203e7cb0
我非常感谢每一个回答。
答案 0 :(得分：0)
说明：您的工具（支持 processDebugMainManifest 任务的代码，我认为是 Android 构建系统）正在尝试用 Java 执行任务，但此任务只是在公共 API 中不可用。 android 的开发者并没有接受不可能按照 android 团队想要的方式在 java 中编写 Android Build 系统，而是意识到 JVM 可以做到这一点，只是没有公共访问点要求它去做。因此，他们决定使用非公共消费部分，因为不这样做他们根本无法完成工作，并且已经接受了维护负担。
不幸的是，OpenJDK 团队正在积极地锁定这些东西，即使通常没有现成的替代品（例如，正确的顺序显然是首先列出常用私有 API 的清单，然后为前 95 名制定合适的替代品% 的使用率，然后然后继续锁定，尽管不像他们选择的那样严厉 - OpenJDK 团队没有这样做）1。 >
这就是此警告的含义：您使用的 Java 版本不再“允许”它。这个 java 版本因为一个可疑的原因破坏了 processDebugMainManifest。可能 pDMM 试图做的任何事情现在在锁定它的 Java 版本中是完全不可能的，因此......
解决方案：
降级您的 Java。
下载免费和开源的 AdoptOpenJDK's OpenJDK8。
特别是在进行 android dev 时，这通常是一个好主意。 Android 与较新的 java 从来没有很好地配合；既没有在语言中引入的功能，也没有添加到核心库中（因为 android 有自己的实现）。 this courtcase 的存在可能无济于事。
[1] 我稍微简化了一点；例如，sun.misc.Unsafe 中有一些 OpenJDK 公开声明有时是必要的方法，并且他们或多或少致力于保持 Unsafe 可用，直到他们为所有此类用途找到足够的替代方案（如果他们有这种态度）对于一些更常用的内部位，社区和 openjdk 团队之间不会有这样的鸿沟）。此外，还有一些常见的“内部 API”用法确实是不合适的，例如广泛使用 sun.misc.BASE64Encoder，没有任何库/工具/应用程序应该使用它，并且一直有替代方案可供使用，而如今，替代方案已融入 JDK 本身：因此，OpenJDK 团队决定有效地消除对 BASE64Encoder 的直接访问以及关闭所有尝试解决缺乏直接访问的问题，这可能是合理的。它是灰色阴影：每当使用私有 API 时，部分责任在于 OpenJDK 没有替代方案，部分责任在于库/工具/应用程序以一种可以的方式设想它的工作方式在不依赖不是为公共使用而设计的内部结构的情况下（很容易）完成。我的印象是，核心 OpenJDK 贡献者在这种分歧上疯狂误判了自己，基本上几乎所有的责任都不是归咎于他们，而是归咎于图书馆建设者，除了“拉你的整个工具/库/应用程序从存在，你不应该写它'。因此，我在这里讨论的是统计数据，但很可能是对这里发生的一切的解释：OpenJDK 正在锁定做这些事情的能力，而没有合理的替代方案，因此 processDebugMainManifest，即使是最最新版本，仍然会导致此错误，如果不重写大量代码并完全改变它对 Android Build 基础架构用户的工作方式，他们将无法修复此错误。
一些见解（包括 OpenJDK 核心贡献者似乎认为责任几乎完全归咎于应用/库/工具）在 this Inside Java podcast 与 Alan Bateman 一起展示。