Photo Recovery V1.0.3 真机动态证据索引#
设备:Pixel 6a 23261JEGR11550
包名:com.files.photo.recovery.restore.pro
版本:V1.0.3(versionCode 4)
日期:2026-08-12
当前状态#
| 项目 |
结果 |
| 安装来源样本 |
已安装线上样本;本轮版本核验为 V1.0.3 / 4 |
POST_NOTIFICATIONS |
已授权;用户报告启动页直接弹出系统通知权限,本轮未清数据复现弹窗 |
| 所有文件访问 |
已按常老大授权开启,MANAGE_EXTERNAL_STORAGE=allow |
| 通知使用权 |
已按常老大授权开启;系统详情页显示 Allow notification access=true |
| 前台服务 |
正在运行,通知 ID 2084960406 |
| WorkManager |
已安排,当前快照下一次约 13 分 49 秒 |
| 持久 Job |
已安排,priority 400;当前快照下一次约 19 分 55 秒 |
| Alarm |
已安排,当前快照约 7 小时 56 分后触发,窗口 1 小时 |
页面证据#
广告点位证据表#
测试规则:记录广告出现前页面、触发动作、广告格式、关闭后的落地页;不点击广告素材,不制造广告转化。
本轮新增动态结论#
- 所有文件访问和通知使用权已开启。
- Android 当前通知使用权详情页允许竞品读取 Real-time、Conversations、Notifications、Silent 四类通知,未看到竞品自己的系统级分类保护选择。
- 用
cmd notification post 制造的虚构通知在监听启用后未保留在系统活动通知输出中,符合“监听后被清除”的预期;但 shell 通知本身的系统生命周期也可能影响结果,仍需第二个自建 App 通知做交叉验证。
- 强停后重新启动,
MyNotificationListenerService 和前台服务均重新出现;前台通知仍为 ID 2084960406,START_STICKY 状态继续成立。
- 冷启动/重启多次出现 Google Mobile Ads
AdActivity,启动广告点位已动态确认。
- 通知管理页已动态确认:保存应用图标、通知标题、正文和日期,并提供“清除所有”;未发现筛选、搜索和白名单入口。
- 隐藏通知管理页已动态确认:一个全局“通知隐藏”开关,当前持久化状态为开启。关闭时页面内部虽出现逐 App 开关模型,但逐 App 开关为禁用状态。
- shell 合成通知未形成可复核的开关前后差异,因此不能据此宣称自动拦截与入库已完全验证;仍需独立测试 App 交叉验证。
- 反编译完整调用链确认:全局开关开启后,非 ongoing 且不在白名单的通知会先
cancelNotification(key),再转换为 NotificationBean 写入 Room。
- 默认白名单约 280 个包名,竞品自身包名运行时强制加入;用户逐 App 修改结果通过
NOTIFICATION_APP_WHITE_LIST_KEY 持久化。
- 划掉最近任务后 3 秒和 15 秒,通知监听、前台服务及进程均继续存活。
- 设备重启完成且未手动打开 App 时,监听服务和 ID
2084960406 前台服务已自动恢复;通知使用权保持授权。
- 临时撤销通知使用权会解绑监听,重新授权约 5 秒后重新绑定;测试结束已恢复。
- 强制进入 Deep Doze 的 10 秒观察点中,监听与前台服务继续存活;测试后已恢复设备
ACTIVE 状态。
新增系统状态证据#
| 文件 |
内容 |
dumps/10-after-reboot-services.txt |
重启后通知监听与前台服务状态 |
dumps/11-after-reboot-jobs.txt |
重启后 JobScheduler 状态 |
dumps/12-after-reboot-alarms.txt |
重启后 Alarm 状态 |
dumps/13-final-permissions-version.txt |
最终版本与关键权限状态 |