Android使用限制应用是判断“是否立即允许此应用”并将其决定应用于实际设备的程序。理解代码结构和让操作系统执行该决定需要不同的验证。
REA是Reverse Engineer Anything的缩写，它是一个分析工具，用于连接代理以调查应用程序或二进制文件的结构和行为。通过REA找到类或调用关系，并不能得出应用限制策略是正确的、已获得必要的Android权限或在实际手机上能持续阻止的结论。REA官方仓库
本文以虚拟的Demo Controller和示例应用为基础，区分了分析、策略决策和Android执行，并设计了合成模拟器测试。本文未执行APK分析、模拟器或实际手机测试。不应将其解读为商业应用逆向工程或复制完成后的评论，也不是过去的测试业绩报告。
AI生成的概念图。不代表实际应用/手机屏幕或测试成功。
1. 从APK分析可知的部分开始区分
APK是分发Android应用的软件包。通过调查其结构，可以查看应用中声明了哪些组件，哪些代码调用了哪些API，以及策略存储或读取的位置。这为缩小调查的执行路径提供了依据。
REA官方的Android指南描述了通过JADX调查APK的清单、类、反编译方法和引用。REA的作用是将分析结果和证据连接到代理。反编译的描述是审查的线索，不能替代执行结果。REA Android分析指南
假设在虚拟的Demo Controller中，我们找到了“判断策略是否过期”的函数和“调用Android API”的函数。之后需要确认的问题如下：
- 分析的APK与当前要验证的构建版本是否相同？
- 发现的函数是否在实际执行路径中被调用？
- 调用时是否具备必要的管理权限和配置文件范围？
- 在失败、离线或重启后，是否仍应用相同的策略？
如果分析的是旧的调试APK，其结果是该产物结构的依据。不应将其扩大为确认最新实现的行为或或他应用的内部实现。通过反编译推断的条件必须通过自己的代码和测试再次确认。
2. 分离策略引擎和执行适配器
策略引擎是根据输入状态做出允许、限制或暂停等决定的部分。执行适配器是将这些决定连接到Android提供的API或经批准的设备管理手段的部分。
정책·허용 기간·현재 상태
↓
정책 엔진: 허용 / 제한 / 확인 대기
↓
Android 집행 어댑터: 권한과 적용 범위 확인 → API 호출
↓
실제 상태 확인: 대상 앱 진입, 실패 항목, 복구 상태决定立即限制示例应用与实际无法启动示例应用是独立的观察。即使策略引擎的单元测试成功，如果执行API被拒绝，设备状态也可能与预期不同。
测试记录也保持这种区分。
| 观察 | 含义 | 尚未确认的事项 |
|---|---|---|
| 策略结果为“限制” | 判断函数在给定输入下选择了限制 | 是否在Android上应用 |
| 执行调用已运行 | 适配器调用了API | 返回值、失败、实际应用状态 |
| 示例应用的Activity启动被阻止 | 在相应用户/设置下观察到进入限制 | 不同配置文件/操作系统/重启后的状态 |
| 模拟器场景通过 | 满足了相应测试环境的条件 | 实际手机和制造商的行为 |
这种分离也有助于评估实现。它可以分别调查策略条件是否错误、权限是否缺失、是否遗漏了应用失败，或者设备状态验证是否不足。
图：分析、判断、执行、观察阶段的区分。基于官方文档重构，并非本文中执行的开发或测试结果。官方依据1
3. DevicePolicyManager不会给任何应用相同的权限
DevicePolicyManager是Android的设备管理策略API。例如，setPackagesSuspended()是一个将指定用户的软件包设置为暂停状态的功能，它具有设备所有者、配置文件所有者或指定委托范围等调用条件。普通应用不会仅仅因为知道方法名称就获得该权限。DevicePolicyManager官方API)
这里，设备所有者（device owner）和配置文件所有者（profile owner）是Android的管理角色。不应将配置文件所有者的管理范围解释为控制整个个人区域的权限。必须确认要调用的API的当前用户、管理角色和委托条件。
根据官方文档，暂停的软件包会受到限制，例如无法启动Activity，但某些必需应用无法暂停。此外，API会返回未设置为请求状态的软件包列表。不要只记录“已调用”的日志，而应同时检查失败列表和目标的实际状态。
应用限制与强制终止所有运行进程和服务也不是同义词。必须首先定义要阻止哪些进入和行为，才能使测试准确。本文的“应用阻止”测试是根据明确的条件设计的，包括阻止示例应用的Activity进入。
创建管理角色的配置也是一个单独的程序。Android的管理配置流程是告知用户管理含义并设置设备或管理配置文件的所有者。设备所有者设置也有初始设置状态等前提，因此不能将其描述为像向现有个人设备添加一般权限那样简单。Android管理设备配置
在实验中，首先记录可初始化专用模拟器的管理条件。在撰写本文期间，未初始化或注册任何实际设备为管理员。不建议在未确认权限条件和合法管理范围的情况下测试执行。
4. 用两种时钟检查“时间已到”
在虚拟示例中，假设一个曾经允许的应用在一定时间后再次被限制。日历时间和经过时间是不同的标准。
Android的挂钟时间（wall clock），即日期和时间，可以由用户更改或校正。SystemClock.elapsedRealtime()表示自启动以来的经过时间，包括深度睡眠时间，是一个单调递增的时钟。这为区分通过回拨系统日期进行的测试和基于经过时间进行允许期测试提供了依据。Android SystemClock
使用单调递增时钟并不能自动解决重启问题。基于启动的值不能直接与上次启动的值进行比较。策略版本、保存的允许状态、重启后的恢复条件和重新确认方法必须单独设计。
离线终止也分为是否必须从服务器接收终止命令才能运行，以及是否根据本地保存的策略判断终止。在与服务器断开连接期间，对策略过期、更新、撤销信息的信任程度，以及在未确认时保持何种状态，都是设计者需要确定的条件。
作者的建议是，规定限制目标应用未经确认的允许不应无限期延长，同时也要设计维护管理界面和必要紧急功能的恢复路径。这并非Android官方强制阻止所有功能的规则，也不是本文中验证的完整实现。
5. 在合成模拟器中，同时准备正常对照和故障注入
下表是未来将要执行的测试设计。这不是本次撰写工作中执行的结果。将使用仅安装了示例应用和Demo Controller的专用模拟器，并将Android版本、管理角色、用户和构建标识固定为测试条件。
| 测试 | 合成条件 | 预期结果 |
|---|---|---|
| 正常对照 | 允许策略和所需权限已准备就绪 | 示例应用可进入，无过度限制 |
| 应用限制 | 策略引擎决定限制 | API失败项与示例应用进入状态一致 |
| 权限不足 | 无管理角色或范围的条件 | 不将应用失败记录为限制成功 |
| 离线终止 | 无连接时允许期结束 | 按规范进行本地决策和执行，检查是否存在未经确认的延长 |
| 时钟回拨 | 合成环境的挂钟时间更改 | 经过时间策略不会仅因日历移动而延长 |
| 重启恢复 | 具有保存状态的专用模拟器重启 | 策略、权限、执行状态的重新评估和恢复顺序 |
| 锁定·休眠 | 锁定·空闲后再次进入应用 | 设定的时间允许误差和恢复状态 |
| 新安装·策略变更 | 示例应用重新安装或策略版本变更 | 旧状态未被错误地重复使用 |
判断需要正常对照。不应将示例应用未安装或运行本身出现故障的状态计为阻止成功。应连接确认在更改策略前是否可进入，以及在应用策略后是否因预期原因被限制。
屏幕上显示“限制中”的单张截图不足以作为充分证据。必须同时阅读判断结果、API失败列表、实际示例应用行为以及启动/离线前后的状态。如果保存的策略版本与测试构建版本不同，则不应将这些结果合并为一次验证。
重启测试还需明确解锁前后的数据访问和恢复顺序。由于实际应用中预约、后台执行、存储和设备管理条件共同作用，因此不应将单个Python判断函数的结果重新表达为整个Android的执行结果。
将失败判断和恢复完成条件也纳入测试表
每个测试用例都应设计为包含构建标识、Android版本和用户、管理角色、策略版本、预期结果、API失败列表和实际Activity进入结果。如果只记录应用屏幕上的“限制”显示和API调用情况，可能会遗漏权限拒绝或部分软件包失败。这种方法将setPackagesSuspended()的失败列表与预期的策略结果进行对比，并单独确认示例应用是否实际可进入。Android软件包暂停API)
恢复场景包括在解除限制请求后示例应用是否可以重新启动、管理界面和必要的紧急功能是否保持、以及重启后是否重新确认策略版本和权限。此列表是未来将要执行的测试设计。由于尚未执行，因此不附带通过次数或成功率。
时间测试中，不仅要确定时钟类型，还要预先设定预期的终止时间和允许误差。即使经过时间已过，实际执行时间仍可能受到预约和后台执行条件的影响，因此不能仅凭使用了elapsedRealtime()这一事实就宣布在精确时间成功阻止。其结果必须在模拟器和实际设备上分别观察。
6. 模拟器结果和实际设备结果应单独列出
模拟器对于重复条件和注入故障很有用，但它不能代表所有制造商特定的电源管理、操作系统更新、实际设备的锁定/设置和使用模式。实际手机验证需要单独的授权设备、管理范围和恢复计划。
本文确认了REA官方和Android文档，并编写了上述测试的判断标准。未执行REA·JADX运行、APK获取·分析、Android策略API调用、模拟器和实际设备测试。实际实现结果应与构建、管理条件和执行范围一起，作为单独的验证记录进行评估。
在查看独立使用限制实现的状况时，仍有三个问题：分析了哪些产物，验证了哪些策略输入，以及在哪些Android权限和设备条件下确认了执行。将这三者分开，可以不将分析工具的成果和应用的实际限制功能混为一谈，从而做出判断。
发表回复