Flare Cleaner v1.0.7 保活恢复、通知召回与产品族群逆向报告#

包名：com.flare.cleaner.storage
样本：Google Play 当前安装包，versionName 1.0.7，versionCode 8
测试设备：Pixel 6a，Android 16 / API 36
报告日期：2026-08-31
本报告只分析保活与恢复、通知召回、产品族群；不展开用户可直接看到的清理功能页面。

1. 一页结论#

1. [静态 + 动态确认] 它有前台服务恢复链，但不是“所有 Job/Alarm 都在拉 FGS”，更不是永久保活。 主服务 llLI.ILI1L 是 specialUse 前台服务，返回 START_STICKY；前台初始化、服务销毁/任务移除和高优先级 FCM 会直接请求主 FGS，启动异常时再由约 3.8–5.8 秒持久化 Job 兜底。约 23 分钟 Job、20 分钟 WorkManager 和约 8 小时 Alarm 当前静态调用点主要续订 FCM topic 并进入通知引擎，未见它们直接调用主 FGS 启动入口。
2. [动态确认] 划掉最近任务后，Flare 的任务卡消失，但原进程和原前台服务持续存在。 PID、ServiceRecord 和创建时间均未重置。这证明“划卡没杀掉它”，不是“被杀后成功拉活”。
3. [静态 + 动态确认] 单独停止前台服务后，它会在同一进程内快速重建。 这是服务级自恢复；不能外推为进程死亡后的可靠冷启动。
4. [动态确认] Force Stop 是硬边界。 强停后至少 17 秒内无进程、无服务，包为 stopped=true；只有人工重新打开后才恢复。
5. [动态确认] 本次真实重启没有观察到前台服务自动恢复。 BOOT_COMPLETED 的 20 秒临时白名单痕迹存在，持久化 Job 也跨重启保留，但设备已解锁后仍没有 Flare 进程/前台服务；人工打开后才重建。因此不能写“开机即可恢复前台服务”。
6. [静态 + 动态确认] 高优先级 FCM 同时承担拉起机会和用户召回。 客户端判断 google.delivered_priority=high 后先请求启动前台服务，再刷新通知；测试机曾记录 PUSH_MESSAGING 原因的约 20 秒临时白名单。
7. [静态确认] 本地通知召回不是单一“每天一次”。 它覆盖解锁/Home/最近任务、退后台、包安装卸载、电池、网络、截图、Alarm、开机/升级和 FCM 等入口，并叠加全局开关、首次使用延迟、前后台/锁屏判断、场景冷却和日上限。
8. [动态确认] 常驻通知与召回通知是两套东西。 常驻 FGS 通知 ID 为 66666、重要性 3；召回通知使用 30001…30011 场景 ID 和高重要性渠道。本次曾实际观察到 ID 30010 的 H2 召回通知。
9. [静态确认] APK 内置远端配置入口。 本地 assets/conf.json 是默认兜底，代码还包含 https://fese.freshenupapp.com/enConf。因此默认值不等于服务端当前线上最终值。
10. [当前库与测试机比对] 暂无证据把 Flare 归入现有竞品库中的已知产品族。 它与本地 7 个已拆 base APK、测试机另外 3 款清理 App 均不同签名；核心配置和代码指纹也未在当前库命中。现阶段只能建立 Flare 自身的技术指纹，不能硬判同厂兄弟包。

2. 样本身份与证据边界#

2.1 样本身份#

本次使用四种证据口径：

• 静态确认：Manifest、DEX、resources 或 assets 中直接可见。
• 动态确认：本次测试机实际操作以及 dumpsys、PID、Service、Job、Alarm、Notification 结果。
• 合理推断：多条事实共同支持，但没有服务端或跨设备验证。
• 待验证：当前 APK、设备或观察窗口不能确认。

2.2 关键边界#

• APK 中存在组件，不等于它在所有设备、所有时刻都能执行。
• Job/Alarm 的请求时间不是系统承诺的准点执行时间。
• FCM 客户端路径不能证明服务端人群、发送计划、TTL、实际优先级和线上到达率。
• 15 秒 Doze 短测只能证明已有前台服务短时未中断，不能证明长期待机或死亡后的恢复率。
• 本次没有撤销通知权限；通知权限关闭后的完整链路仍需单独验收。
• JADX 1.5.5 已生成源码与资源目录；11,766 个处理项中有 92 个反编译错误。关键的 FCM 高优先级分支因 Java 控制流还原不完整，已另用 DEX 指令反汇编复核；不把全部 JADX 输出当成无误原码。

3. 保活与恢复结构#

3.1 结构图#

【直接 FGS 恢复链】
前台初始化 / 高优先级 FCM
服务 onTaskRemoved / onDestroy
                 │
                 ▼
          统一启动入口 S7.d.h()
                 │
        ┌────────┴────────┐
        │启动成功          │启动异常
        ▼                  ▼
llLI.ILI1L 前台服务    ldlI7Sl.ILI1L 兜底 Job
START_STICKY            3.816–5.816 秒调度窗
（服务回调会重新进入上方统一启动入口）

【独立后台/通知维护链】
约 23 分钟持久化 Job / 20 分钟 WorkManager / 约 8 小时 Alarm
Boot / App 更新 / 解锁、Home、最近任务等系统事件
                 │
                 ▼
       topic 续订 + 通知引擎/召回场景
       （当前调用点未见直接 S7.d.h）

3.2 组件与职责#

3.3 关键参数#

3.4 真实限制#

• FOREGROUND_SERVICE_SPECIAL_USE 只是技术声明，不自动等于 Google Play 合规。
• 主 FGS、两个 JobService 和自定义 FCM Service 均声明了 exported=true；其中主 FGS 未见组件级权限保护，存在不必要的外部调用面。
• Android 16 对后台启动 FGS 有严格限制；注册更多入口不等于每条入口都能恢复 FGS。
• Force Stop 会把包置为 stopped，常规广播、Job、Alarm 和 Service 链无法自行突破。

4. 真机动态验证#

5. 通知召回系统#

5.1 两套通知必须分开#

本机重启后的一次统计窗口内，Flare 通知 78 次入队、其中 77 次为更新、仅 1 次新发布；当前只剩 ID 66666。这说明常驻通知被频繁刷新，但该计数不能解释为用户收到了 78 条营销通知。

5.2 召回入口和门槛#

说明：Eco_noticount_unlock=4、Eco_noticount_fcm=5、NotifiEcoBurstCount=2、AlarmecoInterval=120 是默认配置文件中的值；其中各字段在最终线上配置中的值可被远端配置替换。未把仅见配置值、尚未完整闭环到执行点的字段写成已验证线上频控。

5.3 当前 APK 内置的默认召回文案#

以下只列默认 English 标题和点击目的，便于识别策略，不展开产品页面。

5.4 通知策略判断#

• [事实] 文案大量使用“RAM 满、存储满、发现垃圾、电池异常、网络变慢”等即时性表达。
• [风险判断] 如果标题中的 %1$s 不是由真实测量值生成，而是随机/估算值，就会构成误导性召回；本报告只证明模板和路由存在，未证明每次展示值都来自真实扫描。
• [事实] 常驻通知为中重要性，业务召回渠道可达 importance 5；高重要性渠道更容易打扰用户。
• [事实] 客户端有多层本地频控，但服务端 FCM 的总频控、人群和发送计划不可从 APK 得出。
• [建议边界] 可借鉴“触发入口分层 + 每场景频控 + 点击路由”，不建议照搬夸张文案、过高渠道重要性或 specialUse 声明。

6. 产品族群指纹#

6.1 已确认指纹#

6.2 当前比对结果#

6.3 当前族群结论#

当前只能定义“Flare 技术指纹”，不能确认它属于竞品库里的某个既有产品族。 后续 6 个包拆完后，应使用同一组字段横向匹配：签名 SHA-256、配置域名、Adjust Token、广告位前缀、FCM topic、包内代码根、混淆组件名和通知模板事件码。只要出现 3 个以上独立高区分度指纹一致，即可提高“同产品族/同技术底座”的置信度。

7. 可借鉴与不建议照搬#

7.1 可借鉴#

• 用一个统一启动入口收口 Service、Job、Alarm、Boot 和 FCM，减少多入口状态不一致。
• 把“任务卡移除后持续存活”“服务重建”“冷进程拉起”“开机恢复”“Force Stop”拆成独立验收项。
• 给每个通知入口单独设置首次使用延迟、场景冷却、日上限和点击路由。
• 将 FCM 高优先级的短时执行机会与普通本地通知路径分开记录。
• 动态记录通知是新发布还是更新；不能用 notify() 次数代替用户实际曝光。

7.2 不建议照搬#

• 不应把 specialUse 当通用保活通行证。
• 不应把主 FGS 和 FCM Service 无保护地 exported=true。
• 不应承诺 Force Stop 后自恢复或永久保活。
• 不应使用未经真实测量支持的“垃圾已发现、RAM 已满、电池异常”等文案。
• 不应只靠客户端频控；服务端还需要总频控、人群排除、时区、退订和实验控制。

8. 未验证项#

• 通知权限关闭后，主 FGS、Job 和 FCM 的完整行为。
• Android 16 以外 ROM，特别是小米、OPPO、vivo、三星的后台限制差异。
• 周期 Job 在自然等待到期后能否从死亡进程恢复，以及是否能获批启动 FGS。
• 远端 enConf 当前线上返回值与分群规则。
• FCM 服务端的发送人群、频率、TTL、优先级降级率和真实到达率。
• H1/H3、全部电池/包变更/截图模板逐条动态展示与点击路由。
• 商店主体与其他公开产品的最终同族关系；当前仅完成本地签名与代码指纹比对。

9. 样本与证据位置#

• 原始 split APK：Clean/cleaner-7-pack-2026-08-31/flare-cleaner/apk/
• JADX 反编译：Clean/cleaner-7-pack-2026-08-31/flare-cleaner/jadx/
• 真机证据：Clean/cleaner-7-pack-2026-08-31/flare-cleaner/evidence/
• 本报告：Clean/Flare_Cleaner_v1.0.7_保活恢复_通知召回_产品族群逆向报告.md