VirtualApp 悬浮窗权限适配从宿主到沙盒的 4 个关键卡点【免费下载链接】VirtualAppVirtual Engine for Android(Support 14.0 in business version)项目地址: https://gitcode.com/GitHub_Trending/vi/VirtualApp悬浮窗是沙盒应用的基础能力但它的权限机制和普通应用有本质区别系统只认宿主 UID悬浮窗却属于沙盒里的应用。VirtualApp 悬浮窗权限适配就围绕这两条主线展开权限引导以及跨进程的窗口透传。为什么沙盒悬浮窗比普通 App 难搞普通应用的流程很简单声明SYSTEM_ALERT_WINDOW用户授权addView成功。VirtualApp 多两层。第一层宿主权限 ≠ 沙盒权限。系统侧的权限检查按谁发起请求UID执行。沙盒应用的窗口操作实际由宿主进程代为执行伪装的包名在权限检查里不存在。在 SYSTEM_ALERT_WINDOW 多开场景下同一个 VAPP 里的所有沙盒应用共享宿主的权限状态——宿主授权一次全部实例生效。第二层跨进程状态同步。沙盒应用跑在独立的 VAPP 进程宿主进程负责生命周期和 IPC。能不能弹悬浮窗这个状态必须在两个进程间保持一致任何一侧失步窗口都会被系统撤掉。沙盒悬浮窗跨进程问题的本质就一句话窗口活在 VAPP 进程里权限却挂在宿主 UID 上。VirtualApp 三层架构与 overlay 权限VA Framework 在应用层 Hook AMS、PMS、Window 等系统服务。沙盒应用调用 WindowManager 时先经过这一层窗口请求由此被改道到宿主的执行链路。VA Server 负责跨进程通信。overlay 权限是否授予、窗口记录等状态都汇总在 ServerVAPP 进程查询权限时从这里取答案而不是本地缓存。VA Native 负责文件系统和 syscall 级 Hook为沙盒应用提供稳定运行环境。它不直接处理 overlay 权限却是悬浮窗进程不被回收的底座。Android 沙盒应用 overlay 权限适配的核心原则是发起窗口前必须走一次宿主侧的权限判定。架构细节可参考官方 VADev 开发文档。分场景适配4 个真实卡点卡点一宿主拿不到 SYSTEM_ALERT_WINDOW 时的引导流程现象addView抛BadTokenException或悬浮窗直接不显示。原因API 23 起它被归为特殊权限运行时授权弹框授不了必须由用户在设置页手动打开。正确姿势是先查、再引导、返回后再复查if (Build.VERSION.SDK_INT 23 !Settings.canDrawOverlays(host)) { Intent i new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse(package: host.getPackageName())); // 引导到宿主的权限页 host.startActivity(i); } // 返回回调里再次检查 canDrawOverlays为 true 才展示悬浮窗同时确认宿主在 AndroidManifest.xml 中声明了该权限否则用户打开后查询结果永远是 false。卡点二沙盒应用发起悬浮窗时的 Overlay 权限透传现象宿主已授权沙盒应用弹悬浮窗却失败。原因沙盒的窗口调用全部被宿主 Hook 拦截、以宿主 UID 执行宿主进程和 VAPP 进程的权限状态一旦不同步比如用户刚在设置页撤掉授权系统会直接撤窗。VirtualApp 的窗口服务 Hook 入口在WindowManagerStub它替换了系统的 WindowManager Binder 引用// WindowManagerStub.inject()把全局代理替换为 Hook 代理 WindowManagerGlobal.sWindowManagerService .set(getInvocationStub().getProxyInterface()); // 之后所有 addView / updateViewLayout 都经过 Hook 层实现见 窗口服务 Hook 目录。适配要点仍是那句窗口发起必须走宿主侧的权限判定结果而不是本地缓存。卡点三后台悬浮窗被系统回收怎么办现象熄屏或切后台后悬浮窗消失。原因系统会主动清理后台窗口和低重要性进程悬浮窗挂在已 pause 的 Activity 上时会随 token 一起失效。⚠️ 可靠的做法有两个把悬浮窗生命周期挂到宿主的前台 Service 上进程重要性高窗口不被回收或宿主回前台时主动补申请窗口Override public void onResume() { // 宿主回到前台 if (shouldShowFloat() floatView null) { windowManager.addView(floatView, params); // 补申请被回收的窗口 } }补申请必须在onResume之后做在onPause/onStop里补会撞上 token 失效。卡点四Window Type 的跨版本兼容写法现象API 26 上用TYPE_PHONE弹窗口抛BadWindowType异常。原因API 26 起TYPE_PHONE等旧类型保留给系统应用第三方悬浮窗必须改用TYPE_APPLICATION_OVERLAY。int type Build.VERSION.SDK_INT 26 ? WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY // API 26必须用它 : WindowManager.LayoutParams.TYPE_PHONE; // API 26-用旧类型 WindowManager.LayoutParams lp new WindowManager.LayoutParams( WindowManager.LayoutParams.WRAP_CONTENT, WindowManager.LayoutParams.WRAP_CONTENT, type, WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE, PixelFormat.TRANSLUCENT);悬浮窗权限适配 Checklist #检查项判断方式1宿主声明SYSTEM_ALERT_WINDOW设置页无权限入口 未声明2跳设置返回后canDrawOverlays为 true日志或断点验证3沙盒窗口请求走宿主侧权限判定权限状态无本地缓存4API 26 使用TYPE_APPLICATION_OVERLAY日志无BadWindowType5宿主回后台再回前台后悬浮窗可补上真机在 API 29 验证6撤销授权后窗口被移除且无残留撤销再授予反复验证7VAPP 进程退出后无窗口泄漏强杀宿主后检查屏幕测试矩阵与后续 ✅测试矩阵至少覆盖API 23动态权限基线、API 26Window Type 变更、API 30后台启动限制、API 34最新系统行为四档并建议在主流通用 ROM 上各跑一遍相同用例。VirtualApp 版本迭代较快新系统上的权限行为也在持续变化最新适配情况以官方仓库 issue 区的讨论为准。【免费下载链接】VirtualAppVirtual Engine for Android(Support 14.0 in business version)项目地址: https://gitcode.com/GitHub_Trending/vi/VirtualApp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 VirtualApp 悬浮窗权限适配：从宿主到沙盒的 4 个关键卡点
VirtualApp 悬浮窗权限适配从宿主到沙盒的 4 个关键卡点【免费下载链接】VirtualAppVirtual Engine for Android(Support 14.0 in business version)项目地址: https://gitcode.com/GitHub_Trending/vi/VirtualApp悬浮窗是沙盒应用的基础能力但它的权限机制和普通应用有本质区别系统只认宿主 UID悬浮窗却属于沙盒里的应用。VirtualApp 悬浮窗权限适配就围绕这两条主线展开权限引导以及跨进程的窗口透传。为什么沙盒悬浮窗比普通 App 难搞普通应用的流程很简单声明SYSTEM_ALERT_WINDOW用户授权addView成功。VirtualApp 多两层。第一层宿主权限 ≠ 沙盒权限。系统侧的权限检查按谁发起请求UID执行。沙盒应用的窗口操作实际由宿主进程代为执行伪装的包名在权限检查里不存在。在 SYSTEM_ALERT_WINDOW 多开场景下同一个 VAPP 里的所有沙盒应用共享宿主的权限状态——宿主授权一次全部实例生效。第二层跨进程状态同步。沙盒应用跑在独立的 VAPP 进程宿主进程负责生命周期和 IPC。能不能弹悬浮窗这个状态必须在两个进程间保持一致任何一侧失步窗口都会被系统撤掉。沙盒悬浮窗跨进程问题的本质就一句话窗口活在 VAPP 进程里权限却挂在宿主 UID 上。VirtualApp 三层架构与 overlay 权限VA Framework 在应用层 Hook AMS、PMS、Window 等系统服务。沙盒应用调用 WindowManager 时先经过这一层窗口请求由此被改道到宿主的执行链路。VA Server 负责跨进程通信。overlay 权限是否授予、窗口记录等状态都汇总在 ServerVAPP 进程查询权限时从这里取答案而不是本地缓存。VA Native 负责文件系统和 syscall 级 Hook为沙盒应用提供稳定运行环境。它不直接处理 overlay 权限却是悬浮窗进程不被回收的底座。Android 沙盒应用 overlay 权限适配的核心原则是发起窗口前必须走一次宿主侧的权限判定。架构细节可参考官方 VADev 开发文档。分场景适配4 个真实卡点卡点一宿主拿不到 SYSTEM_ALERT_WINDOW 时的引导流程现象addView抛BadTokenException或悬浮窗直接不显示。原因API 23 起它被归为特殊权限运行时授权弹框授不了必须由用户在设置页手动打开。正确姿势是先查、再引导、返回后再复查if (Build.VERSION.SDK_INT 23 !Settings.canDrawOverlays(host)) { Intent i new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse(package: host.getPackageName())); // 引导到宿主的权限页 host.startActivity(i); } // 返回回调里再次检查 canDrawOverlays为 true 才展示悬浮窗同时确认宿主在 AndroidManifest.xml 中声明了该权限否则用户打开后查询结果永远是 false。卡点二沙盒应用发起悬浮窗时的 Overlay 权限透传现象宿主已授权沙盒应用弹悬浮窗却失败。原因沙盒的窗口调用全部被宿主 Hook 拦截、以宿主 UID 执行宿主进程和 VAPP 进程的权限状态一旦不同步比如用户刚在设置页撤掉授权系统会直接撤窗。VirtualApp 的窗口服务 Hook 入口在WindowManagerStub它替换了系统的 WindowManager Binder 引用// WindowManagerStub.inject()把全局代理替换为 Hook 代理 WindowManagerGlobal.sWindowManagerService .set(getInvocationStub().getProxyInterface()); // 之后所有 addView / updateViewLayout 都经过 Hook 层实现见 窗口服务 Hook 目录。适配要点仍是那句窗口发起必须走宿主侧的权限判定结果而不是本地缓存。卡点三后台悬浮窗被系统回收怎么办现象熄屏或切后台后悬浮窗消失。原因系统会主动清理后台窗口和低重要性进程悬浮窗挂在已 pause 的 Activity 上时会随 token 一起失效。⚠️ 可靠的做法有两个把悬浮窗生命周期挂到宿主的前台 Service 上进程重要性高窗口不被回收或宿主回前台时主动补申请窗口Override public void onResume() { // 宿主回到前台 if (shouldShowFloat() floatView null) { windowManager.addView(floatView, params); // 补申请被回收的窗口 } }补申请必须在onResume之后做在onPause/onStop里补会撞上 token 失效。卡点四Window Type 的跨版本兼容写法现象API 26 上用TYPE_PHONE弹窗口抛BadWindowType异常。原因API 26 起TYPE_PHONE等旧类型保留给系统应用第三方悬浮窗必须改用TYPE_APPLICATION_OVERLAY。int type Build.VERSION.SDK_INT 26 ? WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY // API 26必须用它 : WindowManager.LayoutParams.TYPE_PHONE; // API 26-用旧类型 WindowManager.LayoutParams lp new WindowManager.LayoutParams( WindowManager.LayoutParams.WRAP_CONTENT, WindowManager.LayoutParams.WRAP_CONTENT, type, WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE, PixelFormat.TRANSLUCENT);悬浮窗权限适配 Checklist #检查项判断方式1宿主声明SYSTEM_ALERT_WINDOW设置页无权限入口 未声明2跳设置返回后canDrawOverlays为 true日志或断点验证3沙盒窗口请求走宿主侧权限判定权限状态无本地缓存4API 26 使用TYPE_APPLICATION_OVERLAY日志无BadWindowType5宿主回后台再回前台后悬浮窗可补上真机在 API 29 验证6撤销授权后窗口被移除且无残留撤销再授予反复验证7VAPP 进程退出后无窗口泄漏强杀宿主后检查屏幕测试矩阵与后续 ✅测试矩阵至少覆盖API 23动态权限基线、API 26Window Type 变更、API 30后台启动限制、API 34最新系统行为四档并建议在主流通用 ROM 上各跑一遍相同用例。VirtualApp 版本迭代较快新系统上的权限行为也在持续变化最新适配情况以官方仓库 issue 区的讨论为准。【免费下载链接】VirtualAppVirtual Engine for Android(Support 14.0 in business version)项目地址: https://gitcode.com/GitHub_Trending/vi/VirtualApp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考