一、审计目标
在安卓手机通过无线 ADB 连接家庭服务器后，可以让自动化代理执行一次较为深入的非 Root 审计。
此次审计目标不是获取个人内容，也不是制作取证镜像，而是检查：
- 系统安全基线
- 已安装应用
- 权限与特殊访问
- 无障碍和通知监听
- 设备管理员
- VPN 与网络代理
- 电池和后台运行
- 崩溃与 ANR
- 共享存储残留
- 输入法配置
- APK 静态风险
整个过程遵循：
先只读审计
再人工选择整改
最后逐项验证
二、非 Root ADB 能做到什么
通过 ADB，可以获取：
- 系统版本和安全补丁
- SELinux 状态
- Verified Boot 状态
- Bootloader 锁定状态
- 用户和工作资料
- 应用包名与版本
- 安装来源
- 权限和 AppOps
- 默认应用
- 输入法
- 无障碍服务
- 通知监听器
- 设备管理员
- VPN 状态
- 电池与温控
- 内存和进程快照
- 网络接口与监听端口
- logcat
- 共享存储文件元数据
- 可访问 APK 文件
但它不能：
- 读取其他应用的私有数据库
- 解密聊天内容
- 获取密码和登录令牌
- 检查安全文件夹内部数据
- 检测所有内核级威胁
- 证明手机绝对安全
因此，这类任务应称为：
非 Root 系统与应用层安全审计
三、审计过程设计
审计分成两阶段。
第一阶段：只读采集
所有操作只读取，不修改：
- 不卸载应用
- 不撤销权限
- 不清除数据
- 不删除文件
- 不停用系统组件
- 不重启手机
- 不修改输入法
- 不调整 VPN 和网络
所有证据保存到服务器独立目录，并生成结构化报告。
第二阶段：定向整改
审计结束后，仅处理用户明确选择的项目。
每项整改必须包含：
- 修改前状态
- 精确目标
- 执行命令
- 修改后状态
- 非目标状态对比
- 回滚方法
四、系统安全基线
审计确认了以下基础安全状态：
- Android 使用正式用户构建
- SELinux 处于 Enforcing
- Verified Boot 状态正常
- Bootloader 保持锁定
- 未发现常见 Root 框架
- 未发现注入框架
- 没有异常 Android 用户
- 没有工作资料残留
- 没有固定 ADB 远程端口
- 系统代理为空
- 审计时没有活动 VPN
这些结果说明系统完整性基础正常。
未发现以下常见高风险迹象：
Magisk
KernelSU
APatch
Xposed
LSPosed
test-keys
SELinux Permissive
Bootloader unlocked
但“未发现”只能代表当前可见证据中没有，不能等同于绝对排除。
五、应用和权限审计
自动化代理逐个扫描了大量用户应用，并生成：
- 完整应用清单
- 用户应用清单
- 系统应用清单
- 运行时权限表
- 特殊访问表
- 高风险能力组合
- 安装来源和签名信息
重点检查的能力包括：
- 无障碍
- 通知监听
- 设备管理员
- 悬浮窗
- 管理所有文件
- 安装未知应用
- 使用情况访问
- VPN
- 输入法
- 自动填充
- 电池优化白名单
审计发现的高权限应用，大部分都能与实际用途对应。
例如：
- 远程桌面应用需要文件访问和后台能力；
- 代理客户端需要 VPN 服务；
- 输入法需要输入法服务；
- 手机互联工具需要通知访问；
- 屏幕辅助工具需要无障碍。
因此，高权限并不等于恶意。
风险判断必须结合：
权限
用途
安装来源
当前是否启用
运行状态
用户是否认识
六、一次重要的误判纠正
报告最初将某个远程桌面应用写成“无障碍已启用”。
但原始系统状态显示，它只是安装了无障碍组件，实际没有启用。
真正处于启用状态的无障碍服务只有两个用户明确使用的工具。
这说明自动化审计不能只依赖应用 Manifest 或已安装服务列表。
必须区分：
应用声明了无障碍服务
应用安装了无障碍服务
无障碍服务当前已启用
无障碍服务当前正在绑定
这四种状态完全不同。
七、共享存储中的残留 APK
共享存储检查发现一个文件名看起来像常见社交应用的 APK。
静态分析后发现：
- 实际包名完全不同；
- 是一个开发版本；
debuggable=true；- 没有安装；
- 没有明显危险权限；
- 文件名与真实内容不一致。
这类文件不一定恶意，但容易产生误解。
最终选择删除该 APK，并记录删除前哈希。
删除时严格限定：
只删除指定文件
不删除整个目录
不处理其他 APK
八、定向整改项目
根据审计结果，选择了四项整改。
1. 删除残留 APK
目标文件经过包名和哈希确认后删除。
删除后确认：
- 文件不存在；
- 同目录其他文件未变化；
- 没有误删目录；
- 没有删除其他安装包。
2. 关闭远程桌面应用悬浮窗
远程桌面应用仍然保留：
- 管理所有文件
- 剪贴板访问
- 后台能力
- 原有应用数据
只关闭：
SYSTEM_ALERT_WINDOW
修改后 AppOps 状态变为拒绝。
这种做法比卸载应用或批量撤销权限更精准。
3. 关闭浏览器安装未知应用权限
只针对一个浏览器关闭：
REQUEST_INSTALL_PACKAGES
其他浏览器保持原状。
修改后确认：
- 浏览器仍启用；
- 默认浏览器没有变化；
- 书签和历史未受影响；
- 其他权限未变化。
4. 停用运营商附加组件
手机原本属于运营商定制版本，但设备已经解除网络锁定，很多运营商附加功能不再使用。
审计后停用了一批明确属于以下类型的组件：
- 推荐内容
- 运营商商店
- 应用管理器
- 数据备份
- 帮助中心
- 日程附加功能
- 远程锁定
- 远程擦除
- 通知扩展
同时保留了可能关联以下功能的组件：
- 运营商初始化
- 网络服务
- APN
- IMS
- VoLTE
- SIM
- 身份服务
- FeliCa
- 系统设置
- 推送聚合
判断不清的组件没有盲目停用。
九、设备管理员处理中的细节
两个运营商远程管理组件原本注册为设备管理员。
直接通过 ADB shell 移除时，Android 拒绝了操作，原因是它们不是测试管理员。
随后对应应用被执行 user 级停用。
最终系统状态显示，这两个组件已经不再出现在活动设备管理员列表中，只剩厂商安全组件。
这说明：
直接移除命令失败
不等于最终管理员状态没有变化
最终判断必须以整改后的 dumpsys device_policy 为准，而不是只看某条中间命令是否报错。
十、整改后的系统验证
整改后确认：
- 指定 APK 已删除；
- 远程桌面应用悬浮窗已关闭；
- 浏览器未知来源安装权限已关闭；
- 运营商附加组件已停用；
- 默认输入法仍为 Fcitx5；
- Rime 和日语插件正常；
- 电话和 SIM 状态没有异常；
- 移动数据没有明显异常；
- APN、IMS 和 VoLTE 未发现被修改；
- 没有改变 VPN、Private DNS 或系统代理；
- 没有清除任何应用数据；
- 没有重启手机；
- 没有留下临时诊断文件。
十一、为什么手机可能变得更流畅
停用运营商附加组件后，手机主观上可能更流畅。
原因可能包括：
- 后台服务减少；
- 广播接收器减少；
- 通知监听减少；
- 周期性同步减少；
- 应用管理任务减少；
- 内存中的常驻组件减少；
- 系统调度压力下降。
但短时间的流畅感还可能受到：
- 手机温度
- 当前后台应用
- 内存回收
- 存储状态
- 网络状态
等因素影响。
更可靠的判断需要观察数天：
- 应用启动是否持续更快；
- 待机耗电是否改善；
- 后台杀进程是否减少；
- 电话、短信、移动网络和支付是否正常。
十二、哪些组件不应继续处理
剩余可能涉及运营商网络和系统集成的组件不应继续盲目停用。
特别是与以下功能有关的包：
CarrierConfig
APN
IMS
VoLTE
VoWiFi
SIM
eSIM
FeliCa
紧急呼叫
小区广播
系统更新
网络注册
即使平时看不到界面，也可能承担底层功能。
安卓系统优化不应以“包名看起来没用”为标准，而应以组件用途和系统依赖为依据。
十三、审计和整改的正确方法
这次实践说明，自动化代理处理安卓手机时，最可靠的流程是：
完整只读扫描
→ 生成证据
→ 人工选择项目
→ 单项整改
→ 前后对比
→ 验证非目标功能
→ 保留回滚记录
不推荐：
一键精简系统
批量停用运营商包
根据包名猜用途
一次撤销所有高权限
删除整个配置目录
自动化的价值不是“操作更多”，而是：
更准确地识别目标
更完整地保留证据
更小范围地修改
更可靠地验证结果
十四、最终结论
本次审计没有发现明确恶意软件、Root、系统注入或严重安全异常。
实际需要处理的内容主要是：
- 一个文件名与内容不符的残留开发 APK；
- 一个不再需要的悬浮窗权限；
- 一个不必要的未知来源安装权限；
- 一批已经失去用途的运营商附加组件。
整改后，系统基础通信和输入法保持正常，手机也出现了更轻快的主观体验。
这类非 Root ADB 审计无法证明设备绝对安全，但足以发现大量配置风险、权限冗余和预装服务负担，并在不破坏系统的前提下进行精细化优化。