报告口径本页直接渲染本地报告真源；静态能力、动态观察、推断和线上未验证项不得互相替代。

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

包名：com.blaze.cleaner.clean.storage
样本：Google Play 当前安装包，versionName V1.0.7，versionCode 8
测试设备：Pixel 6a，Android 16 / API 36
报告日期：2026-08-31

1. 一页结论#

[静态 + 动态确认] BlazeClean 是白标常驻框架的另一资源分支。 主 FGS GcPoRRCp.o6MRacr 为 specialUse/quick entry、START_STICKY；正常启动 PID 30388、通知 ID 88888。
[静态确认] 快速恢复 Job 为 4.852–6.852 秒；周期 persisted Job 为 20分59秒–21分3.852秒；Alarm 约 8 小时。 与 CleanMas/CleanLoom/NeatPulse 同算法但常量不同。
[动态确认] 主 FGS、周期 Job 和 Alarm 全部真实存在。 Job ID 5470，Alarm 为 ELAPSED_WAKEUP 且有约 1 小时系统批处理窗。
[动态确认] 本次重启后恢复成功。 Boot 初期直接启动主 FGS被拒；RdroDbQ.o6MRacr 短 JobService 在 Boot 白名单内获得前台资格，再启动主 FGS。
[动态确认] Force Stop 是硬边界。 10 秒无 PID，stopped=true。
[静态确认] 通知召回覆盖内存/存储/垃圾、包安装卸载、充电/低电量、网络、截图、Home/解锁、后台和 FCM。 Blaze 与 Aura 的资源和通知模型高度一致。
[族群确认] BlazeClean 与 AuraClean 的 Google Play 开发者同为 Alsaeed，代码结构与 548 条 strings 精确一致。 但两包 Play 签名不同，所以应写“同开发者 + 同代码母版”，不能写成“同签名发布”。
[强指纹] Blaze APK 中还残留 AuraFnavAdActivity、AuraClean Firebase bucket/project 等资源。 这不是普通相似，而是同源工程换皮留下的交叉品牌残留。

2. 样本身份#

项目	值
应用名	BlazeClean
applicationId	`com.blaze.cleaner.clean.storage`
版本	`V1.0.7`（versionCode `8`）
minSdk / targetSdk	24 / 36
base APK 大小	28,867,350 bytes
base APK SHA-256	`fdd7f6d818402ad44597fe18bda0e803247c34e0f9762bf73302a5a41c1a888c`
签名 SHA-256	`6e3c4838d3ab9ee15a271a0228bd696d07e8553ef7b1e4bb88605a1d245edb76`
业务代码根	`com.blacln.mmi`
Play 开发者	Alsaeed
安装来源	Google Play，installer=`com.android.vending`

3. 保活与恢复#

Boot / 正常启动 / onDestroy / onTaskRemoved
                  │
                  ▼
 GcPoRRCp.o6MRacr 主 FGS
 specialUse / quick entry / START_STICKY / ID 88888
                  │
                  ▼
 RdroDbQ.o6MRacr 短 Job（4.852–6.852 秒）

RppUoJP.o6MRacr：约 21 分钟 persisted Job
OCP8Og6g.o6MRacr：约 8 小时 Alarm
PB.o6MRacr：BOOT_COMPLETED / MY_PACKAGE_REPLACED
GwLbqpLD.o6MRacr：FCM

组件	当前值	作用
主 FGS	ID `88888`，specialUse，START_STICKY	常驻载体
快速 Job	4,852–6,852ms	恢复桥接
周期 Job	1,259,000–1,263,852ms	persisted/high 周期机会
Alarm	28,797,843ms	约 8 小时通知/topic 维护
Boot Receiver	Boot + 包更新	进入恢复链

3.1 真机结果#

场景	结果
正常启动	PID `30388`；主 FGS `isForeground=true`；ID `88888`；START_STICKY
Job	ID `5470`；约 20分59秒–21分3.852秒；persisted/high
Alarm	约 7小时59分50秒后；window 1 小时
Force Stop	10 秒无 PID，`stopped=true`
重启	PID `11956`；短 JobService 与主 FGS 均为前台 ID `88888`；恢复成功

Android 16 日志显示：直接从普通后台态启动主 FGS 会被拒；Boot 临时白名单允许短 JobService 先进入 FGS，再通过 PROC_STATE_FGS 合法启动主服务。它依赖系统豁免链，不是无限后台启动能力。

4. 通知召回#

4.1 本轮动态#

常驻通知 ID 88888，渠道 BlazeCleanhBB，ONGOING | ONLY_ALERT_ONCE | NO_CLEAR | FGS。
本轮短观察窗未看到独立业务召回通知；静态模板存在不等于这次已经曝光。

4.2 静态策略#

Blaze/Aura 分支使用 a*_title/content、b*、d*、网络、截图、扬声器等模板组，入口覆盖：

Home、解锁、日期/定时、高值占用；
App 退后台；
安装/卸载其他 App；
充电、低电量、充满；
网络类型变化；
截图/媒体变化；
Boot、升级和 FCM。

展示前同样有前台、锁屏、屏幕、方向、首次延迟、冷却与上限判断。模板包含“存储满、RAM 满、发现垃圾、电池状态”等强即时性表达；是否由真实测量值驱动仍需逐条动态回查。

5. 产品族群#

5.1 BlazeClean 与 AuraClean#

证据	结果
Play 开发者	均为 Alsaeed
签名	不同，不能用同签名确认
strings	两包均 565 条，其中 548 条精确相同
组件布局	FGS + 2 Job + Boot + Alarm + FCM + NovaNotificationListenerService 同构
时间算法	同一抖动算法，仅常量不同
交叉残留	Blaze 内含 Aura 命名 Activity 与 Firebase 项目资源

结论：BlazeClean 与 AuraClean 是同发布者下的同源代码母版；签名不同可能来自 Play App Signing 的不同应用密钥，签名本身不支持跨包同一性。

5.2 与 CleanMas/CleanLoom/NeatPulse#

五包的恢复核心高度同构，属于同一白标技术框架的不同资源/发布分支。Blaze/Aura 的业务代码根、通知资源皮肤和发布签名与 CleanMas/CleanLoom 不同，暂不把“同技术框架”升级为“同法律主体”。

6. 未验证项#

多轮重启和不同 OEM ROM 的成功率。
自然进程死亡、长期 Doze、后台限制设置下的恢复率。
Remote Config 当前线上值、FCM 服务端策略和真实到达率。
每条业务通知的触发值是否来源于真实测量。
specialUse/quick entry 的商店合规合理性。
Force Stop 无法突破。

7. 证据位置#

APK：Clean/cleaner-7-pack-2026-08-31/blazeclean/apk/
JADX：Clean/cleaner-7-pack-2026-08-31/blazeclean/jadx/
关键类：GcPoRRCp/o6MRacr.java、RdroDbQ/o6MRacr.java、RppUoJP/o6MRacr.java、OCP8Og6g/o6MRacr.java、PB/o6MRacr.java、GwLbqpLD/o6MRacr.java
动态证据索引：Clean/cleaner-7-pack-2026-08-31/blazeclean/evidence/证据索引.md