📚 课程目录第2章 Android窗口安全机制解析

二、Android窗口安全机制解析

Android窗口安全机制依托于 WindowManager 提供的标志位体系，其中最核心的是 FLAG_SECURE。本章围绕该标志的原理、设置方式、系统截屏完整触发链路以及调试/稳定性要点展开，为后续基于 Compose 的防截屏输入组件提供底层知识支撑。

2.1 FLAG_SECURE 原理

FLAG_SECURE 是定义在 WindowManager.LayoutParams 中的一个公共标志位（public flag），整型值为 0x00002000。当窗口被设置为该标志时，SurfaceFlinger 会在合成帧阶段进行安全策略判断：

系统截屏服务在抓取屏幕内容时，会跳过所有携带 FLAG_SECURE 的图层（layer）。
非安全显示设备（例如通过无线投屏、录制服务）试图获取帧缓冲区时，同样会被滤除。
该标志在 View 层级和 Surface 两个维度生效，无需应用主动参与截屏回调。

注意： FLAG_SECURE 是硬件层与显示合成层联合保障的，并非仅靠软件标记。其实现依赖于 SurfaceFlinger 中的 secureDisplay 位掩码检查。

2.2 WindowManager.LayoutParams 截屏相关标志位

标志位	常量值	作用
FLAG_SECURE	0x00002000	禁止截屏/录屏/非安全显示
FLAG_NOT_FOCUSABLE	0x00000008	窗口不接收焦点，间接影响截屏服务对焦点窗口的判断
FLAG_LAYOUT_IN_SCREEN	0x00000100	全屏布局，与截屏区域计算相关
FLAG_WATCH_OUTSIDE_TOUCH	0x00040000	监视外部触摸事件，不影响截屏但常用于安全键盘

关键API调用：

// Activity 中设置
getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

// Dialog 中设置
dialog.getWindow().setFlags(...);

// Compose 环境下需通过 ComponentActivity 获取 Window
val window = (context as ComponentActivity).window
window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

2.3 系统截屏触发流程

从用户按下物理按键组合（音量下+电源）或触发系统手势，到最终生成截屏图片，完整链路如下：

2.4 调试与验证方法

# 方式1：使用 dumpsys 查看当前窗口 FLAG_SECURE 状态
adb shell dumpsys window windows | grep -E "mFlags|FLAG_SECURE|0x2000"

# 示例输出片段
Window #0 Window{...}:
  mFlags=0x2000  (FLAG_SECURE 已设置)

# 方式2：通过开发者选项启用“屏幕录制”并尝试录制包含安全窗口的画面，观察是否出现黑屏区域
# 方式3：使用第三方“协助工具（AccessibilityService）”作为测试代理，验证截屏回调是否返回空图层

2.5 常见错误与稳定性优化

问题类型	描述	解决方案
Dialog 未传递 FLAG_SECURE	Dialog 拥有独立的 Window，若不在 show 之前设置标志则无保护	在 `dialog.show()` 前调用 `window.setFlags(FLAG_SECURE)`
Compose 环境回调延迟	Compose 的 `AndroidView` 嵌套中窗口尚未创建就设置标志可能失效	使用 `LaunchedEffect(Unit)` 在协程中延迟一帧后再设置
低版本兼容性	Android 4.x 某些设备上 FLAG_SECURE 仅阻止录屏，不阻止截屏	增加运行时检测（`Build.VERSION.SDK_INT >= 17`）并输出警告日志
WebView 安全窗口冲突	WebView 内嵌视频可能因 FLAG_SECURE 导致无法渲染	对视频区域单独用 `SurfaceView` 并移除 FLAG_SECURE

安全提示： 部分定制 ROM（如 MIUI、ColorOS）可能绕过 FLAG_SECURE 机制，在系统截屏时错误地合成安全窗口内容。建议在生产环境中配合 DisplayManager 的 FLAG_SECURE 检测，并在关键业务页面增加第二层防护（如自定义内容遮盖）。

2.6 性能与稳定性优化建议

不做额外 I/O： FLAG_SECURE 本身是 SurfaceFlinger 层面的位运算，不产生额外的内存拷贝或磁盘操作，性能开销可忽略不计。
防止标志泄露： 当 Activity 或 Dialog 退出时，系统会自动清除窗口标志；但若手动复用 Window 对象（如自定义 Toast 窗口），需在复用前重置标志。
结合 ANR 监控： 在短时间内频繁切换 setFlags 可能触发窗口布局重排，若在主线程执行过多标志变更操作（如每100ms切换一次），建议使用 HandlerThread 或仅变更时机。
断点续传场景： 应用进入后台再返回前台时，系统可能会重新创建 Window 并丢失 FLAG_SECURE（罕见情况）。应在 onResume() 中重新确认标志状态。

实战检查代码片段：

// 在 onResume 中强制重新应用 FLAG_SECURE（兼容窗口重建场景）
override fun onResume() {
    super.onResume()
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
        if (window.attributes.flags and WindowManager.LayoutParams.FLAG_SECURE == 0) {
            window.setFlags(
                WindowManager.LayoutParams.FLAG_SECURE,
                WindowManager.LayoutParams.FLAG_SECURE
            )
            Log.d("SecureWindow", "FLAG_SECURE re-applied in onResume")
        }
    }
}