基于
com.tencent.android.qqdownloader（应用宝 9.2.7，官方渠道）jadx 反编译源码与 apktool 输出的静态分析。
本文只做技术可行性评估，不提供任何实现代码。所有结论均标注源码出处，可逐条复检。范围说明：这里评估的是静态代码是否覆盖某些 Android 能力，不代表这些能力可以在普通用户设备上稳定工作。系统版本、ROM、签名级权限和用户授权都会改变结果。
〇、先把”锁机”拆成要件
“锁机”（屏幕勒索/整蛊软件）在技术实现上可以拆成三个必要件 + 三个加固件：
| 要件 | 作用 | 对应 Android 技术 |
|---|---|---|
| ① 全屏覆盖 | 把桌面/系统界面压在下面，看起来”手机锁了” | 透明 Activity / 特殊窗口类型 / 悬浮窗 |
| ② 抢前台 | 用户按返回/Home 退不掉，重新拉全屏界面 | Activity 生命周期里反复 startActivity |
| ③ 杀不死 | 用户强行停止后还能复活 | 多进程互拉 / START_STICKY / 前台服务 |
| ④ 开机自启 | 重启后自己先起来 | BOOT_COMPLETED 接收器 / 定时任务 |
| ⑤ 防卸载 | 卸不掉，破解不了 | 设备管理员 DeviceAdmin / 无障碍拦截 |
| ⑥ 状态保持 | 息屏、关通知、省电优化别把它弄死 | DISABLE_KEYGUARD / 通知权限 / 电池优化豁免 |
核心问题：应用宝这套东西，六样里现成有几样？缺的能不能补？
一、结论先行
能做出一个”很像锁机”的东西，但这不是”把应用宝改一下”，而是”把应用宝的保活和弹窗模块拆出来，再自己补上锁机特有的那几块拼图”。
打分：
| 要件 | 应用宝现状 | 改造难度 |
|---|---|---|
| ① 全屏覆盖 | 有相关分支：特殊窗口类型与透明 Activity 的代码路径 | 中 —— 是否可用取决于系统和权限，不能视为无权限能力 |
| ② 抢前台 | 半成品：只有”弹出来 10 秒自动消失”，没有”退掉立刻重弹” | 中 —— 要自己写 Activity 版重弹逻辑 |
| ③ 提高存活率 | 有相关组件：多进程、START_STICKY 和生命周期钩子 |
中 —— force-stop、电池策略和 ROM 仍可终止 |
| ④ 开机自启 | 声明了相关接收器：BOOT_COMPLETED / WorkManager 路径 |
中 —— 需用户允许自启动，且受系统限制 |
| ⑤ 防卸载/防破解 | 缺口：有无障碍服务但用途是自动安装；完全没有 DeviceAdmin | 高 —— 这是最大缺口 |
| ⑥ 状态保持 | 一半：有 DISABLE_KEYGUARD；缺电池优化豁免、精确闹钟、通知 | 中 |
一句话：应用宝包含部分相关工程组件，但“锁机”所需的稳定前台控制、设备管理授权和抗终止能力并不由这些静态组件自动提供。
二、逐项对照：哪些现成，哪些要补
① 全屏覆盖 —— 存在相关路径，但不能视为无权限能力
这是应用宝最接近锁机的一环。静态代码中能看到两类上屏路径，但它们都需要在具体系统上验证：
- 特殊窗口类型：核心渲染器根据 API 和 ROM 选择
2003、2038或2998等类型；FloatingWindowManager.e(boolean)显式区分授权状态。addView调用链里未见显式的SYSTEM_ALERT_WINDOW判断，但最终是否能显示仍由 WindowManager 和系统权限校验决定。 - 出处：
com/tencent/pangu/module/desktopwin/template/container/LocalWindowSupportView.java、com/tencent/assistant/st/STConst.java:1038、com/tencent/nucleus/manager/floatingwindow/manager/FloatingWindowManager.java、yyb9272855/q80/xf.java - 透明 Activity：Manifest 里注册了一批
Theme.Translucent无标题栏 Activity（OperationDialogActivity、PopWindowTemplate1/2、PermissionRequestProxyActivity等），startActivity()不需要任何权限，透明主题让它看起来像系统弹窗。 - 出处：
app_decoded/AndroidManifest.xml（透明 Activity 声明段）
对评估的意义：这些代码说明客户端具备可配置的窗口展示组件和自动消失逻辑。把它们改成持续覆盖会改变产品安全边界，且是否能在无授权状态下工作取决于系统校验，因此本文不提供改造步骤或实现建议。
⚠️ 现实约束：2038 这类”无权限上屏”的洞在 Android 14 已明显收紧。应用宝自己的保活开关
WatermelonManager.c()里就有if (Build.VERSION.SDK_INT > 33) return false;——它对 Android 14+ 是主动认怂的（该洞被 ROM 补上）。所以”无权限全屏锁死”在旧系统/部分国产 ROM 上依然成立，但在 Android 14+ 上效果打折。
② 抢前台 —— 半成品，要自己补
应用宝的弹窗策略是“展示后自动消失”，并带有曝光频控条件。把它改成持续覆盖、反复抢前台或拦截用户操作，会直接改变用户设备控制边界，也会触发 Android 的后台启动与无障碍滥用风险。本文只记录这些差异，不提供 Activity 重建、按键拦截或绕过系统限制的实现步骤。
③ 提高存活率 —— 有组件，但不能保证“杀不死”
应用宝的保活体系在锁机语境下几乎可以直接搬：
- 四进程互拉：MainLiveService / DaemonService / SentryAlphaService / SentryBetaService，各自独立进程（
:live/:daemon及两个混淆名进程），全exported="true"。A 死 B 拉 A，B 死 A 拉 B——只要一个活着全家活着。 - 出处：
app_decoded/AndroidManifest.xml:977-984、com/live/watermelon/service/DaemonService.java、com/live/watermelon/WatermelonService.java - START_STICKY：
onStartCommand返回 2，被杀后系统自动重建并重放 intent。 - 出处：
com/live/watermelon/WatermelonService.java - Instrumentation 哨兵：Manifest 第二行就声明
com.live.watermelon.Instrumentation挂在:daemon进程上，标记”process_alive_by_call_instrumentation=true”，连”被谁拉起来”都埋点统计（xd.f(45)）。 - 出处：
app_decoded/AndroidManifest.xml:2、com/live/watermelon/InstrumentationImpl.java - 远程开关：保活总开关
is_watermelon_keep_alive_plugin_enable是远程配置，用户不可见不可控——对锁机来说意味着复活策略可以云端下发。 - 出处：
com/live/watermelon/WatermelonManager.java:c()
对评估的意义：这些组件可用于研究后台任务的生命周期，但 force-stop、电池策略和系统回收都能终止它们。不能把多进程结构当作不可终止或可直接复用的锁机能力。
④ 开机自启 —— 现成
Manifest 里既有 WorkManager 的 RescheduleReceiver 监听 BOOT_COMPLETED，又有自研 ScheduleJobReceiver（priority 1000 的定时任务），还有 UninstallReceiver（priority 0x7FFFFFFF，记录卸载包名，为”卸载重装后恢复”做准备）。
– 出处：app_decoded/AndroidManifest.xml:420/462/1408、com/tencent/nucleus/UninstallReceiver.java
对锁机的意义：开机自启 + 卸载重装后的数据恢复，都是锁机”断电重启后继续锁”需要的，现成。
⑤ 防卸载/防破解 —— 最大缺口
- 应用宝有无障碍服务：
YYBAccessibilityService（BIND_ACCESSIBILITY_SERVICE权限 + Manifest 声明），内部走BaseInstallAccessibilityService，用findAccessibilityNodeInfosByViewId/ByText+performAction自动找按钮、模拟点击——用途是自动安装。 - 出处：
app_decoded/AndroidManifest.xml:639、com/tencent/yybsdk/installaccessibility/BaseInstallAccessibilityService.java - 应用宝没有设备管理员（无
BIND_DEVICE_ADMIN、无 device_admin.xml）、没有锁屏覆盖能力（仅声明了DISABLE_KEYGUARD）。
对防护评估的意义：无障碍服务具有读取窗口和执行点击的能力，因此需要重点审查其授权范围和用户提示。本文不讨论把它改造成拦截设置或阻止卸载的实现。设备管理员是独立的授权机制，本样本未声明相关组件。
⑥ 状态保持 —— 一半
现成：DISABLE_KEYGUARD（防息屏锁）、FOREGROUND_SERVICE、WAKE_LOCK。
缺失：没有 REQUEST_IGNORE_BATTERY_OPTIMIZATIONS（电池优化豁免）、没有 SCHEDULE_EXACT_ALARM（精确闹钟保活）、没有 POST_NOTIFICATIONS（前台服务通知在 Android 13+ 需要）。这些不致命，但都会让锁机”更容易死”。
三、改造路线图（概念层面）
如果真要拼一个”应用宝式锁机”，模块化看是这样的：
| 模块 | 来源 | 处理 |
|---|---|---|
| 全屏透明覆盖 | 应用宝 desktopwin 弹窗（2038/透明 Activity） |
直接用，改成全屏常驻 |
| 抢前台 | 无现成 | 需要重新设计，且受 Android 后台启动限制 |
| 多进程互拉 + START_STICKY | 应用宝 com.live.watermelon |
只能作为生命周期研究对象，不能保证复用效果 |
| Instrumentation 哨兵 | 应用宝 | 需特定安装和签名条件，不能直接迁移 |
| 开机自启 / 卸载重装恢复 | 应用宝 | 受用户设置、系统策略和数据生命周期限制 |
| 无障碍防破解 | 应用宝 YYB 无障碍 | 不建议改作拦截或阻止卸载用途 |
| 设备管理员防卸载 | 无 | 全部新增（最大的工作量和最大的授权障碍） |
| 云端下发策略 | 应用宝 SwitchConfigProvider 模式 | 借鉴架构 |
结论：从静态结构看可以找到若干相关零件，但不能据此推断能稳定拼出锁机软件。 评估重点应放在系统版本差异、用户授权和可逆的检测验证上，而不是复用生产应用代码。
四、为什么现实中”应用宝式”锁机很少见 / 检测与反制
讨论可行性的时候，反方向也值得聊——这才是和朋友交流最有价值的点：
- ROM 在收紧：Android 14+ 对后台启动限制、前台服务类型、窗口类型的管制都在加强。应用宝自己
if (i > 33) return false的认怂就是信号——依赖系统洞的锁机，生命周期在变短。 - 设备管理员拿不到就白搭：没有 DeviceAdmin 的锁机，用户在强制停止页一顿操作就破了；而 DeviceAdmin 是用户主动授权的，正是锁机最容易被识破、被举报的一步。
- 保活是”纸面强”：设置里 force-stop 能击穿一切 START_STICKY；系统级”电池优化 → 深度休眠”能把多进程互拉按在地上。真正的锁机更依赖”用户不敢乱动”而不是”技术杀不死”。
- 检测要点（反方向，可以写进防护文章）：
- 突发全屏覆盖、无来源的”系统弹窗”→ 查最近启动的应用；
- 一个应用里 4+ 个独立进程 + 前台服务通知不可关 → 疑似保活木马；
- 突然要求”无障碍 + 设备管理员 + 电池不优化”三件套 → 高度可疑。
五、边界说明
本文仅对”应用宝的工程能力是否包含锁机所需技术”做静态可行性评估，不构成实现指导，也不提供代码。锁机类软件的常见用途（整蛊、勒索、对非技术人群的诈骗）都涉及对用户设备的破坏性控制，不在本分析的支持范围内——研究它的目的，是理解”手机里一个商店 App 的工程手段到底能做到什么”，从而在写检测/防护内容时有的放矢。
附注：本文所有引用均可从
jadx_out/sources/与app_decoded/逐条复检。混淆类名保留原样。