自 2019 年以来，Android 团队一直致力于将 Rust 编程语言引入 AOSP（Android Open Source Project），以作为平台原生代码开发的内存安全替代品。近日，谷歌则在一篇博客文章中进一步阐述了关于将 Rust 整合到 AOSP 的更多信息。

博客内容指出，与任何大型项目一样，引入一种新的语言需要仔细考虑。对于 Android 来说，一个重要的方面就是评估如何将 Rust 最好地融入 Android 的构建系统。根据 Android 团队的说法，将 Rust 集成到大型项目中存在许多挑战；例如放弃 Cargo 而直接使用 Rust 编译器 rustc 的可能会存在使组织脱离更广泛的 Rust 社区的风险。 

该团队还表示，当为 Android 开发的 crates 可以使 Rust 社区受益时，他们希望将其作为独立的 crates 发布。并认为，Rust 在 Android 中的成功取决于最大限度地减少 Android 和整个 Rust 社区之间的分歧，并希望 Rust 社区能从 Android 的参与中受益。

Rust 提供 Cargo 作为默认的构建系统和包管理器，收集依赖关系并调用 rustc（Rust 编译器）来构建目标 crate（Rust 包）。而在 Android 中，Soong 则替代了这个角色，并直接调用 rustc。原因在于：

• Cargo 中的 C 语言依赖是独立处理的，而 Soong 已经提供了相关的机制；
• 通过 Soong 直接调用编译器可以提供更多 Android 所需的稳定性和控制力，以支持各种构建配置；
• 独立的构建对于 Android 创建可重复的构建非常重要；
• 增量构建对于保持工程生产力非常重要。

Android 团队的 Ivan Lozano 称，“直接使用 Rust 编译器使我们能够避免这些问题，并且与我们在 AOSP 中编译所有其他代码的方式一致。它提供了对构建过程的最大控制权，并简化了与 Android 现有构建系统的整合。但是，由于 Cargo 的使用在 Rust crate 的生态系统中根深蒂固，避免使用 Cargo 则会带来一些挑战，并影响到许多其他构建系统的决定。”

此外，关于为什么支持 proc_macros，而不支持 build.rs 脚本。该团队则解释称，这是因为 build.rs 代码是作为一次性代码编写的，而 proc_macros 定义了编译器中可重用功能，这对于 Rust 社区可能更有用。且 proc_macros 通常能得到更好的维护和更多的上游审查，在代码审查过程中更容易处理、更容易进入沙盒。

Android 团队还透露，他们计划在不久的将来在 source.android.com 中添加关于如何在 Soong 中定义和使用 Rust 模块的文档。其希望 Android 对 Rust 的支持能与 Rust 生态系统一起继续发展，并希望继续参与有关如何将 Rust 集成到现有构建系统的讨论。

详情可查看：https://security.googleblog.com/2021/05/integrating-rust-into-android-open.html