喜欢就关注我们吧!

文 | 白开水

出品 | OSC开源社区(ID:oschina2013)

自 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

拥有超能力的专属机器人,我也想要!

2021-05-14

Babel项目陷入财务困境,尤雨溪力挺负责人

2021-05-13

微软发布新的开源项目,Windows上支持Linux工具eBPF

2021-05-12