Androd 11之后的get_render_resolution不正确

[hgjazhgj]

描述问题bug
airtest.core.android.android.Android.get_render_resolution 描述了一个应用在屏幕上的位置，排除了诸如刘海屏、分屏的其他应用等与用户所关注的应用无关的区域
该方法最终调用 airtets.core.android.adb.ADB.get_display_of_all_screen，通过 adb shell dumpsys window windows 的输出并正则匹配“Frames: containing=...”来判读具体应用的相关信息
在Android 10 以及之前的版本上，相关输出形如
Frames: containing=[...] parent=[...] display=[...]
而在Android 11 以及更新的版本上，相关输出形如（一个上下分屏场景中下方应用的真实输出）
Frames: parent=[0,1779][1116,2480] display=[0,1779][1116,2480] frame=[0,1779][1116,2480] last=[0,1779][1116,2480] insetsChanged=false
此时没有内容被正则匹配，get_display_of_all_screen返回整个屏幕的尺寸而非具体应用的尺寸
其中各个字段的含义见下方评论，你应该匹配出其中的frame作为render_resolution（事实上，在现有代码中，匹配containing也不正确，应该匹配display）

预期效果
请更新相关代码，添加对安卓11及更高版本的支持
或者至少在匹配失败时报错，而不是返回错误的数值

python 版本: python3.13

airtest 版本: 1.4.3

设备:

• 系统: Android 11 或更高

[longqijiashen]

您的邮件已收到！将会尽快处理！

[Pakhiufu]

我是刘一鸣，您的邮件我已收到，我会尽快查看。若有紧急情况请联系17612087473（手机号）。

[hgjazhgj]

下面分别解释几个字段。（由ai生成，供参考）

---

1. parent

parent=[0,1779][1116,2480]

表示父窗口（Parent Window）提供给当前 Window 的可布局区域。

Android Window 是有层级关系的，例如：

Display
 └── Task
      └── Activity Window
            └── PopupWindow
                  └── Dialog

对于普通 Activity：

parent
≈ Task 的 bounds
≈ AppWindowToken 的 bounds

也就是说：

当前 Window 只能在 parent 这个区域里面布局。

你的例子中：

parent:
x = 0~1116
y = 1779~2480

说明：

这个 Activity 所属 Task 本身就在屏幕底部的一块区域。

这和前面看到的

mBounds=Rect(0, 1779 - 1116, 2480)

完全一致。

---

2. display

display=[0,1779][1116,2480]

表示：

当前 Display 对这个 Window 可见的区域（Display Frame）。

注意：

不是整个物理屏幕。

如果：

• 分屏
• 自由窗口
• PiP
• 多显示器
• Letterbox

Display Frame 都可能小于整个屏幕。

你的例子：

display == parent

说明：

这个窗口已经被 Display 裁剪成这一块区域。

---

3. frame

frame=[0,1779][1116,2480]

这是最重要的一个。

它表示：

Window 最终真正占据的位置。

也就是：

SurfaceFlinger 最终创建 Surface 的位置。

很多情况下真正关心的是：

frame.width
frame.height

例如：

frame:
left=0
top=1779
right=1116
bottom=2480

因此：

实际窗口宽 = 1116
实际窗口高 = 701

很多自动化工具（如 Scrcpy、uiautomator、截图工具）实际都是依据这个 Frame。

---

4. last

last=[0,1779][1116,2480]

表示：

上一次布局（layout）计算得到的 Frame。

WindowManager 每次 performLayout 时都会比较：

last Frame

↓

current Frame

如果发生变化：

例如

old:
[0,1800][1116,2480]

new:
[0,1779][1116,2480]

那么说明：

窗口移动了。

于是：

• relayout()
• Surface 更新
• Insets 更新
• 重新绘制

都会发生。

你的例子：

frame == last

说明：

这一次没有发生位置变化。

---

5. insetsChanged

insetsChanged=false

表示：

本次布局过程中：

Insets 是否发生了变化。

Insets 包括：

• Status Bar
• Navigation Bar
• IME（键盘）
• DisplayCutout（刘海）
• Gesture Insets
• System Gesture Insets

例如：

情况一：键盘弹出

frame:
1116×2200

↓

1116×1600

那么：

insetsChanged=true

因为 IME Insets 改变了。

---

情况二：状态栏隐藏

Top Insets

80

↓

0

也会：

insetsChanged=true

---

你的输出：

false

说明：

系统 Insets 没有变化。

---

为什么四个 Rect 都一样？

你的例子：

parent  =
display =
frame   =
last

全部一致。

这是最简单的一种情况：

Task Bounds
        │
        ▼
┌─────────────────────┐
│ parent              │
│ ┌─────────────────┐ │
│ │ display         │ │
│ │ ┌─────────────┐ │ │
│ │ │ frame       │ │ │
│ │ └─────────────┘ │ │
│ └─────────────────┘ │
└─────────────────────┘

窗口正好填满整个 Task，因此没有任何裁剪。

---

为什么窗口只有 701 高？

这一点其实从你的配置就能看出来：

Requested w=1116 h=701

以及：

mBounds=Rect(0,1779 - 1116,2480)

说明：

当前 Activity 运行在

WindowingMode = multi-window

而不是：

fullscreen

所以它只占据了：

y = 1779

↓

2480

这一块区域。

即：

2480 - 1779 = 701 px

因此：

frame.height = 701

而不是整个屏幕高度。

---

总结一下，这几个字段的职责可以概括为：

字段	含义	是否表示最终窗口大小
parent	父容器允许布局的区域	否
display	Display 分配给该窗口的可见区域	否
frame	窗口最终实际占据的矩形（最重要）	是
last	上一次布局得到的 frame	否（用于比较变化）
insetsChanged	系统 Insets（状态栏、导航栏、IME 等）是否变化	不涉及大小，仅表示 Insets 是否更新

对于获取应用当前实际显示区域来说，通常应以 frame（或等价的 mWindowFrames 中的 frame）为准，因为它反映了窗口最终在屏幕上的实际位置和尺寸。