国内卖了一般都是国外的 CA 根在国内分销，买了时候应该跟你讲明提供哪条证书链的。除非有 GR 需要，不太建议买根是国内的。

商业证书主要是有效期更长可以不搞证书轮替自动化（换言之，风险变成运维人员操作），但 OV 一般也就一年一签，而且像 OSCP/CT 日志/CRL 分发之类的可达性会好些，能更好兼容一些默认要求严格或者信任根过于古老的客户端。EV 的话可能有些特殊系统要求，但 EV 证书通常要求用 HSM 部署，用起来会比较麻烦，一般不需要用这个。

以 Let's Encrypt 为例，目前只提供 ISRG X1 根，十几年前的设备和系统如果没法更新信任根的话就没法用这个。只有 DV ，有效期最长 3m 且将会缩短到 1m ，意味着 ACME 自动化是必须的。CRL 分发点有可能被墙，会导致某些客户端首次握手时间大幅延长。

只考虑现代系统现代浏览器的话没太大区别，基本等于花小钱请个理论上的背锅侠。

想在 win 下自动化的请用 powershell 。
cmd 自 vista 开始就不再积极开发的，所有系统 CLI 都通过 powershell 暴露。
你们还那么喜欢用 cmd 只不过是因为 bat 可以双击执行而已

hyperos3 以下和所有 miui 的 package installer 有一个长期未修复的 bug 导致 split apk 无法用 adb/play 以外的方法安装，系统备份和换机也会错误处理这类 apk ，据说 5.4.1.0.0 解决了。然后呢这玩意又不允许手动更新。黑名单只是新版本顺带的功能。

原则上以服务器防护为准，高价值功能用服务器实现。

360 曾被抓包过加固有插入外部未知逻辑的事迹，那时 360 商店将用自家加固作为上架条件，可能就是免费的代价吧。

如果可以，尽量用高版本 Android ，因为高版本通常权限管控更严格，甚至说是 AOSP 对国内用户最重要的内容。国行的 ROM 可能不执行 Play 市场的政策不用 AOSP 的 UI 设计但 AOSP 本身的权限政策是只紧不松的，自分发渠道没人管，只能看 AOSP 的政策。

高版本 Android+高 TargetAPI 应用是最佳选择，很多隐私限制对高 Target 是强制执行的，无视 Target 强制执行的政策相对慢些但也有。由于 Play 市场有 AOSP 稳定版发布一年内强制执行适配的要求，国内常用有上 Play 的应用基本都服从管理正常上架的，优先用 Play 的版本。例外主要有 QQ （ 2020 断更）、抖音（港版支付用不了）、PDD （查无此人），以及推送可能不工作，可能没办法预载 App Bundle on-demand feature 。

就算用国内版，一般也不会强行索要在外版要求授权或者禁止申请的权限，所以说哪怕 Play 不进来也是能影响国内生态的，有经验的用户可以回忆下 6/10 年前以前是怎么申请存储权限和手机状态权限的。野鸡 APP 可能还是 10 年前的那副模样。

（以下内容以 API Level 指代版本，30=Android11 ，34=Android14 ）

具体到照片这事：
1. 系统&Target 至少 30+ 强制执行分区存储
2. Target33+ 媒体权限细分，可以使用照片选择器

当然，坚持用旧版本 APP 也无法获得上述好处，你得自行取舍，或者就多用户/隐私空间吧。另外不要用这些方法跟

Play 市场政策有以下额外好处
1. 禁止非核心功能/风控名义获取所有软件包列表，这个权限并非敏感权限而且有变通手段，想拦要靠国行加补丁（所以我是不觉得原生在这点有优势）
2. 禁止非核心功能/风控名义获取所有文件管理权限
2. 一年强制适配
3.（感觉未必审得出来）禁止可执行代码下载
4. 要求使用 App Bundles （双刃剑，省存储但基本把侧载干没了）
5. 支持 16K 页
6. 搞小动作有可能会被 Play Protect 扬了（美团就被整过，虽然我也不信任 Play Protect ）

目前 Play 上面的美团 12.35.236 的 Target 是 35 ，适配了图片选择器，没发现什么问题。
删照片这事其实跟伸缩摄像头抓包一样其实是老黄历的纯技术问题，但要推动研发流程去改善就是要外部反馈推一下，不然程序说启动就预热相机不好也没人鸟。

Target30 行为变更，每个版本都有一个列表的：

https://developer.android.com/about/versions/11/behavior-changes-11

媒体存储：

https://developer.android.com/training/data-storage/shared

至少小米 vivo 的系统备份是可以不直传的，可以选择备份到 U 盘或者直传 SMB ，可以先翻下设置。不过这个不支持跨品牌。
微信 qq 这种还是建议用 pc 端的备份功能，能去掉部分冗余数据，反正两种方式都不保证能保留应用类的数据。

@KazeW 广电用的老的 MPEG2,正常的 H264,高端的估计 AVS+(可能没硬解，但以前那些破盒子也不大可能支持这个),这些只要是支持 DTMB(电视国标强制要求)的都支持，之前说的不合规有可能是 DRM 上的要求，不过广电自家的 DRM 都没做到端对端，可能也没人 care 这个了

印象中五年前的 iptv 就是可以不用专网的，现在 cdn 技术成熟了也不用靠 ip 组播来承载直播业务了。当时我就见过专网 pppoe 和共享网 dhcp 两种，盒子没条件直连 ONU 就会用后一种方式，盒子也是非智能的，跑 java 和网页的那种。
现在智能电视普及了，直接装 app 还能省笔硬件采购费用，至少我用过的盒子名义是租用的。

老板要 AI 提效，又不出 token 和订阅的钱，那不是付费上班？

没能力迁移出来可以考虑只在输入输出隔离，原来的计算还是在 excel 里跑，填数据和提取结果用读写 xlsx 的库来做。

jd 和 tm 等平台的 3c 类商品页通常会有一些增值服务，例如碎屏延保意外险啥的，大部分情况这玩意的提供商就是纯粹的金融公司，没有任何售后能力的，而且卖货商家可能完全不知情或者无法控制只能场外声讨，性质类似快递盒子上的牛皮癣红包二维码。

平台有意将这些信息透露出去做营销的，我就接过两次 jd 营销电话推销延保的。

这个手机租赁也有可能是这种套路产物，反正都是金融产品。

（图床图我没法看）

国内的法规和国家标准不使用电车 Tram/轻轨 LightRail/重铁 HeavyRail 这样的描述，对于城市轨道交通，按运量分低运量/中运量/高运量，基本对应前面的定义。民间通常将有轨道专有路权的统称为地铁 Metro/Subway ，电车特指共享路权的无轨/有轨电车。
以前电车这词更多是东亚其他国家的轨道交通名字直译过来。

现在用来指 EV 属于用得多的词义把用得少的词义占了。上个被这么占的有个词是内存。

哦，为了凸显 BEV 的至高无上，BEV 开始自称纯电了，不跟 HEV 一桌了。

你都用 lineage 了
毕竟上游 aosp 里面的这几个系统应用已经很多年没有维护过了，这还是 google 官宣过弃坑的。
别太指望一个社区驱动项目搞什么 UX 专项优化，没人做这事的。
没主意可以用 GMS 的那一套，至少算是 google 目标上的最终体验，虽然还是不咋好用就是了。

不知道兴奋个啥，去年的已申报收入随时都能查，计算方法又不是啥秘密，AI 都能替你算。
纯前端防护没啥毛病，又不是能查别人收入数据。

不想被税局多预扣就提早填好专项让扣缴义务人申报。退税的钱可是不给利息的。

因为现在手机基本都是 arm64 了，分架构打包可以实现跟 app bundle 类似的省空间功能还不需要特殊安装器来安装，而且 AGP 自带 abiFilters 可以很轻松打出分架构包和多架构包出来。

我更讨厌的是毫无必要的压缩原生库，安装时会额外占用一份空间来存储解压的库，为了“让 apk 变小”。

因为很多人压根不了解上面的问题，所以有了“预留 apk3 倍安装空间”的经验，包括部分做应用市场的开发者把这做进逻辑里了，倒带着一票开发者用错误方法解决问题。

真要装用楼上的方法吧，miui 屎山问题，只有装 split apk 才会有的问题，但因为不影响 google play 的安装流程所以一直拖着没修复。
多数时候所谓的纯净只不过是 play 上的版本，不如直接走 play 下载。

OSS 可以认为是 FS 的阉割版本，缺少一些 FS 的功能，如果用 OSS 做后端模拟一个 FS 出来，这些缺失的功能就不会实现或者要用低效的方法模拟，举些例子：
1. 随机访问某个对象，OSS 你得整个对象下载下来再提取期望偏移的内容
2. 读写锁，FS 基本都需要实现锁功能来应对并发读写的，OSS 通常无此功能
3. 树形结构，如果 OSS 用 path 作为名字模拟，移动目录要修改所有下级对象的名字，列举目录下文件也很麻烦
4. 软链接/硬链接，OSS 无此功能

如果业务可以将功能需求限制在 OSS 的能力范围，那确实可以用 OSS 代替，因为 OSS 通常比块存储便宜。

我不好说用百度是个更好的选择，可能还不如小红书。
b 站其实还算是个不差的选择了。

@Kirkcong
1. oobe 强制更新在美国可能不是问题，他们可能不知道这边的 cdn 网优做得一坨，oobe 强制更新可以避免（理论上）避免暴露 bug 和安全问题
2. 某种程度上是因为 WaaS 策略以及 win11 将联网能力列为必须要求，现在每年都会出一个 rtm 镜像，所以才会暴露这些问题。win7 sp1 就只有一个最初的 rtm 镜像，没机会改。所以现在想只用官方途径部署 win7 并打上所有补丁就很麻烦，得预先准备驱动没法自动下，必须手动更新 SSU 和 UCRT 等组件才能让 WSUS 下到后期的补丁
3. 设备加密其实从 win10 就可以出厂/新装自动启用，但因为启用条件要求 DMA 保护和现代待机，所以多数设备都不会触发，直到 24H2 取消了这个要求，就从这时大伙才开始因为这事喷，三教鸡教程也只会教裸奔来逃避问题而不是解决问题。你说让微软别动加密这主意别要求用户适应吧也不合理，主流消费级 OS 就你 win 没加密也说不过去吧？
4. 不同意放松 pcr7 （安全启动状态）绑定要求，不然攻击者可以用篡改过的固件或者降级缺陷固件注入 rootkit 突破保护盗取密钥。微软实际要求更改固件前要暂停保护，现在 oem 固件内更新基本都有做二次提示了（用户当耳边风，事后又甩锅），走系统内 efi capsule 更新的也没问题
5. 不受支持的意思是可能会没通知就更改实现，把你流程干炸了不负责（除非课金要支持）。例如这种直接部署 wim 就绕过了指令集检查，没 popcnt 的机器就 boot 启动不了，官方不管，只是比起老古董 ghost 这个看上去规范些。