我这边无论微信还是支付宝都是有门槛(20 ，100 甚至 1000 的)而且是几毛钱不到的。

云闪付其实也有，但没门槛，所以常用。

坏处是有些银行不把云闪付当快捷支付，有些银行内的羊毛统计微支抖美京但没有云闪付

有点哗众取宠了

1. 不管是 ios 还是 android 都没说不让获取设备指纹，只是要求这个指纹是可以被用户主动重置的(通常是恢复出厂设置，所以这个操作门槛有点高)

2. ios 查询软件包只能查通过清单列出的 scheme 且上限 50 个，不能用来检测任意已安装应用。前者有很合理的用途，例如调微信支付前检查下微信有没有安装给个出错提示。倒是后者必要性不足且可能用于非核心用途的用户画像分析。android 也有类似限制，play 对申请检测任意已安装应用有额外审核要求

3. 让非专业用户判断这种用途是否必要属于为难用户了，apple 的做法是要求隐私声明并在商店页展示，合理性让 apple 来决定

4. 如果某种权限使用广泛到所有 app 都需要，那请求授权属于骚扰，根本起不了限制不合理使用的效果，参见现在外国网站的 cookies 声明

主要是跟 tpm2 的功能会受限，例如 windows hello 、设备加密。例如最新 edge 会依赖这个来保护浏览器密码和 cookies

虽然我想说 同样功能 pwsh 基本都内置而且不用动不动就扭各种字符串处理

如果有人要冒领证书冒充你的网站，你其实没法阻止问题的发生，因为攻击者和恶意 CA 不需要跟你有任何往来，跟你用哪家 CA 无关。CT 的意义是让你知道你是否有被冒用（这通常还是通过第三方供应商提供的 CT 监控服务实现的）。除非客户端受你控制（你可以决定信任锚而不是让 OS 替你选一批），否则你也没办法阻止冒领证书被客户端信任。

选择支持 CT 的 CA 的意义是让你相信这个 CA 收你钱不是乱搞的，谁都能监督 CA 是不是在乱搞，不然凭啥信任这个 CA 呢。商业证书通常是有 SLA 要求的，通过合同利益，约束 CA 合规，别被主流平台处罚，进而影响用户的可用性，引发索赔。

商业 CA 是要赚钱的，只能被少数平台信任的 CA 的证书是卖不出去的。除非这 CA 完全不按商业逻辑运作非要恶心人，不然主流平台的合规要求是不可能无视的。

普遍支持 zip 是因为 zip 是 apk/apex 的实际底层格式，android 直接提供相关的稳定 api ，所以系统文件管理器基本都顺手支持 zip 的基础功能(zip64+deflate)
7z 没这待遇，要应用自己带 7z 或者 libarchive 实现。

所以工作之余还是得有点兴趣爱好，有点自我评价的能力，不然你就只能玩这套给无产者设计的循环了

@fromshawn 这是早期华米代工的小米手环用的，后面分家就改名了，也不支持后面的非华米型号，更新可以走 play 商店

从某个版本开始，国际版小米运动健康(版本号 i 结尾)不再支持大陆内的服务，必须下国内版。
我强行把地区改成香港也不管用，可能会查硬件销售区域？

跟 edge 学的

android5 是目前几乎所有 app 的“支持”下限，说下限是因为可能根本没在如此低版本的系统上测过，只是工具链逼的，实际可能没法跑。
大概率这盒子还不支持 wifi5 ，所以建议别折腾，买个次新的二手盒子都行。

145G 也不算很大
开发用机两年下来也能用掉这么多空间
现在很多开发工具都直接把*nix 那边的习惯平移过来了，用户目录那些.XXX 目录，不知道混了多少缓存

@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