Pure Clean Master 权限与后台机制拆包报告
Pure Clean Master 权限与后台机制拆包报告返回竞品库
报告口径本页直接渲染本地报告真源；静态能力、动态观察、推断和线上未验证项不得互相替代。

Pure Clean Master 权限与后台机制拆包报告#

文档日期：2026-10-12
静态样本：com.pureclean.smartfile.master，APK 1.1.8（19）。
S1=静态事实，I=合理推断，U=未验证。未操作测试机、未抓网络。

一、结论先行#

  1. 高权限组合明确：所有文件访问、Usage Access（使用情况访问）、Notification Listener（通知使用权）、通知、开机广播、前台服务、唤醒锁和应用卸载请求。 它们分别支撑文件清理、流量/应用管理、通知清理、通知召回和后台调度。（S1）
  2. 后台机制是多通道冗余，不是单点定时。 初始化 Provider、START_STICKY 前台服务、两个 JobScheduler、15 分钟 WorkManager、每日 10:00 Alarm、开机/升级接收器、系统事件动态接收器和 FCM 共同形成触发网。（S1）
  3. Android 14+ 有降级。 前台服务在 API 34+ 返回 START_NOT_STICKY，低版本返回 START_STICKY；系统/OEM 仍可限制后台启动，静态结构不等于实际保活成功。（S1/U）
  4. FCM 更像“远程唤醒/刷新入口”，不是已证实的可见通知发布器。 自有 FirebaseMessagingService 收到消息后调用保活/调度入口，但在该方法中未发现直接 NotificationManager.notify；可见通知是否由 payload 或后续逻辑发布需抓包验证。（S1/U）
  5. allowBackup=true 且组件存在导出面。 多个 App 自有 Service/Receiver 标为 exported=true，虽部分有系统权限保护，仍需做 Intent 注入和组件调用安全测试。（S1/U）

二、Manifest 权限总表#

Manifest 依据：jadx/resources/AndroidManifest.xml:12-30,74-86。

权限 类型 App 内用途/证据 判断
INTERNET 普通 广告、Firebase、Adjust、配置、网络工具 S1
ACCESS_NETWORK_STATE 普通 网络状态、广告前置判断、网络切换场景 S1
ACCESS_WIFI_STATE 普通 Wi-Fi/网络状态 S1
READ_EXTERNAL_STORAGE 危险/旧模型 文件、图片扫描；minSdk=32 时 API 32 仍可能使用 S1
WRITE_EXTERNAL_STORAGE maxSdk=28 旧权限 样本 minSdk=32，对可安装系统范围实际不可生效，属于遗留声明 S1/I
MANAGE_EXTERNAL_STORAGE 特殊访问 所有文件扫描、清理；代码跳转 All files access 设置 S1
PACKAGE_USAGE_STATS AppOps 特殊访问 流量、应用使用统计；跳 Usage Access 设置 S1
BIND_NOTIFICATION_LISTENER_SERVICE 签名权限声明 真正授权来自 Manifest 中 NotificationListenerService 与用户打开“通知使用权”；作为 uses-permission 本身不能由普通 App 获得 S1
REQUEST_DELETE_PACKAGES 普通/受系统确认 应用管理调用系统卸载页面 S1
FOREGROUND_SERVICE 普通 常驻前台服务 gXXfik/JobService 兜底 S1
FOREGROUND_SERVICE_SPECIAL_USE 普通+声明用途 两个服务声明 specialUse S1
POST_NOTIFICATIONS 危险（API 33+） 拉活提醒、常驻通知、通知清理提醒；启动页请求 S1
RECEIVE_BOOT_COMPLETED 普通 开机后重新启动/调度 S1
WAKE_LOCK 普通 打包依赖/后台任务可能使用；尚未确认 App 自有代码直接持锁 S1/U
AD_ID 广告标识 广告与归因 S1
ACCESS_ADSERVICES_TOPICS/ATTRIBUTION/AD_ID Privacy Sandbox 广告 SDK 能力 S1
com.google.android.c2dm.permission.RECEIVE 普通 FCM 收消息 S1
VIBRATE 普通 通知提醒 S1
CHECK_LICENSE、Install Referrer bind 商店/归因 Google Play 授权检查、安装来源归因 S1
Amazon attestation SDK Amazon 隐私/证明 SDK 组件 S1/U

2.1 权限调用链#

所有文件访问#

  • le.java:74-83,117-126 检查 Environment.isExternalStorageManager() 并构造 Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION。（S1）
  • 它支撑缓存、大文件、截图、相似照片的全盘读取与删除。（I，由页面与文件访问代码共同证明）
  • Manifest 未声明 READ_MEDIA_IMAGES/VIDEO，目标 SDK 37 下媒体访问是否完全依靠 MANAGE_EXTERNAL_STORAGE、系统选择器或其他路径，需真机覆盖 Android 13-17。（U）

Usage Access#

  • at.java:245 检查权限，me.java:144 查询使用统计，页面会引导用户打开 Usage Access。（S1）
  • 用于流量模块和应用管理的使用信息，不等于可读取其他 App 的业务内容。（S1）

Notification Listener#

  • 服务声明：AndroidManifest.xml:292-300，由系统权限 BIND_NOTIFICATION_LISTENER_SERVICE 保护。（S1）
  • NotificationListener.java:62-91 对非 ongoing、非自身通知读取标题/正文，调用 cancelNotification，保存本地记录并累计当日数量。（S1）
  • 这意味着用户授权后，App 能观察并移除第三方通知；隐私政策/Data Safety 应准确披露相关处理。（I，合规判断）

通知权限#

  • SplashActivity.java:175-181 在 API 33+ 检查并请求 POST_NOTIFICATIONS。（S1）
  • 通知策略再次用 areNotificationsEnabled() 做发布前门控。（S1，jadx-targeted/vn.java:659-663；t22.java:95-97）
  • k82.a() 在 API 33+ 检查 POST_NOTIFICATIONS，更低版本检查 areNotificationsEnabled()；tm.a() 与 md.a() 都以此为前置，因此前台服务、Alarm、Job、Work 的 App 自有主链在通知不可用时不会初始化/启动。（S1，k82.java:23-27、tm.java:31-103、md.java:173-243）

应用卸载#

  • REQUEST_DELETE_PACKAGES + Intent.ACTION_DELETE 只发起系统卸载确认页；静态代码不支持“静默卸载”。（S1）

三、App 自有组件与暴露面#

组件 exported/保护 用途 风险边界
WpCyBN ContentProvider exported=false、initOrder=100 进程启动即初始化保活框架、回调、生命周期、Adjust S1
gXXfik Service exported=true、无自定义 permission、specialUse 常驻前台服务 外部 App 能否直接启动受 Android 版本/后台限制影响；仍应做组件滥用测试（U）
PsaeNNErXb JobService exported=true、BIND_JOB_SERVICE 前台服务失败的 Job 兜底 系统签名权限保护绑定（S1）
sToBblBqZa JobService exported=true、BIND_JOB_SERVICE 15 分钟自续约 Job 系统签名权限保护绑定（S1）
NaKMPne FirebaseMessagingService exported=false FCM 消息与 Token S1
ZPHDnIht Receiver exported=true、要求 RECEIVE_BOOT_COMPLETED BOOT_COMPLETED、MY_PACKAGE_REPLACED 发送方权限/系统广播限制降低外部滥用；仍需设备测试（U）
BpFZcYhmZ Receiver exported=true、无 intent-filter/permission 每日 Alarm 回调，重新调度 PendingIntent 为显式组件；但组件本身导出，建议测试外部显式广播是否会触发调度（U）
NotifyRepeatReceiver exported=true、无 permission 取消重复通知协程 外部显式广播可能影响提醒流程，需安全测试（U）
NotificationListener exported=true、系统签名权限 通知监听/清理 由系统绑定保护（S1）
OutOpenActivity 见 Manifest 通知点击落地、Action 转发 应检查伪造 action 和导出状态；当前报告未动态 fuzz（U）

依据：AndroidManifest.xml:285-352。

四、后台保活调度全链路#

4.1 初始化入口#

WpCyBN 是高优先级、非导出的 ContentProvider。进程创建时：

  1. 保存 Application Context；
  2. 做包名摘要/完整性门控；
  3. 从 Manifest metadata 反射取得 KeepCallbackImp；
  4. 注册 Activity 生命周期； 5.读取 Adjust attribution/adid；
  5. 调用 tm.a(context) 启动后台体系。

证据：jadx-targeted/WpCyBN.java:76-179。（S1；simple 模式恢复）

4.2 前台服务#

  • md.a() 优先 startForegroundService(gXXfik)。（S1，md.java:173-243）
  • gXXfik 创建常驻通知并以 ID 1 调用 startForeground，前台服务类型为 specialUse。（S1，gXXfik.java:36-85）
  • onStartCommand 在 API 34+ 返回 2（START_NOT_STICKY），更低版本返回 1（START_STICKY）。（S1，gXXfik.java:115-118）
  • onDestroy 与 onTaskRemoved 再调用 md.a()，形成自恢复尝试。（S1，gXXfik.java:107-125）
  • 是否能在 Android 14+/厂商省电策略下真正重启，不能由静态代码保证。（U）

4.3 JobScheduler 双路径#

Job ID 组件 计划参数 行为
3857 PsaeNNErXb persisted；minimum latency 5s；override deadline 7s；API 33+ priority 400 前台服务启动失败时兜底；自身进入前台并再次尝试启动 gXXfik
3432 sToBblBqZa persisted；minimum latency 15min；deadline 15min+5s；API 33+ priority 400 Job 到点调用 ac3.a() 重新安排自身

证据：md.java:210-235、PsaeNNErXb.java:46-139、ac3.java:80-127、sToBblBqZa.java:21-47。（S1）

4.4 WorkManager#

  • 唯一周期工作名解码为 MiGS，Worker 为 kcTBvDgL，周期 15 分钟、flex 5 分钟。（S1，q41.java:145-181）
  • Worker 的 doWork() 调用 md.a() 与通知/保活调度入口后返回成功。（S1，com/ai/smart/kcTBvDgL.java:26-35）
  • Android WorkManager 的 15 分钟只是最小周期，真实执行可能因 Doze、配额和 OEM 策略延迟。（U）

4.5 每日 Alarm#

  • qu3.e() 构造 requestCode 74655 的显式 PendingIntent 指向 BpFZcYhmZ，目标本地时间为 10:00。（S1，qu3.java:79-130）
  • 调用 AlarmManager.set(2, ...)，Android type 2 为 ELAPSED_REALTIME_WAKEUP：可以唤醒设备，但使用的是 set()，不是 exact，系统仍可批处理和延迟。（S1）
  • Receiver 触发后调用保活入口并重新安排下一次 Alarm。（S1，BpFZcYhmZ.java:20-29）
  • 因为不是 setExact*，实际触发时间仍可漂移；但它是 *_WAKEUP 类型，休眠中具备唤醒设备执行 Receiver 的能力。（S1/I）

4.6 开机、升级和系统事件#

  • ZPHDnIht 接收 BOOT_COMPLETED 与 MY_PACKAGE_REPLACED，调用 md.a() 与调度入口。（S1，AndroidManifest.xml:339-348；ZPHDnIht.java:21-39）
  • MyApplication 动态注册 USER_PRESENT、充/断电、BATTERY_CHANGED、SCREEN_ON/OFF、PACKAGE_ADDED/REMOVED/REPLACED、CLOSE_SYSTEM_DIALOGS、CONFIGURATION_CHANGED。（S1，MyApplication.java:99-126）
  • 这些事件既服务保活，也驱动通知召回；完整映射见通知报告。（S1）

五、常驻通知#

  • Channel channel_id_resident，名称 resident，importance 3，静音。（S1，KeepCallbackImp.java:13；w61.java:38-74）
  • 固定通知 ID 1，ongoing 常驻；自定义大小布局。（S1，w61.java:98-230）
  • 五个快捷动作 requestCode：8197 Clean、8198 Cache、8199 App、8200 Photo、8201 Speed；分别转为 resident_clean/cache/app/photo/speed。（S1，w61.java:98-230；t22.java:39-71）
  • 时间戳被设置为未来约 365 天，删除 Intent 会再次走前台服务启动逻辑。（S1）
  • “Speed” 路由到 Network Traffic，不是系统级网络加速。（S1/I）

六、FCM 与 Remote Config#

6.1 FCM#

  • NaKMPne 是 App 自有 FirebaseMessagingService，Manifest action 为 com.google.firebase.MESSAGING_EVENT。（S1）
  • 收到消息立即调用 md.a() 与 ep3.d(...)，说明它是远程触发保活/调度的入口。（S1，jadx-targeted/NaKMPne.java:35-43）
  • 后续检查消息优先级、后台 Activity 数、锁屏/方向、距上次时间至少 5 分钟、07:00-22:59 等。（S1，NaKMPne.java:44-100）
  • Token 回调交给 yd1.a(context, token)。（S1，NaKMPne.java:110-114）
  • 此方法内没有直接 notify()；控制流又受 JADX simple 恢复影响，因此只能确认“收到远程消息后尝试激活后台链路”，不能确认“必定显示一条通知”。（U）

6.2 Firebase Remote Config#

  • Firebase Remote Config、Messaging、Analytics、Crashlytics、Installations、ABT、Sessions、Performance 均在 Manifest 注册。（S1，AndroidManifest.xml:512-580）
  • SplashActivity.h() 读取本地配置后发起 Remote Config 拉取并注册配置更新监听。（S1，SplashActivity.java:123-174）
  • 关键远程字段：
分类 字段
启动/广告 openTime、day0_ad…day3_ad、banAdVPN、clean_ad_show、clean_ad_click
通知 targetSwitchValue、sendFirstIntervalHigh、sendRepeatIntervalHigh、sendIntervalMedium、sendIntervalLow、specialSendInterval、consecutive_no_click_limit

证据：bi2.java:128-203。（S1）

  • consecutive_no_click_limit 在代码中被 clamp 到 0..1，但通知策略又比较“最近任务通知连续两次未点击”；字段语义与实际门槛可能存在反编译变量误配或实现缺陷。（I/U）

七、安全、隐私与合规关注点#

  1. android:allowBackup="true"；backup_rules.xml 是空的 <full-backup-content/>，data_extraction_rules.xml 也只有空的 <cloud-backup/>，未见显式排除项。因此 App 私有数据可能进入平台备份范围，但具体可备份内容仍受 Android/设备策略影响，需真机验证。（S1/U）
  2. 通知监听会读取第三方通知标题/正文并落地本地记录；需与隐私政策、Data Safety 和用户授权说明对账。（S1/I）
  3. MANAGE_EXTERNAL_STORAGE 是 Google Play 高审权限，产品核心用途、商店声明和审核材料必须一致。（S1/I）
  4. specialUse 前台服务需有准确 subtype/用途声明；仅靠“保活”通常不能证明合规。（I/U）
  5. gXXfik、BpFZcYhmZ、NotifyRepeatReceiver 的导出状态值得做显式 Intent 安全测试。（U）
  6. App 内嵌第三方 SDK 配置标识；本报告不复制敏感值。是否存在可滥用的真正服务端密钥需做专门 secrets 扫描。（U）
  7. 初始化链会访问两个自有域名接口做 IP/广告标识黑名单判定，其中一个请求包含包名和本地标识；事件名指向 adid，但标识来源与服务端留存规则仍需抓包/后端核验。（S1/I，jadx-targeted/cz.java:60-297、l41.java:25-232）

八、未验证项#

  • 后台链路在 Pixel/Samsung/Xiaomi 等设备、Android 12L-17、Doze、强停、重启、升级后的真实恢复率。（U）
  • 用户从系统设置“强行停止”后，任何 Receiver/Job/FCM 是否恢复；Android 通常会限制，不能宣称可拉活。（U）
  • FCM payload、优先级降级、通知 payload 与 data payload 的真实服务端格式。（U）
  • Remote Config 当前生产值、激活时机、缓存 TTL 和按渠道/国家条件分发。（U）
  • 导出组件的外部调用面、PendingIntent mutability 和 Intent 注入风险。（U）
  • ip.brisk-signal.com / pwz.brisk-signal.com 请求的真实 header、请求体标识、响应和数据治理。（U）
竞品拆包报告库 · 逆向结论按证据等级阅读