rustls-platform-verifier-android

此crate是实际rustls-platform-verifier crate的实现细节。

它不包含任何Rust代码，仅作为主crate在Android平台上执行TLS证书验证所需的辅助Kotlin代码的便捷交付机制。

其他crate不应以任何方式直接依赖此crate，因为它没有任何稳定之处，并且可能在其他地方毫无用处。

详细信息

注意：本节中的所有内容都可能随时更改。可能不会遵循Semver。

为什么？

这是在几个权衡之间找到的最佳平衡点。其中最重要的，按优先级排序如下：

• 自动同步组件版本
• 允许在所有地方应用经过良好测试和公认的cargo依赖关系管理模式
• 为Android用户提供了流畅的开发体验rustls-platform-verifier

首先，分发此组件有哪些替代方案？已知的其他两种是某种形式的源代码分发（在此，将通过crates.io进行）和Maven Central。首先，由于工具链同步要求，源代码分发变得不可行。如果Android组件是作为宿主应用Gradle构建的一部分构建的，那么它就受到Gradle或Android Gradle Plugin不兼容性/要求的影响。在实践中，这意味着此项目和主应用程序之间的AGP版本必须始终匹配。有时这可以工作，但它在每年工具链/SDK升级期间变得具有挑战性/不可行，并且长期不可维护。请注意，这是本节中唯一保留与Cargo的Git依赖关系修补兼容性的选项。

接下来是Maven Central。这是分发公共Android依赖的标准方式。这种方法的两个缺点是版本同步和发布开销。版本同步是最困难的部分：没有一种方法可以知道某个crate的版本，同时不影响构建的Cargo部分或损害功能。因此，我们不需要在运行时做出假设，而是需要进行笨拙且手动地版本计数，并且还要处理额外的错误情况。其次，Maven Central的管理开销不是零，所以在这种小需求的情况下最好尽可能避免。

还有一组更糟糕的选项也值得指出：要求用户在每次更新时手动下载和安装Android组件，这放大了版本同步问题，增加了大量用户开销，并最终直接删除组件。可以使用原始JNI调用进行重写，但这会使得现有实现的大小增加3倍，并且需要大量unsafe代码进行审查和审计。

解决方案

最终的设计旨在避免前两种选项中提到的陷阱。为了构建它，我们依赖于CI和打包脚本在创建发布之前将Android组件构建为预构建的AAR文件。接下来，在仓库内部托管一个磁盘上的Maven仓库。只保留其不变的文件结构进行提交，以避免频繁变动。剩余的部分在打包/发布过程中填充，然后在通过include Cargo.toml指令包含在cargo package之前填充。最后，一旦仓库添加了其工件，包含Maven仓库的crate就会发布到crates.io。然后，主要crate确保在编译Android目标时下载它，通过平台特定的依赖来实现。

在Gradle端，我们包含一个非常小的代码片段，供用户将其包含在他们的settings.gradle文件中，以根据Cargo当前版本自动在磁盘上动态定位本地Maven仓库。该脚本对配置缓存友好，且不会影响性能。当脚本运行时，它会找到cargo-cached下载的crate，并告诉Gradle当它被源到托管应用程序的构建树中时，它可以在那里找到Android组件。

假设Gradle项目配置正确，该慢速（约500毫秒）的脚本在android-release-support crate保持未更改的情况下，只需在每次Gradle同步时运行一次。这是由于之前提到的配置缓存，并确保了与“正常”Maven仓库相当的性能。在版本更新（semver、Git引用等）时，变化将被Gradle按预期检测到，破坏缓存，项目将更新依赖引用到新的AAR文件。

预编译的工件？

对于一些人来说，将预编译的工件与现有的源代码分发一起运输的想法可能看起来不正确或不安全。然而，在这个特定情况下，不考虑运输Kotlin代码不起作用的事实（见上文），有许多原因说明这不是这种情况

• 在Java生态系统中，运输预编译的工件是正常的。Maven Central和其他软件包仓库做同样的事情，并提供.jar下载。
• 不使用Android的人永远不会下载预编译的AAR文件。
• 给定一个相同的编译工具链，工件可以非常容易地重现。
• 这些工件不是本地可执行文件，也不是原始的 .jar 文件，因此它们不会在主机系统上意外执行。

摘要

总的来说，所选的发布方式避免了大多数先前的陷阱，同时仍为 cargo 和 Gradle 用户提供了良好的体验。其一些积极特性包括

• 与 Cargo 的依赖管理完全兼容，包括 Git 补丁[^1]
• 无需版本检查或同步
• 轻松且无害地集成到 Android 应用程序的构建系统中
• 对主要crate维护者的维护成本较低

[^1]：所使用的 Git 引用必须首先构建并提交本地的 Maven 仓库。