Second half of the intents feature (docs/INTENTS_PLAN.md §3-§5), engine first: the
options screen that WRITES a registration follows in this same ticket.
WHAT SHIPPED.
* THE MODEL (const.py + media_player.py). A registered intent is ordinary options
data — a list of dicts {id,name,package,activity,action,categories,data,fields}
— so it survives a reload and is otherwise inert. `normalise_intent` accepts a
row only if it names something to launch (a component with the slash Android
requires, OR an action), `registered_intents` reads the options defensively
(junk rows dropped, duplicate ids keep the first, the registration cap applied)
and never touches a shell.
* THE COMMAND. `intent_am_start_command` assembles
`am start -n <component> -a <action> -c <category>… -d <data> --es/--ei/--ez key value`.
`{placeholder}` substitution is plain regex replacement over the DATA template
only — no eval, no format(), no shell interpolation — and every value is
shlex.quote'd, so a variable whose value is `"; rm -rf /"` reaches the device as
literal data inside one quoted word. Address validation for adb_command is
untouched; `adb_command` stays the one raw-shell door.
* HONEST FAILURES, each with a plain message AND a translation key so the button
and the action both read well: an unknown intent name lists the registered ones,
a missing REQUIRED field names the field, a variable the intent did not declare
is REFUSED (nothing silently travels to the device and nothing is silently
dropped), a value that cannot become its declared type names the field and the
value, a data template with an unfilled placeholder names the placeholder, ADB
off/down says the protocol cannot carry intents, a transport that never answered
says so, and a device that refused the intent surfaces the DEVICE'S OWN message
("unable to resolve Intent", "does not exist", "Permission Denial") and raises.
* THE ACTION. `nvidia_shield.send_intent` takes `intent` (a select selector whose
options are the loaded intents, `custom_value` on) plus `variables`, resolves
exactly ONE Shield through t14's resolver (one participant, or no_target /
unsupported_target / ambiguous_target naming the service), and returns the
device's output under `intent_response`. Registered with
`SupportsResponse.OPTIONAL` FIRST, because `async_set_service_schema` reads
`hass.services.supports_response()` to publish the response flag — the t14
mechanism, re-verified against the installed HA for t17. The description is
republished on every entry setup, so an options change (which reloads) refreshes
the dropdown.
* THE BUTTONS. One button per registered intent (name from the registration, id
from the intent's stable id so a rename does not orphan the entity), pressing it
sends the intent with the fields' declared defaults and raises on every failure
instead of doing nothing. Its extra attributes expose what it will send.
TWO MEASURED REPAIRS IN THE SAME HOOK (media_player.py). Both were latent because
the test harness pre-sets `_manager`:
* the service registries were filled BEFORE the entry's manager was assigned, so a
real entry registered `None` and `adb_command` would crash with AttributeError
instead of answering. The manager is now consumed first, and both registries are
filled after it;
* `async_will_remove_from_hass` never dropped the entity's participation (the
comment said it did), so a removed or unloaded entry left a stale manager and the
action answered `adb_unavailable` for an entity that no longer exists instead of
reporting an unsupported target. Both registries are dropped now, keyed by the
key computed at add time.
Verify: 794 passed / 4 skipped and 795 passed / 3 skipped (androidtvremote2) —
unchanged counts, so nothing regressed; ruff clean.
James Mackay
a8041e1428
