看到权限弹窗时，简单地说“常见”或“不常见”都不够。应当读清应用自述用途、系统显示的权限名称和请求发生的场景。
先把权限翻译成具体能力
系统权限名称可能很宽泛，应用介绍中的功能说法则可能较简短。记录原始名称，不用自己熟悉的功能词替换。再问该能力为什么与当前页面的操作相关；若两者之间缺少解释，把缺口标为待核实。
看请求发生在何时
某项功能在用户明确触发时提出请求，与应用打开后立刻请求，提供了不同的阅读线索。但时机本身不能证明用途合理或不合理，还需要对应的产品说明、系统权限描述和版本信息。不同操作系统的权限分组也可能不同，不能混成一张没有平台标记的表。
核对后续控制方式
查找系统是否允许单次、使用时或完全拒绝等选项，并以设备实际显示为准。应用说明若声称某权限必需，可记录其对应功能；不能核实时，不要猜测权限会如何被使用。保存权限表时标注系统版本，日后更新才容易比较。
一条权限记录
- 系统显示的权限名称。
- 请求出现在哪个功能和时间点。
- 应用说明的用途、来源及待核实之处。
把权限放回触发场景
绘制一张三列表：系统显示的权限名、应用说明声称的用途、它实际请求出现的操作位置。填写时使用原始名称和文字，不把自己的推测写成用途。若某一列为空，标出需要哪份资料才能继续核对。
系统升级后，相同功能可能以不同权限组合呈现，因此给表加设备和系统版本。比较两次记录时先核对这些前提，再讨论变化。单看一张权限弹窗，既无法证明功能一定需要它，也无法证明请求必然不当。
把一项权限请求放到两个不同场景中想象：进入相关功能时出现，以及打开应用时出现。两种场景带来不同的核查问题，但不自动产生好坏结论。实际记录应写设备版本、权限原名、请求时间和应用提供的说明，而不是只留一张缺少上下文的弹窗图片。
阅读边注
权限名称与设置项会随系统版本变化；本文讲的是核对方法，不给某应用做权限背书。
继续核对
对安装链接本身缺少来源的情形，可先沿下一篇的检查路径处理。