译文 | 关于 Android Q 背后的新变化，我们和谷歌开发团队聊了聊
编注：
本文翻译自 ArsTechnica（本文简称 Ars）的采访文章 《 Android Q(&A): Android Engineers take us on a deep dive of Android Q 》，少数派已获得原文作者 Ron Amadeo 授权。
在这次访谈中，ArsTechnica 与 Android 开发团队围绕 Android Q 探讨了不少我们平时在媒体报道或更新日志中看不到或是注意不到的新变化，包括：
- 为了更即时地推送安全更新补丁而衍生出的 Project Mainline。 Android 系统因此进一步「模块化」，这对开发者、用户和 OEM 厂商来说意味着什么？
- 通过双系统启动的方式来进行动态系统升级。 借助通用系统镜像（GSI）和一种类似虚拟机的技术，今后我们可以将新版本系统以子系统的方式进行启动，体验新功能的同时不干扰当前正在使用的稳定版操作系统！
- 自适应休眠、桌面模式这些神秘的新功能将何去何从。
- 最高可获得六年支持的 Linux 内核是怎样挑选出来的 ， 未来又将如何影响同样使用 Linux 内核的 Android 系统？
在这篇译文中，ArsTechnica 的提问我们将以 绿色粗体 字体呈现，而绿色方框内的内容则代表他们针对采访内容的背景知识补充。
文章较长，如果你想直接阅读感兴趣的内容可以使用目录进行跳转。
作为每年 Google I/O 开发者大会期间的一项传统，同时也为了更好地了解 Google 推出的最新操作系统，Ars 最近又和几位打造 Android 的工程师一起坐下来聊了聊。
今年我们访谈的话题主要围绕 Android Q 以及包含其中的心血之作 Project Mainline。Project Mainline 的目标是让 Google 甚至是 OEM 在不推送系统更新的情况下直接升级系统的核心组件，这个想法听起来并非易事，事实上也的确充满了挑战性。
所以在这一次的访谈中，我们请到了这一环节的常客、 Android 工程部副总裁戴夫·博尔克（Dave Burke），作为 Android 团队的领头人，他简直是 Android 操作系统的活百科全书，无论我们提出的问题有多么刁钻，他总能给出独到的见解；以及连续两年参加到这一活动的伊利安·马尔切夫（Iliyan Malchev），他不仅是 Android 项目的首席工程师、Project Treble 的主管，也是一位 Linux 整合全才。
为了对 Android 的新内容进行深度而透彻地剖析，我们还请到了安瓦尔·古罗姆（Anwar Ghuloum），他是 Android 开发的资深总监，同时也是 Project Mainline 的领头人。从这一次 I/O 大会的分会场主题就能看出这个新功能有多受欢迎：「Android 更新的下一次跃进」——Project Mainline 很快就成为了本次 I/O 大会最为轰动的新闻。
准备好迎接一场详尽的 Android Q&A 吧——不过在此之前，我们还是得先了解一下 Project Mainline 的相关背景知识。
Project Mainline：将 Android 拆开来更新
通过拆分 Android 系统的方式来降低系统升级的难度，近年 Google 在这件事情上的努力可以说是有目共睹。
在之前的 Android 版本中， Google 将 Google 应用和系统核心应用迁移到了 Play 应用商店，借此更加方便地向用户推送新功能；整合、接管了不少 API 接口的 Google Play 也随之登陆了应用商店，让应用开发者也能更快地用上最新的 API 接口进行开发测试。
在之后的 Android 8.0 中，Google 则带来了 Project Treble——它将软件操作系统和底层硬件支持剥离开来，使得系统升级更加容易。
关联阅读： Project Treble 是什么，又将为 Android 带来怎样的改变？
这种模块化的处理方式在 Android Q 上呈现出的新形式就是 Project Mainline。和上面提到的做法类似，Project Mainline 把那些关乎系统运行的核心组件模块化并交由 Play 商店负责更新，这些组件与表层应用相比更加关键，都是堪称「重量级」的系统功能组件，如媒体框架、ART 运行时等等。
从传统意义上来讲，Play 商店只分发 APK 格式的应用（也就是我们所熟知的「安装包」）。而大多数 Project Mainline 系统组件模块无法使用这种格式进行打包：APK 是面向软件系统和用户级别设计的，会受到诸如权限、开机启动优先级等等限制。
因此 Google 提出了一种比 APK 更为强大的文件格式——APEX，APEX 赋予系统核心组件模块 root 级别的权限，让它们在开机过程中拥有非常高的优先级，这样一来 Google 和各 OEM 厂商就能以组件的方式升级系统底层不同的核心区域。
系统和用户应用采用 APK 格式进行分发，系统核心组件则通过 APEX 格式的模块进行更新升级。通过下面这份表格，我们就可以看到 Android Q 中第一批以 APEX 格式进行打包的系统组件：
我们有望在未来看到 Project Mainline 涵盖更多的 Android 系统组件，而在目前的 Android Q 当中，Google 更为关注 Android 系统的连续性、安全性和隐私。在我们的访谈正式开始之前， Google 已经给了我们上面那张 Project Mainline 组件的表格，详细阐述了哪些部件正被模块化，以及哪些系统组件 Google 建议进行模块化。这也就引出了我们的第一个问题。
以下内容就是本次访谈的文字记录，出于可读性考虑我们对极少内容作了些许修改，为了提供一个更加全面的视角，我们也用斜体字（译文中为绿色方框内字体）为相关话题做了一些背景介绍。
Ars：我们看到这张 Project Mainline 的表格中给出了一系列系统组件名称，有的是推荐进行模块化，有的则是强制要求。你们是如何决断这种划分标准的呢？
安瓦尔·古罗姆（Project Mainline 主管） ：理想情况下，我们的目标是让表格中所有的组件都被强制模块化。不过现阶段我们的做法还是和此前类似：先和我们的设备生产商沟通，告诉他们「嘿，我们在做这个，来和我们一起做吧」，然后他们会提交一部分代码，表明正在着手开发哪些新功能。
Android 系统底层中能够满足这些新功能需求的部分，就是我们定性为强制要求的部分；如果模块化之后的系统组件和这些厂商期望功能之间存在较大的适配和兼容性难度，则将其定性为可选部分。可选部分在下一个 Android 系统版本更新中才会改为强制。
通过这样的方式，我们就有足够的时间和空间来平衡各方利益，我们不想折损厂商自身的设备使用体验，因而在推行这些模块化举措的过程中，我们希望厂商也能够一起参与进来。
戴夫·博尔克（开发副总监） ：我认为这项工作的重要组成部分其实就是和这些合作伙伴达成代码的上游同步（upstreaming）。
我说的「合作伙伴」指的当然就是 Android 设备制造商，在他们向自己的设备中添加代码改动的时候，我们希望这些改动能够全都上传到 Android 系统的主分支当中，以此实现 Google 和设备制造商之间的一致性。这就需要花费点时间了。
古罗姆： 是啊，我们其实已经完成了不少上游同步工作，还挺难以置信的。对于一部分软件包来说我们去年完成上游同步的代码要比之前 10 年的还要多。
博尔克： （对我们当前正在做的事情而言）上游同步的确很重要。
在我看看来这里有一个非常重要的背景信息：Project Mainline 意味着 Google 正尝试从 OEM（也就是设备生产商）那里收回部分系统核心代码的最终所有权。而在设备生产厂商放弃掉这部分代码最终所有权的同时，Google 会确保 OEM 厂商此前常常所做的定制工作在今后的 AOSP 代码中变得可用且通用。
你可以试想一下这样的场景： Google 遍历整个生态系统，斟酌每一个模块，问各个厂商「 你们需要对 DNS 解析的方式作出修改吗？」这样的问题。如果厂商不需要对 DNS 解析进行定制，那么 Google 就会接管这部分功能并将其强制模块化（方便后续更新）；如果厂商需要进行定制，Google 则会尝试将这些厂商想定制的功能通过上游同步（upstreaming）的方式合并进入 AOSP 主分支，最终让 AOSP 直接提供针对这类定制的、可用且通用的选择。
对厂商而言，上游同步到 AOSP 主分支中的代码越多，进行 Android 系统版本升级时需要他们自行跟进的代码就越少，整个流程相应的也会更加容易。
古罗姆： 我们向负责这部分的团队成员解释说，使用 Mainline 模块的前提是每个月都会有一次更新，因此我们必须与合作伙伴积极合作、共同研发同时一起规划产品路线。我们组里的人觉得这样做压力挺大，但都还挺激动的。
Ars：所以 Mainline 组件每月升级一次——这就是你们的目标吗？
古罗姆： 这是我们已经习惯了的更新节奏，也差不多是由安全更新的周期所决定的，因为有些组件和安全性关系十分紧密。对主要由编解码器（codec）和提取器（extractor）组成的媒体组件而言更是如此——把它做成模块的一个原因就在于，回顾去年的安全漏洞，我们发现接近 40% 的安全更新都与这部分功能息息相关。
所以我们自然会想：「何不索性把这些内容推送到整个生态，直接为 OEM 厂商省去自行测试、发布和更新这些安全补丁的负担？」
Android 的媒体播放引擎又叫 Stagefright，它需要从互联网载入各种繁复文件，而如何安全地执行这个流程一直以来也是一个不小的挑战。很多人第一次听说 Stagefright 或许是在 2015 年的新闻里，那时人们在这个媒体播放引擎里发现了一系列远程代码执行漏洞。古罗姆所说的月度升级便是从那个时候开始的，对媒体框架安全性的加固也持续至今现阶段 Google 每个月都会推出 AOSP 安全更新并把它们提交给 OEM，这种方案并不完美。不是每一台手机都支持每月的安全更新，也不是每一台手机都能及时收到这些安全更新，大多数手机也只有两年的安全更新维护周期。
就如同古罗姆所说，Project Mainline 不仅让 Google 接过了测试、整合和推送更新的重任，它也能让 Google 直接向整个 Android 生态系统（而不仅仅是个别旗舰手机）推送漏洞修复更新。当然前提是 Android Q 得到普及。
博尔克： 还有一件事，我们经常听到开发者抱怨说为什么我们不能让 Android 开发者的日子变得更好过一点。这种声音最为常见的根源之一，就是系统不同组件之间行为差异导致的「碎片化」问题，即便是同一个 OEM 厂商的不同机型之间也存在这个问题。媒体框架就是他们常常用到的一个例子。
所以上面提到的这种「连续性」做得越好，开发者需要面对的错误排查工作量也就越少；对应用本身来说自然也会提高应用质量，让用户也用得舒心。
古罗姆： 我昨天还管这个叫「bug 连续性」呢。
博尔克： （笑）「bug 连续性」！是这样的，没错。
古罗姆： 有这么一个叫做「ANGLE」的模块，简单来说就是在 Vulkan 上执行 OpenGL。现阶段这个模块对 OEM 厂商来说是必须强制性兼容的，但开发者可以根据需求选择是否使用。这样做其实也是向 Vulkan 投入更多的支持，毕竟它很快就会实装到设备上。
构建一个连续性的图形 API 实例，并不是说我们要以此根除 bug（因为这谁都做不到）——而是为了游戏开发者：虽然他们习惯了在 bug 中挣扎，但五花八门的 bug 和各色各样的驱动处理起来真的特别痛苦。而我们我们可以让这一过程更加连贯。
博尔克： 从另一个角度出发，这件事其实和养成好的卫生习惯有点类似。
拿今年 4 月 GPS 重置事件为例，有些飞机没办法起飞，就是因为时钟重置之后它们不知所措了。软件系统中这类事情在所难免，所以你会想让它们有自我升级的能力，比如那些非常底层的东西——Conscrypt 安全库 、SSL 库、TLS，这些都是可以升级的。因此类比过来这个领域中，如果设备上的 TLS 证书过期或者证书提供商忽然不干了，我们是可以进行灵活地自我修复的。
古罗姆： 那些 BoringSSL bug 也同样适用。
博尔克： 哈，你说得太对了。它们是系统里无趣却很重要的部件。
伊利安·马尔切夫（Project Treble 主管）： 几年前，在 Bionic（作者注：Android 的基本 C 程序库）中有一个由我们合作伙伴引入的 bug，他把符号表搞错了，所以 trade 函数会无规律地出错，其输出值有可能完全不靠谱。而这样的东西在推送前其实很难注意到的。
古罗姆： 但开发者不得不在接下来几年中试着适应它——毕竟这个问题还没有被修复，包括我们的自家应用也必须用同样的方法来解决这个问题。这简直就是杂乱无章的面条式代码。
Ars：那么 Android Q Beta 用户之前有没有收到过测试更新呢？
古罗姆： 有的——其实我们早在 Beta 2 的时候就进行过测试推送了。Reddit 上有不少人注意到了这件事。
Ars：好吧，原来如此。
古罗姆： 没错，我们在推送一些用于测试的更新，很多用户的设备重启也是因此造成的。
事实上我们只会在 Beta 测试阶段这样做。在 Android Q 正式推送后，我们就不会用这样的方式重启用户的设备了，所有的重启行为都仅限用户手动操作。
我们的统计数字表明，几周之后安装了更新的用户数量便达到了一个合理的饱和状态。另外，我们还有每月安全更新，所以每个月用户会至少重启一次。因此你可以这样理解：我们不想把用户体验强加给用户，如果有正在等待安装的安全更新，我们会等待用户手动重启。
Ars：好的，你觉得这就是最终的形态吗——类似一个安静的后台更新，不太可见那种？
古罗姆： 是的。
博尔克： 关于 Mainline 在博客文章和其他讨论中有一点可能没怎么提到，这算得上是至今为止我们在操作系统软件开发上最为根本的转变了。
Android 是这样运作的：首先我们建立一个参考标准，或者像现在这样做一个完整的设备，也就是大家所熟知的 Android 操作系统和 Pixel 手机；然后我们将这些代码进行开源，诸如一加这样的合作伙伴接着就会从我们手中拿过这些开源的代码去生产他们自己的设备。其他相对比较复杂的细枝末节都是在这之后才发生的。
而在 Mainline 这样的模式之下，Android 开发小组不仅有一套通用的代码，我们 Android 开发团队还将负责对其进行散播，因此现在我们直接对每一台 Android 设备上的这些通用代码负责。所以要是今后一加手机上出现了一个 bug，负责解决这个 bug 的人很有可能就是我们 Android 开发团队自己。那个 bug 会被直接反馈给我们，由我们进行修复和二次推送。
为了使这一模式更加高效，我们的自动化测试过程必须全面升级，也就是所谓的提高「开发生产力」。我们需要加强远程数据的收集、建立回滚保护系统、设置检查点（checkpoint）、启用 Canary 测试等等。
整个 Android 系统的软件开发流程都因此而改变。这也正是我们这次只启用了一组强制性模块的原因：我们需要对这套工作流程进行检验，如果没问题再将其进行扩张和推广。
Ars：看来在你们的预想中，Project Mainline 的规模会不断扩大。
博尔克： 嗯，我觉得是这样的。但其实也不好说，因为我们都知道，Android 是一个开源项目，我们只是其中一份子，于是我们必须和我们的合作伙伴合作，以求对所有人都有意义。
但确实，Project Mainline 可以让我们做得更好。
Ars：我有一点想问的，因为我看 APEX 文档中提到了 ART（Android RunTime）和硬件抽象层（HAL），但这两部分还没成为 Mainline 模块。
古罗姆： 其实，如果你去 Pixel 3 的系统镜像里面找一找，就会看到 ART 是和 Libcore 一起封装成一个 Mainline 模块的。我记得应该是在 Beta 3 中我们就把 Libcore 和 Bionic 做成了 APEX，但在 Android Q 这个阶段我们并不打算对其进行升级。
（行话译白话：Libcore 是许多 ART 和 Java 组件的所在；Bionic 是 Android C 的标准库。）
Ars：哦，是这样——我确实是在最新的推送里看到了一个「APEX」文件夹。
博尔克： 我们还是深信让它开源才是正道。
我们相信各方要勤加合作才能让生态蓬勃发展，在这个过程中，不同的设备制造商依然可以做到让自家的产品独具特色。所以很多时候我们必须得权衡各方利益。
然而对那些 Android 系统中厂商不需要进行定制的部分，比如说 Conscrypt 安全库，将其做成模块可以让设备更加安全，减少 bug，同时简化开发工作。好处是显而易见的。
古罗姆： 关于 OEM 定制有一件事很有意思：我们挑选的这些模块化部分要么是与安全、隐私紧密相关的，要么就是 OEM 厂商都不怎么愿意定制的。但媒体框架是个例外，因为制造商们往往也会定制自己的媒体插件。
所以这是唯一一个我们允许合作伙伴推送他们自己的 APEX 包的领域，也就是在常规的媒体组件 APEX 之外再推送 APEX 以扩展功能。当然我们未来还会对这方面进行深入研究的。
博尔克： 对，我们现在是用扩展程序的方式，就是一个通用的核心加上实现功能的模块。
Ars：所以没准会有「三星媒体」这样的模块，用来实现其他的功能？
博尔克： 是的，没准厂商会愿意推送 Dolby Vision，或者 Dolby Atmos 这样的模块。
古罗姆： 或者其他的我们不支持的编解码器什么的。
Ars：所以这就是让厂商采用 AOSP 的通用版本，再在上面加点他们自己的特色吗？
古罗姆： 挺有意思的，我们朝着这个方向的努力还真的越来越多了。
看看我们去年是怎么做自适应性电池这个功能的其实大概就能明白：我们把一些系统 API 和一个可交互的 AI 模型组合起来，让这个功能可以大致预测用户接下来会运行什么应用。如果 OEM 厂商想要把这部分功能整个换掉，他们完全不用将这些东西完全拿掉然后将代码重写一遍——选择现成的界面和接口，然后以此为基础附加自己的功能就好了。
我们会继续朝这个方向发展的。
博尔克： 我觉得我们应该给这种软件研发方式起个名字。
二十年前，人们写好软件之后封装到 CD-ROM，派发出去，之后可能还得发布个服务更新包。而在现在这种模式下，我们把软件推广到大多数用户，靠的全都是远程数据的收集。开启 Canary 测试、发布新版本、出错了再回滚、迅速改进、频繁升级……测试必须一丝不苟，这样你才不会原地踏步。
应该给这种研发方式起个名字的，就叫「现代软件研发」好了。
古罗姆： 「渐进式」这词怎么样？
博尔克： 不错！那就叫「渐进式软件研发」吧。这种方法真的是独一无二：你看看其他的操作系统，他们要是在视频通话中出了个 bug，他们没准要推送一整个操作系统，对吧？那就是「不渐进」的典型。
但如果从整体上来看 Android，你会发现许多部件已经可以独立完成升级了。 Google App 升级就十分频繁， Google Play 服务也是这样。对我们来说，这算是一种自然适应的过程。
APEX 其实是「Android Pony Express」的缩写——官方文档里面就是这么写的，我发誓。你肯定想知道这背后的故事吧！
Ars：所以说，Mainline 所需要的条件是怎样的？所有出厂搭载 Android Q 的手机都必须支持吗？
古罗姆： 是的，所有出厂预装 Android Q 的手机都必须支持。另外，对于那些升级到 Android Q 的设备来说，有一小部分模块是要求支持的，你应该想知道为什么吧。
Ars：当然啦！
古罗姆： 对于那些升级到 Q 的设备来说有两项必须要满足，分别是 ExtServices 和 Permissions Controller，因为它们已经被 Google 签过名，分发到合作伙伴那里作为他们系统的一部分了。
所以我们现在就是对它们做一个更新。
给应用程序签名是分发过程之前的最后一步，古罗姆说「 Google 已经给这两个程序包签过名」，就是说 OEM 无法再对这两个程序包做出改动了。之前，制造商会原封不动地将这些程序包放进他们的增量更新（OTA）中，而从这个角度看，把这部分放到 Google Play 商店确实更为合理。
Ars：所以，ExtServices 里面有什么？我问起是因为几年前我们曾写过有关的文章……
博尔克： 是呀，我还记得呢。
Ars：好像也没有什么变化呀。
古罗姆： 要是说得简单一点，这是一堆我们用于更新的常驻系统进程。明白一点说的话，这里有一些隐私相关的东西我们需要升级，修 bug、优化、策略变更等等。这里面也有一点关于自动填充区域检测的东西。还有一些可升级的 Mainline 程序，比如说设备上的 Mainline 监测程序。这些东西其实都在 ExtServices 里面。
Ars：你们最终决定这样一个复杂的升级清单是为什么呢？
古罗姆： 我们想把那些细碎的却又要常驻后台的东西放在一起，它们不和用户直接交互，也不占用太多内存。这就是我们 ExtServices 的真正用途，它设计之初便被用来存放小东西，比如一些我们可以优化的的算法。
Ars：Mainline 不会对低内存设备提供支持。为什么会这样呢？
古罗姆： 其实不在于内存，而是存储空间。许多低内存设备，尤其是 512MB，1GB 内存的设备的存储空间一般来说都特别紧张。
博尔克： APEX 模块是需要占用 Data 分区的，升级一个系统模块其实就是在复制文件。
Ars：就像是升级 APK 一样。
古罗姆： 我们会想办法修复这个缺陷的，但现在它还只处在一个实用的想法阶段。
博尔克： 我有个问题。「Android 小马专递」这个名字是谁起的？
戴夫·博尔克开始接管访谈问他自己的问题了！APEX 其实是「Android 小马专递」（Android Pony Express）的缩写——官方文档里面就是这么写的。我发誓你肯定想知道这背后的故事吧！
马尔切夫： 我可以告诉你。我可以把当时所做的修改的链接给你发过去，好让你看看是我想出了这个如此好听的名字。我们本来要叫「NPK」，就是「原生程序包」的意思（Native PacKage）
博尔克： 但是它也包括 Jar 啊。
马尔切夫： 正是这样。所以，黛安·哈克伯恩（Dianne Hackborn），Android 工程师之一，说「这个名字和 APK 太像了，我觉得不行。」然后我们开始东聊西扯，我说，就叫 APEX 吧，「Android 小马专递」的意思。
古罗姆： 你说出 APEX 的时候，大家都表示「行吧，那就这个吧。」然后讨论就停止了。
博尔克： 挺不错的。
马尔切夫： 所以说，这还是个「反向缩略语」？（译注：缩略语（acronym）是将较长单词取其首字母并形成新单词的过程，例如 SWAT = Special Weapons And Tatics；反向缩略语则反其道而行之。）
还有个没什么意思的叫「Android 移动交换」，但不如「Android 小马快递」好听。
博尔克： 「Android 小马快递」好多了。
古罗姆： 有意思多了。
博尔克： 我们得多起一些这样的名字。
官方支持双系统启动，无痛体验新系统
摸清与 Project Mainline 有关的一切之后，我们转而讨论起了 Google I/O 大会上其他有意思的 Android 项目。在 Android Sandbox 展区中，展示了一个之前从未公开过的 Android Q 功能，叫做「动态系统升级」。这是一个 Android 上的双系统启动方案，可以让用户通过简单的重启来从一个 Android 系统切换到另外一个 Android 系统。对于开发者，设备制造商、第三方开发者以及那些想要快速切换到新版或旧版系统的用户来说，这或许会成为一个很有意思的功能。
这个功能似乎也和 Project Treble 有关。I/O 大会上试验用的样机可以在一个 Android 的零售版和一个常规系统映像（Generic System Image, GSI）之间进行切换。在之前版本的 Android 中，Android 被处理为一个嵌入式系统，也就是操作系统和硬件支持库融合为一个简单的镜像。Project Treble 将二者分开，而这种方案的终极形式就是 GSI，一个「通用」的 Android，可以在任何有 Project Treble 的手机上运行。有了 GSI，Android 硬件支持库的工作方式更像是非嵌入式系统，比如 Windows 或者桌面版 Linux，只需构建一份系统就可以在许多设备上运行。
在 Android 8.0 Oreo 时代，支持 Project Treble 且能以 GSI 方式启动就已经是 Android 兼容性的一项要求了。 Google 甚至还放出了一份 GSI 版本的 Android Q 测试版。把这一项功能和双系统启动相结合，明年等到 Android R 测试版推出的时候，你很有可能不用抹除设备，只是做一个双系统启动就好了。
因为 Project Treble 的领头人伊利安·马尔切夫正好也在我这三个人的访谈组里面，我觉得我可以问到一些关于这个双系统项目的确切信息。
Ars：所以，这个「实时重启」功能是怎么样的？首先它到底是「动态 Android 系统」还是「动态系统升级」？我在四处询问的过程中听到好几个不同的名字了。
马尔切夫： 一开始我们叫它「实时镜像」或者「实时启动」，因为这个系统的第一个版本其实是把一个通用系统镜像放在内存里，所以它模仿了我们从 Linux Live CD 启动时的操作。但安全小组随后让我们在 10 月和 11 月把它彻底重写了。重写之后确实比之前好了。
博尔克： 安全小组「逼他们重写」——这有点像是 Android 团队内部的工作日常（大笑）。我们的安全小组十分优秀，他们真的很棒很棒，Android 因为他们而变得更加安全。
马尔切夫： 抱歉打断，所以在「等待安全评测反馈」期间，我们重写了所有代码，结果第二版要好得多。我们将其这个双系统固化在了用户数据镜像之上，所以也就不能再叫它「实时」了。现在我们管它叫「Android 随取」（Android on tap）。
Ars：这个名字我也听说过。
（Google 的人是不是不太会起名字啊）
Ars：好的，我明白了。我记得沙箱演示 UI 上面的名字就是这么说的。所以，他的工作原理是怎样的，它会被挂载到一个额外的分区上吗？
马尔切夫： 不，其实发布 Android Q 的另一个意义在于借助动态分区来让升级系统这件事情变得更加容易。虽然和我们现在讨论的话题不相关，但在这些特性上我们其实使用了相同的机制：动态分区允许通过 OTA 调整分区的大小，而不必负担搞乱分区表而无法正常启动的风险。
现在想起来，在采访的时候没有问这个问题让我觉得有些后悔：因为通过改变分区大小来使升级更容易，这对存储空间较小的设备而言是一件好事。一部 Android 手机出厂自带两个主分区：包含出厂系统、只可以通过 OTA 更新（over the air 更新，也就是系统更新）更改的「系统」分区，还有一个储存用户文件的「Data」分区。这两个分区的容量是在出厂前就是固定好的，这对于存储空间足够的设备来说自然不成问题，但如果是只有 8GB 的 Android Go 机型的话，想要给用户足够的存储空间，又要给系统分区分出足够的空间以进行未来的系统更新就变成了一个棘手的问题。
拥有可调整大小的分区意味着制造商不必为预留空间接收更新大伤脑筋。他们可以尽可能地给用户分配空间，然后再按需进行调整。
马尔切夫： 所以，这背后的实现方法是：我们从存储上收集存储区块，并将其组合成为一个逻辑分区。在「动态系统升级」中用到的也是同样的方法， 我们在 /data 分区下创建了两个文件。
博尔克： 其中一个是给系统镜像的，另外一个给用户数据，所以有点像虚拟分区。
马尔切夫： 对的，一个给 system，一个给 data，二者的大小可以自由调整。我们会找出在这两个文件背后的存储区块，在这些存储区块的基础之上，用前面提到的方法创建一个虚拟分区。
然后就是将常规系统镜像（GSI）放进去了，与此同时，我们会在这个用户数据分区上再使用 F2FS 或者 EXT4 格式建立一个空的用户数据分区，也就是说上面的 data 分区里还可以创建一个 data 分区——我们得给这个操作起个好名字。
马尔切夫： 然后，我们有一个设置是，init（Android 启动过程的一部分）会重引导启动流程使设备从隐藏的分区启动。所以，你既可以从这个分区启动也可以将其删除——最终用户既可以尝试新版本的 Android 系统，也可以正常使用当前的稳定版操作系统。
Ars：听起来像是虚拟机一样，真厉害。
博尔克： 是挺像的，不像虚拟机的一点是，它是直接运行在设备上的。
Ars：所以，这个额外的 Android 是永久存在的吗？我可以想用多长时间就用多长时间吗？
马尔切夫： 事实上，戴夫（博尔克）给我们提交的反馈是：「我们不想让太多的人一直用这个系统」。所以如果你重新启动，你就会回到你的初始系统。我们不想让用户一直用这个，但你可以在 ADB 中调整一个 flag 开关，这样你就可以重启进入 GSI 了。这个 flag 的效果也是暂时性的，所以如果想重启进入 GSI 的话你需要不断手动将其打开。
在这个 GSI 系统上用户可以照常设置账户，数据也只会存储到那虚拟分区当中，GSI 系统和用户的初始系统之间数据不会出现交叉。
Ars：这不需要解锁 Bootloader 吧？
马尔切夫： 动态系统升级不是预装 Android Q 设备发行的必需条件，但如果非要使用这个系统，它也并不需要解锁 Bootloader，某种程度上来说这也正是它的目的所在。
Ars：好的，所以目标就是可以在三星手机上测试最新版本的 Android 系统，或者是任意一台没有解锁的 Android 设备。
马尔切夫： 是的，我们在 Pixel 设备上已经试验成功了，就是你在桌子上看到的那台。
博尔克： 还有一件事你也是知道的，Project Treble 的支持是动态系统升级的关键，设备的硬件接口并需得相当规整（完全符合 Project Treble 要求）。这件事放在三四年前根本就是天方夜谭。
马尔切夫： 所以如果我们早几年做动态系统升级这个功能，其实也不会有符合条件的设备来进行刷入。目前我们也不清楚要如何利用这个机制，但因为开启十分简单，我们希望合作伙伴都开启这一功能。我们也已经和这当中的许多厂商沟通过了，具体效果如何大家拭目以待。
自适应休眠和桌面模式
接下来就是此访谈的「为什么会这样」部分了。我们所提出的第一个疑惑点的在于 Android Q 的「通知延后」功能。这个功能由 Android 8 Oreo 引入，却在 Android Q Beta 3 中离奇消失。Android Q Beta 4 中这个功能又回归了。这又是为什么呢？
Ars：问点 Android Q 相关的问题——「通知延后」为什么从通知面板里移除了，是在进行功能调整还是在修复 bug？
博尔克： 这个功能日后的去留还说不准。
为了进一步简化与通知相关的概念，我们在 Android Q 中引入了「提醒（Priority）」和「静音（Gentle）」两种通知类别。因为在我看来 Android 的通知系统其实已经非常复杂了，（除了优先级）用户还需要设置通知分类、进行通知延后。
所以我们团队中的部分成员一直提议针对普通用户进行简化并移除「通知延后」这个功能——我也支持这部分人的观点。我们显然清楚会有用户真的喜欢这个功能，但对大多数用户来说哪种做法才是正确的？简单就意味着更好吗？
这就是这个功能被「砍」掉之后又回归的原因所在，某一个测试版中有这个功能，另一个测试版则没有，可能最终它会回归，但这个功能的使用率真的不高。
Ars：嗯，这功能不怎么好找。
博尔克： 做测试版就是这样，有利有弊，你也能看到我们团队内部的博弈。
下一个奇怪的点：一个名为「自适应休眠」的设置曾出现在部分用户的 Android Q 测试设备上，按照相关设置的描述，这是一个用于检测用户的屏幕注视行为并以此判断是否保持亮屏的功能。这个功能并不能正常工作，我们也不清楚其工作原理。
有些设备，比如说三星的 Galaxy 系列已经搭载了基于前置摄像头的类似的功能。这个功能在屏幕点亮后便会开始工作，前置摄像头（编者注：部分型号应该是虹膜传感器）如果检测到面部就会保持屏幕常亮。
Ars：设置里这个「自适应休眠」是个什么东西？所有人都有这个功能吗？
博尔克： 这是一个还没准备好的实验性功能，因为 bug 的原因，它提前出现在了部分设备的设置当中。
Ars：是的。
博尔克： 所以不少人都问过我们这件事，我们的基本想法是当用户在看手机的时候让屏幕保持常亮。现阶段这个功能还只有个框架，未来发展成什么样子都有可能。
我觉得这个功能应该还没有合并进入 AOSP 源码，现阶段出现只是想告诉大家我们大概会把这个功能放在哪个地方，这样今后 OEM 厂商也可以给它配备一个相应的后端入口。
这个功能应该也赶不上 Android Q 的正式版发布。这个功能还不成熟，实话说我看到它出现在系统中也是挺惊讶的。
Google 经常这样做。OEM 要是想要给 Android 带来一项新功能，比较普遍的做法要么是自己做，要么就只能依靠 Google 提供的 API 钩子。拿 Android 7.0 Nougat 的分屏功能来说，OEM 先做了这么个功能，然后 Google 才有了他们自己的方案，随后它们还给整个 Android 生态系统带来了一套可以适配跟进的标准和规范。
而在「自适应休眠」这个例子中，如果 Google 添加了这个相关的 API 接口，三星就可以很轻松地适配自家的注视亮屏功能。即便这些功能并不会在下一代 Pixel 机型上登场，这两种做法都有其正面意义——他们都可以减少 OEM 的工作量。
我想问的下一个问题就是 Android 的桌面模式——只需一条精心编写的 ADB 指令，你就可以开启 Android 的桌面模式界面。看起来还有点像 Chrome OS，有桌面、悬浮式窗口，还有一个应用抽屉按钮同时也是「开始」按钮。为什么 Google 会做这样的东西？Chrome OS 要被替换掉了吗？Android 要向 Windows 开战吗？会推出带有鼠标和键盘的 Pixel 电脑吗？
Ars：说到奇怪的功能，为什么会有一个桌面模式？
博尔克： 什么是「桌面模式」？
Ars：敲一行 ADB 命令你就可以启用的桌面模式，有悬浮窗口之类的。
博尔克： 哦，是有这么个东西。
古罗姆： 我可以给你讲讲它的由来。
这其实是我们和折叠设备小组还有不同 OEM 的小组们一起合作完成的项目，目的是为实时多窗口和多显示器提供更好的支持。这里有一个有趣的用例，虽然桌面模式并没有正式支持 Pixel 设备，但我们的合作伙伴是有设备支持这一特性的，比如三星的 DEX 模式和其他 OEM 的桌面模式。我们在这个功能上所做的一切都同样适用于 Chrome 上的 Android 运行时，也非常适合桌面模式。我们所做的运行十分优秀，对于 Chrome 上的 ART 来说，对于桌面模式来说也很棒。所以负责桌面模式的小组索性就把它当作是实机设备推出前的功能展示了。
Project Treble 的下一个目标是 Linux 内核？
Kernel.org 列出了两个在六年 LTS（Long Term Support）计划上的内核版本：4.4 和 4.9。新发布的 Linux 内核还是只有两年的支持时长，所以看来不是每一个版本都能有六年的支持的。既然是马尔切夫自己宣告了这个计划，他一定也知道这些挑选是如何进行的。
Ars：你宣布了一个六年的 LTS 内核支持计划，但似乎不是每一个版本都有六年的支持，这是为什么？
马尔切夫： 六年支持版本的 LTS 内核很热门，我们也会持续发布这样的内核。因为并不是所有的 LTS 内核最后都会用在 Android 设备上，所以同理也并不是所有的 LTS 内核都会从两年支持版本变成六年支持版本。
Ars：所以说这个基本上是高通主导的吗？
马尔切夫： 基本上是这样，高通、联发科等 SoC 制造商想要商用哪个版本的内核，我们就为哪个提供六年的支持。举例来说，在 Android Pie 上厂商被要求提供三个内核版本中的一个，我们则对每个版本进行精简。在这三个版本种，我认为 4.4 和 4.9 是六年支持的版本；剩下的那个，应该是 4.14 吧，现在还不是六年支持，因为我们在观望这个内核在 Android 生态内的表现。
事实上这个版本的内核的处境还有点尴尬：一方面我们要在 Android 通用内核中提供一个版本好让芯片制造商进行权衡，另一方面如果想宣布一个六年支持版本的内核，这个内核必须是已经实装使用中了。
所以 4.14 内核还处在这么一个等待阶段，进入 Android Q 的时代后应该还会有两个内核版本等待得到六年支持 ，这个是不是就像是前后交叠的推拉窗？
Ars：所以说，是大家一起讨论决定哪一个内核可以得到六年的支持。
马尔切夫： 是啊，内核发展迅速，所以就算是两年支持的内核也颇费工夫，别说六年的了。内核进步很快，导致内核版本之间的差距很大，两三年后通过 cherry-pick （直接攫取代码）挑选和移植的时候就不得不小心谨慎了。在为哪些内核提供六年支持这件事情上，我们需要做出明智的选择。
如同马尔切夫所说，Android 9 的 Linux 4.4~4.14 版本内核要求是针对新设备而言，但 Android 设备一般不会对内核进行大版本更新。既然 Google 想让旧设备也能升级到 Android 9，就意味着 Android 9 必须支持版本号低于 4.4 的旧版内核。事实上，Android 9 支持的内核版本包括 2014 年发布的 3.18 版本。看来对于 Android 平台来说，支持使用了近六年的内核是很正常的事情。
如果不必在每一个 Android 版本中的 Linux 内核提供完整的六年支持当然是好事，但是想要达到这个目的，意味着必须使现有的设备和设备生产商升级到新的 Android 大版本才行。Project Treble 在使 Android 模块化，将其和硬件驱动分离，但 Linux 内核其实是在「硬件驱动」那一边的。所以当大版本发布的时候，Android 的现状就是，Linux 内核被留在手机上忽视不管。虽然说可以有更好的做法的。
桑迪普·帕蒂尔，Android 小组里的一名高级工程师，去年在 Linux Plumbers 大会上在演讲中详细描绘了一个在未来 Linux 和 Android 平台同步向前升级的远景。Project Treble 有「通用系统镜像」（GSI），即一个原生的 AOSP 系统，可以在所有支持 Project Treble 的设备上运行，帕蒂尔详细地讲述，这个设想其实由「GKI」发源，即「通用内核镜像」，一个可以在任何 Treble 设备上运行的内核。帕蒂尔说， Google 可能会发布这种内核，将来甚至可能演变成一种带有驱动以及其他硬件支持的最新主流 Linux 内核，一起封装成特定的 SoC 模块中。
上图是帕蒂尔讲 GKI 时的演示文稿。这表明了在 Project Treble 的分离中，Android 和 Linux 处在一边（即白色背景），Vendor HAL 界面和内核模块在另一侧。现在的情况是，Android 在左侧可以升级，而 Linux 这只小企鹅则呆在右侧，没办法升级。
帕蒂尔也提到，Treble 给 GKI 提供了基础和背后支持，Google 则需要为此提供了一个接口，需要倡导跨生态系统合作，需要进行一系列测试。这些听起来像是主攻 Linux 的第二代 Treble，但我不确定这样是不是有些言过其实，我也不确定它发展的过程，所以……
Ars：我听说的这个「通用内核镜像」是个什么东西？你们确定会和 GSI 一起分发内核吗？在场的哪位来让我们了解一下情况？
马尔切夫： 在其他条件不变的情况下，我们想以一种合理的方式来将各种事物统一起来。遵循我们的要求的话，那就是开源，允许被用户自定义。这些东西都很棒，我们想要它「和而不同」。我们以统一开源模式来分发内核源码已经有一段时间了。
通用内核镜像的想法就是：我们有源代码，所以我们为什么不用它来做个内核并用这个内核来测试设备呢？这也是通用系统镜像（GSI）的核心思想。虽然现在我们还没造出来呢。从概念上看挺有意思的，如果从整个生态角度来看行得通的话，我们就做大量的工作把它做出来。
Ars：这个计划是让主流 Linux 内核在手机上运行吗？
马尔切夫： 我会大胆地说，我们想要这样做。但这项工作既耗时又耗力，又牵扯到整个生态，所以我们只能一步一个脚印地走。我们统一源代码，但并不是单单局限于一个内核，而是能够让人们把他们的内核都升级到最新的 LTS 版本。这就是我们现在所专注的目标，我们也在此方面取得了长足的进展。
博尔克： 顺便一说——很明显的，这样做可以解决相当多的安全问题。
Ars：但是你说「升级」，但你并不是在升级手机上的内核，对吧？
马尔切夫： 对的，这里所隐含的就是，一旦一部设备发售，就不会从 4.14 跳到 5.1，对吧？你不会直接跳到下一个内核版本，但既然现在有了长期支持内核，我们就让他们也获得长期支持更新，我们这么努力才做到的。所以我们想让这一系列 LTS 能实装到设备上。
即便这很难——从用户态（user space）对内核做任何修改都很不容易。
所以，我们在朝着这方面努力了，有了安全小组和我们合作伙伴的帮助，我们其实已经取得了许多进展。
结果是，小型长支持更新确实会在某些手机上实现。比如 Pixel 3 XL 出厂自带 4.9.96，而现在（至少在 Q Beta 里是这样）它运行的是 4.9.165。我们的采访到此也告一段落，感谢博尔克，马尔切夫，和古罗姆接受我们的采访，明年我们还要再来一遍！
原文： Android Q(&A): Android Engineers take us on a deep dive of Android Q
关联阅读：
> 下载少数派 客户端 、关注 少数派公众号 ，第一时间掌握 Android 新动态 ⏱
> 特惠、好用的硬件产品，尽在 少数派 sspai 官方店铺
About The Author
