最近， XDA-Developers的一位认证开发者，在谷歌Project Treble团队提交的新代码中发现，Android 11中似乎有了新规定，谷歌将强制要求厂商在新推出的Android设备中采用虚拟的A/B分区，以保证这些设备能够支持A/B无缝更新。根据提交的Vendor Test Suite(一个自动测试，厂商的设备必须通过这个测试才能认为是兼容Project Treble的)代码，这个测试会检查使用Android 11或更高版本启动的设备是否支持虚拟A/B分区。这意味着，今后的安卓设备都将支持A/B无缝更新。
A/B分区与无缝更新
1、A/B分区是什么？
实际上早在Android 7.0版本中，谷歌就在支持A/B分区的设备上引入了“无缝更新”的功能。只不过谷歌一直没有强制让新的Android设备支持无缝更新，也因此，许多设备都是不支持A/B分区和“无缝更新”的。不过很多人可能并不了解A/B分区和“无缝更新”，这里借用XDA-Developers的一篇文章，结合安卓的官方文档，作一个简单介绍。
手机的分区就是内部存储保存数据的一个独立区域，Android系统、用户数据等，每个名字不一样的分区，都保存了不一样的数据。"/system "和"/cache "之类的说法，实际上就是给不同的分区进行单独的命名而已。A/B分区基本可以理解为，保存了不同系统数据的两个独立区域。下图是一加6的部分手机分区，由于这款手机支持A/B分区，我们可以看到划线部分的那些分区，实质上就是手机的A/B分区。
2、支持A/B分区的手机怎样进行无缝更新
无缝更新会使用到手机的A、B这两个分区，分别称为槽位A和槽位B，系统在当前槽位运行时，不会访问未使用的槽位中的分区。这样，未使用的那个槽位就可以作为后备槽位，用来防范系统更新时出现问题。如果A槽位更新出现问题，系统可以回滚到B槽位，反之亦然。
上图是整个流程的示意，假设A分区会活动分区，B为非活动分区，无缝更新的过程大概是这样的：
用户在A分区使用系统，系统有OTA更新时，会在非活动的B分区进行后台更新。用户重启后，A分区被设置为非活动分区，用户进入到活动的B分区，使用最新的系统下一次OTA更新推出时，系统会在变为非活动的A分区更新，重复上述流程。如果更新失败，例如，系统在非活跃的B分区更新，用户重启手机后更新出现问题，系统会回滚到之前活跃的A分区上的正常版本，由于更改的是B分区上的数据，用户的A分区不会受到影响。
国内厂商生产的手机中，一加6是较早支持A/B分区的一款机型，小米手机的部分海外版本也支持这个特性。想要知道自己的手机是否支持A/B无缝更新，可以下载一个叫做“Treble Check”的应用，打开这个应用就能看到结果。
A/B无缝更新的优点
A/B无缝更新确实解决了我们更新手机系统时常常遇到的一些问题，这也是谷歌强制要求后续的安卓手机支持这个特性的根本原因。
1、减少系统更新造成的死机、数据丢失等问题
由于A、B两个分区是相互独立的，系统在当前分区活跃时不会访问非活跃的分区。我们刚才也提到，使用A/B无缝更新时，如果出现问题，系统会回滚到原来的分区，我们依旧可以使用原来的系统版本。而且不会损坏原来的系统数据。如果手机只有一个分区的话，用户可能会面临手机数据丢失甚至变砖的风险。
2、最大程度地减少系统更新对日常使用的影响
目前我们对手机系统进行更新时，我们需要花费较长时间等待更新完成，过程中无法对手机进行任何操作，不仅浪费时间，也很容易错过一些重要消息。许多厂商为了最大程度地避免系统更新对用户造成影响，都会将更新时间设置在夜间等用户使用手机频度较低的时间段。A/B无缝更新是在后台进行的，可以最大程度地避免这种等待。
3、不会耗费过多存储空间
尽管支持A/B无缝更新的手机存在两个分区，但并不会导致一堆的重复分区占用大量存储空间。谷歌从A、B两个分区中删除了许多不必要的部分，使得两个分区对存储空间的占用基本达到了最小化。实际上，支持A/B分区的手机和只支持单个分区的手机，系统占用的差别并不大。也就是说，我们在享受这个特性带来的各种好处的同时，也不必牺牲宝贵的手机存储空间。
尽管A/B无缝更新可以带来更好的系统更新体验，还能减少更新过程中带来的各种风险，但由于种种原因，很多Android手机厂商都没有支持这个特性。如今，谷歌终于对这些厂商提出了强制要求，相信我们很快就能在接下来的手机中，获得更好的系统更新体验了。
