AutoJS悬浮窗权限适配问题

Question

在使用AutoJS实现悬浮窗功能时，常见问题为：应用在Android 8.0及以上系统中无法正常显示悬浮窗。该问题通常源于系统对TYPE_APPLICATION_OVERLAY类型窗口的权限限制。尽管已申请SYSTEM_ALERT_WINDOW权限，若未在代码中正确适配新版本API或未引导用户手动开启“显示在其他应用上方”的权限，悬浮窗仍会被系统拦截。此外，部分国产ROM（如小米、华为）存在额外的权限管理策略，需跳转至系统设置页面手动授权，否则会导致悬浮窗创建失败或被立即销毁。

Answer 1

一、问题背景与现象分析

在使用AutoJS实现悬浮窗功能时，开发者普遍反馈：应用在Android 8.0（API Level 26）及以上系统中无法正常显示悬浮窗。该现象的核心原因在于Android系统对窗口类型的权限控制机制进行了重大调整。

从Android 8.0开始，Google引入了新的窗口类型TYPE_APPLICATION_OVERLAY，以替代此前广泛使用的TYPE_PHONE或TYPE_SYSTEM_ALERT。这一变更旨在增强用户隐私和系统稳定性，防止恶意应用滥用悬浮权限进行界面劫持。

尽管应用已通过Settings.ACTION_MANAGE_OVERLAY_PERMISSION申请了SYSTEM_ALERT_WINDOW权限，但若未正确调用新API或未适配国产ROM的特殊策略，仍会导致悬浮窗创建失败。

二、技术演进与权限变迁

• Android 7.1及以下：可直接使用TYPE_PHONE创建悬浮窗，只需声明权限并请求授权。
• Android 8.0+：必须使用TYPE_APPLICATION_OVERLAY，否则系统将抛出异常或静默拦截。
• 权限模型变化：SYSTEM_ALERT_WINDOW变为“特殊权限”，无法通过常规requestPermissions()动态申请，必须引导用户手动开启。
• 国产ROM干扰：小米MIUI、华为EMUI、OPPO ColorOS等均在此基础上添加了额外限制，如“自启动管理”、“后台弹出界面”开关等。

三、典型错误代码示例与对比

版本	旧写法（Android 7.x兼容）	新写法（Android 8.0+适配）
窗口类型	WindowManager.LayoutParams.TYPE_PHONE	WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY
权限检查	Settings.canDrawOverlays(ctx)（不完整）	if (Build.VERSION.SDK_INT >= 26) { ... } 分支处理
启动方式	直接create	需先跳转设置页，确认授权后重启服务

四、完整的解决方案流程图

```mermaid
graph TD
    A[启动AutoJS脚本] --> B{Android版本 >= 8.0?}
    B -- 是 --> C[检查SYSTEM_ALERT_WINDOW权限]
    B -- 否 --> D[使用TYPE_PHONE创建悬浮窗]
    C --> E{已授权?}
    E -- 否 --> F[跳转系统设置页]
    F --> G[提示用户手动开启“显示在其他应用上方”]
    G --> H[返回后重新检测]
    E -- 是 --> I[使用TYPE_APPLICATION_OVERLAY创建窗口]
    I --> J{是否为MIUI/EMUI/ColorOS?}
    J -- 是 --> K[进一步检查ROM专属权限]
    K --> L[引导至厂商设置页面]
    J -- 否 --> M[成功显示悬浮窗]
```
  

五、关键代码实现片段

// 检查并请求悬浮窗权限
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    if (!Settings.canDrawOverlays(context)) {
        Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + context.getPackageName()));
        context.startActivity(intent);
        return;
    }
}

// 创建LayoutParams适配不同版本
WindowManager.LayoutParams params = new WindowManager.LayoutParams(
    WindowManager.LayoutParams.WRAP_CONTENT,
    WindowManager.LayoutParams.WRAP_CONTENT,
    Build.VERSION.SDK_INT >= Build.VERSION_CODES.O 
        ? WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY 
        : WindowManager.LayoutParams.TYPE_PHONE,
    WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE | WindowManager.LayoutParams.FLAG_LAYOUT_IN_SCREEN,
    PixelFormat.TRANSLUCENT);

// 绑定View并添加到WindowManager
windowManager.addView(floatingView, params);
  

六、国产ROM适配策略汇总

部分主流厂商对悬浮窗行为施加了更严格的管控：

1. 小米（MIUI）：需在“权限管理”中开启“显示在其他应用前面”和“后台弹出界面”。
2. 华为（EMUI）：除基础权限外，还需关闭“纯净模式”或在“应用启动管理”中允许自启动。
3. OPPO/Realme（ColorOS）：存在“无边界窗口”开关，需手动启用。
4. Vivo（Funtouch OS）：“后台高耗电”白名单影响悬浮窗存活。
5. Samsung（One UI）：部分版本限制第三方应用使用OVERLAY类型。
6. AutoJS应对方案：可通过包名识别设备品牌，定向提示用户跳转至对应设置界面。
7. 自动化检测工具：利用Build.MANUFACTURER和Build.BRAND判断设备来源。
8. 用户教育成本：建议在首次运行时展示图文指引，降低使用门槛。
9. 日志埋点：记录权限拒绝次数，用于后续优化引导逻辑。
10. 降级兼容：当无法获取权限时，提供Toast提示或局部UI替代方案。

七、调试技巧与常见陷阱

在开发过程中，以下几点容易被忽视但至关重要：

• Logcat中搜索WindowManager关键字，查看是否因类型错误被拒绝。
• 某些ROM会在锁屏后自动清除悬浮窗，需注册广播监听屏幕状态。
• Activity销毁后未及时removeView，可能导致内存泄漏或崩溃。
• 多进程环境下，需确保权限检查发生在主进程中。
• 目标API级别应设为30以上，并在AndroidManifest.xml中声明uses-permission。