三款清理类竞品真机动态验证与后台存活报告
三款清理类竞品真机动态验证与后台存活报告返回竞品库
报告口径本页直接渲染本地报告真源;静态能力、动态观察、推断和线上未验证项不得互相替代。

三款清理类竞品真机动态验证与后台存活报告#

文档日期:2026-10-12
验证日期:2026-09-30
设备:Google Pixel 6a,Android 16(SDK 36),安全补丁 2026-04-05
证据口径:D1=本轮真机直证;S1=APK 静态直证;I=基于多项证据的合理推断;U=未验证。
本报告只描述本轮样本与测试窗口,不把一次设备结果外推为全部 OEM、全部用户或线上长期效果。

1. 结论先行#

  1. 三款 App 都在首次进入产品前立即请求通知权限;用户同意后,都会建立常驻前台服务(Foreground Service,FGS)、常驻通知、周期 Job/Work 和约 24 小时后的 ELAPSED_WAKEUP Alarm。(D1)
  2. 三款 App 在按 Home 退到后台 12 秒后,以及从最近任务向上划掉 12 秒后,进程和常驻前台服务都仍存在,周期 Job 也仍在排队。当前样本能证明其“抗普通退出”链路在本机短窗口内生效。(D1)
  3. 系统“强行停止”是明确边界:三款 App 的进程、活动服务和活动通知均消失,原 Alarm 在系统历史中记录为 pi_cancelled,自有周期 Job 不再出现在活动 Job 清单中。不能把这套机制描述为“强停后仍能自启”。(D1)
  4. Swift Clean 在本轮实际发出一条场景拉活通知,标题为“背景應用正在拖慢手機”,正文为“太多應用在背景執行。一鍵釋放記憶體。”;通知 ID 为 21,重要性为 4。这证明其拉活模块不是只存在于反编译代码中。(D1)
  5. 广告介入非常早:三款均在通知授权后立即进入全屏广告;Pure Clean 还在首次引导完成后进入 AppLovin 全屏广告,Swift Clean 和 CleanTool 则在首个 CTA 后出现第二次 Mintegral 全屏广告。(D1)
  6. 本轮未授予“所有文件访问”(All files access),因此没有执行真实全盘扫描、删除或清理。功能入口和权限路径已验证,清理准确率、删除效果与空间收益仍为 U。

2. 样本身份与纠错#

用户输入/公开入口 本机实际包名 本机版本 targetSdk 动态结论范围
Pure Clean Master com.pureclean.smartfile.master 1.1.8 (19) 37 以本机 Play 安装样本为准;公开页曾显示 1.1.2,存在版本差异
Com.swift clean.phone.managepro com.swiftclean.phone.managerpro 1.0.9 (11) 36 原输入包名不存在;已按设备与 Play 结果纠正为无空格、managerpro
com.brisksignal.easyproxyapp com.brisksignal.easyproxyapp 2.3.1 (231) 36 商店产品名实际为 CleanTool:file manager,不是代理/VPN 产品

三款均为 Play split APK(基础包 + arm64-v8a + xxhdpi)。APK 哈希、签名、版本和组件索引见各包的《样本与证据索引》;本报告不以商店页版本覆盖已提取 APK 的真实版本。

3. 权限测试边界#

本轮只同意了 Android 13+ 的通知运行时权限,未授予下列高影响特殊访问:

  • MANAGE_EXTERNAL_STORAGE(所有文件访问);
  • Notification access(通知使用权);
  • Usage access(使用情况访问)。

因此:

  • 可以验证通知、前台服务、Job、Work、Alarm、首启流程与广告;
  • 可以验证所有文件访问的提示和系统设置跳转;
  • 不能验证全盘扫描/删除、第三方通知撤下、按 App 流量统计的真实效果;
  • 不使用调试命令绕过系统授权,避免把非真实用户路径误写成产品能力。

4. 首次启动与广告链路#

4.1 Pure Clean Master#

实测顺序:

  1. 首启进入扫描式背景,同时立即弹系统通知权限;
  2. 同意后进入 Mintegral 的 MBRewardVideoActivity 全屏广告;
  3. 关闭广告后进入设备/系统/存储信息引导页,CTA 为 Start to Use;
  4. 点击 CTA 后进入 AppLovin AppLovinFullscreenActivity 全屏广告;该素材至少观察 30 秒,返回键未退出;
  5. 为进入主界面,本轮关闭网络后重新启动,随后恢复网络;
  6. 首页/工具页可见缓存、大文件、通知清理、相似照片、截图、应用管理、流量、RAM 和设备信息等入口。

证据:

判断:广告位强度与静态 newcleanStart/extra 配置一致;具体素材由广告平台实时返回,截图只能证明本次展示,不能认定为 App 永久固定素材。(D1/I)

4.2 Swift Clean-Phone Manager Pro#

实测顺序:

  1. 首启立即请求通知权限;
  2. 同意后进入 Mintegral 全屏广告;
  3. 关闭后进入 ScanGuidePage,显示设备信息与“快速清理”;
  4. 点击“快速清理”再次进入 Mintegral 全屏广告;
  5. 关闭后出现 App 自绘的“一键清理垃圾文件”权限引导;
  6. 点击继续进入系统 All files access 页面,同时覆盖一层教学遮罩;关闭遮罩后能确认开关保持关闭;
  7. 返回后仍可进入首页,看到通知清理、RAM、网络流量、测速、应用管理、大文件、截图、相似照片和设备信息等入口。

证据:

4.3 CleanTool:file manager#

实测顺序:

  1. 首启立即请求通知权限;
  2. 同意后进入 Mintegral 全屏广告,本次素材使用“Memory is full”叙事;
  3. 关闭后进入设备信息引导页;
  4. 点击 Start to Use 后再次进入 Mintegral 全屏广告,本次素材使用“PDF 过期/需更新”叙事;
  5. 关闭后进入首页并立即展示所有文件访问提示;本轮关闭提示、未授权;
  6. 首页/工具页可见缓存、大文件、通知清理、相似照片、截图、应用管理、网络流量、测速、RAM 和设备信息等入口。

证据:

本次广告素材具有“设备内存不足”“PDF 失效”等系统/文件风险暗示。这里只记录本轮实际素材;是否构成误导以及素材责任归属仍需结合广告来源、地域、投放后台与平台政策专项审核。(D1/U)

5. 后台存活实测#

5.1 启动前后差异#

三款在首次启动前均未观察到自身活动 Service、Job 或 Alarm;完成通知授权并进入产品后均建立后台链路。(D1)

App 常驻服务 FGS 通知 周期任务 Alarm
Pure Clean com.ai.smart.gXXfik ID 1,channel_id_resident,ongoing/no-clear WorkManager job(系统 ID 可变化)+ 自有 job 3432 com.ai.smart.BpFZcYhmZ,ELAPSED_WAKEUP,约 24 小时
Swift Clean crown.arithmetic.floor.mowxgu ID 20,crown_floor,ongoing/no-clear WorkManager job + 自有 job 20 crown.arithmetic.floor.kQuACgQQ,ELAPSED_WAKEUP,约 24 小时
CleanTool com.ai.smart.gXXfik ID 1,channel_id_resident,ongoing/no-clear WorkManager job + 自有 job 3432 com.ai.smart.BpFZcYhmZ,ELAPSED_WAKEUP,约 24 小时

注:三款都使用 AlarmManager.set(type=2, ...);Android 常量 2 是 ELAPSED_REALTIME_WAKEUP。它具备 wakeup 类型,但不是 exact Alarm,系统仍可批处理或延迟。

5.2 Home 退后台 12 秒#

App PID 仍存在 FGS 仍为 foreground 结论
Pure Clean 8358 是,ID 1 短窗口后台存活成功
Swift Clean 9630 是,ID 20 短窗口后台存活成功
CleanTool 12895 是,ID 1 短窗口后台存活成功

证据:各包 evidence/services-background-12s.txt。

5.3 最近任务划掉 12 秒#

App PID 仍存在 FGS 仍在 自有周期 Job 仍排队 结论
Pure Clean 是 是 job 3432 + WorkManager onTaskRemoved/FGS 链在本机短窗口内有效
Swift Clean 是 是 job 20 + WorkManager 同上
CleanTool 是 是 job 3432 + WorkManager 同上

证据:

  • */evidence/recents-before-swipe.png
  • */evidence/recents-after-swipe.png
  • */evidence/services-after-recents-swipe-12s.txt
  • */evidence/jobs-after-recents-swipe-12s.txt

“12 秒后仍在”不能外推为数小时/数日持续存活,也不能替代 Doze、低电量、后台受限和 OEM 杀进程测试。(U)

5.4 系统强行停止#

三款在 am force-stop 后 3 秒均出现:

  • pidof 无结果;
  • dumpsys activity services <package> 无活动服务;
  • 活动通知记录消失;
  • 自有活动 Job 定义不再出现,仅可能在系统历史统计中留下旧记录;
  • Alarm 历史明确记录 Reason=pi_cancelled。

证据:各包 evidence/force-stop-after-3s.txt。

推荐对外结论:可以描述为“普通退后台/划任务后仍尝试保持服务”,不可描述为“强停后自动复活”。

6. 通知动态证据#

6.1 常驻通知#

三款均生成自定义 RemoteViews 常驻通知,包含多个清理快捷入口与实时网速;系统记录为 ONGOING_EVENT | NO_CLEAR | FOREGROUND_SERVICE。通知正文不走标准 title/text 字段,因此仅靠通知 dump 无法完整读取图形化布局文字,需结合通知栏截图与反编译资源。(D1/S1)

通知栏截图:

测试机同时安装了多款清理竞品,截图中存在其他包的常驻卡片;视觉卡片归属以 dumpsys notification 的 package、ID、Channel 和 RemoteViews 记录为准,不凭相似图标猜测。

6.2 Swift Clean 场景拉活通知#

本轮在 Swift Clean 首启后观察到:

字段 动态值
package com.swiftclean.phone.managerpro
notification ID 21
Channel 构建记录为 cleaner_help2;系统 effective channel 为 event_recall_channel_v2
Channel name EnMusic 提醒(与清理产品语义不一致)
标题 背景應用正在拖慢手機
正文 太多應用在背景執行。一鍵釋放記憶體。
flags `ONGOING_EVENT
importance 4(HIGH)
点击 startActivity PendingIntent
划掉 broadcastIntent delete PendingIntent

证据:swift-clean/evidence/notifications-after-launch.txt。这条通知与静态“后台应用/RAM”模板和点击路由应在 Swift 专项通知报告中交叉核对。

7. 当前未验证项#

  1. 未授予所有文件访问,未验证清理扫描、删除准确率、删除恢复性与空间收益。
  2. 未授予 Notification access,未动态验证“读取、落库并撤下第三方通知”的真实行为。
  3. 未授予 Usage access,未动态验证按 App 流量/最近使用时间的准确性。
  4. 未逐个触发截图、安装/卸载、充放电、低电量、解锁、最近任务、网络切换、20 条通知、广告外跳、自动、FCM 等全部通知场景;全量规则主要来自静态反编译。
  5. 未验证线上 Remote Config 当前值、FCM 服务端频次/受众/payload、广告 waterfall/bidding 和地域差异。
  6. 未做重启、升级、Doze、后台受限、电量低、断网数小时、多 OEM 长窗口保活测试。
  7. 未抓包,因此 SDK 打包、日志和一次广告 Activity 不能替代真实网络请求归因。

8. 给开发的使用建议#

  • 实现参考优先看各包《保活与拉活反编译代码册》,再回到完整 jadx/ 核对失败方法;不要直接复制等价伪代码。
  • 产品规则优先看各包《拉活通知规则与文案全量报告》;Remote Config 和 FCM 标为 U 的部分必须补线上实测。
  • Android 适配需要把“普通划任务”“进程被系统回收”“用户强停”分成三种状态,三者不是同一能力。
  • 不建议照搬未经真实检测的“内存高、存储低、后台 App 拖慢”等状态文案;动态变量必须来自可解释的当下测量。
  • 常驻 FGS、specialUse、所有文件访问、通知使用权和开机广播均涉及 Google Play 合规,应先确认用途与披露,再讨论实现。
竞品拆包报告库 · 逆向结论按证据等级阅读