权限并不是启动时随手点一下的小事，它能反映应用是如何设计的。只要理由清楚，麦克风、相机或本地网络访问都可能适用于婴儿监护器；但如果没有明显必要却要求位置、通讯录或广告标识符，家长就该提高警惕。
| 权限 | 合理的情况… | 需要警惕的情况… |
|---|---|---|
| 麦克风 | 宝宝端设备需要发送实时声音 | 应用无法说明此时为何需要该权限 |
| 相机 | 视频是实际提供且可选的功能 | 视频并非核心功能、无法关闭，或相机权限被提前请求 |
| 本地网络 | 应用明确支持本地发现或同一网络内的设置 | 没有说明本地网络访问为何重要 |
| 位置 / 通讯录 / 广告标识符 | 只有极少数情况下，并且理由非常充分 | 通常不合理，因为这些权限与核心监护任务无关 |
设备角色逻辑
不同角色适合哪些权限？
宝宝端设备
几乎总是需要麦克风；仅使用视频时才需要相机；本地配对时也可能需要本地网络访问。
家长端设备
通常需要的权限更少：音频输出、通知，以及对讲时可能需要麦克风访问。
可选功能
只有在明确启用视频、对讲或本地发现等功能时，才有理由请求相应的额外权限。
请求时机和权限本身同样重要
Android 和 iOS 都要求在相关使用场景中请求受保护资源。对家长来说，这意味着一款靠谱的婴儿监护器应用会先说明设备角色，再请求麦克风或相机权限。如果一启动就把所有权限都要一遍，或许对应用方便，却会损害信任。
弹窗中的文字也很重要。“此设备需要麦克风权限，才能传送婴儿房里的声音”就很容易理解；没有上下文、只说“请授予访问权限”则不够。在婴儿房这种场景中，权限提示的措辞也必须严谨。
Android 和 iOS 虽有不同，但核心问题相同
Android
Android 的指南强调运行时请求、结合具体场景，以及确认某项权限是否仍确有必要。电池优化也常常是实际使用中需要考虑的问题。
iOS
Apple 将麦克风、相机和本地网络访问列为受保护资源，相关系统权限提示尤其重视用途说明。原则相同：这些访问权限可能是合理的，但必须有充分理由。
额外权限往往是最明显的警示信号
当婴儿监护器应用要求位置、通讯录、广告标识符或其他与核心功能无关的权限时，家长应特别留意。并非每项额外权限都一定有问题，但必须给出具体理由。解释越笼统，这项请求就越不可信。对于家庭和儿童相关产品，标准应比普通生活方式应用更高。
另一个警示信号是把核心功能和附加功能混在一起。若一个简单的音频监护器突然想获取多种系统访问权限，这款应用追求的目标可能比家长预期的更多。
如何识别有问题的权限
通常就比较合理——例如宝宝端的麦克风，或用户主动开启视频时使用的相机。
家长在信任这项请求前应更谨慎地核实。
这款产品很可能没有清晰地区分设备角色和使用场景。
安装前的权限检查清单
- 每一项请求的权限，是否都能清楚对应一个可见功能？
- 权限是否在恰当时机请求，而不是一次性全部索取？
- 宝宝端和家长端设备是否确实需要不同的权限？
- 位置或通讯录等额外权限真的合理吗？
- 视频是可选功能，还是应用把相机访问设成默认状态？
常见问题
为什么婴儿监护器应用需要麦克风权限？
宝宝端设备需要麦克风来传送实时声音。应用应说明请求原因，只将其用于监护，并清楚处理用户拒绝授权的情况。
如果我只想使用音频，必须允许相机吗？
不需要。设计良好的应用会让音频功能无需相机权限，并且只在你选择开启视频时才请求相机权限。
为什么可能需要本地网络访问？
在 Apple 设备上，设备需要在同一网络中互相发现或连接时，可能需要这项权限。它不会授予对文件或其他私密内容的访问权。
来源与延伸阅读
- 请求应用权限 · Android 开发者
- 请求访问受保护资源 · Apple 开发者文档
- NSLocalNetworkUsageDescription · Apple 开发者文档
- MediaDevices：getUserMedia() · MDN Web 文档
- 家庭政策要求 · Google Play 帮助
- 使用 Firebase 进行匿名身份验证 · Firebase 文档
- Babyphone Timmy 的安全性与架构 · Babyphone Timmy
- *Privacy Not Included – 联网产品购买指南 · Mozilla 基金会