Opening Android, Closing Competition? The DMA’s AI Interoperability Paradox

Last month, we argued in an ECIPE Insight that the Digital Markets Act (DMA) is not so much promoting competition anymore but rather actively trying to re-design products and shape system architecture. This new style of DMA intervention, however, comes at a time when the underlying technological landscape is rapidly evolving. As various AI systems and services become increasingly competitive alongside advances in other emerging technologies, the structure of platform markets is itself changing. The market the Commission seeks to regulate is no longer the one that existed in the 2010s, the very context on which the DMA is based.

The Commission has proposed to drill down even deeper into systems architectures and redesigning products. The Commission’s draft measures under Article 6(7) DMA, as applied to AI assistants on Android,[1] reveal a fundamental structural paradox. If taken to their logical conclusion, these measures may ultimately force Google to make Android less open, not more competitive. The proposed measures would be a strong limitation of basic economic freedom and intellectual property rights – and lead to less actual competition.

The measures effectively mandate operating system (OS) level “functional equivalence” between Google’s own AI assistant and third-party apps and services seeking access to the relevant features within a fragmented, partially open-source ecosystem. They are unlikely to result in the “level playing field” that the Commission seems to seek. Because the measures would open the OS for severe and unacceptable cybersecurity risks, it is difficult to see how Android could comply safely without moving toward greater centralisation and closing off key parts of its open ecosystem.

Remarkably, this DMA enforcement seems to seek a market outcome that goes against key objectives of the Act: strengthening competition, preserving contestability between different architectural models, and encouraging product differentiation.

The Commission’s Logic: What Is Being Mandated and Why

A close reading of the draft specification measures and its Annex reveals that the Commission’s mandate is considerably more expansive than its framing as an interoperability obligation suggests. The measures address four capability layers across thirteen specific features.

The draft measures impose four broad categories of access obligations, all governed by an “equal effectiveness” standard (para 138 of Annex) and provided free of charge (para 145).

• First, it covers invocation: third parties must receive access equivalent to Circle to Search, a system-wide overlay that captures on-screen content at the moment of use and displays results over the user’s current activity (Annex, paras 2–3).
• Second, it covers context: access to on-device data and signals, including AppSearch, proactive suggestions, context-aware intelligence, and ambient data (paras 22, 30, 40, 49).
• Third, it covers actions: integration that allows third-party services to act on the device and across Google services, including structured on-device integration, screen automation, read/write access to Gmail, Calendar, Maps and YouTube, and OS-level integration (paras 58, 67, 76, 86).
• Fourth, it covers resources: access to system-level on-device AI models, implementation rights, hardware resource allocation, and background execution (paras 95, 104, 113). Each feature category also includes a rolling future-updates clause, requiring Alphabet to make any new Android AI functionality available to third parties at the same time as it deploys it itself (paras 18, 26, 36, 45, 54, 63, 72, 82, 91, 100, 109, 118). In effect, the draft measures create a permanent and open-ended obligation extending beyond existing functionality to future capabilities not yet developed.

This matters because the measures do not simply require Google to expose a discrete interface or enable compatibility with a defined third-party service. They require parity across the functional building blocks of Android-native AI: how an assistant is invoked, how it accesses context, how it acts across the device and Google services, and what computational resources it can use. The Commission’s logic is therefore not only to remove a bottleneck, but to replicate for third parties the conditions under which Google’s own AI agent can operate on Android.

Innovation Incentives and the Limits of Technical Prescription

The rolling future-updates obligation creates a distinct innovation concern. Although it may advance some versions of contestability, it also changes the investment calculus for Android-native AI. If new AI capabilities must be made available to rivals at the moment of deployment, they become less proprietary from the outset. This reduces the practical value of lead time and is likely to weaken incentives to develop capabilities that must immediately be opened to third parties on equivalent terms.

This concern is reinforced by the role of specification proceedings under Article 8(2) of the DMA. These proceedings are formally intended to clarify compliance with the DMA’s interoperability mandate. In practice, however, they increasingly shape the technical conditions under which firms must operate. The present measures further provide detailed guidance on how Google is expected to implement interoperability across a defined set of Android AI functionalities, including OS integration points, interactions with first-party services, and access to device resources.

This degree of technical prescription matters because Android AI capabilities often depend on hardware–software co-design. Firms invest in integrating device resources, controls, security architecture, and user-interface design to optimise performance, privacy, security, and user experience. If key functionalities must be shared under conditions that constrain control over deployment, particularly where sensitive device resources or security and privacy risks are involved, the expected return on such investment will be reduced. The result will be greater short-term access for rivals, but weaker incentives to develop performance-enhancing platform innovations over time.

Android’s Actual Architecture: Why the Premise Is Empirically Wrong

To understand the technical logic underpinning the draft measures’ approach to Google-Android, let’s look at how interoperability is expected to be operationalised in practice, primarily through the use of application programming interfaces (APIs).

Android combines open-source components, platform-controlled services, OEM customisation, and compatibility requirements, meaning that the user experience is shaped by several actors rather than by one vertically integrated provider. This distributed architecture does not provide the kind of end-to-end control that would make system-level AI parity a simple matter of opening APIs. In the current Android environment, third-party AI applications operate largely as standalone apps, with more limited access to system-level functionalities compared to the platform’s integrated assistant. While mechanisms exist to share data or trigger actions across apps, these interactions are often mediated, permission-based, and less deeply integrated into the operating system. For example, a third-party AI assistant can initiate actions such as composing an email or sharing content, but cannot execute tasks across multiple applications through persistent system-level access in the same way as a native assistant.

From a technical perspective, the Commission’s approach aims to elevate third-party AI services from application-level tools to fully integrated system actors. In effect, these measures seek to require the development of APIs that replicate, for third parties, the level of integration currently available to the platform’s own services.

But the measures proceed from a premise that does not accurately reflect Android’s existing architecture: that third-party AI assistants are categorically excluded from core functionalities. The distinction is not between access and exclusion, but between different levels of integration, each carrying different security implications, different trust requirements, and different feasibility constraints for regulatory intervention. Understanding this taxonomy is essential to evaluating what “equal effectiveness” actually demands.

Google has already introduced open-weight model families such as Gemma 4, which are designed to run across a wide range of environments, including consumer devices. These models support local, on-device AI applications and can be deployed on smartphones, including Android devices, without requiring continuous cloud connectivity. Unlike Gemini, which is integrated into Google’s cloud and platform services, Gemma models can be downloaded and run on consumer hardware.

This development is significant. It demonstrates that the platform is not only enabling third-party integration through APIs, but also lowering barriers to entry at the model level itself by providing open, deployable AI systems. While such solutions do not replicate the full system-level integration of platform-native services, they nonetheless expand the space for independent AI development in ways that are consistent with the Commission’s broader objectives.

The fact that such capabilities are evolving organically raises, in the first place, questions as to whether regulatory intervention is necessary to achieve interoperability. More fundamentally, it points to the sensitive balance between platform openness, on the one hand, and security, performance, and system design, on the other hand. Rather than promoting interoperability, the Commission’s intervention appears less as a response to a technical constraint and more as an attempt to design an ecosystem that is already evolving. And this takes us to a central problem in the new style of DMA enforcement that the Commission seeks: mandating a specific model of interoperability constrains the very experimentation and architectural diversity that technical and market developments are beginning to enable.

What “API Access” Actually Means: A Three-Level Taxonomy

The problem is that “API access” is not a single technical category. On Android, access to platform capabilities exists across at least three distinct layers.

• At the first layer are application-facing APIs, through which one app exposes defined functions or data to another app through structured interfaces, permissions, and access-control mechanisms. Android Intents, ContentProviders, and AppFunctions broadly fall into this category.
• At the second layer are OS-mediated service APIs, through which apps interact with system services that can provide persistent or sensitive access to notifications, accessibility events, voice interaction, sensors, background execution, or contextual signals. AccessibilityService, NotificationListenerService, and VoiceInteractionService are examples. These APIs are not merely app-to-app interfaces; they depend on system binding, user-granted access, privileged permissions, roles, and continued platform enforcement.
• At the third layer are OS-internal and hardware-abstraction functions, where core system services interact with hardware or low-level resources without ordinary app-facing mediation. The SoundTrigger HAL belongs at this layer because Android uses it, together with hardware support, to enable DSP-level always-on hotword detection: a low-power mechanism for detecting a wake word, such as “Hey Google,” without relying on ordinary application-level audio capture. Applications typically encounter this capability through higher-level assistant and voice-interaction frameworks, while the underlying function is implemented closer to the hardware.

Importantly, these layers have different security implications. Application-facing APIs can often be governed through ordinary consent, scope limitation, and revocation. OS-mediated service APIs require stronger safeguards because they may allow continuous observation of user activity or execution of actions across apps. Hardware-adjacent or OS-internal capabilities still require deeper controls, because safe operation depends on system privileges, vendor integration, certification, auditability, and clear liability for misuse.

A parity obligation framed only as “equal effectiveness” therefore risks collapsing materially different forms of access into a single standard. The relevant question should not be whether a third party receives the same functional outcome in the abstract, but whether equivalent access is accompanied by equivalent trust, accountability, user control, security review, and revocation mechanisms.

The context-aware intelligence provisions create the broadest access category in the Commission’s draft measures. For instance, paragraph 42(a) requires third-party services to receive access to the user’s physical and digital context, including camera, microphone, accelerometer, proximity sensor, GPS and other location signals, device audio, screen contents, screenshots, foreground-app data, notifications, app launches, contacts, shortcuts, SMS, and app package details. Paragraphs 44(a) and 44(b) then require that this access be provided continuously, in the background, and with the same granularity, frequency, and recency as is used by or available to Google’s services.

Let’s be clear: this is not a narrow query API!

It is a platform-level framework for persistent, real-time contextual intelligence across sensors, apps, screen state, communications metadata, and user activity signals. The associated AppSearch / centralised on-device data provisions compound the issue: AppSearch is described as enabling centralised cross-app access to on-device app data, currently for the default assistant role, while the draft measures require third-party access to centrally stored on-device data and equal access to data stored by Google apps where that data is shared with Google’s services.

The concern is not that the Commission’s proposed measures authorise unrestricted collection in all circumstances; the measures still refer to user control, process isolation, encryption, and non-discriminatory technical safeguards. The chief concern is that the Commission attempts to transform highly sensitive inputs – camera, microphone, location, screen content, notifications, contacts, SMS, app launches, and cross-app on-device databases – into a continuous interoperability surface for qualifying AI services.

Through these measures, the Commission risks placing data privacy objectives and cybersecurity standards in tension with interoperability requirements. In combination, these signals can support behavioural profiling far beyond what any single permission category suggests. Such access therefore requires a differentiated trust framework for purpose limitation, concurrency, retention, auditability, local processing, app-level consent, revocation, and independent verification, rather than treatment as ordinary non-discriminatory API parity.

We are not in Kansas anymore. These measures – would require Android to make highly sensitive capabilities available to qualifying third-party AI services under an equal-effectiveness standard – a demand for access that will profoundly change the platform privacy and security architecture.

What Third-Party Projects Actually Demonstrate and What They Do Not

Application-layer systems such as Vosk offline speech recognition and Porcupine on-device wake-word detection demonstrate that third-party developers can build usable voice recognition and wake-word detection using standard Android APIs. However, these systems operate entirely within application constraints: they rely on foreground services, standard microphone access, and continuous execution to remain active. They do not access low-power DSP-based hotword detection or system-level persistent listening capabilities. As a result, they are structurally incompatible with the always-on, energy-efficient behaviour associated with deeply integrated system assistants. They demonstrate feasibility of function, not parity of integration.

At the next level, projects such as Open-AutoGLM illustrate that more advanced automation is possible through Android’s AccessibilityService and screen capture APIs. These capabilities can approximate cross-application task execution, but only within a permission regime explicitly designed to signal elevated trust and potential risk. Android requires explicit user consent and displays prominent warnings precisely because these APIs can observe and interact broadly with device state. Their existence shows that limited system automation is achievable under tightly controlled conditions, not that broad agentic control is either equivalent to or substitutable for system-level integration.

Similarly, Android’s AppFunctions framework provides a structured mechanism for interoperability by allowing applications to expose narrowly defined, declared capabilities to external callers. This represents a deliberate architectural choice: interoperability is achieved through explicit, revocable, and scoped interfaces rather than broad system access. However, such mechanisms are inherently limited in scope and do not extend to persistent sensor access, background autonomy, or cross-service control over core system applications such as Gmail, Maps, or YouTube.

The Neural Networks API (NNAPI) is often cited in discussions of AI capability parity, but it operates at the hardware abstraction layer, not the system intelligence layer. It allows third-party applications to perform accelerated inference on-device, but it does not grant access to privileged system models, persistent model residency, or fine-tuning rights over system-integrated AI components such as Gemini Nano. It therefore reflects compute accessibility, not architectural integration.

These examples demonstrate a consistent pattern: third-party developers can access functional approximations of system behaviours only by operating within bounded, permissioned, and often energy-inefficient layers of the Android stack. They do not demonstrate equivalence with privileged system-level capabilities.

The Commission’s measures would require Google to extend access that, in several respects, approaches level-three functionality to qualifying third parties. However, they do not specify how this could happen safely given the trust, certification, auditing, and liability framework that currently justifies privileged access for Gemini and other platform-integrated services. Rather, the measures appear to assume that pre-installation vetting, system-service accountability, and original equipment manufacturer (OEM) certification can be replicated for an open-ended set of external actors.

The conceptual error in the measures is therefore to infer from these limited forms of interoperability that full “functional equivalence” is technically feasible across all layers of the system. Yet on Android, higher levels of access are not simply more powerful APIs; they are embedded in distinct trust regimes tied to multi-party authorisation, sandboxing, compatibility requirements, persistent execution, energy efficiency, and OS mediation. Measures intended to increase competition may therefore risk incentivising a less open system architecture, because the only way to approximate “equivalence” safely across such fundamentally different access layers may be to concentrate control rather than disperse it.

The integrity provisions, in paragraphs 127–131, permit Google to apply security measures, but only on non-discriminatory terms: it cannot apply a higher standard to third parties than it applies to itself. The practical consequence is that the trust architecture currently protecting level-three access may either have to be generalised to external actors or redesigned for Gemini itself, with consequences for product quality, security, and accountability. Neither outcome sits comfortably with the security properties that Android’s architecture currently provides.

The Security Attack Surface: Why the Mandate Is Technically Problematic

Even accepting that greater interoperability is desirable, the specific architecture the measures require creates security risks that are not yet addressed. These are not edge cases. They are structural consequences of the mandate as written, visible in the specific technical language of each feature section.

Circle to Search as the Invocation Baseline

The Commission’s proposed invocation layer is not limited to a generic search trigger. It is modelled on a system-level capability exemplified by Circle to Search, Google’s Android feature that lets users invoke search from anywhere in the operating system by circling, highlighting, or tapping content on the screen, without leaving the app they are using. The relevant capability is therefore system-level: a persistent overlay that can be invoked from designated access points, capture contextual information from the current screen, and present results over the user’s ongoing activity.

Under paragraphs 4(b) and 4(c), third-party services must be able, upon invocation, to receive contextual data such as a current screenshot, information about active applications, URLs, images, or other structured content exposed by those applications, and to render overlay content over any current activity. Paragraph 6(a) further requires the APIs enabling this functionality to be publicly accessible to both pre-installed and user-installed applications.

The effect is to treat real-time screen context capture and overlay execution as a standard platform primitive. This does not necessarily create unrestricted surveillance: access would still be subject to Android’s consent, permission, and security architecture. But it does require a highly sensitive system-integrated capability capturing the user’s current interface state across apps and acting over it, to be made broadly replicable by qualifying third-party services. The concern is therefore not merely search interoperability, but the standardisation of screen-level contextual access across the platform without a correspondingly differentiated trust and accountability framework.

Always-On Hotword Detection: The Full Architecture and Its Risks

The always-on hotword provisions describe more than ordinary app-level voice invocation. They would require Android to support third-party custom sound models for first-stage hotword detection, including models capable of running on the device’s DSP, and to allow users to define custom wake phrases through developer-controlled enrolment flows. Paragraphs 12(e), 14(g), and 15(e) require continued microphone access after invocation, while paragraph 16(a) requires multiple first-stage DSP models to run concurrently across third-party and first-party apps, subject to DSP capability.

This changes the architecture of hotword detection from a tightly controlled system function into a multi-tenant, always-on sensing layer. Instead of a small set of centrally managed activation phrases and models, the system would have to support multiple assistants, multiple concurrent detection pipelines, and potentially user- or developer-suggested branded wake phrases. The specification does not clearly define a central registry for hotwords, phonetic-collision checks, and limits on concurrency, resource-allocation rules, or validation mechanisms to ensure that custom phrases do not interfere with system commands, emergency flows, or other assistants.

The concern is therefore not whether always-on hotword detection is technically possible. Continuous passive audio processing is a highly sensitive capability whose safety depends on bounded activation semantics, resource isolation, model validation, power and latency guarantees, and clear microphone-state transparency. In a multi-assistant environment, unintended activation, adversarial acoustic inputs, phonetic similarity, and sustained post-activation microphone access become harder to reason about across services. The proposed framework would shift hotword detection from centrally mediated platform control toward a fragmented trigger ecosystem, where security depends increasingly on distributed configuration and coordination among third-party services rather than on a single platform-level assurance model.

The Commission acknowledges that DSPs are subject to hardware constraints (para 16 of the measures) but does not clearly specify how such limitations should be reconciled with the expectation of “equal effectiveness” across multiple assistants. In practice, supporting several concurrent hotword models may create trade-offs between responsiveness, battery life, and system stability. This introduces implementation uncertainty, particularly where resource allocation decisions could later be interpreted as discriminatory.

Connected Device Invocation: Extending the Attack Surface beyond the Phone

The Commission’s logic is further reinforced. Paragraph 117(b) extends always-on assistant invocation beyond the handset to connected peripherals such as earbuds, smartwatches, and Bluetooth accessories. It requires hotword detection and invocation pathways to function through those devices and grants third-party services the same background-execution access available to Alphabet for that purpose. This turns connected peripherals from passive input devices into invocation endpoints capable of triggering assistant actions on the Android device.

The architectural consequence is a broader trust boundary. Assistant activation is no longer governed solely by the handset’s local permission and sandboxing model, but by a distributed chain involving external hardware, Bluetooth pairing, device firmware, and communication channels. The concern is not that peripherals automatically bypass Android security controls. It is that, once they become trusted triggers for OS-level assistant activation, the integrity of the invocation pathway depends on the security of every participating device and link.

This materially expands the attack surface. Bluetooth accessories and wearable devices have heterogeneous security properties and are clearly governed less tightly than the mobile OS itself. If such devices can initiate assistant invocation and enable background execution privileges, then weaknesses in pairing, firmware, signal handling, or channel integrity may affect the reliability and trustworthiness of system-level assistant activation. The provision therefore shifts the model from device-local invocation to a multi-device trust chain, without clearly specifying the assurance requirements, certification standards, or failure-handling rules needed for peripheral-triggered assistant access.

Screen Automation: Autonomous Background Device Control for Any Qualifying AI Agent

The screen-automation provisions go beyond contextual access or app-to-app interoperability. They define a framework for agentic device control. Paragraph 69 describes a capability by which an AI service can imitate user interactions, access the controlled app’s screen content, discover installed apps, and execute control in the background. Paragraph 71 then requires Google to make this capability available to third-party apps, including control over third-party apps, OEM apps, system apps, and Google apps, and prohibits limiting the capability to a single default assistant.

This creates a materially different risk profile from ordinary API access. A qualifying agent could enumerate the user’s application inventory, retrieve relevant app metadata such as app name, package name, and developer name, observe controlled-app screen content, and automate interactions in the background through a virtual display while the user continues using the device. The Commission does include mitigating concepts, including OS indicators, user observation and intervention, concurrency management, and the ability for controlled apps to block sensitive views. But the “blocking sensitive areas” protection depends on controlled apps identifying and shielding sensitive views, meaning protection is not inherently guaranteed for all applications or all sensitive states.

The concern is therefore not merely that third-party AI services can perform tasks across apps. It is that the proposal standardises autonomous background control of other applications as a platform capability, including apps that the user may not have specifically intended to expose to a given agent. Such access requires more than non-discriminatory availability: it requires a clearly specified security and accountability framework for consent granularity, sensitive-view protection, audit logs, liability, user intervention, app-developer opt-outs, and independent verification of agent behaviour.

Read and Write Access to First-Party Services: Beyond the OS

The read/write access provisions extend the draft measures beyond Android as an operating system and into Google’s cloud-connected service layer. Paragraphs 80(a)–(b) require third-party services to receive the same read and write access to Google first-party services including Gmail, Google Calendar, Google Maps, YouTube, Google Keep, and SMS/RCS as is available to Gemini. Paragraph 78(d) gives concrete examples: third parties must be able to pause or play YouTube, change a Google Maps destination, send emails or SMS messages on the user’s behalf, and change device settings. Paragraph 81 makes clear that this obligation applies even where the relevant features are not part of Android itself and rely on server-based integrations.

This changes the nature of the obligation. It is not merely about exposing Android APIs or enabling local device interoperability; it requires action-level access into Google’s first-party services and cloud-backed user accounts. The resulting security questions are different from ordinary OS access: what credentials, session tokens, or delegated authorisations are required; how they are scoped and protected; how irreversible actions are confirmed; how audit logs are maintained; and who is liable when a third-party assistant sends a message, modifies a route, changes a calendar entry, or otherwise acts contrary to the user’s intent. The concern is therefore that the draft measures require parity of functional capability without specifying the corresponding authentication, authorisation, confirmation, auditability, and liability framework for cross-service write access.

More broadly, expanding persistent access to sensitive inputs such as microphones or contextual data streams across multiple applications increases the system’s attack surface. Shared access to audio inputs can give rise to novel privacy risks, including side-channel inference and unintended data leakage. While Android already permits microphone access subject to user consent, extending such access in a persistent, multi-assistant environment raises qualitatively different risks. Android’s existing mechanisms, such as accessibility services, are deliberately mediated through granular permission structures and user-facing safeguards. These constraints are designed to limit abuse by restricting the scope and persistence of access. This may place pressure on existing safeguards, particularly where achieving “equal effectiveness” entails more continuous or less frictional access to system-level data and functions.

The Commission emphasises that consent flows should be “non-discriminatory” (paras 125–126 of the measures), but reducing friction in access mechanisms to achieve parity is likely to weaken the protective function of those mechanisms. The resulting trade-off is not simply technical, but structural: expanding interoperability at the system level comes at the cost of increased security exposure, raising questions as to whether the current approach adequately accounts for these risks.

Implementation Challenges: OEM Fragmentation

These security concerns are compounded by Android’s federated, OEM-mediated ecosystem. Unlike a vertically integrated platform, Android is implemented across hundreds of device configurations by independent manufacturers, each with their own hardware, firmware, and security layers. Much of the Android platform is made available through Android Open Source Project (AOSP) under the Apache 2.0 licence, and Google does not manufacture most Android devices. Independent OEMs such as Samsung, Xiaomi, Oppo, Vivo, Motorola, and others build their own Android-based device implementations, add proprietary layers, integrate different hardware components, and make independent choices about pre-installed applications, system customisations, and security configurations. Google’s control is therefore mediated through a combination of open-source platform development, compatibility requirements, Google Mobile Services licensing, Play services, certification, and distribution rules.

The key point is that these mechanisms were designed primarily to preserve Android compatibility and access to Google services across a diverse device ecosystem, not to provide a single, vertically controlled security architecture for AI-agent capabilities across all device variants.

The Android Compatibility Definition Document enumerates the hardware and software requirements that a device implementation must satisfy to be Android-compatible, and compatibility is assessed through tools such as the Compatibility Test Suite. But that framework does not, by itself, constitute a comprehensive assurance regime for AI-agent capabilities across hundreds of OEM configurations. Android compatibility requirements are designed to preserve baseline platform compatibility, not to guarantee uniform security behaviour for capabilities that depend on sensors, firmware, HALs, OEM overlays, background-execution policies, device-specific DSPs, pre-installed security frameworks, and cloud integrations. The more fragmented the implementation environment, the harder it is to impose uniform security guarantees for continuous context access, multi-assistant hotword detection, cross-app automation, or third-party AI-agent control.

The draft measures address OEM fragmentation directly in paragraphs 122–123 by requiring Alphabet to ensure compliance on all Google Android mobile devices, including devices supplied by third-party OEMs, through technical and contractual means, and by requiring consistent APIs across Android versions and form factors. The measures therefore do not ignore fragmentation; they seek to resolve it by making Google responsible for imposing uniform interoperability outcomes across the Android ecosystem.

That is the central problem. Google has significant levers over Android, but those levers were built for compatibility, distribution, and access to Google services — not for guaranteeing uniform security behaviour for highly sensitive AI-agent capabilities across a federated, OEM-mediated ecosystem. Requiring Google to deliver such guarantees will therefore convert an interoperability obligation into a de facto obligation to centralise security governance across Android. The Commission is seeking to make Google a regulator of independent hardware manufacturers – restricting the choices they make in order to have a competitive product and control basic things like battery life. The likely result, at least in Europe, will be less product differentiation.

OEM customisations are not merely cosmetic. Samsung Knox, OEM battery-management systems, proprietary Android skins, device-specific DSP implementations, and vendor security layers can all affect precisely the OS layers implicated by the draft measures. Requiring Google to guarantee consistent AI-agent security behaviour across this landscape through contractual and technical means is therefore not a simple extension of ordinary compatibility enforcement.

Table 1: Existing Android Capabilities Relevant to AI Interoperability and Their Architectural ConstraintsSource: Author’s own elaboration

Conclusion: Misalignment of Legal Objectives with Technical Reality

In our view, the European Commission is reinforcing a model of DMA enforcement that raises fundamental questions about competition, integrity, and security in the market for operating systems. It does so with extraordinarily little attention to outcomes and consequences: it is a programmatic application of a DMA framework that neither reflects the “Android market” nor the new landscape of agentic AI competition.

Generative AI tools raise confidentiality risks, and European agencies like France’s ANSSI and Germany’s BSI are already drawing attention to the need for protections against prompt-injection vulnerabilities. Before the Commission decides on the draft measures, it should consult with European authorities tasked to protect against the very risks that the measures will exacerbate. Even under the DMA, the user must have the right to a safe mobile and AI environment in which integrity also means the ability to protect against non-deterministic AI.  

While the Commission’s draft measures reflect an ambitious effort to operationalise Article 6(7) DMA, they reveal important limitations. In particular, they pay insufficient attention to the technical constraints that shape real-world implementation, the distributed nature of performance dependencies across device and cloud infrastructure, and the fragmented nature of the Android ecosystem.

More fundamentally, the measures risk conflating a question of access with one of integration. By mandating “equal effectiveness” across core system layers, they move beyond ensuring contestability toward prescribing architectural outcomes. In doing so, they may inadvertently weaken security safeguards, reduce flexibility in system design, and place obligations on the gatekeeper that depend on factors beyond its control.

The result is not necessarily greater competition: in fact, product centralisation is likely to reduce competition. What we will rather have in Europe is a regulatory framework that risks misaligning legal objectives with technical realities in a rapidly evolving ecosystem. The DMA may be trying to open Android to AI competition, but by requiring equivalent access to system-level assistant capabilities, it risks forcing Google either to weaken security boundaries or to centralise control over an ecosystem whose openness depends precisely on distributed implementation.

Overall, the issue is therefore not solely one of technical interoperability, but of governance asymmetry. Google’s own assistant operates within an internally governed trust framework tied to platform auditing, update management, liability allocation, and OS-level security review. Extending equivalent privileges to heterogeneous third-party AI agents raises the question of whether functional equivalence can realistically exist without equivalent governance structures. The Commission appears to assume that functional equivalence can be mandated without first creating equivalent governance, certification, audit, and liability structures.

If that assumption is wrong, as we believe it is, the result may be less openness, less architectural diversity, and weaker innovation in mobile AI.

[1] This Insight analyses the European Commission’s draft specification measures in case DMA.100220, Annex – Measures, concerning interoperability with Google Android under Article 6(7) of Regulation (EU) 2022/1925, as published for consultation in April 2026.