Checkpoint: The Agent Loop Before It Can Act
The Android measures become easier to judge when invocation and context are treated as one chain rather than as separate permissions. This chapter connects the reachable assistant from the preceding discussion with the data, device signals, and output surfaces that can make it context-aware. The practical conclusion is a boundary: an assistant can be reachable and informed without yet being authorised, equipped, or able to change anything on the device.
That boundary is the key to understanding the Commission's intervention. The 11 features are not valuable merely because each exists. Their value depends on whether a user-selected service can pass through a sequence of handoffs while preserving user intent, permitted data, understandable control, and enough timing to be useful. A weakness at any handoff can turn a system-level capability back into an isolated app experience.
From an entry point to a listening system
The first handoff begins with the user. A long press on the home button or navigation handle can call the selected assistant while another application remains open. A validated hotword can do the same without requiring the user to touch the screen. These triggers are different in operation, but they have the same structural consequence: Android chooses a service to receive the beginning of an interaction that previously could be reserved for Google's own services.
The next handoff is from Android to the context layer. A gesture-based invocation may carry a screenshot, information about the open app, or data supplied by the foreground application. A hotword invocation begins with a validated voice trigger and may then continue with audio until the user ends the request or conversation. Neither path means that the assistant automatically receives every kind of context. The entry event opens a route; the relevant data still has its own access conditions.
Those conditions create three useful distinctions. App-donated data is information an application chooses to share through a central on-device mechanism, allowing an assistant to search and retrieve permitted material across applications. Digital and physical context is information about the device and the user's activity—such as screen contents, notifications, location, or sensor signals—that can support context-aware suggestions. Ambient data is the live input or output stream from capabilities such as the microphone, camera, screen, system audio, and environmental sensors. All three can inform an assistant, but they differ in who supplies them, how continuous they are, and what a user may reasonably expect them to reveal.
The assistant then interprets what it has received. That step is not just a technical transformation from data to text. It is where the service decides whether a piece of context is relevant to the user's apparent request and whether to produce an answer, a proactive suggestion, or a route into another capability. The Commission's description of context-aware intelligence includes processing resources and output surfaces precisely because an assistant needs somewhere to turn an input into an experience. A signal that arrives without a usable surface is not a complete interaction.