Files

T

Tests / Test passed: 624

Details

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/.

2026-07-13 20:39:27 +08:00

2.1 KiB

Raw Blame History

driver-registry Specification

Purpose

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", "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

Requirement: Adding a driver type requires no changes outside the driver layer

The system SHALL allow a new driver type to be added by registering it in the driver package's registry alone; no other package (api/, device/, tools/, runtime/) SHALL need code changes to support constructing devices of the new type.

Scenario: API layer is agnostic to registered driver types

WHEN the console config API resolves a driver_type string into a driver factory to register a device
THEN it does so by calling into the driver registry rather than maintaining its own mapping of driver_type to concrete driver classes

2.1 KiB Raw Blame History