@Chihaya0824 @typetraits
另外我看到一个观点是由于目前 GaN 的发热问题，不推荐用作长时间满功率供电（例如连续十几个小时跑额定功率）。反正用来接有电池的设备比较难遇到这种场景。所以长时间满功率供电保持稳定就不列为我的需求了。

@echo1937 我也不知道瞬时功耗论是不是靠得住脚，也不知道是否值得为了这个买留有功率余量的电源，但我想现在买 GaN 充电头 /高端显卡能遇到电压不稳、断电、啸叫的问题，好像也只能用瞬时功耗来解释了。

FCP 从来没推荐过给电源做 cost down，顶多认为他高估风险。同理，我也有理由认为平民价 GaN 不能买的论点是高估风险。高估风险算不上啥 RP 问题，FCP 也没有因为这个观点推销过任何特定品牌的产品，说他通过这个论点获取商业利并不合理。作为消费者，我没法用需要 EE 知识的方法判断某个产品的风险平衡点，只能用随市场大流的方法做出选择。

@echo1937 按照 FCP 的说法，啸叫跟动态负载相关，甚至可以故意触发，所以可能只能通过另类手段掩盖问题 ( https://weibo.com/1092211747/JDESIj6Gg ) 反正我觉得耳朵贴近才能听到的啸叫是可以忽略的。

@Chihaya0824 @typetraits
如果一个充电头短路就能把空开烧掉，那你应该怀疑你家的空开有问题不能在过流的时候自动断开。

另外我并不觉得 100-的价位买个 65W 算是什么很离谱的定价，其他主流厂家在这个价位的差价基本就是看有多少个口，多口就贵些，而且出货量都不算低的，要是这算有严重缺陷，那售后早闹翻天了。我买多口也就为了灵活性，因为多口功率分配策略导致超功率能自动断电我都没啥意见。

啥叫禁止网卡随系统启动？
如果希望网卡处于 unmanaged 状态，/etc/network/interfaces 移除所有 auto 及 allow-hotplug 方法

@allentong AOSP 的 package installer 就不能直接装 aab 文件也不能逐个安装 slice apk 的，所以不算国内魔改的锅。
但不能用 adb install-multiple 安装就肯定是魔改的问题了。

既然作者给你回复了，等于是专门给了一个针对你的 license 。虽然这样的口头授权不太正规也有很多瑕疵，但肯定是有效的。
贴在 repo 里的 license 是针对不特定个体的，因为多数开源项目的作者都懒得逐个跟使用者谈授权。

@sidkang @wenhua @Chihaya0824 @typetraits 刚买了倍思 GaN2 Lite 65W 2C，JD 花了 68，打算给轻薄本和手机用，有没有人说一下有没有坑。
本来是想跟风 59 块捡锤子那个 65W 单 C 的遗产的，但是觉得只支持单口纯 PD 适用面窄还是稍占面积的方形外观，所以才加 9 块选了倍思。

@paopjian 手头其实还有个首发 199 买了闪极 90W，打算配合诱骗线给我的老全能本（标配 95W 圆口电源）用的，结果单口还是经常触发过流保护。后来还试过轻薄本(C1)+手机(C2)+USB 台灯(A)，结果由于奇怪的功率协商，C2 开不出 9V 快充。感觉想一个头搞定三个设备还是不行，顶多两个，还不能贴着功率上限买。

@echo1937 现在单口顶多 100W，更高电压和功率的 PD3.1 标准前几天才出炉，肯定没产品。

题主要明白 Websocket 有很多你看起来很多余的设计，是因为设计者希望 Websocket 能跟完全不支持 Websocket 的网络中间件（防火墙、代理）兼容，所以就有：
1. 必须使用 HTTP Upgrade 握手，因为 Upgrade 语义早在 HTTP1.1 就被定义了，标准定义 Upgrade 之后的流内容就不是 HTTP1.1 了，HTTP2 采用相同方法进行升级。正确实现 HTTP1.1 Upgrade 语义的网络中间件无需修改即可让 Websocket 穿透
2. Upgrade 头通过 Sec-WebSocket-Key Sec-Websocket-Accept 头对暗号，确保两头都真正支持 Websocket 而不是一个只会 copy 头的哑主机
3. 数据必须经过 MASK，防止使用关键字匹配的网络中间件意外篡改数据流

你用的是啥手机啥系统啊？
由于部分伸缩摄像头的手机的存在，国内主流的 APP 基本上就是打开相册和明确要用摄像头的时候才会打开摄像头的。
不知道的话去系统设置把所有软件的摄像头权限改为拒绝 /询问，用的时候再跳转过去打开。

就是蜜罐嘛，以前只有安全厂商自己搞这个来采集病毒样本，现在可能做进安全解决方案里卖给企业了，顺便采集样本。
拿真实数据注水做蜜罐也不是不行，不过安全策略得跟生产环境一致，那种故意放松安全策略的蜜罐肯定只能用模拟数据。
安全这个东西就是多一个技术就多一个发现威胁的途径，多了有好处，不能说没用也做不到绝对安全。要不要上还得看预算。
这个方法主要意义在于更早更好地发现数据泄漏和隐藏威胁，至于能不能抓到人——别的方法一样没法解决这个非技术问题。

很多非技术原因可以左右其应用场景，Google 有 Youtube 、Android 、Chromium 这几个产品，它给这些产品上了 AV1 就能在网络流媒体领域有不错的市占率，AV1 有没有更高效都不见得是关键因素。

Google 也没少给竞争对手下绊，Chromium 全系都不支持 HEVC 。当然对面也不是吃素的，做电视和电影的那帮公司是偏向支持 HEVC 的，苹果一直拒绝支持 VPx 家族。

AV1 软件编码器有好几种实现啊，有试过别的实现吗？

个人感觉前代 VP9 算不上最广泛但算得上主流吧。

个人感觉这个更新只负责部分 Google 直接发布和部署的组件，例如部分 com.google 开头的系统 APK 和 APEX 模块。
目前感知最明显的除了 GMS 的核心组件之外就是 Android System Webview，主流厂商预装的都是用 Google 签名的包。

@cathedrel 清空 userdata=工厂级恢复出厂设置，所以预装的 APP 是保留在 system 分区里的（也有可能单独分区，例如 cust 、vendor，反正是只读的只通过 OTA 更新的分区），对于可卸载的预装应用，首次开机对 userdata 初始化时执行安装流程。

预装应用向来都是这样部署的，别大惊小怪，这也是为啥我并不关心隐藏预装应用和卸载预装应用的区别，因为基本不能省空间。

通常是有 userdata 的，你可以在预装系统中用 adb 看看有什么分区
```adb shell ls -all /dev/block/bootdevice/by-name```

通常刷机用的 userdata 是空文件系统，可能 fastboot format 格式化 userdata 分区就行。

APP 的数据有两个存储位置，一个是在 /sdcard/Android/data 下面（不规范的可能直接在 /sdcard 下拉屎），提取和修改这里的文件比较简单。另一个位置是 /data/data 下面，这部分数据比较难用非 root 的手段进行访问和修改。如果 APP 打存档放在后者，就得用比较复杂的方法了（非 root 方法例如利用系统的应用备份获得备份档，然后解包 /重建备份档后还原回去）。

建议设置里选用系统浏览器打开。
另外推荐换用 Microsoft 商店的版本。

感觉你只需要在数据库或者后端服务搞 ACL 访问控制啊。数据库提供两个账户给后端服务用，其中一个可以访问敏感数据。

如果你这里的两个系统都是受信任环境下的（就是外人获取不到程序，运行在自己控制的服务器上），web 应用自己做 ACL 就行。如果不是（也就是需要直接对外暴露 mysql 端口），那你可能得用 mysql 中间件做复杂的 SQL 过滤了。

后端 per-user 加密--前端 per-user 解密 这个流程很多余，前端始终是获得解密的数据的。如果只是想避免连接窃听的话上 TLS/HTTPS 就行了，

@x86 #98
黑字按钮算增强，绿字按钮得打开看看是不是电信的链接，如果是，那就算增强。