Why Android's AI Advantage Is Becoming a Regulatory Question
The subject of this series is the European Commission's 2026 proceeding requiring Alphabet to open parts of Google Android to competing AI services. The immediate focus is the advantage that comes from controlling the operating system rather than merely publishing an app: who can summon an assistant, what context it can receive, which actions it can perform, and which device resources it can use. Understanding that distinction gives readers a way to judge the measures without reducing them to either a competition victory or a security threat.
The dispute is easy to misread because “Android is open” and “Android is interoperable” sound like nearly the same statement. They are not. An app can be downloadable and still be unable to behave like a system assistant. It may live inside a sandbox, while Google's own service can respond to a voice phrase, inspect relevant on-device context, operate across applications, and draw on system-level models and background execution. The question before the Commission is whether that difference is a legitimate product distinction or a form of operating-system control that the Digital Markets Act must constrain.
The operating-system advantage behind the app
On 16 July 2026, the Commission adopted measures under Article 6(7) of the Digital Markets Act. That provision requires Alphabet, as the gatekeeper responsible for Google Android, to provide third parties with effective interoperability with hardware and software features accessed or controlled through the operating system, free of charge. The proceeding opened on 27 January 2026, after Alphabet had already been designated a gatekeeper for Android; preliminary findings followed in April.
The Commission did not ask Alphabet to hand over every internal component or to turn Android into an undifferentiated public utility. It specified interoperability for 11 Android features relevant to AI services. The reason is practical. The Commission says that around 60% of European mobile users are on Android devices, making the operating system a major route to users. It also argues that Gemini benefits from deep access to capabilities that user-installed assistants have not been able to use on comparable terms. If one provider controls the route into the phone, the information around a request, the actions available after the request, and the resources that keep the interaction responsive, competition at the visible app layer is incomplete.
That makes the parties' relationships important. Alphabet controls the Android features and must implement the solutions. Third-party AI providers seek comparable access, but may have to meet conditions for especially sensitive capabilities. App developers decide, in specified cases, which data and actions their apps expose. Device manufacturers can still differentiate their products, provided their customisations do not prevent effective interoperability. Users remain the people whose consent selects an assistant and authorises access. The proceeding is therefore not a simple transfer from Google to “developers”; it redistributes control across an operating system, the services using it, the apps supplying capabilities, the manufacturers shaping devices, and the people carrying them.
Google's public response makes the opposing intuition clear. The Android security team says that services such as ChatGPT, Claude, and Perplexity currently operate within app sandboxes, and warns that deep system access could weaken Android's defence-in-depth model. That is evidence of Google's security position, not an independent finding that the measures will produce those harms. But it identifies the real point of tension: the same privileges that make an assistant useful also enlarge the consequences of a mistaken, compromised, or manipulated assistant.
Interoperability means a control loop, not a list of APIs
The Commission's 11 features are easier to understand as four connected layers. The first is invocation: the user must be able to reach a chosen assistant through a system access point, such as a long press on the home button or navigation handle, and eventually through an always-on hotword pathway. The second is context: an assistant may use app data that applications choose to share, digital and physical context, and ambient inputs such as the microphone, camera, screen, location, or environmental sensors, subject to the stated controls.
The third is action. An assistant may discover and execute structured functions exposed by apps, automate another application's interface, or interact with operating-system settings and activities. The fourth is resources: the assistant may need an on-device model, access to specialised hardware, memory, and enough background execution to finish a task while the user does something else. These categories are not interchangeable. A voice entry point without context is limited; context without action is mostly observation; action without reliable compute and background time can fail halfway through a task.
The combined model changes what an AI service can be. Today, the ordinary mental model is an app that waits for a user to open it, receives what the user puts into its interface, and returns an answer. The model described by the measures is closer to a system participant: reachable from the device, able to assemble permitted context from several places, capable of asking other apps or the operating system to do something, and supported by resources that are not simply private to Google's service.
Consider the difference through a task rather than a feature catalogue. A user might ask an assistant about a flight while speaking with a partner. The Commission uses a similar example: information stored in an email could be surfaced when a related conversation occurs. A more active task might involve ordering items from a shopping list: the assistant would need to find the list, open a delivery application, select the items, and add delivery details. The point is not that every such experience already exists for every provider. The point is that each experience crosses boundaries that a conventional app does not control on its own.
That composition is why the proceeding matters beyond an API checklist. If a competing assistant can invoke itself but cannot obtain the relevant screen or app context, the user must manually transfer information. If it can read context but cannot use declared app functions or automation, it can recommend an action without completing it. If it can act but receives less background time or less dependable model access than Google's service, parity disappears at the moment reliability matters. The Commission's platform intervention is aimed at these combinations.
Equal does not mean unbounded
The phrase “same access” still needs several qualifications. The measures define equal effectiveness across more than technical availability: the end-user journey, ease of use, device and software setup, data-transmission speed, and energy consumption all matter. Alphabet may not reserve covered access points for its own services, require an assistant to hold the default role, or add unnecessary friction through leading prompts, recurring notifications, blocked deep links, or a sequence of permissions that could have been combined. The solution must also be free, documented, testable, and updated when the corresponding Google functionality changes.
Those requirements apply across the Google Android ecosystem, including devices supplied by other manufacturers when the relevant feature exists and the device continues to receive the specified updates. OEMs retain room to customise branding, preinstalled apps, defaults, interfaces, and hardware. They do not retain room to use that customisation to make a third-party solution nominally available but practically ineffective. This is an important shift in what interoperability means: it is a quality and governance obligation, not merely a switch that exposes an endpoint.
Nor is every capability governed by one access rule. The measures generally require access for all third parties, but identify five restricted features: centralised access to on-device app data, context-aware intelligence, structured on-device integration, screen automation, and system integration. Alphabet may require an eligible service to qualify for these features, using conditions that are transparent, objective, precise, non-discriminatory, strictly necessary, and proportionate. The published measures establish a Qualified AI Assistant Programme and a Trusted Certification Authorities Programme, along with direct certification, appeal, suspension for evidence of severe and immediate harm, and a per-service user choice to opt out of the certification requirement.
The broader safeguards matter just as much. Users must be able to consent to access and revoke it. Apps can choose what data to share in the centralised on-device mechanism, and the measures preserve app-level opt-outs in the context-aware system. Alphabet may use process isolation, encryption, indicators, and other integrity controls, but those controls must respond to a genuine risk, be independently verifiable, apply to Alphabet as well as third parties, and not impose a higher integrity standard on competitors than Alphabet accepts for itself. Google's concern is that emerging agents can be manipulated through techniques such as indirect prompt injection and can take consequential actions in ways that are harder to predict than traditional software. The legal design does not settle whether those safeguards are sufficient; it sets the conditions under which the disagreement must be handled.
There is also a crucial difference between a legal design and a delivered product. The retained Commission publication is a provisional non-confidential version of the measures, not the full decision, and it does not show the eventual APIs, device coverage, performance, battery cost, certification outcomes, or incident record. Most measures are due in Android 18 by 1 August 2027; concurrent hotword detection is due in Android 19 by 1 August 2028. Until those milestones are implemented and tested, “Android as an AI interoperability platform” is a well-defined direction, not an observed result.
The first practical test is therefore reachability. Before asking whether a third-party agent can safely coordinate several apps or run a model in the background, Android must let a user call that agent through an equally usable system path. The next question is how a tap or wake word becomes a controlled handoff—and where the phone draws the line between hearing a request and granting a new participant access to the rest of the device.