chore(openspec): archive android-driver

Archives the completed android-driver change (16/16 tasks). Promotes the driver_type="uiautomator2" scenario into the canonical driver-registry spec and moves the change artifacts to openspec/changes/archive/2026-07-13-android-driver/.
docs(openspec): complete android-driver command sanity check
2026-07-13 20:39:27 +08:00 · 2026-07-13 20:24:49 +08:00
6 changed files with 6 additions and 2 deletions
@@ -1,6 +1,6 @@
 ## 1. Appium UiAutomator2 command surface (confirmed via research, see design.md Decisions)

- [ ] 1.1 Sanity-check the confirmed mobile commands against whatever `appium-uiautomator2-driver` version is actually resolved in `.venv` before coding: `mobile: clickGesture` (tap), `mobile: dragGesture` (swipe/drag), `mobile: pressKey` (home), `appium:systemPort` (port isolation capability). Docs referenced (2026-07): `github.com/appium/appium-uiautomator2-driver` README and `docs/android-mobile-gestures.md`.
+- [x] 1.1 Sanity-check the confirmed mobile commands against whatever `appium-uiautomator2-driver` version is actually resolved in `.venv` before coding: `mobile: clickGesture` (tap), `mobile: dragGesture` (swipe/drag), `mobile: pressKey` (home), `appium:systemPort` (port isolation capability). Docs referenced (2026-07): `github.com/appium/appium-uiautomator2-driver` README and `docs/android-mobile-gestures.md`.

 ## 2. Driver implementation

@@ -4,12 +4,16 @@
 TBD - created by archiving change device-agent-runtime-foundation. Update Purpose after archive.
 ## Requirements
 ### Requirement: Driver type registry lives in the driver layer
-The system SHALL provide a registry, owned by the `driver` package, that maps a `driver_type` string (e.g. `"wda"`) to a builder function producing a `DriverFactory` for that type, so that any caller needing to construct a driver for a device does so without importing a concrete driver class directly.
+The system SHALL provide a registry, owned by the `driver` package, that maps a `driver_type` string (e.g. `"wda"`, `"uiautomator2"`) to a builder function producing a `DriverFactory` for that type, so that any caller needing to construct a driver for a device does so without importing a concrete driver class directly.

 #### Scenario: Building a factory for a known driver type
 - **WHEN** a caller requests a driver factory for `driver_type="wda"` with connection info (e.g. `server_url`, `udid`)
 - **THEN** the registry returns a `DriverFactory` that, when invoked, constructs a working `WDADriver` configured with that connection info

+#### Scenario: Building a factory for the Android driver type
+- **WHEN** a caller requests a driver factory for `driver_type="uiautomator2"` with connection info (e.g. `server_url`, `udid`)
+- **THEN** the registry returns a `DriverFactory` that, when invoked, constructs a working `AndroidDriver` configured with that connection info
+
 #### Scenario: Building a factory for an unknown driver type
 - **WHEN** a caller requests a driver factory for a `driver_type` that is not registered
 - **THEN** the registry raises a clear error naming the unsupported `driver_type`, instead of returning `None` or a factory that fails later at connect time