[jinghero]

摘要

• 魔改 AVD 新建默认 1080p（1920×1080 / DPI 280），可选 720p（1280×720 / DPI 240）；单台和批量设置支持换档，联动宽高与 DPI、保留方向，下次开机生效。雷电与 MuMu 的 DPI 档位保持原值，配置守卫按每台设备实际应用的值记录基准。
• 包内 CLI 新建与设置传递 --resolution。没有 CLI 时，Python 回退按已有宽高识别档位并在开机前保档，已有横竖屏 1080p 不再被降为 720p；缺字段旧配置保持 720p。
• 对旧版包内 CLI，720p 仍可使用；1080p 新建、换档和启动会在写盘前提示升级，避免旧启动路径重新写回 720p。接口模型通过 OpenAPI 生成器更新，复用现有创建与设置的遥测事件。

Refs ModAVD/ModAVD#100

证据

基于 upstream/dev 的 d49cff7c5，独立 worktree，当前提交 420a9eaf3a8ee5041d9b5c4a76b1a50a751ae525。Windows、锁定依赖、Python 3.12.13；实机在功能提交 01e676b6f 上使用 ModAVD 0.37.1 模拟器和 ModAVDManager#61 的 CLI 构建。专用根、物理复制的 SDK、私有 ADB server 和独立实例/端口，未使用 K 的测量实例。当前补丁修改守卫基准记录，未修改启动或显示写回逻辑。

实机场景	读取客体的结果
CLI 与 Python 两条路径新建默认实例	1920×1080 / DPI 280
显式 720p 新建	1280×720 / DPI 240
CLI 横屏 1080p → 720p → 1080p，Python 横屏 1080p → 720p	重启后宽高、DPI 均与档位一致
Python 竖屏 720p → 1080p → 720p	1080×1920 / 280、720×1280 / 240
Python 旧 720p 缺 DPI，连续两次冷启动	保持 1280×720 / DPI 240
运行中改档	当前客体仍用原档，重启后使用新档
已发布旧 CLI 启动已有 1080p	启动前拒绝，配置字节不变；新版 CLI 正常启动为 1080p / 280

读取 wm size、wm density，Python 路径另读 dumpsys display，不以表单或 config.ini 代替客体验证。实际 Vue 组件验证了新建默认值、设置换档及明暗主题；没有运行游戏或真实账号调度 E2E。

• uv run --no-sync python -m pytest tests/core/test_emulator_batch_baseline.py tests/tools/test_avd_resolution.py tests/tools/test_avd_cli.py tests/tools/test_avd_metadata.py tests/api/test_emulator_resolution.py -q：43 passed。默认新建、旧 CLI 启动保护和批量基准记录均有红/绿对照。新增基准回归通过真实 AVD 配置与 YAML 保存、重载，验证横竖屏的实际 DPI 280、无虚假偏移，以及偏移至 720p 后可由守卫恢复 1080p。
• yarn test src/views/Emulator/settingsTiers.test.ts src/i18n/locales.test.ts：4 passed。yarn lint、yarn typecheck、yarn format:check、yarn e2e:check 通过。
• uv run --no-sync ruff format --check .、改动文件 Ruff、uv lock --check、changelog check、git diff --check 通过。
• 当前提交的 完整 Python CI 已通过：Windows 1005 passed、1 skipped，Ubuntu 995 passed、11 skipped，两者均有 15 subtests passed。本机定向回归 43 passed；本轮扩大回归在 test_hsr_m7a_lifecycle.py::test_cancel_during_launch_cleans_tracked_process 的事件循环关闭阶段等待，未跑完。该用例在未修改的 d49cff7c5 基线单独运行通过，未修改其源码或断言。先前 MaaEnd 线程池关闭的本机阻塞及基线对照也保留在本地记录中。
• 当前提交的 Windows 验证包构建、格式、锁文件和更新日志 CI 均通过。

按 pstack 的 blast-radius、prove-it-works、type-system-discipline 和 unslop 审查了页面到 API、CLI/Python、持久化、重启及混合批量设置的链路，并补齐了旧 CLI 启动保护。

合并风险

1080p 的 CLI 路径需要先发布包含 ModAVDManager#61 的包内管理器；旧 CLI 会明确报不支持。Python 回退不依赖该更新。文档配套见 modavd.github.io#12。维护者私有启动器的默认值仍需维护者调整。

[jinghero]

总体结论：修改后合并

宝宝，AUTO-MAS #1837 的批量设置现在会按实际应用的值保存基准了，这处修得好喵～不过旧版 ModAVD 管理器还有一种情况会显示设置成功，实例却仍无法启动，需要先处理。

设置页面负责提交用户选择，MAS 的 AVD 管理器负责读取和修改实例配置；使用包内命令行管理器时，MAS 还要兼容它报告的显示参数。

[兼容 · P2] 旧版管理器下，批量设为 720p 可能显示成功但没有生效

位置： 读取设置、判断是否需要修改、启动前检查。

现状与证据： 以下是静态推演，尚未实际复现。假设实例配置文件中已有 1080p，包内管理器是已发布的 v0.3.1：

1. 旧管理器的 info 返回的是它启动时将使用的固定 720p，而不是配置文件中原来的 1080p。相关逻辑见 Display 和 info.Config。
2. 用户批量选择 720p 后，MAS 以为当前已经是 720p，跳过写入并向页面返回成功；配置文件实际上仍是 1080p。
3. 随后启动时，新增检查读取真实配置，发现 1080p 而旧管理器不支持，于是要求用户升级。单台设置也会显示已经是 720p，无法通过再次选择 720p 修正。

**影响：**用户看到批量设置成功，但实例仍不能启动，也无法从单台设置看出实际配置尚未改变。旧管理器拒绝启动 1080p 是已说明的保护；这里的问题是把没有完成的 720p 设置报告为成功。

**建议：**设置时区分旧管理器报告的预计启动值与文件里的实际配置。若不能安全地改为 720p，至少明确返回失败并提示升级，不要记录为成功；也可以在保证配置安全的前提下完成降档。增加一条回归：旧版管理器、原文件为 1080p，批量设为 720p 后检查结果与实际文件一致，再检查能否启动。

本次为静态审查，没有运行项目代码或测试。已有 CI 包含 Windows、Ubuntu 测试和 Windows 验证包构建；真实模拟器及客体结果以作者提供的验证为准，本次没有独立复现。

—— dot酱敬上 🐾