@cubecube #16 AVB 可以把密钥写到 TEE 里的，换了 SoC 自然 boot 不起来。分区加密的密钥一般是 wrapped key 或者放到另一个 metadata 分区里。扩容存储的话，整个分区表都需要重写或者调整吧？不保数据也正常。

@WebKit #8 互换 SoC 后不能开机可能是因为 AVB (Android Verified Boot)，签名对不上了，bootloader 是解锁状态的话，把 AVB 关掉应该就好了

Google 要求 data 分区出厂必须加密，但是你把锁屏密码/手势/PIN 都移除后，data 就解密了。理论上可以先把 data 的内容读出来，然后换主板后恢复就好。维修的不愿意搞，一个原因可能是比较费时间（小米大多数手机还是祖传 USB 2.0 ），另一个是 virtual a/b 之类的分区格式，会在 OTA 前后把很多分区的内容或者 diff 存到 data 分区，然后在 boot 过程中 mount 起来。换主板之后，如果只恢复 data ，其他分区跟原来的手机对不上，可能还是会变砖。

随便打个电话，然后打开免提，再降低音量，不知道这样管不管用？

@yanqiyu #22 从 android 11 开始，绝大多数新设备出厂就是 virtual a/b 了，android 13 开始应该是强制要求新设备必须 virtual a/b 。virtual a/b 已经不怎么浪费空间了，我觉得最大的缺点是 OTA 比较慢，耗费 CPU ，好在可以后台慢慢做。

今年 LPC 2022 的 Android MC 上面，在讨论完 erofs 之后，问答环节有人问到了使用 btrfs 的问题。https://youtu.be/PW7XA237dgI?t=9630

对于 data 分区使用 btrfs ，Google 应该也是有类似的想法，我理解目前问题主要有两个：
1. fs-crypt: android 设备出厂，data 分区必须加密，而且目前要求必须是 FBE (File-Based Encryption)。btrfs 的 fs-crypt 支持应该还有些问题。
2. fs-verity: 主要是用来验证文件的 integrity 的，某些 app 文件用了证书签名之后，证书存到 /product/etc/security/fsverity ，在启动的时候加载，只有证书验证成功，app 文件才能正常读取。btrfs 同样也需要支持这个才行。

@Buges #7 想法很好，但是过于理想主义了。对于认真维护 ROM 的人，每天都刷好多个版本，还经常一不小心某个改动导致启动不了了，或者 /data 出问题了，最后全得格式化重来。你觉得在这种情况下，怎么可能把这台机器作为主力来使用？所以实际情况往往恰好相反，真正靠谱的都不会把开发机器作为主力，这样才能毫无顾忌的去尝试新东西，遇到用户反馈的问题也能及时的按步骤去复现。

举个例子，假设用户告诉你，当前这个版本在系统初始设置的时候，录入指纹会崩溃，你怎么办？如果手机上有你当前几十上百 G 的数据，你是根本不可能去全都格式化掉，自己亲自测试系统初始设置。

相反，大量依赖别人的工作的人，才会放心大胆的把设备当作主力来用，因为他 cherry-pick 的东西都是别人那里来的，别人都测试过的，大概率是可以直接拿来用的，没有什么试错的成本。

非常好的问题。先声明一下，我是 PE 核心组成员，目前维护 Mi 11 和 Mix 2s 。作为一个圈内人，我当然会有一定的偏见，但是我会尽量客观的说一下我的看法。

1. 维护者的负责任程度是非常难以判断的，不过可以去观察一下他对于用户的反馈是否及时回复，在 XDA 或者 telegram 上是否活跃，在与用户交流的时候是否能够理性的承认存在问题的可能性，并礼貌的要求提供复现的步骤或者提交日志。

维护者的技术水平，我个人认为作为一个普通用户是很难判断的。我自己在维护两个型号，并且经常审核一些 PE 收到的官方维护者申请，见得多了，自然看一眼 GitHub repo 就知道这个人是真的有水平还是只是 cherry-pick 别人的东西。如果你是一个普通用户，那可以去翻翻维护者的 device 和 kernel repo ，看看有多少是他自己原创的 commit ，有多少是 cherry-pick 别人的东西。这里并不是说 cherry-pick 不好，开源社区里面，使用别人的 commit 的时候保留原作者信息是很重要的。我的意思是，如果他永远在用别人的东西，自己不尝试做一些修复或改进，那大概率这个人水平并不怎么样。原创 commit 也要看是什么样的 commit ，是在实现一些新功能，还是只是改个版本号，更新个 proprietary blobs 之类的。

2. 由于存在利益冲突，我就不推荐了。

3. 从我个人的观察来看，LineageOS, Pixel Experience, Paranoid Android, ArrowOS 普遍来讲都相对靠谱一些。当然可能还有其他的团队也不错，不过我也不是所有的都了解。

@DianQK #22 并不是 kernel 故意关掉了 wireguard 。Linux 5.6 的时候 wireguard 才正式进入 mainline ，在这之前的版本是没有 wireguard 的，需要维护者在 kernel 内手动添加 wireguard 为旧版本 kernel 做的 backport 。如果维护者没添加，那自然就没有……

理论上可以自己编译一个 CarrierConfig 的 rro overlay ，把对应运营商的 carrier_vt_available_bool 之类的关掉？

@dzyou2007 #8 微信指纹支付用的是 soter 那一套东西，跟支付宝不一样

@ysc3839 #6 看起来 IFAA 只是一个接口，依赖不依赖 TEE 还是看你设备本身指纹的实现吧

支付宝指纹需要设备上编译或者添加了 IFAA Manager ，我维护的 PE 都可以直接用支付宝指纹的

@whileFalse #9 如果有完整的谷歌套件的话，android 也可以自动记忆和填充 app 密码

@LaCAfJH #25 不清楚，没用过 Airsonic

这个标题其实不太准确，GKI 说实话只是强制 vendor 把所有改动都模块化，使用谷歌弄出来的统一的 KMI (Kernel Module Interface) 接口挂载。

KMI 的一个问题就是，为了保证 vendor 的内核模块能正常挂载，KMI 必须保持稳定。这就导致了一个问题，linux 主线内核是没有维持 KMI 不变这个要求的，所以在谷歌的 GKI 内核里，一些情况下主线和上游的补丁如果不小心造成了 KMI 的改变，反而不能直接合并，必须用别的方式移植或者魔改，这个问题谷歌在去年的 LPC 会议上也提到了。从这个层面来说，GKI 反而离上游更远了，因为 vendor 是面对 KMI 开发，而不是想办法把自己的改动直接合并进上游主线。

对于 vendor 来说，一切开发的目的都是为了发布和更新产品，所以只要谷歌不强制 vendor 去把改动合并入上游 linux 内核，vendor 自己是没有动力去做这件事的。的确，GKI 从某种意义上，至少避免了很多 vendor 魔改通用的内核部分代码，让大家都用同一套 GKI 的东西。但是，我个人觉得这种事情意义有限。GKI 其实是 Treble 的一种延申，Treble 把 system 和 vendor 分离，搞出了 GSI (Generic System Image)，并且通过 VTS/CTS 之类的让 vendor 的东西“理论上”能启动 GSI 。但是从 Oreo 到现在三四年过去了，也没有哪个 vendor 会真正在发布的产品内用 GSI，我记得之前小米的工程师也抱怨过，升级大版本，说好的 Treble 的一些接口不变，该重新写代码还是要重写写。只要谷歌还在对 vendor 做类似的妥协，GKI 内核几年后也会是这个样子。

@acess #7 小米 2018 年的 Mix2s 就在用超声波的距离传感器了，我之前看过一眼 Mix 和 Mix2，也是超声波的，而且实现的更简单。不清楚新设备上超声是什么情况，我维护的 PE 在 Mix2s 上防误触是可以用的呀，亮屏前同时检查超声距离传感器和光线传感器，如果光线暗（在包里或者兜里）并且距离近就阻止触控。

Skia vulkan 的问题，去 build.prop 里把 debug.hwui.renderer 那一条删掉

进 Magisk Manager 开启 MagiskHide