A New Android Contract for AI
The opening question was whether the Digital Markets Act is turning Android into an AI interoperability platform. After following an assistant from invocation through context, action, model access, and background execution, the most defensible answer is conditional: the Commission's measures clearly create that direction in law, but the platform does not exist as a demonstrated outcome until the access is equally usable, the safeguards work under pressure, and the implementation can be observed across real devices. This final synthesis connects those conditions and gives readers a way to judge what happens next.
The change is larger than a new permission and narrower than the abolition of Android's platform boundaries. It concerns who can participate in the operating system's AI control loop. A user-selected service may gain a system entry point, permitted information from apps and sensors, routes into app and OS actions, and the models and hardware time needed to complete them. That combination can make an alternative assistant a system participant rather than an isolated application. It also makes the consequences of a mistake, a hidden instruction, or a discriminatory implementation more consequential.
The contract is a control loop
The Commission's 11 covered features form a single operating model when viewed from the user's task. Invocation determines which service can begin. Context determines what the service may know and how continuously it may know it. Action mechanisms determine whether the service can change another app or the operating system. Resource access determines whether the service can reason and continue long enough to finish. The legal categories are separate, but the user experiences their composition.
Consider a request about a trip. The assistant must first be reachable through a gesture or validated wake word. It may then use permitted information stored in an email or available from the current conversation. If the user asks it to do more than surface the information, it needs an app function, a controlled interface, or an operating-system integration. If the task takes several steps, the model and background scheduler must keep the service running. A failure at any link changes the result: a service that cannot be invoked is hard to discover; one that cannot receive context is hard to personalise; one that cannot act is only a recommender; one that cannot obtain resources is unreliable.
This is why the central theme is interoperability as a control layer, not interoperability as an endpoint. The relevant question is not “Does a third-party API exist?” but “Can a user-selected service pass through the same chain with comparable conditions?” The Commission's equal-effectiveness rule reaches the end-user journey, ease of use, setup, data-transmission speed, and energy consumption. It also bars default-role gatekeeping and unnecessary friction in prompts, notifications, settings, and consent flows. A competitor that receives an endpoint but must tolerate slower data, more confusing choices, or higher energy costs may be technically connected and still competitively disadvantaged.
The rule reaches across the Android ecosystem. Alphabet must provide the solutions on eligible devices from other manufacturers when the relevant feature exists and the device continues to receive the applicable Android or Google system updates. OEMs can still customise branding, preinstalled apps, defaults, interfaces, and hardware. The boundary is that those choices cannot make third-party interoperability less effective. Consistent APIs across versions, devices, and form factors matter because a permission that works on one handset but fails on another does not produce a dependable platform for developers or users.
The contract also has a time dimension. Alphabet must make documentation and technical assistance available, allow development and beta testing, maintain the solution, and expose new functionality to third parties when it becomes available to Google's service or hardware. Without that obligation, a platform could comply at one moment and restore the original advantage through product updates. Interoperability would become a snapshot rather than a continuing condition of Android's evolution.
The intended redistribution of control is specific. Under the measures, Google's exclusive control over the route into the device and the system resources behind an AI experience would be narrowed. Third-party providers gain a path to build more capable services. App developers gain a common way to expose selected data and actions, but also face new questions about which parts of their state can be combined. OEMs retain product differentiation while taking on a role in preserving effective access. Users receive more meaningful choice, but also need clearer information about which service can observe context and cause changes.
None of that guarantees that an alternative assistant will be better, more popular, or more innovative. The measures change the opportunity structure. They remove or narrow an operating-system advantage that the Commission says Google's own services have enjoyed, but they do not supply a model, product strategy, developer community, or user trust to a competitor. A level starting position is a condition for competition, not its result.
Competition and security pull on the same lever
The competitive case and the security case are linked because they concern the same privileges.