去年只有 iPhone 13 Pro 和 Pixel 6 Pro 对阵，最后得出的结论是「Pixel 6 Pro 适合 Android 用户，iPhone 13 Pro 适合 iOS 用户」，但实际上确实有点敷衍了。

虽然今年第一次引入了三星，但最后三大旗舰的竞争结果获胜的却是 S22 Ultra，Becca Farsace 给出的理由是：

（三星）Pro Mode 让拍照体验更接近相机，而非其他两款机器基于手机 UI 而来的拍照体验。

研究人员 David Schütz 在 Pixel 6 上 发现 严重的安全漏洞，攻击者只需插入一张已知 PIN 码及 PUK 码的 SIM 卡，即可物理解锁你的手机

且漏洞复用方式异常简单：仅需插入这张 SIM 卡、故意输错三次 PIN 码，然后输入正确的 PUK 码，即可绕过锁屏密码解锁手机。

目前 Google 已在 11 月安全更新中修复该漏洞，CVE 编号为 CVE-2022-20465。注意该漏洞理论上也会影响 AOSP，请有条件获得安全更新的设备尽速升级，以免设备遗失被人轻易物理解锁。

由于 Pixel 4 已结束安全更新支持，请寻找带有 11 月安全更新的第三方 ROM 刷入，或等待 Google 推出带外更新修复该漏洞（不保证）

相关链接：
https://source.android.com/docs/security/bulletin/2022-11-01

得益于 Android 的开源特性，可以从该漏洞的对应提交记录中获知有关此次锁屏绕过漏洞的触发原理

首先，在 Android 上有个被称作“安全屏幕” (security screen) 的概念，指纹输入界面、密码输入界面，以及此次造成问题的 PIN 码输入界面和 PUK 输入界面都包含在“安全屏幕”之内。

同时安全屏幕之间可以相互堆叠，即 PUK 输入界面实际是堆叠在指纹输入界面之上。由于函数调用设置错误，在 PUK 码校验通过后，实际也一并关闭了叠在下面的指纹输入页面，导致此次输入 PUK 码后手机意外解锁的情况。

Google 对此重写了整套函数调用逻辑，现在调用请求可以指定要关闭的安全屏幕类型，假设请求关闭的安全屏幕未处于活动状态（例如今天指纹输入界面被叠在 PUK 码输入界面之下），则不会执行任何操作。

注意该漏洞实际是绕过锁屏密码输入界面，并非真正解锁手机。当设备处于首次启动未解锁数据加密的情况下，此时 PUK 码虽然可以绕过锁屏界面，但手机会卡在“Android 正在启动”界面，并不能解锁数据分区。

对该漏洞感兴趣的朋友可以参阅上报者 David Schütz 为此漏洞写的记录文章，里面详细阐述了漏洞的发现过程及演示，也多亏上报者负责任的持续跟进，该漏洞才得以在短期内修复。

说明文章：
https://bugs.xdavidhu.me/google/2022/11/10/accidental-70k-google-pixel-lock-screen-bypass
相关代码提交记录：
https://github.com/aosp-mirror/platform_frameworks_base/commit/ecbed81c3a331f2f0458923cc7e744c85ece96da

利用此漏洞破解 Pixel 锁屏密码的实际测试视频。

考虑到此漏洞异常简单且可以轻易解锁手机，因此强烈建议所有 Pixel 用户立即更新带有 11 月安全更新的系统版本。

Pixel 4 及以下用户目前暂无官方解决方案，只能通过刷入合并 11 月安全更新的 ROM 来解决这一问题。

刚刚群友提示发现 Google Phone App 已经支持预测性返回手势了。

该功能可让用户在完全完成某个返回手势之前就能预览此手势完成后的目的地或其他结果，以便用户能够决定是继续完成手势还是留在当前视图中。

目前 Android 13 中的也只是一个早期版本，这个功能的完整版最早可能要到 Android 14 开发者预览版才能看到了。

Android Developer（预测性返回手势）

尽管距离 Pixel 7a 的发布还有段时间，Kuba Wojciechowki 仍然从各种驱动文件的拆包分析中捕捉到这款新机的蛛丝马迹

先前代号为 Pixel Lynx (L10) 的新机被标记为包含三组摄像头 (GN1+IMX787+IMX712) 而一度认为是 Pixel 的下一代旗舰级，或是正在开发的 Pixel Fold。而近日 Google 将 GN1 从 Lynx 的相关备注中删去，并标记为 Pixel 22 Mid-range (与此相对 Pixel 7/Pro 为 Pixel 22 Premium)，证实 Lynx 就是下一代 Pixel 7a。其中最大的改变就是 Google 终于抛弃了 IMX363 传家宝，改用升级款 IMX787 作为主摄，而超广角选用了 IMX712，并无配备长焦镜头。

在已发布的驱动中搜索 Lynx 关键字，还能得知 Pixel 7a 终于用上了 1080p 90Hz 刷新率屏幕，与 Pixel 7 保持一致，并支持 5W 无线充电。同时与 Pixel 6/7 不同，Pixel 7a 似乎没有继续使用博通的无线芯片 BCM4389，而是改用高通 WCN6740，这也是 Pixel 改用 Tensor 后首次采用高通无线芯片。

若 Pixel 7a 维持现在 6a 的定价，我认为 7a 将相当有竞争力，甚至不亚于降价后的大哥 Pixel 7 及同价位的一众产品。当然距离发布还有半年左右的时间，也不排除 Google 会继续变更硬件参数，毕竟之前 Google 还计划让 Pixel 7a 使用 GN1 呢。

来源：
https://twitter.com/Za_Raczke/status/1591176262944706560

目前原作者 Danny Lin 仍在研究在没有 root 权限的 Pixel 6 上启用 KVM 的方法，目前已经找到仅需 adb shell 调整几个 persist.device_config 值设定，即可成功启用 KVM 并套用虚拟机 App 的方法，遗憾的是它仍需要解 BL 锁才可完成设定。

来源：
https://twitter.com/delet_thiskthx/status/1592009399681576961

Here's Android's new Photo Picker working in Google Keep. Except Keep hasn't been updated to support it, and I haven't flipped any Keep flags to make this happen.

How does this work? The Photo Picker is being updated to work with existing apps - without any code changes needed.

The actual mechanism Google is using to make this Photo Picker takeover happen is quite simple, but also quite clever!

If you want the full breakdown of how this works, check out this article.

Google 开始为 Pixel 4a (5G), Pixel 5, Pixel 6 及 Pixel 6 Pro 提供纯 64 位构建，用于给开发者测试 64 位兼容性。注意这些构建与 Pixel 7 不同，是完全不含任何 32 位运行库的，相应系统分区大小相比正常构建都有一定程度的缩小，大约都小了 100~200MB 左右

与此同时 Chrome 在 RAM 小于 8GB 的设备上仍然默认提供 32 位构建，对 RAM 要求不达标的 Pixel 4a (5G) 来说，这可能是一次正式用上纯 64 位 Chrome 构建的机会。

相关链接：
https://developer.android.com/about/versions/13/download#64-bit-only

Android 13 存在可能无法连接低功耗蓝牙 (BLE) 设备的问题，设备将无法发现或连接已配对的 BLE 设备，需重启设备恢复。其中尤以启用 LE Privacy 特性的设备更为严重，像特斯拉车门解锁，及一些健康设备连接是此次问题重灾区。

该问题最早从 Android 13 Beta 4 就有报告案例，直到目前 Google 仍在调查问题原因。已升级 Android 13 正式版的 Pixel 设备，包括已停更的 Pixel 4 在内均确认受到影响。

问题追踪：
https://issuetracker.google.com/issues/242755161

关于 Pixel 4 升级 Android 13 后无法使用无线充电的问题，虽然 Google 尚未修复该问题，但在相关问题追踪下有用户提供了临时解决方案。在关机状态下将设备放在无线充电底座上后开机，只要开机开始正常无线充电了，直到重启前无线充电都能工作。

问题追踪：
https://issuetracker.google.com/issues/238969890

不知不觉频道已经经营一年有余了，订阅数也即将突破 3K 关口。在此想征求各位对频道未来发展的意见，有什么未来想看到的内容，以及目前我们有什么做得不够的地方，都可以在评论区交流一下

我自己认为做得不够好的地方，比如主观点评内容偏少，尽管资讯类频道应尽量做到内容准确与来源清晰两点，但个人看法有时与这些观点并不冲突，反而能起到点缀的作用，有利于发展频道的独特性，这也是频道未来要改进的方向之一。

说到第一手资料内容的选材方面，我们主要参考的是比较有公信力的 Android 上游媒体，例如 9to5Google、The Verge，以及 Mishaal Rahman 老师。由于目前我们频道的主要编辑主力基本是 iPhone, Pixel 双持，对国产品牌的相关资讯内容也比较欠缺，关于这方面我们后续可能会做个受众机型的小调查，视情况决定是否要多关注一些相关话题。

最后，感谢各位持续关注 Android Weekly Update，在此代表全体编辑祝各位玩机愉快。

在 Android 上曾经印象非常深刻的一款浏览器（早期主打的特征是不到 1mb 的 apk 大小，不知道如今多大），最近 iOS 版本开始 testflight 了。

Android 版体积虽小但却有不少实用功能，iOS 版本未必能完全复刻，但还是值得一试）。

https://testflight.apple.com/join/z6cAoQs1

#Update

骁龙 8 Gen 2 SoC 发布

CPU 规格没有采用 1+4+3 架构，而是采用了相对比较特殊的 1+2+2+3 架构，推测主要目的是为了使用两颗 A710 大核心，搭配剩余三颗 A510 小核心，提升 32 位应用的运行性能。

Play Store 已经强制要求开发者上传 64 位安装包多年，高通骁龙 8 Gen 2 的这种硬件设计，或许更多也是考虑到中国 Android 生态中剩余的大量 32 位应用。


1x 3.19GHz (Cortex-X3)
2x 2.8GHz (Cortex-A715)
2x 2.8GHz (Cortex-A710)
3x 2.0GHz (Cortex-A510)

总体来讲，按照高通官方的数据：8 Gen 2 相比前代（8 Gen 1）能有 35% CPU 性能提升，40% 效能提升。

自 Android 11 起，Google 开始实施被称为 Google Requirements Freeze (简称 GRF) 的更新策略。得益于 Android 8.0 开始引入的 Project Treble，供应商支持框架 (Vendor) 开始与 Android 解耦，但在 GRF 之前，每次更新 Android 大版本，上游 SoC 供应商（例如高通）仍然得推出新的 Vendor。更新后的 Vendor 主要用于提供给出厂预装新 Android 版本的 OEM 厂商，以适配新版本 Android 的底层功能要求

这导致上游 SoC 不得不维护多种 Vendor 版本，同时若新版本 Android 提升了底层功能要求（例如必须支持多摄像头切换 API），一些想要升级通过新版本兼容性测试 (Compatibility Definition Document, CCD) 就会遇到困难，而不得不等待上游 SoC 供应商更新 Vendor 版本。这也是过去中低端机及联发科机型即使拥有 Project Treble，更新 Android 也不积极的首要，无论是上游 SoC 供应商还是 OEM 厂商都不愿意在中低端机上投入过多心力去维护。

而在 Google Requirements Freeze 引入之后，Vendor 版本将被冻结，而 Google 将承诺为各 Vendor 版本提供 N+3 的特性向后兼容保证。例如首次利用 GRF 特性的骁龙 888，Vendor 版本适配当年的 Android 11，那么即便后续升级 Android 版本，Vendor 版本也不再变动，而 Google 将保证 Android 14 能够支持 11 的 Vendor 版本启动，并通过新版本的兼容性测试。这也是 Nothing Phone 作为 2022 年发布并出厂搭载 Android 12 的手机，但其 Vendor 版本仍然基于 Android 11 的原因。其搭载的骁龙 778G+ 同骁龙 888 一样，也是首批支持 GRF 特性的 SoC。

GRF 无疑减轻了上游 SoC 供应商的维护压力，在 GRF 之前，高通承诺为 Vendor 提供 N+2 及 3 年的安全更新支持，而 GRF 至少能为 OEM 厂商提供绕开上游 SoC 供应商的机会，独立提供 N+3 的大版本更新（这也是站在 Android 维护的角度，我不推荐任何骁龙 870 新机的原因，由于反复鞭尸炒冷饭，可预见今年发布的 870 新机即便定价没怎么降，各种维护支持都将显著比同期中高端 SoC 来得更差）

当然引入 GRF 也带来一些问题，由于 Google 必须保证 Android 新版本与先前 Vendor 版本的兼容性，而无法做到涉及硬件支持的特性在相同版本 Android 上体验一致。例如由于涉及 Vendor 改动，即使 Google 在 Android 12 上引入了禁用 2G 的开关，也无法推广到所有 Android 12 的设备上，即使是出厂搭载 Android 12 的设备也是如此。同时由于自发布起 Vendor 版本就被冻结，导致 GRF 机型在后续维护中都将很难获得涉及硬件改动的新特性。同时 Google 对 GRF 的承诺只到 N+3，若 OEM 厂商想扩展支持到 4 个大版本升级，将必须自行移植最新版本涉及 Vendor 的特性需求，以通过对应版本的兼容性测试。即 GRF 的出现能让各厂商轻易做到 N+3 的支持承诺，却很难更近一步做到 N+4。同时也极度不利于利用旧 SoC 推出新机的厂商保持正常的支持更新节奏。

对于刚刚发布的骁龙 8 Gen 2 来说，自然也支持 GRF 策略。骁龙 8 Gen 2 搭载最新的 Android 13 版本的 Vendor，将享受完整的 Android 13 底层特性支持，并继续提供 N+3 的版本更新承诺。

扩展阅读：
https://android-developers.googleblog.com/2020/12/treble-plus-one-equals-four.html

#Update

📱骁龙 8 Gen 2 所有主打新卖点。

1️⃣ 采用 TSMC 4nm 制程工艺

2️⃣ 与三星联合优化两亿像素三星 ISOCELL HP3 传感器

3️⃣ 首发支持 Wi-Fi 7

4️⃣ AV1 硬件解码支持 8K60FPS