Android公共安全类应用通常运行在应急调度、社区安防、现场巡检等强监管场景中，这类软件对设备能力的使用深度远高于普通App。由于涉及个人位置、通话记录、媒体采集等敏感资源，一旦在权限使用和隐私保护上出现疏漏，不仅会通过应用商店审核失败，还可能违反公共安全行业的合规红线。因此，针对此类应用的测试不能只停留在界面功能，必须把系统权限模型和隐私数据流作为核心验证对象。
Android权限模型与公共安全场景的映射关系
Android系统从6.0开始将权限分为普通权限和危险权限，危险权限进一步按功能聚合成权限组，例如位置组包含ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION。公共安全应用为了实时回传现场坐标，往往会申请精细位置权限，但不少开发人员在清单文件里直接声明了整个权限组，导致用户授权时看不到具体用途。从测试视角看，第一步应当是反编译APK并提取AndroidManifest.xml，核对每一个uses-permission是否真的被代码调用。
我们可以用apkanalyzer或者AXMLPrinter2把二进制清单转成文本，重点看是否出现了READ_CALL_LOG、CAMERA、RECORD_AUDIO等高风险声明。如果发现某公共安全App在清单中声明了READ_SMS却没有任何短信模块，就说明存在过度申请。此时测试人员应记录为权限冗余缺陷，并建议开发改为按需动态申请，或在产品说明中补充法律依据。
除了静态声明，运行期权限弹窗也是验证重点。系统通过ActivityCompat.requestPermissions向用户索取授权，测试需要覆盖用户拒绝、永久拒绝、仅本次允许三种路径。特别是在现场网络不稳定的情况下，若App未处理onRequestPermissionsResult中的denied分支，就可能直接崩溃，影响公共安全任务的连续性。下面是一段用于模拟权限拒绝后兜底逻辑的参考代码：
// 处理位置权限回调
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
if (requestCode == 1001) {
if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
startLocationReport();
} else {
// 公共安全场景下应降级为手动坐标上报
showManualInputDialog();
}
}
}
隐私数据流向追踪与越权采集识别
公共安全测试里最容易被忽略的是后台隐私采集。很多App在前台声明了位置权限，却在用户退出后通过后台服务继续调用LocationManager或FusedLocationProviderClient，这种静默行为在常规功能测试中很难暴露。测试人员可以借助adb命令adb shell dumpsys location观察系统服务中活跃的定位请求来源包名，从而判断目标应用是否在非必要时段拉取坐标。
另一个高风险点是剪贴板和媒体库的读取。Android 10之后系统限制了后台读取剪贴板，但部分公共安全应用为了快捷填充表单，会在输入框聚焦时调用getPrimaryClip。如果测试没有构造包含身份证号、电话号码的剪贴板样本做注入验证，就无法发现敏感信息回传漏洞。我们通常使用如下adb指令向设备写入模拟数据：
adb shell am broadcast -a clipper.set -e text "身份证110101199003078888电话13800000000"
在追踪数据流时，建议结合网络抓包与代码静态扫描。例如利用mitmproxy拦截App出向请求，看上报字段里是否混入了未脱敏的android_id或IMEI。若发现明文传输，需在报告中标记为隐私泄露高危，并对照《公共安全移动应用安全规范》给出整改项。同时，测试团队应维护一张敏感API对照表，把TelephonyManager.getDeviceId、Settings.Secure.getString等调用点列清楚，方便回归。
| 敏感API | 常见滥用场景 | 测试手段 |
|---|---|---|
| getLastKnownLocation | 后台周期上报 | dumpsys location监控 |
| getPrimaryClip | 聚焦读取剪贴板 | adb注入模拟数据 |
| MediaStore查询 | 全量遍历相册 | 权限拒绝后观察崩溃 |
自动化检测工具链与回归用例设计
面对频繁发布的公共安全版本，纯手工测试效率太低，需要搭建自动化工具链。最基础的组合是静态扫描加动态沙箱：静态侧用Androguard提取权限和方法调用图，动态侧用adb grant/revoke配合UI自动化框架点击关键路径。这样可以在每次构建后自动产出权限合规报告，指出新增了哪些危险权限、删除了哪些防御逻辑。
在回归用例设计上，建议按权限组来组织场景。比如位置组用例覆盖首次启动授权、使用中收回权限、系统重启后状态保持；摄像头组用例覆盖锁屏状态下触发采集、多App抢占摄像头的异常恢复。每条用例都要写明预期的系统回调和UI提示，避免开发人员以“系统差异”为由搁置缺陷。下面给出一个用UiAutomator执行权限弹窗点击的片段：
// 自动允许位置权限弹窗
UiObject allowBtn = new UiObject(new UiSelector().text("允许"));
if (allowBtn.exists()) {
allowBtn.click();
}
// 验证上报服务已启动
UiDevice.getInstance().executeShellCommand("dumpsys activity services com.pub.safety");
最后，测试负责人应把公共安全合规清单纳入发布门禁。任何未通过权限最小化核查、隐私加密校验的包体都不允许进入生产环境。只有把模型理解、数据流追踪和自动化回归三者串起来，才能让Android公共安全应用既好用又经得起监管抽查。
Androidpublic_safetypermission_test修改时间：2026-08-18 14:50:31