真机证据索引
真机证据索引返回统一总览

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 小时

页面证据#

编号 操作路径 页面/结果 截图
00 打开竞品 首页存在“通知清理”入口 00-initial-screen.png
01 首页 → 通知清理 先进入“请允许访问所有文件权限”引导,而非通知使用权引导 01-notification-cleaner-entry.png
02 关闭所有文件权限引导 返回 MainActivity,未授予高敏感存储权限 02-after-dismiss-all-files-guide.png
03 开启所有文件访问 系统授权过程证据 03-all-files-system-setting.png
04 权限开启后启动 重新启动竞品 04-after-permissions-launch.png
05 系统设置 → 通知读取、回复和控制 Photo Recovery 已进入 Allowed 分组 05-notification-access-list.png
06 Photo Recovery 通知使用权详情 总开关为开;Real-time、Conversations、Notifications、Silent 四类读取权限全部勾选 06-notification-access-detail.png
07 首页 → 通知清理(权限已开) 通知管理历史页;展示应用图标、标题、正文、日期,底部为“清除所有” 07-notification-management.png
08 通知管理 → 隐藏通知管理 “通知隐藏”总开关当前为开;副文案“在通知栏中隐藏应用通知” 08-notification-hide-enabled.png
09 关闭通知隐藏 总开关可被用户关闭;测试结束后已恢复为开启 09-notification-hide-disabled.png

广告点位证据表#

测试规则:记录广告出现前页面、触发动作、广告格式、关闭后的落地页;不点击广告素材,不制造广告转化。

证据号 业务页面 触发动作 广告格式 是否实际出现 前置截图 广告截图 关闭后截图 备注
AD-001 冷启动/重新启动 启动竞品 Google Mobile Ads 全屏插屏/启动广告 已出现 启动页 AD-001-cold-launch-interstitial.png 首页 广告底部覆盖卡片,顶部显示 Continue to app;未点击广告素材
AD-002 启动广告 误触广告覆盖区域 外部落地页 已出现 AD-000-launch-webview.png 外部 Chrome 页面未作为广告成功点击证据使用 返回竞品 测试过程中误触,后续继续只使用返回键关闭广告
AD-003 Notification Management 退出页面 插屏请求场景 AD_SCENE_NOTIFICATION_EXIT_INT 本次未展示 07-notification-management.png 无填充/频控未出广告 AD-003-notification-exit-no-fill.png 静态代码确认 onDestroy 请求该场景;动态本次直接返回首页,因此不是每次必现

本轮新增动态结论#

  • 所有文件访问和通知使用权已开启。
  • Android 当前通知使用权详情页允许竞品读取 Real-time、Conversations、Notifications、Silent 四类通知,未看到竞品自己的系统级分类保护选择。
  • cmd notification post 制造的虚构通知在监听启用后未保留在系统活动通知输出中,符合“监听后被清除”的预期;但 shell 通知本身的系统生命周期也可能影响结果,仍需第二个自建 App 通知做交叉验证。
  • 强停后重新启动,MyNotificationListenerService 和前台服务均重新出现;前台通知仍为 ID 2084960406START_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 最终版本与关键权限状态
Photo Recovery V1.0.3 竞品逆向分析 · 2026-08-13