从一次诡异崩溃说起：VirtualApp 悬浮窗权限的十年适配之路
项目地址: https://gitcode.com/GitHub_Trending/vi/VirtualApp 导语：你在真机上测得好好的悬浮窗功能，上线后却收到一屏"无法添加窗口"的崩溃日志；同一个包名，Android 9 上正常，Android 12 上却毫无反应。作为一款主打应用多开与沙盒运行的引擎，VirtualApp 几乎把每个 Android 版本的权限规则都踩了一遍。这篇文章不堆概念，只讲坑——从崩溃现场出发，带你逐层拆解悬浮窗权限在 Android 6 到 14 之间的真实行为差异，并给出可落地的检查与加固方案。
一次诡异的线上崩溃，逼我重读权限源码
崩溃日志里的关键词
先还原事故现场。某个双开应用上线后，华为与小米的反馈群里先后出现同一类崩溃：
BadTokenException: Unable to add window -- permission denied
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:...)
报错的位置是 WindowManager.addView，而日志里"permission denied"这个词，几乎与"你还没拿到 SYSTEM_ALERT_WINDOW（悬浮窗）权限"画等号。诡异的是，部分用户明明在系统设置里看到了"允许显示在其他应用上层"的开关处于打开状态。
权限开关打开了，系统却不认账
随后我们发现一个更反直觉的现象：同一台设备上，宿主应用能正常弹窗，沙盒里被多开的应用却依然崩溃。这说明问题不在"用户有没有授权"，而在"系统认为谁在申请这个权限"。
💡 这里引出本篇文章的第一个关键结论：悬浮窗权限的判定，从来不是看 AndroidManifest 里有没有声明，而是看系统在运行期向谁查询、查询到了什么结果。
顺着这条线，我们最终定位到两处需要关注的代码：一是权限检查的入口 Settings.canDrawOverlays()，二是它背后的 AppOps（应用操作）服务。弄清楚这两者的关系，后面所有版本适配才有了根基。
本章收获：崩溃日志中的 "permission denied" 只是表象，真正的排查起点是"系统向谁查询了悬浮窗权限"。
悬浮窗权限的"两层皮"：声明、检查与授予
第一层：Manifest 声明只是入场券
在 VirtualApp 的 lib 模块清单文件里，你可以找到这样一行：
<!-- lib/src/main/AndroidManifest.xml -->
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
注意，这只是"申请"，系统并不会因为它就给你授权。Android 6.0 之后，SYSTEM_ALERT_WINDOW 被归入"特殊权限"，必须由用户从系统设置页手动打开，普通运行时权限弹窗对它无效。
第二层：运行时判定走的是 AppOps
真正决定"能不能弹"的，是系统内的 AppOps 服务。用大白话说：AppOps 就是系统给每个应用记的一本"操作台账"，SYSTEM_ALERT_WINDOW 是台账上的一个条目，条目值是 MODE_ALLOWED（允许）还是 MODE_ERRORED（拒绝），由用户在设置页里的开关控制。
我们封装一个统一的检查工具，让 6.0 以下老设备也能走通：
public final class OverlayGuard {
/** 判断当前进程是否有权创建悬浮窗 */
public static boolean granted(Context context) {
// 6.0 起官方提供了标准查询入口
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
return Settings.canDrawOverlays(context);
}
// 更老的系统没有 canDrawOverlays，退回去读 AppOps 台账
return legacyAppOpsAllowed(context);
}
private static boolean legacyAppOpsAllowed(Context context) {
Object appOps = context.getSystemService("appops");
try {
Method checkOp = appOps.getClass().getMethod(
"checkOp", int.class, int.class, String.class);
// OP_SYSTEM_ALERT_WINDOW = 24
int result = (int) checkOp.invoke(appOps, 24,
android.os.Process.myUid(), context.getPackageName());
return result == 0; // MODE_ALLOWED
} catch (Exception ignored) {
return true; // 极端情况下保守放行，避免误伤老机型
}
}
}
这段代码解决的是"入口统一"问题：无论什么系统版本，业务层只调 OverlayGuard.granted() 一个方法，版本差异全部收敛在工具类内部。
授权跳转的正确姿势
当检查不通过时，需要引导用户去设置页。这里有一个高频失误点：很多人把 ACTION_MANAGE_OVERLAY_PERMISSION 当成普通 intent 直接 startActivity，却忘了带上包名参数，结果跳到的是"所有应用列表"，用户根本找不到自己的应用。
public static void openSettings(Activity activity, int requestCode) {
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION);
// 必须拼接包名，否则系统不知道你想给谁授权
intent.setData(Uri.parse("package:" + activity.getPackageName()));
activity.startActivityForResult(intent, requestCode);
}
本章收获：Manifest 声明只是入场券，运行期真正生效的是 AppOps 台账；检查与跳转都要封装成统一工具，避免散落各处。
用一张表吃透 Android 6 到 14 的权限变迁
很多文章按版本逐个讲，信息是齐了，但脑子是乱的。我们反过来：先把结论浓缩成一张对照表，再挑三个最容易被忽视的变化点展开。
| 系统版本 | 关键变化 | 对开发者的直接冲击 | 处理方式 |
|---|---|---|---|
| 6.0 (M) | 引入运行时权限，悬浮窗升级为特殊权限 | 光声明不行了，必须引导用户去设置页 | Settings.canDrawOverlays() + 授权跳转 |
| 8.0 (O) | 新增 TYPE_APPLICATION_OVERLAY 窗口类型 | 用 TYPE_PHONE 弹窗会抛异常 | 高版本切换新窗口类型 |
| 10.0 (Q) | 后台应用弹窗受限 | 退到后台瞬间弹窗可能被系统拦截 | 结合生命周期控制弹窗时机 |
| 11.0 (R) | 权限授予规则收紧，一次授予长期生效 | 部分设备上"拒绝"变得更难反悔 | 检查结果要兜底，不能只相信开关 |
| 12.0 (S) | 前台服务类型化，长驻弹窗需配前台服务 | 后台保持悬浮窗的场景必须挂前台服务 | 服务启动时声明 foregroundServiceType |
| 14.0 (U) | 悬浮窗显示时机进一步收紧 | 冷启动即弹窗的场景要重新设计 | 等首个 Activity 进入前台后再 addView |
最容易被忽略的三个变化点
其一，窗口类型的分水岭在 8.0。 TYPE_APPLICATION_OVERLAY 是 Android 8.0 起专供悬浮窗的窗口类型，替代了此前的 TYPE_PHONE。声明参数时按版本分流：
int type = Build.VERSION.SDK_INT >= Build.VERSION_CODES.O
? WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY
: WindowManager.LayoutParams.TYPE_PHONE;
其二，10.0 之后"后台弹窗"被系统盯着。 如果你的悬浮窗服务是常驻的，务必监听应用进入后台的时机，主动收起，而不是等系统来拦截你——被动拦截的结果往往是直接崩溃。
其三，12.0 的前台服务类型声明。 长驻悬浮窗通常要挂在服务上，Android 12 要求服务在启动时显式声明类型并配套通知，否则系统直接拒绝启动。这属于"编译期看不出、运行期必炸"的坑，上线前一定要拿 Android 12 以上的真机验证。
本章收获：版本适配的本质是"识别变化点 + 按版本分流"，一张对照表比十篇长文更管用；8.0、10.0、12.0 是三道必须迈过的坎。
沙盒场景的独有考题：权限该落在谁的头上
多进程让权限归属变得模糊
普通应用只需要关心自己的权限。但 VirtualApp 是多进程沙盒：宿主主进程、引擎服务进程、以及被多开的虚拟应用进程并存。每个进程向系统查询权限时，拿到的 uid 和包名可能各不相同——这就回到了开篇那个"开关明明打开了却依然崩溃"的谜题。
引擎如何"欺骗"系统服务
VirtualApp 在 lib 模块中通过 Binder 代理层拦截系统服务调用。以 AppOps 服务为例，AppOpsManagerStub 会在转发前把参数里的包名与 uid 替换成宿主自己的，确保系统始终把虚拟应用当作"宿主本人"来放行。核心思路是"身份归一"：
// 在 hook 到 AppOpsService 的调用后：
// 1. 把 args 里的虚拟包名替换为宿主包名
// 2. 把 uid 替换为宿主真实 uid
// 3. 再放行给真正的系统服务处理
beforeCall(who, method, args) {
replacePackage(args); // 虚拟包名 -> 宿主包名
replaceUid(args); // 虚拟 uid -> 宿主 uid
return true; // 继续走系统原逻辑
}
简而言之：系统只认宿主这一个人的"身份"，沙盒里所有虚拟应用的权限查询都被折算成宿主的查询。这样宿主一旦获得悬浮窗权限，所有虚拟应用天然共享。
共享权限后还要解决"时机"问题
身份归一解决了"有没有权限"，但没解决"什么时候能弹"。虚拟应用在 onCreate 阶段就弹窗，此时窗口管理器可能尚未就绪，依旧会失败。稳妥的做法是延迟到首个可见窗口之后：
// 虚拟应用的 Activity 进入 onResume 后再 addView
if (OverlayGuard.granted(context)) {
windowManager.addView(floatView, buildParams());
} else {
// 记录待办，等待宿主授权回调后补弹
pendingViews.add(floatView);
}
⚠️ 不要小看这个"时机"：在沙盒场景下，权限与时机是两个独立的崩溃源，前者报 permission denied，后者报 BadTokenException，日志几乎一样。
本章收获：沙盒引擎通过"身份归一"让虚拟应用共享宿主权限，但弹窗时机仍需按窗口生命周期精心编排。
上线前的兼容加固清单与回归验证
适配方案再完整，最终都要落在验收上。这里给出一份可直接抄的检查清单。
五项必查清单
- 声明完整性：宿主与引擎进程所在模块的 Manifest 都声明了
SYSTEM_ALERT_WINDOW，缺一不可。 - 检查兜底：授权回调回来后，不要直接信任
RESULT_OK，要再次调用granted()复核——部分 ROM 会在返回前才落盘授权状态。 - 窗口类型分流：搜索代码中所有
addView调用点，确认窗口类型按 8.0 做了分支。 - 生命周期联动：
onPause时如果判定应用已退后台，主动移除悬浮窗视图。 - 多进程回归：分别在宿主进程与虚拟应用进程里各弹一次窗，确认都正常。
用真机矩阵代替主观自信
版本碎片化的残酷在于：任何"我以为没问题"的结论都可能在某个 ROM 上翻车。建议至少覆盖以下组合再发版：
- Android 6.0 / 7.x 模拟器：验证 AppOps 兜底路径
- Android 8.0 / 9.0 真机：验证
TYPE_APPLICATION_OVERLAY切换 - Android 12 / 13 / 14 真机：验证前台服务类型与弹窗时机
回归时重点关注两条路径：全新安装后首次授权、以及授权后重启设备的二次验证。
本章收获：兼容加固的本质是把"版本判断"、"身份归一"、"弹窗时机"三个环节分别验收，并用真机矩阵覆盖关键版本。
摘要
悬浮窗权限从 Android 6.0 的"特殊权限"一路收紧到 Android 14 的"时机管控"，VirtualApp 的适配实践告诉我们：声明、检查、授权、时机四件事缺一不可，而沙盒多进程场景还需额外处理权限归属问题。建议以 OverlayGuard 工具类统一入口，用版本对照表指导分流，并坚持用真机矩阵验收，才能在系统碎片化面前稳住悬浮窗功能的稳定性。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
