Flutter Device Testing 用于在具体目标上操作并验证 Flutter 应用，目标可以是模拟器、仿真器、浏览器、桌面端或物理设备。其核心原则是：使用能证明所改动行为的最小目标矩阵，并明确说明哪些被实际执行、哪些没有。同时，需要把运行时目标与流程所使用的数据源区分开来。
用途 该技能面向 Flutter 应用在真实或虚拟目标上的运行与验证，覆盖目标生命周期、平台状态检查、用户流程执行、断言与日志采集，以及任务产物的清理。
主要能力
- 发现优先：检查项目的 SDK、支持的平台、flavor、入口点和现有测试工具；运行 flutter devices，在需要启动虚拟目标时运行 flutter emulators。
- 目标解析：按稳定标识符解析一个目标，记录它是被复用还是由任务创建，并等待其就绪。
- 安全约束：没有明确需求和授权时，不得擦除、重置、重建、卸载或清除用户目标上的数据。
- 工具选择：Flutter 自有状态优先使用 Flutter CLI 以及可用的 Dart 和 Flutter MCP 能力；adb 或 simctl 仅用于它们实际提供的平台控制。Flutter 查找器无法操作原生系统 UI（如权限对话框、通知托盘或平台视图），需要此类交互时应使用项目已采用的原生能力测试装置，不应仅因熟悉就引入 Patrol、Maestro、Appium 或其他框架。
使用方式 工作流包括：
- 确认依赖和生成代码已就绪，但不改变项目的包或架构选择。
- 在改变运行时状态前，验证目标就绪状态和 flavor 特定的应用标识。
- 使用正确的 flavor、入口点、defines 和构建模式启动；绝不要把凭据放在命令行参数或保留的产物中。
- 执行精确的用户流程以及相关的生命周期或平台状态；区分状态注入与观察真实提示、提供方或操作系统投递路径。
- 捕获与所测构建对应的聚焦断言、截图和过滤日志；需要持久自动化时，运行项目的集成或原生 UI 测试装置。
- 恢复任务创建的目标覆盖，并只移除任务拥有的产物，失败后也要执行。
可靠性要求
- 不要假设构建成功、启动命令成功或操作系统触发成功就证明应用行为正确。
- 优先使用语义查找器、无障碍标识符或集成 API，而不是硬编码坐标；优先使用有界就绪条件，而不是任意等待。
- 热启动声明需要显式前置条件，证明触发前预期的进程和 UI 状态。
- 使用生命周期运行器时，确认每个钩子继承其有界超时，并且 after 清理在通过、失败、超时或命令错误后都从其 finally 路径尝试执行。
报告与证据边界 报告应包含目标类型和安全标签、操作系统/运行时、构建模式、flavor、入口点或相关 defines、精确流程、数据源、断言、产物以及跳过的边界。默认不要发布原始物理设备标识符。模拟器或仿真器行为是功能证据，不是物理硬件性能、GPU、摄像头、传感器、OEM 或生产推送的证据。基准归因应交给 flutter-performance，更强的硬件声明需在代表性物理设备上以 profile 或类 release 模式验证。
参考
- 设备发现与仿真器：共享目标选择、所有权、就绪、安全和证据规则。
- Android 仿真器操作：使用 Flutter 和 adb 启动或控制 Android 虚拟或物理目标。
- iOS 模拟器操作：使用 Flutter 和 simctl 控制模拟器，包括权限、位置、截图或模拟推送。
- 集成测试工作流：在活动目标上编写或运行 package:integration_test 套件、深链接或冒烟测试。
- 生命周期入口矩阵：需要在冷/热启动、认证、重复投递、慢数据或账户变更中重放深链接或通知点击时使用；解析占位符，并要求所包含运行器的 dry run 以预期计划成功退出后，再添加 --execute。
来源 Flutter CLI、集成测试、Dart 和 Flutter MCP 服务器。