PushClock 需要哪些系统权限、为什么每项都不能少
权限清单一览
| 权限 | 系统 | 用途 | 能否拒绝 |
|---|---|---|---|
| 摄像头 | iOS + Android | 运动任务的姿势检测、拍照任务的拍摄 | 拒绝 → 运动任务和拍照任务全部不可用 |
| 通知 | iOS + Android | 闹钟到点响起、后台唤醒 | 拒绝 → 闹钟不会响 |
| 精确闹钟 | Android 12+ | 系统级精准闹钟触发 | 拒绝 → Android 12+ 上可能不让设闹钟 |
| 电池优化排除 | Android | 防止系统杀掉后台进程 | 不做 → 闹钟被延迟或漏掉 |
| 自启动 | 国产 Android | 开机后自动启动守护进程 | 不开 → 闹钟不响 |
| 麦克风 | Android | 语音指令相关（可选） | 可以拒绝，核心功能不受影响 |
| 位置 | Android | 触摸草等户外任务（可选） | 可以拒绝，影响特定任务类型 |
| 存储 | Android | 缓存历史记录截图（可选） | 可以拒绝，功能受限但核心闹钟可用 |
摄像头权限：最核心的权限
PushClock 里最有特色的功能——摄像头实时计数俯卧撑和深蹲——完全依赖摄像头权限。
前置摄像头在闹钟响起后开启，实时分析你的身体姿势（头部、肩膀、手肘、躯干），判断你是否完成了一个完整的动作周期（比如俯卧撑的完全下压和完全起来），每个完整周期算一次。
这个过程完全在设备本地运行（on-device ML），视频帧用完即弃，不会上传到任何服务器。具体隐私细节见 摄像头数据不上传。
通知权限：闹钟响起的前提
通知权限不只是"能不能弹窗推送"——对于 Android 来说，它涉及 PushClock 能否在后台维持一个前台服务（Foreground Service）。前台服务是 Android 系统允许应用在后台持续运行的唯一方式，闹钟的准时触发靠的就是这个。
iOS 的通知权限本质上是对"本地通知"的授权——iOS 系统级的闹钟通知，App 本身不需要后台进程也能到点触发（但 PushClock 仍然需要权限来让任务界面弹出）。
精确闹钟（Android 12+）
Android 12 引入了"精确闹钟权限"——任何使用 AlarmManager.setExact() 或 setAlarmClock() API 的应用都需要用户主动授权。PushClock 的闹钟走的就是这条路。
拒绝这个权限后，Android 12+ 上可能会出现：你能设闹钟但到点不响、或者系统直接提示该应用不支持精确闹钟功能。
电池优化排除（Android）
Android 的省电策略在不同厂商手上力度差异很大。原生 Android 比较温和，但国产系统（小米、华为、OPPO、vivo）的激进策略会把"非活跃 App"的后台进程在锁屏几小时后直接杀掉。
把 PushClock 加入电池白名单 = 告诉系统："这个 App 的后台进程不能杀，哪怕长时间没打开。"
自启动（国产 Android）
小米的 MIUI、华为的 HarmonyOS / EMUI、OPPO 的 ColorOS、vivo 的 OriginOS——这几家都有独立于 Android 原生机制之外的"自启动管理"。就算你电池白名单加了，自启动没开的话，重启手机后 App 不会自动拉起，第一个闹钟大概率漏掉。
路径大同小异，设置里搜「PushClock 自启动」或「PushClock 后台」就能找到对应开关。