jim9606

@changnet
主要是 c 标准缺太多 os 功能了，posix 是相对中立又是 os 提供的东西，在 c/c++标准化吵完细节之前也只能这么干了

@Ketteiron
C/C++也没说绝对向后兼容，更多时候是新旧 abi 都给你留着（例如 libstdc++的 c++11 双 abi ，可以用新库原地替换），但还想新旧 abi 之间互操作就不现实了

@beautyplus
我目前的感觉是，就算用了 SetConsoleCP 和 win10 1903 增加的 activeCodePage manifest ，还是无法避免依赖系统全局 utf-8 开关，必须走 wchar 那一套

@cnbatch
1. 我知道有些系统受 y2038 影响，但工具链应该有条件做到尽力支持，例如，默认行为就是 64bit time_t ，允许最低限度 opt-out 来解决历史兼容
2. 我是没明白为啥都弃坑 mingw32/clang32 了还没解决这个问题，可能单纯没人搞？
3. 预期是依赖 win 系统的自动转换，程序可以不依赖全局 utf-8 开关的状态也能正确显示中文愉快地用窄字符 C/C++，CPython UTF-8 mode 算是相当接近这个目标了
4. 那还行，至少应用侧有方便 opt-in 的方法
6. 因为很多时候会出现新硬件搭配旧系统的情况，出货时间往往决定应用何时无条件停止支持。例如 Intel/AMD 已经停止出货不支持 AMD64(NX,SSE2)的 x86 CPU 相当长的时间，所以主流应用和工具链基本都不考虑不支持 NX/SSE2 的情况了，但 android 这边因为依然有 armv7 的 SoC ，或者 armv8 SoC 搭配 32 位 os 的硬件在出货，所以无论系统还是工具链短期内都不太可能弃坑

我就这么说吧，绝大多数人学 C/C++,直到结课考完试，都没写出过一个能正确支持非 ascii 字符和长路径的程序，哪怕你是用没有任何遗产从零开始的控制台程序。
可能根本没有教材会说怎么处理这事。

我反正不知道跟 native 搭上关系的地方怎么确保集成后能正确处理这些问题，特别是很多组件不是你自己实现的时候。

国内卖了一般都是国外的 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 这个了