Cleaner 7 包保活恢复、通知召回与产品族群横向总览#

样本日期：2026-08-31
测试设备：Pixel 6a，Android 16 / API 36
范围：保活与恢复、通知召回、产品族群；不做可见清理功能盘点。

通知英文原文、中文释义、动态变量、触发条件、频控、通知 ID 和点击路由见：7 包通知场景、文案与触发规则全量摘录。

1. 最终结论#

1. 7 包不是 7 套完全独立技术。 当前可分为三类：Flare 独立族、Clean Sweep Master 独立族、五包白标核心族。
2. CleanMas + CleanLoom 是已确认的同产品族。 同 Play 开发者、同签名、同业务根、同主域、925 条 strings 精确相同。
3. BlazeClean + AuraClean 是已确认的同发布者同源代码族。 同 Play 开发者 Alsaeed、548 条 strings 精确相同、组件完全同构，还有 Aura 品牌残留进入 Blaze 包；但签名不同。
4. NeatPulse 是五包白标核心的独立品牌分支。 与 CleanMas 有 917 条 strings 精确相同，保活和通知算法同构；缺少同开发者/同签名证据。
5. 五包白标核心最成熟的点不是“永久保活”，而是多入口恢复编排。 specialUse FGS + 2–7 秒 Job + 21–25 分钟 persisted Job + 8 小时 Alarm + Boot + FCM + WorkManager，各包通过常量抖动和换名降低表面相似度。
6. Android 16 真机证明 Boot 恢复有明显时序差异。 CleanMas、CleanLoom、BlazeClean、AuraClean 本轮通过 Boot 白名单内短 JobService 成功建立 FGS；Clean Sweep Master 和 NeatPulse均有进程/服务启动尝试，但 FGS 被系统拒绝；Flare 的单包测试也未实现开机 FGS 恢复。
7. Force Stop 仍是统一硬边界。 7 包都没有证据可突破；剩余 6 包本轮强停复测均保持 stopped=true、无 PID，Flare 单包测试同样如此。
8. 通知召回都不是单一 FCM。 共同覆盖前后台、Home/解锁、包安装卸载、电池、网络、截图、Boot/升级、定时和 FCM；区别主要在配置模型、模板皮肤和频控颗粒度。
9. 最值得借鉴的是分层验收和统一恢复入口，不是照抄 specialUse。 应分别验证划卡、服务销毁、进程死亡、Boot、Doze、Force Stop 和通知权限关闭，不能把组件存在写成效果成立。

2. 样本清单#

所有样本均由测试机 Google Play 安装，installer 为 com.android.vending，已拉取 base + split 并完成签名摘要和 JADX 静态逆向。

3. 产品族群地图#

Cleaner 7 包
├── 独立族 A：Flare Cleaner
│   └── com.liam.garbagecleaner / freshenupapp.com
├── 独立族 B：Clean Sweep Master
│   └── CoreTaskExecutor / 30s Job / 15m WorkManager
└── 白标核心族 C
    ├── BetterFly Games 分支
    │   ├── CleanMas ─┐ 同签名、同业务根、同 cleanloom.com
    │   └── CleanLoom ┘
    ├── Alsaeed 分支
    │   ├── BlazeClean ─┐ 同开发者、同资源皮肤、签名不同
    │   └── AuraClean  ─┘
    └── 独立品牌分支
        └── NeatPulse：同核心算法与大量相同资源

3.1 族群证据强度#

“同技术母版”只表示代码和产品机制同源，不能直接推出同一公司、同一账号或同一法律主体。

4. 保活恢复横向对比#

4.1 Boot 成功链的真实机制#

四个成功白标包的系统日志都呈现同一顺序：

普通后台态直接请求主 FGS → DENIED
BOOT_COMPLETED 临时白名单内启动短 JobService → ALLOWED
应用进入 FGS 进程状态
由 JobService 再请求主 FGS → ALLOWED

这说明短 JobService 的价值是作为 Boot 豁免窗口内的前台桥接器。它不是绕过系统限制，而是利用系统在 Boot 场景给出的有限豁免。

NeatPulse 本轮 Boot Receiver 投递较晚，主 FGS和短 JobService都没有拿到有效前台启动资格；CSM 的 SolarMonitor 父类接收逻辑为空，进程初始化后直接启动 dataSync FGS 被拒。单轮结果不能换算成长期成功率，但足以证明“同样写了 Boot Receiver，动态结果会不同”。

5. 通知召回横向对比#

5.1 能证明与不能证明#

能证明：

• 客户端存在触发入口、模板、频控字段和点击路由；
• 正常启动后常驻通知真实存在；
• 部分业务通知在测试机真实发布；
• FCM Service 和 topic 订阅路径存在。

不能证明：

• 服务端当前向哪些用户、何时、以什么优先级发送；
• APK 默认配置就是线上最终配置；
• notify() 调用次数等于用户实际展示次数；
• 强即时性文案中的 RAM/垃圾/存储值一定来自真实扫描；
• 一次 Boot 成功等于长期可靠率。

6. 对我方最有价值的结论#

6.1 可借鉴#

• 统一恢复入口，避免 Service、Job、Boot、FCM 各自维护不同状态。
• 短 JobService 只承担恢复桥接，中/长周期任务承担配置、topic 和通知维护，职责分开。
• 将划卡、服务销毁、进程死亡、Boot、Doze、Force Stop 分成独立验收用例。
• 通知按事件入口、首次延迟、冷却、日上限、点击路由和服务端总频控分层。
• 记录 Boot 白名单是否命中、FGS 请求的系统拒绝原因，而不是只看进程是否出现。

6.2 不建议照搬#

• 不把 FOREGROUND_SERVICE_SPECIAL_USE 和 subtype quick entry 当通用保活通行证。
• 不承诺 Force Stop 后恢复或“永久保活”。
• 不使用未经真实测量支持的“RAM 已满、发现垃圾、电池异常”等召回文案。
• 不把高重要性业务通知和 FGS 常驻通知混为同一曝光指标。
• 不仅靠客户端频控；服务端还需时区、退订、人群排除、总上限和实验控制。

7. 未验证项#

• 多轮重启统计和小米/OPPO/vivo/三星等 ROM 差异。
• 自然进程回收、长时 Doze、App Standby restricted bucket 下的恢复率。
• 通知权限关闭后的 FGS、Job、FCM 和业务通知行为。
• 五包白标核心是否由同一最终法律主体控制；当前只确认技术同源层级。
• Remote Config / 自有配置接口的当前线上响应和服务端通知策略。
• 每个业务模板逐条动态展示、点击路由和真实测量值来源。

8. 报告入口#

• Clean/Flare_Cleaner_v1.0.7_保活恢复_通知召回_产品族群逆向报告.md
• Clean/Clean_Sweep_Master_v1.2.0_保活恢复_通知召回_产品族群逆向报告.md
• Clean/CleanMas_v1.0.7_保活恢复_通知召回_产品族群逆向报告.md
• Clean/CleanLoom_v1.1.8_保活恢复_通知召回_产品族群逆向报告.md
• Clean/BlazeClean_v1.0.7_保活恢复_通知召回_产品族群逆向报告.md
• Clean/AuraClean_v1.1.9_保活恢复_通知召回_产品族群逆向报告.md
• Clean/NeatPulse_v1.0.3_保活恢复_通知召回_产品族群逆向报告.md
• 样本总目录：Clean/cleaner-7-pack-2026-08-31/