All for One, and One for None: The European Commission’s Implementation Measures Target New Entries in the Operating System Market

On 27 April, the European Commission (EC) published the draft measures it seeks to impose on Google to guide the development of its operating system (OS) towards its integration with AI-reliant competitors. These Draft Measures come two weeks after the enforcer also issued its implementation measures relating to the access that Google must render to its search data (see my comment here).

Article 6(7) is much more straightforward than Article 6(11) DMA, because it is fraught with less technical complexity relating to state-of-the-art technologies. The provision mandates a vertical interoperability obligation on gatekeepers that have been designated for their operating systems (aka, Google for its Android OS, Apple for its iOS and iPadOS and Microsoft for its Windows PC OS) whereby they must provide free of charge equivalent access to software and hardware features to their competitors and the complementors of their ecosystem. This is not the first time that the enforcer strives to flesh out the obligation, since it already imposed implementation measures on Apple relating to how it handled interoperability requests procedurally (Case DMA.100204) and substantively (Case DMA.100203). 

Not about lack of compliance, but to provide a response to future market developments

The EC’s case summary providing an outline of the draft measures presents the multi-sided nature of specification proceedings under Article 8(2) DMA. Although one could have thought that these types of procedures are lower-intensity procedures with a punitive component to them (where gatekeepers do not have much of a say with regards to the tweaking of their technical implementation of the DMA provisions), the Draft Measures presented by the EC add some nuance to this black-and-white approach.

Since AI technologies (and AI-reliant features) have irrupted into the digital space, marking a “technological inflection point” where “there is a clear consumer demand for AI-powered devices”, the EC wants gatekeepers to be prepared for the future and seeks to cement the absence of monopolisation before the market has even consolidated. Economic operators such as OpenAI are planning to launch their own proprietary smartphones into the market, aside from a full suite of hardware devices acting as complementors to existing products (e.g., smart speakers, smart glasses or even smart lamps!). Similarly, other competitors that have gained relevance in the AI chatbot market are partnering with major OEMs (Samsung, Deutsche Telekom, and Motorola) to deeply embed their own AI into new AI phones. Given that Google is already innovating in this space by, for instance, releasing Circle to Search for Android phones, which allows users to search from anywhere on their device using gestures such as circling, highlighting, scribbling or topping, the EC wishes to address the potential dominance that may flood the markets in the coming years by making the AI smartphone market (or the AI-reliant smartphone market) as contestable as possible before it is not too late.

As opposed to its previous specification proceedings against Apple, which basically sought to re-direct its non-compliant technical implementation towards a seamless solution, the Draft Measures provide Google “with guidance as to how to comply with its obligations under the DMA when it comes to a defined set of features pertaining to the invocation of services, access to contextual information, ability to execute actions on apps and the OS and the ability to access device resources” (page 2 of the case summary). In other words, the EC wants to ensure that Google knows what features it should open to competitors to make AI integration in their devices more frictionless and consistent with the DMA’s principles and objectives. The EC has published the Draft Measures it wishes to implement in the proceeding and now seeks feedback from stakeholders until 13 May. This is my take on the measures which still leave some room for improvement.

The implementation measures presented by the European Commission

Prior to the EC’s enforcement action, Google had not disclosed how it sought to breathe life into Article 6(7) DMA in terms of its integration of AI-reliant features into its OS. To the extent that some of its software and hardware features, AI-reliant or not, are not compatible with competitor hardware and software, the EC is completely free to seek the DMA’s application in state-of-the-art technologies. A different question is whether the EC is legitimised to tackle AI head on via the DMA (which I argue would cause more problems than provide solutions).

According to the EC’s Draft Measures, Google should adapt to Article 6(7) DMA with respect to four different tenets of its OS that supply data, functionality and resources to its own AI-reliant features. The measures address the full AI assistant stack, notably for the purposes of: i) invocation (how you trigger an assistant); ii) context (what data it can see); iii) actions on apps and the OS (what it can do); and iv) accessing resources (what computing power it can use). In total, 9 features already present in Android OS must adapt to the regulatory regime, abiding by the principle of equal effectiveness. This systemic approach makes it harder for the gatekeeper to comply with one layer while blocking competition at another. The interoperability solution made available to the third parties must be equally effective as that available to the gatekeeper’s own services or hardware (para 138 of the Draft Measures). Remaining consistent with the Apple specification proceedings, the Draft Measures operationalise the principle by reference to the gatekeeper’s own conduct as the benchmark, i.e., Google’s services (Gemini, Google Search and the rest of its proprietary services, regardless of their designation by the DMA) set the yardstick against which interoperability to third parties must be measured.

Notwithstanding, the Draft Measures differ from the Apple specification proceedings to the extent that it is less consistent in providing feature-specific quantitative benchmarks that can establish whether the gatekeeper is abiding by the EC’s prescriptions. For example, in the EC’s previous enforcement action, it set out the explicit latency and bandwith metrics for the P2P Wi-Fi Feature that Apple had to comply with (para 200 of Apple’s specification proceeding decision). In the Draft Measures, such an approach is less clear. For example, the measures for always-on hotword detection (functionality enabling the device to detect the consumer’s use of a keyword to trigger an AI assistant at any given point in time) specify the technical components of the pipeline without articulating measurable performance equivalents (paras 14-16 of the Draft Measures). This asymmetry may reflect the greater difficulty of specifying AI performance in quantitative terms, whilst creating a greater margin of discretion for Google to implement Article 6(7) DMA.

In terms of the particular features concerned, the EC’s Draft Measures are quite comprehensive, to ensure that competitors in AI markets can enter the market without friction. For the purpose of invocation, i.e., the ability for an end user to initiate their interaction with an AI service through a variety of access points, the Draft Measures require Google to open up these features to the extent that they have been only available to itself.

For example, the long-press home handle feature on Android triggers Google’s Circle to Search to the exclusion of any other competitor. It allows Google to read screen content and provide contextual results. Similarly, Google currently allows its own services, such as Google Assistant and Gemini, to listen continuously for key words (e.g., Hey Google) using a Digital Signal Processor (which is a specialised microprocessor designed to filter and compress continuous real-world signals in real-time). Under the Draft Measures, any third-party app, such as a rival AI assistant, will be provided the possibility to use these features to receive the same data (e.g., screenshots, URLs or open app information) and overlay content on the screen in the exact same way as Google’s own services can (paras 1-8 of the Draft Measures).

Similarly, the EC requires Google to open always-on hotword detection functionality to third parties in two ways. First, by allowing developers to create and register their own custom word models to run on the DSP. Second, by enabling users to record their own personalised hotword for a third-party app. Both options require Google to replace the same two-stage detection process that Google uses internally. Multiple hotwords from different apps must be able to run simultaneously (paras 9-20).

Since multiple third-party services may operate simultaneously alongside Google’s own assistant, this may entail capacity constraints. Unlike general-purpose CPUs, DPSs have numerous constraints, such as fixed memory banks (crucial for high-performance processing that hold a fixed amount of data), constrained instruction sets (the frameworks designed to handle the complex requirements of the architecture) and limited parallelism (a function that guarantees that no more than a specified number of tasks are executed at the same time). Bhattacharyya, Leupers and Marwedel showed that DSP memory hierarchies are deliberately narrow to achieve power efficiency. Put into simpler words, DSPs cannot simply run everything that the EC expects it to. Due to this reason, the enforcer provides that “concurrent always-on hotword detection may be limited by the capabilities of the DSP on the Google Android mobile device” (para 16). This effectively allows the gatekeeper to argue that hardware limitations justify restricting the number of third-party models that can be loaded with no regulatory benchmark established for what an acceptable minimum number of concurrent models should be.

Furthermore, for features providing context, i.e., the ability for an AI service to gather inputs and data to then understand and anticipate end user needs and provide helpful suggestions across apps, the Draft Measures require Google to provide interoperability in the form of making data accessible to its competitors to integrate their AI functionality into Android. For example, Android currently holds AppSearch, which provides a centralised database of data shared by apps. Access to the database is restricted to the app holding the default of the smartphone’s assistant. Since Google has been phasing out Google Assistant entirely from its devices, Google Gemini is becoming the default AI assistant on many Android smartphones. In general terms, Google is compelled not to subject access to features to the app holding a default role, including the default assistant role (para 140). Additionally, the Draft Measures mandate Google to open this database to all third-party apps on an equal and concurrent basis, so that a rival assistant can retrieve, for example, flight details by a travel app, in exactly the same way that Gemini can access that same data (paras 21-28).

In this same vein, third parties must also be granted equal access under the same quality, frequency and latency conditions to real-time sensors integrated in the smartphone, such as the microphone, camera, speakers, screen, location and environmental sensors such as accelerometers (paras 48-56). On the particular note of continuous microphone access, significant attention has been dedicated to the fact that granting multiple applications simultaneous access creates resource contention and novel privacy attack surfaces, as pointed out by Quattrone and Badr. Resource contention occurs when multiple tasks or users compete for limited shared resources, causing bottlenecks and performance degradation. For example, Google has managed this through exclusive access policies involving a single-app-at-a-time model for low-latency microphone capture. On top of that, further research has illustrated that multi-source audio captured by different applications can disproportionately affect apps that were not architecturally designated as the primary audio consumer, as set out by Vacher, Porter, Fleury and Noury. In practice, this means that Google’s own services will naturally perform better in this environment and that the Draft Measures may indirectly create a structural first-mover advantage.

Access to data will be provided in equal terms, but with the limitation that user consent is granted, bearing in mind that user consent flows must be presented in a non-discriminatory manner and in a way no more burdensome for third-party apps than for Google’s own (paras 125 and 126). As the EC already did on its specification proceedings against Apple, the Draft Measures apply a non-discriminatory standard to user consent flows and user interface design to avoid Google implementing dark patterns to hinder the provision’s effectiveness (paras 141 and 142). While this aspect of consent flows is addressed, there is little in the Draft Measures to ensure that users are positively informed that they can choose alternative assistants. The burden of creating awareness largely falls on third parties themselves, which may limit the real-world uptake of vertical interoperability in the short term.

The rapid development of the market towards AI assistants seamlessly performing tasks for users in the background of their everyday lives (and their smartphones) has also permeated the content of the Draft Measures. Structured on-device integration, which allows an AI assistant to trigger specific pre-defined actions in other apps (e.g., adding a calendar event) and screen automation, which enables an assistant to imitate user behaviour to complete multi-step tasks inside any app, are both included under the scope of the Draft Measures. Both these features must be opened to third-party assistants on equal terms, including the ability to discover installed apps, retrieve metadata, and perform actions on the user’s behalf without discriminatory restrictions (paras 57-74). To make this new functionality fully operational, the Draft Measures go one step further and establish that Google must grant equivalent read and write access to competitors to its own services, including non-designated core platform services such as Gmail, Google Calendar, Google Drive, Google Photos, Google Maps and YouTube (paras 75-80). One must remind the reader that all these functional and equivalent features will be provided free of charge to Google’s competitors, irrespective of their beneficiary, app, service, product and use case. Google is barred from charging any fees indirectly for any of the measures implemented as a result of the specification proceeding (para 145).

Against this framework, the Draft Measures also account for the constraints that competitors might face when they wish to execute their tasks on Android-reliant smartphones. For instance, Google introduces restrictions on how much CPU, NPU, GPU, RAM and battery a background app executing a particular task for the user receives. Those restrictions might apply differently to third parties than they do to the gatekeeper himself. Due to this reason, the Draft Measures provide that Android’s background execution system must be governed by transparent and non-discriminatory rules. If Google grants its own apps preferential memory or execution treatment, then users must be able to reassign those privileges to third-party apps (paras 112-120).

As shown by research by Gujarati, Karimi, Alzayat, Hao, Kaufmann, Vigfusson and Mace as well as by Crankshaw, Wang, Zhou, Franklin, Gonzalez and Stoica, expanding functionality in this direction is not particularly easy. When multiple inference workloads compete for the same NPU or DSP, latency is not degraded uniformly. Instead, it degrades disproportionately for lower-priority tasks. Thus, if Google assigns priority based on any characteristic that correlates with being a first-party app, the equal access requirement may well be undermined in practice. On top of that, broader computer science literature, notably Zhao, Liu, Liu, Li, Zhu, Huang, Liu and Jin, demonstrates that even when access rights are formally equal, the interaction between workloads on shared hardware produces asymmetric performance outcomes that are difficult to detect and even more difficult to attribute causally to scheduling policy as opposed to its characteristics. This is an additional argument that proves that the EC will find it very difficult to determine whether performance differences reflect discriminatory scheduling or real hardware constraints.

In practical terms, however, Google may raise similar concerns that it has raised in the past with respect to its implementation of Article 6(3) DMA in the past, i.e., the obligation that seeks to end with default settings on all types of devices. Since the 2024 compliance deadline, the EC has struggled in forcing Google to roll out its choice screens surrounding web browsers and search engines on all devices. The gatekeeper argued that it did not have any control over how OEMs decided to roll out the choice screen, and the provision was not fully implemented until a year later. A similar argument may apply here. There is a clear OEM fragmentation risk that may deem the Draft Measures ineffective, even though they compel Google to ensure compliance across all OEM devices through technical and contractual means.

In light of this framework, the principle of effective interoperability takes form in the Draft Measures as a detailed list of what APIs must be opened, what functionalities must be replicated for competitors to access and by what deadline. Notwithstanding, they remain silent on the cloud infrastructure that powers the most significant aspects of AI assistant performance.

The what-ifs and the implementation deadlines

Article 6(7) DMA establishes that the gatekeeper cannot be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the OS, hardware or software features provided by the gatekeeper, provided that the measures are duly justified by the gatekeeper. The EC already expanded the wording of the provision through its Apple specification proceeding (and, in turn, narrowing the possibility of gatekeepers putting them forward) by highlighting that the measures must be: i) strictly necessary, proportionate, based on transparent and non-discriminatory criteria; ii) equally applicable to the gatekeeper’s own services; iii) independently verifiable; and iv) notified to the EC at least four weeks prior to their introduction (para 97 of the Apple specification decision).

The Draft Measures maintain the wording (paras 127-131), and they even provide more detail in specifying what integrity measures will simply not do. For example, those measures that impose limits on the purpose or use case of the app or those introducing any commercial or financial requirement (para 130(e) and (f) of the Draft Measures). The difference between both decisions illustrates the EC’s experience of how it has seen other gatekeepers comply with Article 6(7) DMA.

Stark differences can also be spotted regarding the deadline-setting and reporting obligations that the EC imposes on Google, as opposed to the first exercise it completed with regard to Apple back in 2025. Both decisions impose different implementation deadlines depending on the concerned feature, with features that must be implemented earlier and others that are more technically complex and must be integrated at a later data. However, the timeline structures in both decisions differ significantly. The EC’s Apple specification decision fleshed out a disaggregated timeline structure that reflected the technical differences in each feature’s implementation, whereas the Draft Measures contemplate two primary deadlines: 1 January 2027 for the implementation of most features, whilst a few are delayed to June/July 2027. Additionally, the Draft Measures fail to acknowledge the relevance of beta testing since it does not systematically require specific beta milestones to be rolled out for each feature (para 149), as the previous specification proceeding did (paras 10 and 30 of the Apple specification decision).

Bearing in mind the asymmetry of information between the regulator and the EC, the Draft Measures establish extensive reporting obligations requiring 4 different types of reports as the features are implemented, notably an initial implementation report, a final feature implementation report or monthly reports. The reporting regime is more consistent with the breadth and depth of the measures imposed by the EC on Google, given that the gatekeeper has significant technical information advantages over the enforcer.

Key takeaways

The EC’s Draft Measures addressed at Google’s compliance with Article 6(7) DMA bear an anticipatory nature. Unlike the EC’s earlier specification proceedings against Apple, which sought to redirect non-compliant behaviour, the Draft Measures provide guidance on how to open up four distinct layers of Android to third-party AI competitors, involving invocation, context, actions on apps and the OS, and access to resources. All Android features covered by the Draft Measures are opened to Google’s competitors under the principle of equal effectiveness. In short, all competitors integrating AI features and functionality to Android must be granted access to the underlying software and hardware features under the same conditions that the gatekeeper himself imposes on its proprietary apps.

Despite the EC’s ambitious approach towards fleshing out the practical steps that must be taken by Google to comply with Article 6(7) DMA, one can spot some meaningful limitations in the Draft Measures, notably the silence on the technical constraints operating against their implementation and the absence of the cloud infrastructure in their content. As the saying goes, the EC sought to achieve all for one (i.e., all features to enter the market to be channelled by the gatekeeper’s OS), and it might result in the unfavourable outcome of one for none.