From Tap to Wake Word: Making Any Assistant Reachable
The Android interoperability measures begin with a deceptively simple question: can a person reach a third-party AI assistant as easily as they reach Google's? This chapter focuses on the two system entry points that answer that question—a long press on the home control and an always-on hotword—and traces what happens between a user's signal and an assistant's response. The result is a practical way to distinguish a selectable system pathway from unrestricted background access.
An assistant that must be opened manually is not necessarily inferior. But it starts with a distribution disadvantage when Google's service can be summoned from anywhere on the device, with access to the surrounding screen or application context, while alternatives cannot. The European Commission's measures address that first moment of interaction before they address what the assistant may know or do.
The home control is a distribution channel
The long-press home or navigation-handle feature is more than a button shortcut. On Android, an access point can invoke a Google service while the person is already using another application. The Commission's final measures require Alphabet to provide third parties with access to that point and the functionalities available to its own services. When invoked, the alternative service must be able to receive comparable contextual information—such as a current screenshot, details about the open application, or data supplied by the foreground app—and present an overlay.
That requirement changes the assistant's position in the device. A conventional app waits for the user to leave the current task, locate its icon, and decide what information to transfer. A system-invoked assistant can begin with the task already in view. Someone looking at a webpage might call an assistant to interpret the page; someone reading a message might ask about a visible date or image. The legal measure does not guarantee that every possible context will be available on every phone. It says that where Google's service can use the access point and associated functionality, an alternative must receive a solution that is equally effective.
The user, not the provider, is meant to choose the route. Alphabet must make it possible to customise the access point, and the selection mechanism must be easy and non-discriminatory, including in its interface. The company may not reserve an access point for its own services through technical or contractual means, subject to the decision's allowance for an original equipment manufacturer to reserve one other access point for the default assistant role. That exception matters because it leaves some room for device makers to shape the out-of-the-box experience without preserving Google's exclusive hold over every route into Android.
The difference is therefore not simply “Google button versus competitor button.” It is a contest over whether the operating system treats assistant invocation as a neutral capability or as part of Google's distribution property. If choosing another assistant requires extra steps, a less capable overlay, or a confusing permission journey, an endpoint may exist while the competitive disadvantage remains. The measures' broader equal-effectiveness rules are designed to address that gap between technical availability and a usable path.
The home gesture also establishes a sequence of trust. Android decides which service receives the invocation; the service receives some information about the current task; and the service presents an answer or an overlay without forcing the user to abandon the application they were using. Each link has a different owner. Alphabet controls the access point and the technical handoff, the foreground app may determine what information it makes available, the selected assistant interprets the request, and the user decides which service should be called. Treating all of that as one “assistant permission” would hide where a failure or an abuse could occur.
The requirement for an overlay matters for the same reason. A service that is technically invoked but must open a separate screen may be harder to use than Google's context-sensitive surface. Conversely, an overlay that receives more screen or app information than the user expects could make the handoff opaque. The measures therefore connect the access point to contextual data and presentation, while the general rules add consent, awareness, and revocation. The competitive question and the privacy question begin at the same interface, but they are not the same question.
What “always on” means in the hotword design
Voice invocation creates a harder engineering problem because the phone has to notice a wake phrase even when the display is off, the device is in battery-saving mode, or the person is doing something else. The measure covers an always-on hotword detection feature designed to run continuously in an energy-saving way. It does not describe one undifferentiated pipeline in which an assistant receives all microphone data from the moment the phone is idle. It describes stages with different jobs and, potentially, different protections.
First, a service enrols a sound model with the Android operating system so that the model can be stored and retrieved when the app starts detection. The model is then loaded onto a digital signal processor, or DSP, where a low-power first stage looks for the enrolled phrase. The point of using this processor is operational: a detector that keeps the main application and more demanding compute awake for every sound would consume resources that a phone cannot afford indefinitely.
A candidate match moves to a second-stage validation step. The measure allows this stage to run in a secure and isolated process and to prevent audio data from being extracted before the hotword has been validated. Only after validation does the operating system invoke the assistant to handle the user's request. Once the invocation occurs, the service can continue to receive audio until the user decides to finish the request or conversation. That sequence creates a meaningful distinction between detecting a possible wake word and opening a conversational microphone channel.
The sequence also clarifies what an equivalent implementation has to preserve. A third-party assistant needs more than a callback that fires after Google's detector has done the important work. It needs a way to enrol and retrieve its own sound model, run the first detection stage on the relevant low-power hardware, receive a validation path, and obtain the post-invocation audio needed to answer. If one of those stages is withheld, the service may be listed as compatible while its practical voice experience is materially weaker.
There is a corresponding failure boundary. A false candidate should not automatically become a conversation, and a validated phrase should not silently turn into indefinite recording. The final measures leave room for technical protections such as process isolation and user-facing controls, but the assistant's continued access ends when the user ends the request or conversation. That is not a complete security solution for every future agent; it is a defined handoff in which the operating system can separate detection from conversation and give the user a meaningful point of control.
This is why the legal language around equivalence reaches below the user interface. A third-party service that can register a phrase but cannot keep the detector active on a locked screen or in battery-saver mode would not be comparable to Google's service. Nor would one that receives a lower-quality signal, cannot validate the phrase reliably, or loses the conversation as soon as another application comes to the foreground. The final measures require the relevant access, testing tools, and conditions to be equally effective, within the technical capabilities of the device.
The hard part is sharing the listening path
A phone may support more than one assistant, but it cannot be assumed that every device can run an unlimited number of sound models at once. The final measures handle this in two stages. For the first hotword requirements, Alphabet must provide access to enrolment, DSP detection, validation, invocation, and post-invocation audio in Android 18 and by 1 August 2027. The requirement that multiple services' hotword detectors run concurrently comes in the following major release, Android 19, and by 1 August 2028. Even then, the text qualifies concurrency by the technical capabilities of the device.
That schedule exposes an important design trade-off. The Commission is demanding a common entry point, but it is not pretending that hardware scheduling disappears when a legal obligation is issued. Multiple detectors compete for low-power processor capacity, memory, energy, and possibly the device's ability to distinguish similar phrases. A rule that simply said “everyone gets always-on voice” would leave the most difficult engineering question unanswered. The staged deadlines instead separate the right to build a third-party hotword implementation from the more demanding requirement to run several implementations at once.
The phrase “within the technical capabilities of the device” is a real boundary, not a loophole that makes concurrency meaningless. A phone with a particular DSP design may be able to run several enrolled models efficiently; another may have less headroom. The Commission's wider measures deal with that variation by requiring consistent solutions across eligible Android versions, devices, and form factors, while allowing neutral rules based on system stability and device health. The eventual test is not whether every phone behaves identically, but whether the same constraints are applied without giving Google's detector a hidden exemption.
That makes testing part of the right itself. Developers must receive tools to verify that their implementation recognises the intended phrase, and Alphabet must allow developers to test interoperability, including through beta releases. A voice pathway can fail in ways a static API description will never reveal: a model may work in a laboratory but miss phrases in battery-saving mode; two detectors may compete and increase false activations; or a release may change the audio path without updating the third-party implementation. The measures require the platform to expose enough of the pathway for those practical failures to be found before users rely on it.
The same distinction helps explain why users' choice has to be part of the mechanism. The measures require central settings or comparable controls through which users can manage applications using always-on hotword detection. The enable-or-disable mechanism must be non-discriminatory. A user should not have to accept a different class of warning, a more cumbersome route, or a less visible control merely because the selected service is not Google's. The service also receives the same contextual data available to Google's service upon invocation, but that does not remove the user's ability to decide which applications use the feature.
There are several points at which this design can fail without any dramatic security incident. The access point may be technically exposed but buried behind an unfamiliar interface. A hotword may be registered but not work while the screen is locked. A detector may invoke the wrong service or begin a conversation before the user understands what happened. A third-party assistant may receive the wake signal but not the context that makes the request useful. Each failure changes the user's practical choice even if a developer can truthfully say that an API exists.
This is also where the difference between a feature and a privilege becomes visible. The measures open the invocation pathway, but they do not say that every app automatically receives unlimited microphone access. The hotword sequence contains enrolment, detection, validation, invocation, user settings, and continued audio as separate stages. General rules allow consent, user information, revocation, and integrity measures, as long as the conditions are transparent, objective, precise, and applied equally to Alphabet's services and to third parties. The feature is shared; the responsibility for making its use understandable and bounded remains.
A reachable assistant is not yet a capable one
Opening the entry point changes who can begin the interaction, but not yet everything the assistant can learn or execute after it begins. A long press may supply a screenshot or foreground-app information; a validated hotword may open a conversation. Neither fact alone grants access to a centralised store of app data, to continuous sensor input, or to actions inside other applications. Those are separate layers of the Android interoperability design, with their own consent and security conditions.
That separation is useful for judging the policy. It prevents two opposite mistakes. One is to treat invocation as a trivial interface concession, even though control over the first system interaction can determine which service users discover and continue using. The other is to treat a shared entry point as proof that the whole device has been opened. The measures create a route to the assistant first. Whether that route can lead to relevant context, cross-app action, and dependable background work depends on the boundaries that follow.
For now, the central result is narrower and more concrete: Android's system-level invitation need not be Google's exclusive distribution channel. A user can be given a comparable path through a gesture or, subject to the staged implementation, a wake word. The next question is what the chosen assistant is allowed to know once that path has been opened—and whether “context” means a small amount of app-donated information, a continuous stream of device signals, or something much more powerful.