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