What an Assistant Is Allowed to Know
The Android interoperability measures now move from reachability to knowledge. This chapter examines what a third-party AI service may obtain after a user invokes it: app data deliberately shared through a central on-device mechanism, continuously available digital and physical context, and ambient signals from the phone's sensors and outputs. The useful judgment is not whether “context access” sounds powerful, but which actor supplies each input, how often it is available, and where consent or revocation can stop the flow.
That distinction matters because an assistant's relationship with the device changes as information crosses these boundaries. An app that receives a question typed into its own screen is one kind of service. An assistant that can search selected information from several apps, observe the current screen, or react to signals while the user is doing something else is closer to a system-level participant. The Commission's measures attempt to make that richer relationship available to alternatives on terms comparable to Google's services, without declaring that every service may read everything.
A central store built from app choices
The first context mechanism is centralised access to application data stored on the device. Under the final measures, third-party AI services must be able to search and retrieve data that applications choose to share on an opt-in, role-based basis. The important change is architectural, even at a non-specialist level: an assistant does not need to negotiate a separate bespoke integration with every application for every search. Selected information can be made available through a common access layer.
Imagine a user asking an assistant, “Which time did the hotel confirm?” The answer might be in a mail application, a booking service, or a document saved locally. With only app-by-app integrations, the assistant would need a special relationship with each source and a way to know which one to query. A centralised on-device mechanism can instead search the data that participating applications have chosen to donate and return the relevant material to a service acting for the user. It is not a universal archive: the application decides what to expose, the role-based arrangement limits how it is exposed, and the user remains part of the consent boundary.
Keeping this information on the device can change the trade-off between capability and exposure. The Commission points to possible advantages over cloud storage, including shorter response times, offline availability, more efficient cross-application search, and privacy benefits from processing locally. Those are design advantages, not guarantees for every future implementation. Local storage can reduce the need to send a piece of context to a remote system, but it does not by itself answer which assistant may retrieve the data, what the assistant does with the result, or how a user understands the permission.
The central mechanism also changes who owns the interface between applications. An app developer remains responsible for deciding which data and actions the app makes available. Android provides the common retrieval path. The AI service supplies the interpretation and answer. A user benefits from not having to open each source app, but the convenience is achieved by allowing one service to query material that previously remained behind separate application boundaries. That is why the measure describes a controlled, opt-in sharing model rather than simply “giving assistants access to app data.”
The practical sequence has three distinct decisions. First, an application decides whether a record belongs in the shared layer and what role-based access it will support. Second, Android exposes the permitted material through a central mechanism rather than through a private connection reserved for one assistant. Third, the chosen service decides how to interpret the returned information in response to the user's request. The Commission's parity requirement concerns the second step: a competing service should not be denied the common retrieval capability that Google's AI service can use. It does not transfer the first decision from the application, or the third decision from the assistant, to the operating system.
That separation also makes the limits of centralisation easier to see. A common index can reduce integration work, but it cannot resolve ambiguity in the underlying records or decide whether two pieces of information should be combined for a particular purpose. Those remain questions for the app's sharing rules, the user's authorisation, and the assistant's handling of the result. The legal measure creates a more capable route through Android; it does not convert retrieved data into an automatic entitlement to infer, disclose, or act.
The boundary becomes clearer when the information is incomplete. If a travel app has not donated the confirmation record, a central search cannot manufacture it. If a user has not authorised the relevant service, a third party should not receive it merely because another service can. If an app withdraws what it shares, the common mechanism must respect that decision. Interoperability removes an exclusive technical advantage; it does not remove the source app's role in deciding what enters the shared layer.
When context becomes continuous
Centralised app data is relatively legible: an app contributes selected information, and an assistant retrieves it when needed. Context-aware intelligence is more dynamic. The final measures describe access to physical and digital context, processing resources, and output surfaces so that a service can remain active in the background, personalise the experience, and make proactive suggestions without a fresh invocation for every step.
Digital context can include information about the foreground application, screen contents, notifications, app launches, contacts, shortcuts, messages, or other data made available to Google's services. Physical context can include signals from the camera, microphone, location systems, accelerometer, proximity sensor, and other device inputs. The assistant then needs somewhere to process those inputs—an on-device model, a cloud-based model through communication channels, or a protected execution environment—and a way to surface a suggestion audibly or visibly and connect it to an app or the operating system.
The causal loop is straightforward, but its implications are not. An input arrives; a model interprets it; the service decides that some information or action may be relevant; Android provides an output surface or app integration; and the user may accept, ignore, or revoke the access. A user could be shown a flight number stored in an email when a partner asks about the trip in a message, or receive a restaurant suggestion while chatting with a friend. These examples illustrate the kind of proactive experience at issue. They do not establish that every third-party service will receive every input or that an assistant will make a correct suggestion.
The word “proactive” changes the timing of the permission problem. With a conventional request, the user supplies a prompt and can often see which app is receiving it. A proactive service may use a continuing stream of inputs to decide that a suggestion is relevant before the user has asked a direct question. The measures address that by describing access to the same kinds of inputs, processing resources, and visible or audible surfaces that Google's services use, while allowing users and apps to control access. They also require comparable granularity, frequency, and recency for the context that is exposed. Those details matter because a delayed or heavily sampled signal may be formally present but unable to support the same experience.
There is a further interface boundary at the output. A suggestion is not yet an action, but the system can allow it to open another app, appear in an overlay, or trigger an integration with the operating system. That makes the surface part of the context mechanism: it determines whether a user can see where information came from, whether the service's branding is identifiable, and whether a suggestion remains a suggestion or becomes a route into a consequential operation. The Commission's description supports the availability of these channels; it does not settle how well future services will use them or how users will respond.
Ambient data is a related but distinct layer. It consists of information produced or collected through the phone's core sensors and main output channels. The measures cover access to microphone input, speaker output or system audio, camera input, screen contents, location data, and environmental sensors such as the accelerometer or proximity sensor. These inputs can support sound detection, live screen guidance, or object recognition. They are not merely another database to query; some are live streams whose value depends on continuity, frequency, latency, and availability while the assistant is in the background.
That difference changes the risk surface. A stored booking record is sensitive, but its access can be framed as a search and retrieval event. A microphone or screen feed may reveal a changing stream of private activity. The final measures therefore require ambient-data access under conditions equivalent to those for Google's AI services, including technical quality, continuous availability, background operation, consent flows, and indicators. They also allow integrity measures based on process isolation, encryption, aggregated or anonymous telemetry, and user control and awareness, so long as the conditions are transparent, objective, precise, and non-discriminatory.
“Equivalent consent” should not be confused with a single permission granted once and forgotten. If Google's service can operate continuously after a particular user choice, a third-party service cannot be forced through a fundamentally more burdensome path merely because it is not Google's. At the same time, equivalence does not mean that the user has no choice. The measures preserve the ability to make access subject to consent, inform users about feature use, and revoke access for a particular service. The legal goal is parity in the way the choice is offered, not the elimination of choice.
The shared context layer has several owners
The most important practical lesson is that “Android context” is not one permission with one owner. App developers control what they choose to donate to the central mechanism and may have ways to opt out of context-aware components accessing their digital context or appearing on their surfaces. Android controls the interfaces, consent prompts, indicators, processing resources, and output channels. The assistant selects and interprets inputs, but its access is supposed to remain inside the conditions imposed by the system and the user.
This division helps explain why the Commission's proposal can be both pro-competition and high-stakes. A common context layer can lower the cost of building a capable alternative. Developers would not need to reproduce every Google-specific connection before their assistant can find a permitted piece of information or offer a proactive experience. Users could choose among services that work with the same underlying device capabilities rather than choosing only between an integrated service and a collection of isolated apps.
But centralisation also concentrates meaning. A service that can retrieve several small pieces of data may infer more than any one app intended to reveal in isolation. A continuous stream can make timing and background availability as important as the raw data type. A suggestion surface can turn an inference into a prompt that appears inside another application. These are system-level consequences of composition, not evidence that any specific assistant will misuse access. They are the reason consent, app opt-out, indicators, and integrity conditions must remain visible in the design.
The measures also leave technical limits intact. A device may not expose every feature, and the official explanation ties applicability to the relevant capability being present. Local processing may improve latency or offline operation, but a model still needs compute and a service still needs a reliable route to present its output. Proactive intelligence may be possible in principle while failing in practice if the signal is delayed, the surface is unavailable, or a user cannot tell which service is observing the context.
The result is a more precise definition of the platform shift. Android is not simply opening a vault of private information. It is being required to make certain information pathways and live device inputs available to competing AI services under comparable conditions. The value comes from combining inputs; the risk comes from the same combination. Before the assistant can use that context to send a message, order a meal, or change a setting, the next boundary is action authority: what Android permits a service to do with what it has learned.