Photo Recovery V1.0.3 竞品逆向分析统一总览#

更新时间：2026-08-13
竞品包名：com.files.photo.recovery.restore.pro
样本版本：V1.0.3（versionCode 4）
文档用途：统一查看竞品逆向事实、动态证据、产品逻辑、通知机制、通知清理能力、商业化链路及 Deep Cleaner 参考方案。
说明：本文是整合阅读入口，不删除或覆盖任何原始报告；正文中的 S1～S7 均可点击并回查文末“参考原文”。

目录#

• 1. 阅读结论
• 2. 证据口径与可信度
  • 2.1 证据分级
  • 2.2 样本可靠性
  • 2.3 阅读时必须保留的边界
• 3. 竞品基本信息
  • 3.1 关键敏感权限
• 4. 整体产品与商业逻辑
  • 4.1 七层结构
  • 4.2 核心商业闭环
• 5. 完整运行步骤
  • 步骤1：启动与初始化
  • 步骤2：读取权限状态
  • 步骤3：拉取并激活远程配置
  • 步骤4：注册后台任务
  • 步骤5：周期检查通知条件
  • 步骤6：选择场景和素材
  • 步骤7：展示通知
  • 步骤8：点击并统一跳转
  • 步骤9：业务操作与广告请求
  • 步骤10：继续调度与召回
• 6. 通知系统逻辑
  • 6.1 通知类型
  • 6.2 特殊通知属性
• 7. 通知触发与频控逻辑
  • 7.1 主调度模型
  • 7.2 两套内置兜底策略
  • 7.3 通知 ID、路由与单素材频控
  • 7.4 展示前置门槛
  • 7.5 场景选择优先级
• 8. 多语言文案逻辑
  • 8.1 推荐结构
  • 8.2 动态变量规则
  • 8.3 竞品原始通知素材池
• 9. 通知点击与页面路由
• 10. Notification Cleaner 通知清理逻辑
  • 10.1 用户链路
  • 10.2 用户看到的功能
  • 10.3 白名单逻辑
  • 10.4 权限和产品风险
  • 10.5 Deep Cleaner 通知清理参考规则
• 11. 后台调度与恢复逻辑
  • 11.1 调度链
  • 11.2 为什么需要多路调度
  • 11.3 已动态观察到的状态
• 12. 桌面小组件逻辑
  • 12.1 展示与入口
  • 12.2 刷新机制
  • 12.3 作用
• 13. 广告与商业化闭环
  • 13.1 已识别广告场景
  • 13.2 动态验证状态
  • 13.3 商业闭环
• 14. 已确认事实、合理推断与待验证项
  • 14.1 已确认事实
  • 14.2 合理推断
  • 14.3 尚未验证
• 15. Deep Cleaner 完整复刻范围
• 16. 高风险但仍进入复刻的设计
• 17. Deep Cleaner 完整复刻落地框架
  • 17.1 三套能力
  • 17.2 后台配置页面
  • 17.3 复刻通知场景
  • 17.4 竞品频控基线
• 18. 配置发布步骤
  • 第一步：建立全局安全开关
  • 第二步：建立路由字典
  • 第三步：建立通知场景
  • 第四步：录入多语言文案
  • 第五步：建立策略组
  • 第六步：逐场景测试
  • 第七步：灰度发布
• 19. 验证清单
  • 19.1 竞品后续验证
  • 19.2 Deep Cleaner 开发验收重点
• 20. 参考原文
  • 20.1 来源编号
  • 20.2 原文关系
  • 20.3 冲突处理原则

1. 阅读结论#

Photo Recovery V1.0.3 不是只靠“照片恢复”功能获得收入，它实际形成了一套完整循环：

工具功能吸引安装
→ 获取文件、通知等权限
→ Remote Config 下发通知和广告策略
→ Service / Job / WorkManager / Alarm / FCM 维持后台能力
→ 本地通知、FCM、小组件反复召回用户
→ 统一路由进入恢复、清理、通知管理等页面
→ 在启动、完成、退出等节点请求广告
→ 用埋点继续优化触达和变现

Deep Cleaner v1.0.3 的执行目标是全盘复刻这套系统结构及已确认的激进参数，不做“只参考结构、排除激进部分”的二次筛选：S1：摘要、第二至四章；S2：第4～8章

准确结论应表述为：

V1.0.3 是一款具备激进通知召回、持续后台调度、通知管理和高密度广告变现能力的文件恢复/清理工具。代码和真机证据能够证明这些能力存在并有部分实际运行，但不能据此断言所有线上用户都采用最高频策略，也不能直接证明团队主观恶意。S2：第1、8、9章

2. 证据口径与可信度#

2.1 证据分级#

2.2 样本可靠性#

来源：S2：第2章

2.3 阅读时必须保留的边界#

• APK 内置参数代表客户端具备的兜底能力，不等于线上 Remote Config 当前实际值。
• updatePeriodMillis=24h 代表向系统请求约24小时更新，不保证每天精确执行。
• Service、Job、Alarm、WorkManager 并存会提高恢复概率，但不代表用户一定无法停止 App。
• FCM Service 与服务恢复入口存在；不同优先级消息的最终分支仍需真实推送验证。
• NotificationListener 的取消代码路径已确认，但不同系统和通知类型的实际效果仍需专用测试 App 交叉验证。

来源：S2：第4～6、8～10章；S3：动态结论

3. 竞品基本信息#

来源：S1：第一章；S2：第2、3、7章

3.1 关键敏感权限#

来源：S1：1.2；S2：第3章

4. 整体产品与商业逻辑#

4.1 七层结构#

来源：S1：第二至四章；S4：第1～4、7、10章

4.2 核心商业闭环#

通知或小组件曝光
→ 用户点击
→ App 前台启动
→ 进入具体恢复/清理页面
→ 扫描或操作
→ 在启动、完成或退出节点请求广告
→ 记录通知点击、功能行为和广告数据
→ 调整下一轮策略

来源：S1：3.5、3.6、4.6；S2：第7章

5. 完整运行步骤#

步骤1：启动与初始化#

App 启动后执行许可证检查，初始化 Firebase、广告 SDK、配置、数据库和后台调度，并获取 FCM Token。S1：1.3、1.4、2.1、4.2

**作用：**建立通知、广告、配置和调度系统运行所需的基础环境。

步骤2：读取权限状态#

检查文件访问、通知权限、通知使用权以及后台相关条件。S1：1.2；S2：第3章

**作用：**判断哪些功能可以运行，哪些页面需要引导授权。

步骤3：拉取并激活远程配置#

从 Firebase Remote Config 获取通知开关、间隔、上限、素材和路由；拉取失败时使用 APK 内置 Offline_A / Online_B 兜底值。S1：2.2；S2：5.2

**作用：**运营无需重新发布 APK 即可调整通知策略。

步骤4：注册后台任务#

启动前台 Service，并安排快速 Job、心跳 Job、WorkManager、Alarm、开机/更新恢复和 FCM 入口。S1：4.1～4.3；S2：第4章

**作用：**不同调度机制相互补位，提高后台任务继续运行或恢复的概率。

步骤5：周期检查通知条件#

在允许窗口内按周期尝试，依次检查权限、设备状态、全局上限、素材冷却、通知栏数量等。S1：2.1；S4：4.1、4.2

**作用：**通知不是无条件按点发送，而是先经过一套决策门槛。

步骤6：选择场景和素材#

从照片、视频、截图、文档、联系人、通知清理等场景中选择符合条件的通知，再按语言和素材规则生成标题、正文及样式。S1：2.2；S4：第4、5章

**作用：**尽量让通知与用户当前状态对应，并支持远程替换素材。

步骤7：展示通知#

根据类型生成普通通知、广告召回通知、大样式通知或前台服务常驻通知。S1：第二章；S4：4.3

**作用：**针对不同运营和系统目标采用不同通知形态。

步骤8：点击并统一跳转#

通知点击先进入 NotificationTempActivity，记录埋点、读取路由并启动主 Activity，再进入目标功能页。S1：2.1

**作用：**统一处理初始化、数据记录、路由兜底和广告生命周期。

步骤9：业务操作与广告请求#

用户执行扫描、恢复、删除、清理、通知管理等操作；启动、完成和退出节点可能请求广告。S2：第7章；S3：广告点位证据

**作用：**把召回转化为业务活跃和广告收益。

步骤10：继续调度与召回#

后台任务、FCM 和小组件继续提供下一次检查或回访入口。S1：第三、四章

**作用：**形成持续运营循环，而不是一次性功能使用。

6. 通知系统逻辑#

竞品同时具备四套通知相关能力：

6.1 通知类型#

来源：S1：2.1、2.2；S4：4.3

6.2 特殊通知属性#

来源：S1：2.3、2.4；S2：5.1

7. 通知触发与频控逻辑#

7.1 主调度模型#

竞品主模型是“时间窗口＋循环尝试＋条件判断”，不是单纯固定时间点：S4：4.1

进入允许时间窗口
→ 按全局 interval 周期运行
→ 检查权限和设备门槛
→ 检查全局上限、间隔和通知栏数量
→ 从可用场景选择一条
→ 检查该场景/素材的上限、间隔和重复次数
→ 生成通知并记录时间、次数
→ 等待下一轮

固定 09:00 / 13:00 / 18:00 / 21:00 可以作为另一种策略，但不是本次逆向确认的竞品主模型。

7.2 两套内置兜底策略#

来源：S1：2.2；S2：5.2；S4：2.1

边界：这些是 APK 内置兜底配置，不代表当前线上所有用户实际使用 Online_B。

7.3 通知 ID、路由与单素材频控#

以下内容直接整合自常老大提供/指定整理的竞品通知原始材料：S5：第2、3章

需要区分两层限制：

Online_B 全局最短间隔：2分钟
单个素材自己的最短间隔：15分钟

这表示系统可以每2分钟尝试选择不同素材，但同一个素材项自身仍受15分钟限制；两者不能混为同一个字段。S5：第2章

7.4 展示前置门槛#

来源：S1：2.1；S4：4.2

7.5 场景选择优先级#

可用的合理决策顺序为：S4：4.4

1. 权限或功能异常提醒；
2. 用户刚完成操作后的结果提醒；
3. 有真实数据的待清理提醒；
4. 存储空间不足；
5. 通知积压；
6. 长时间未使用召回；
7. 通用品牌提醒。

该顺序用于 Deep Cleaner 参考方案，不代表竞品代码已完整确认同样的优先级实现。

8. 多语言文案逻辑#

8.1 推荐结构#

通知场景
├── 英文文案池
├── 西班牙语文案池
├── 葡萄牙语文案池
├── 其他语言文案池
└── 默认英文兜底

发送前执行：

确定场景
→ 获取设备/App语言
→ 查找对应语言文案池
→ 按权重、重复次数选择素材
→ 检查动态变量是否真实存在
→ 缺少对应语言时回退默认英文
→ 生成最终标题和正文

这是 Deep Cleaner 配置方案，不是目前已经完整反推出的竞品服务端多语言实现。S4：3.3、第5章、配置发布第四步

8.2 动态变量规则#

允许使用真实变量：

You have {count} screenshots to review.
（你有 {count} 张截图可以检查。）

竞品动态变量按当前有效数据填充；变量缺失或过期时使用竞品无变量素材：

Review screenshots you may no longer need.
（检查可能不再需要的截图。）

同时保留竞品资源中已经确认的固定文件数量、容量、提速比例、风险等级和“手机变慢”等原始素材。动态变量与固定宣称用 fixed_claim 区分，但两类都进入复刻范围。S4：配置发布第四步；S5：通知文案规则

8.3 竞品原始通知素材池#

竞品并不是“一条通知 ID 固定一组标题和正文”，而是按资源池随机组合：S5：第1章

Remote Config 选择 ntf_id 与 router
→ notification_resource_{id}
→ 从标题池选择标题
→ 从图标池选择图标
→ 从正文池选择正文
→ 点击后按 router 进入目标页面

主要素材方向如下：

固定虚假数字问题#

ID 9 的 APK 内置素材中存在以下固定数字：S5：ID 9

• 1.8GB Junk Detected（检测到1.8GB垃圾）；
• Speed Boost up to 35%（速度最高提升35%）；
• 23 Rarely Used Apps Detected（检测到23个少用 App）；
• Free 8.5GB（释放8.5GB）。

这些数字来自固定资源文案，不是根据测试机实时扫描结果动态计算。Deep Cleaner 按竞品完整复刻，原文进入正式复刻素材池，并标记 fixed_claim=true 便于测试识别；不得因其属于固定数字而自动删除。S5：第3、6章

文案策略观察#

完整逐条英文和中文对照仍保留在 S5，统一文档收录其结构、主要素材和风险，不重复堆叠所有同义候选。

9. 通知点击与页面路由#

竞品通过 NotificationTempActivity 收敛通知点击：S1：2.1

用户点击通知
→ NotificationTempActivity
→ 读取 notification_type / router / notification_id
→ 记录点击埋点
→ 保存目标路由
→ 启动 MainActivity
→ 进入照片、视频、清理或通知管理页

统一跳板的作用：

10. Notification Cleaner 通知清理逻辑#

10.1 用户链路#

首页点击“通知清理”
→ 竞品先检查/引导所有文件访问
→ 再检查 Notification access
→ 跳转 Android 系统设置授权
→ NotificationListenerService 连接
→ 读取当前和后续通知
→ 判断通知来源是否在允许集合
→ 对符合条件的通知调用 cancelNotification
→ 转换为 NotificationBean 并写入 Room
→ 在通知管理历史页展示

来源：S1：2.1；S2：5.3；S3：页面证据与动态结论

10.2 用户看到的功能#

真机已确认通知管理页保存并展示：S3

• 应用图标；
• 通知标题；
• 通知正文；
• 日期；
• “清除所有”入口；
• “通知隐藏”总开关。

10.3 白名单逻辑#

反编译调用链确认：S3：动态结论

• 默认白名单约280个包名；
• 竞品自身包名运行时强制加入；
• 用户逐 App 修改结果通过 NOTIFICATION_APP_WHITE_LIST_KEY 保存；
• 总开关开启后，非 ongoing 且不在允许集合的通知会先被取消，再写入本地数据库。

10.4 权限和产品风险#

来源：S2：第7、9章；S3：广告点位证据

10.5 Deep Cleaner 通知清理复刻规则#

以下规则是 Deep Cleaner 当前执行口径：按竞品已确认行为完整复刻；风险只用于测试标记，不再产生额外的保护、降级或排除规则。S6：第4～6、8～11章

权限规则#

• 分别记录 POST_NOTIFICATIONS 与 Notification access 的系统状态；
• Notification Cleaner 入口按竞品链路先进入所有文件访问权限引导，再进入通知使用权设置；
• 返回 App 后按竞品逻辑重新校验权限并进入管理页；
• 权限撤销、重新授权和服务重绑按竞品行为复刻。

白名单与 ongoing 规则#

• 内置竞品约 280 个默认白名单包名；
• Deep Cleaner 自身包名运行时加入白名单；
• ongoing 通知放行；
• 非 ongoing 且不在白名单的通知调用 cancelNotification(key) 后写入本地历史；
• 不增加竞品不存在的额外“高风险分类默认放行”规则。

本地数据边界#

只在本机保存实现通知历史所需的最小字段：来源包名、App 显示名、本地图标引用、标题/正文摘要、产生和隐藏时间、系统可得的类别/分组、已读与保护状态。S6：5.3

禁止上传中台：

• 通知标题和正文；
• 发送者、验证码和聊天内容；
• 通知图片；
• 原始 Intent / PendingIntent；
• 其他个人内容。

交互边界#

• “从系统通知栏隐藏”和“从 Tidyvo 本地历史删除”必须使用不同文案；
• 已从系统清除的通知不能承诺恢复到原 App 通知栏；
• 关闭总开关后，新通知恢复正常显示；
• 用户可以按 App 管理允许名单；
• 埋点只上传授权、开关、处理结果和数量分桶，不上传通知内容或来源包名。S6：5.4、6、9

11. 后台调度与恢复逻辑#

11.1 调度链#

来源：S1：第四章；S2：第4章；S3：当前状态和动态结论

11.2 为什么需要多路调度#

Android 后台任务会受到以下因素影响：

• Doze 深度休眠；
• 厂商省电策略；
• 用户划掉最近任务；
• 系统回收进程；
• 设备重启；
• 网络断开；
• Force Stop；
• Android 版本差异。

因此竞品不是依赖某一条绝对可靠的链路，而是让不同入口相互补位。作用是提高恢复概率，不是保证永远存活。S2：4.2、8、9章

11.3 已动态观察到的状态#

• 前台 Service 正在运行；
• 前台通知 ID 为 2084960406；
• 约24分钟持久 Job 已安排；
• 约18分钟 WorkManager 已安排；
• 约8小时 Alarm 已安排；
• FCM Service 有活动 ServiceRecord；
• 划掉最近任务后短时间观察中服务和进程仍存活；
• 设备重启且未手动打开 App 时，监听服务和前台服务恢复；
• 临时撤销通知使用权会解绑监听，重新授权后再次绑定；
• 短时 Deep Doze 观察中服务仍存活。

来源：S2：4.2；S3：当前状态、动态结论

12. 桌面小组件逻辑#

12.1 展示与入口#

小组件展示可清理空间/缓存状态，并提供清理、恢复和备份/联系人入口。S1：第三章

12.2 刷新机制#

• 系统周期请求：updatePeriodMillis=86,400,000ms；
• 进程存活期间：数据 Flow 变化时主动更新 RemoteViews。

来源：S1：3.3、3.4；S2：第6章

12.3 作用#

边界：24小时更新是系统调度请求，不保证每天准确唤醒。S2：第6、8章

13. 广告与商业化闭环#

13.1 已识别广告场景#

来源：S2：第7章

13.2 动态验证状态#

来源：S3：广告点位证据表

13.3 商业闭环#

通知/小组件召回
→ 启动广告
→ 用户进入功能
→ 扫描或完成操作
→ 完成/结果广告
→ 用户退出页面
→ 退出广告请求

因此通知系统不仅承担用户提醒，还承担扩大 App 启动次数和广告请求机会的商业目标。S1：3.6、4.6；S2：第7章

14. 已确认事实、合理推断与待验证项#

14.1 已确认事实#

14.2 合理推断#

14.3 尚未验证#

1. 当前线上 Remote Config 实际激活值；
2. 不同用户组每天真实收到的通知数量；
3. FCM 服务端的实际发送频率和优先级策略；
4. NotificationListener 对独立测试 App 各类通知的真实取消效果；
5. 不同 Android 版本和厂商 ROM 的恢复成功率；
6. 长达24小时以上的通知、Job、Alarm 实际执行轨迹；
7. 照片恢复究竟是恢复真实删除数据，还是主要扫描现存缓存、缩略图或可访问文件；
8. 团队主观动机、审核期和上线后的真实配置变化。

来源：S2：第9、10章；S3：动态结论

15. Deep Cleaner 完整复刻范围#

来源：S4：第3、4、8～11章

16. 高风险但仍进入复刻的设计#

来源：S1：2.4、4.7、第五章；S2：第9章

17. Deep Cleaner 完整复刻落地框架#

本章把竞品已确认结构、参数和素材转成 Deep Cleaner 执行方案。竞品尚未确认的服务端激活值继续标记待验证，但不删除对应客户端能力和配置字段。完整字段和场景见 S4。

17.1 三套能力#

17.2 后台配置页面#

来源：S4：第3章

17.3 复刻通知场景#

来源：S4：第5章

17.4 竞品频控基线#

18. 配置发布步骤#

第一步：建立全局安全开关#

先完成 master_switch、emergency_stop、允许时段、每日上限和全局间隔。没有紧急停发能力，不进入生产。S4：第9章

第二步：建立路由字典#

为每个目标页面建立稳定路由；非法、缺失或版本不支持的路由统一回到首页并记录错误。S4：3.4、第9章

第三步：建立通知场景#

逐个定义：触发条件、排除条件、优先级、冷却、上限、有效期、路由和停发条件。S4：第5章

第四步：录入多语言文案#

每条素材绑定场景、语言、变量、权重和默认兜底；变量缺失时不得发送带占位符的文案。S4：3.3、第9章

第五步：建立策略组#

完整建立并可直接发布竞品 Offline_A / Online_B，同时支持远程选择策略组、覆盖字段和回滚。不得再建立一套保守生产参数去替代竞品基线。S4：2.1、第9章

第六步：逐场景测试#

每个场景验证：条件满足、不满足、点击路由、语言、变量、冷却、每日上限、有效期和紧急关闭。S4：第9、11、13章

第七步：灰度发布#

按照内部测试 → 1% → 10% → 50% → 100%推进，观察授权率、送达/展示、点击率、清理完成率、通知关闭率、卸载率、崩溃率和投诉。S4：第9、10章

19. 验证清单#

19.1 竞品后续验证#

• 读取 Remote Config 当前激活值；
• 连续观察24小时以上的通知类型、时间、数量和来源；
• 用合法测试 FCM 验证 normal/high priority 分支；
• 用独立测试 App 验证 NotificationListener 白名单和取消行为；
• 分别测试 Home、划任务、停止服务、重启、Doze、后台限制和 Force Stop；
• 验证照片恢复的数据来源和真实恢复能力；
• 对不同 Android 版本和厂商 ROM 复测。

来源：S2：第10章；S3：动态结论

19.2 Deep Cleaner 开发验收重点#

• 总开关和紧急停发立即生效；
• 多语言按设备/App语言正确回退；
• 动态变量全部来自真实有效数据；
• 全局、场景和素材频控同时生效；
• 用户完成目标动作后同类通知停止；
• 通知点击进入正确页面，非法路由回首页；
• 用户关闭通知或营销提醒后不再发送；
• 权限只在对应功能入口申请；
• 设备重启、时区变化和 App 更新后重新校验计划；
• 成功、取消、失败和权限拒绝路径均有验证记录。

来源：S4：第11、13、14章

20. 参考原文#

20.1 来源编号#

20.2 原文关系#

S1 主逆向报告
  ↓ 由 S2 对 V1.0.3 重新复核和纠偏
S3 提供真机截图、系统状态和动态证据
  ↓
S4 将竞品事实转成 Deep Cleaner 可配置执行方案
S5 补充通知文案素材
S6 补充通知清理产品规则
  ↓
本文负责统一解释和索引，不替代原始证据

20.3 冲突处理原则#

当原文之间存在冲突时，按以下顺序判断：

1. V1.0.3 真机动态证据；
2. V1.0.3 独立复核中的明确静态调用链；
3. 主逆向报告中的静态发现；
4. Deep Cleaner 完整复刻执行方案中的字段映射和待验证标记。

Deep Cleaner 的执行范围不得反向改写为竞品线上已激活事实；静态能力也不能直接写成所有竞品线上用户的实际行为。但这些证据边界不影响 Deep Cleaner 完整建设同等客户端能力和配置字段。