Regulatory dossier

Google Android interoperability under Article 6(7) DMA

A clause-by-clause comparison of the European Commission's final and draft interoperability measures for Google Android in case DMA.100220, including the principal changes, implementation dates and redlines.

First published: 25 August 2026
Last updated: 25 August 2026
Current version: 1.0
Legal framework: Regulation (EU) 2022/1925, Article 6(7)
Proceeding: Commission case DMA.100220
Key documents: Draft measures annex
Published final measures
Editor: Mikołaj Barczentewicz
Index: Google
DMA
Interoperability

Download as Markdown

A convenient format for sharing this dossier with AI agents.

Overview

This dossier examines the measures in the European Commission's Article 6(7) DMA specification proceeding for Google Android. It compares the draft's thirteen feature sections with the eleven retained in the published final measures, after the standalone proactive-suggestions and read/write-access sections were removed. Most remaining functionality descriptions are recognisable.

A companion dossier, Integrity under the DMA: sources, interpretation and safeguards, examines the broader legal framework governing integrity-based restrictions on interoperability. It covers the DMA’s statutory basis, legislative development, the Commission’s interpretation, and selected Apple and Android applications. This dossier focuses more narrowly on how the Android draft and final measures differ.

The comparison identifies three systemic changes:

Certification and access. Five feature categories—or specified implementations of them—may become subject to eligibility certification for “Qualified Services.” The final text also provides an end-user opt-out and a route for services that are not AI assistants.
Implementation timetable. Deadlines generally move to August 2027, while the distinct always-on hotword detection (AOHD) concurrency duty moves to August 2028.
Detailed guarantees. Several third-party-facing guarantees disappear without a direct substitute.

A separate dossier examines the Commission's Google Search data-sharing measures under Article 6(11) DMA. Comparing those measures with the Article 6(7) Android measures shows that both final texts give Alphabet more structured roles in controlling access, but with different safeguards. The Android measures include third-party certification routes, a per-service and per-device user opt-out, equal treatment of Alphabet and third-party services, and pre-certification testing. The Article 6(11) Search measures instead relocate sanctions and security screening while preserving independent assurance for other objectives, and add pricing review, technical transparency, and public recipient and termination information. Their different disclosure rules concern different objects, while free-of-charge interoperability and FRAND data-access pricing reflect different statutory obligations.

The comparison overview gives a compact view of all 26 provision groups, including the Section 5 chapeau as its own group. The detailed comparison provides the assessment, source pinpoints, deadline comparisons and provision-body redlines with source notes preserved separately.

Main findings

The ten most consequential changes between the draft and published final measures, ordered by significance.

Five feature categories become conditionally subject to certification

Final §5.4.1 authorises Alphabet to require eligibility certification for five feature categories—or specified implementations of them—but this is not an absolute access condition: paragraph 135 provides a per-service, per-device end-user opt-out, and paragraph 137 extends the relevant processes to services that are not AI assistants. Eligibility conditions must treat Alphabet and third-party services equally, while Alphabet retains central roles in programme terms, direct certification, suspension and appeals.

high
Detailed custom-model and customised-hotword guarantees are removed

The final always-on hotword detection (AOHD) section retains generic sound-model enrolment, DSP loading and execution, validation and testing functionality. It removes the draft's more detailed guarantees concerning custom-model documentation and autonomous training, explicit enrolment and loading APIs, testing without prior approval, OpenHST, branded hotwords and voice-based model creation.

high
The standalone read/write rule gives way to an enumerated app guarantee

Draft §3.3's standalone general read/write provision is removed. Final paragraph 55 guarantees enumerated actions in eight first-party apps to Qualified Services, subject to the user opt-out and non-AI-service route. This is not an exhaustive ceiling on §3.1: the final text also preserves general parity, additional-functionality, all-channel and future-update duties in paragraphs 51, 53, 54 and 57.

high
Implementation deadlines move to later Android releases

Deadlines in Sections 1–4 generally move from 1 January 2027 or Android 17 QPR2 to 1 August 2027 and Android 18. For AOHD, the main final deadline is one month later than the draft's July 2027 customised-hotword track and seven months later than its January 2027 track; the separate multi-hotword concurrency guarantee moves to 1 August 2028, respectively 13 and 19 months later.

high
Three on-device-model resource guarantees are removed

The final text omits the draft's guarantees concerning user reallocation of preferential memory or hardware access, parity for access to AICore's system-privileged APIs, and equal hosting access if Alphabet allows another third party or OEM to use AICore.

high
The express ban on privileged and OEM-controlled restrictions disappears

The system-integration section drops the draft prohibition on preinstallation, privileged permissions and other OEM-controlled access restrictions while the final introduces certification-gated access for the App-Functions channel.

high
Neutral access verification and independent dispute resolution are removed

The draft's beneficiary-registration guarantee that verification be conducted by neutral and independent third parties with independent dispute resolution is deleted. The final text creates distinct certification routes, including Trusted Certification Authorities, direct Alphabet certification and appeals decided by Alphabet, while paragraph 115 separately preserves independent verifiability of integrity conditions.

high
Default public transparency of ongoing reporting is reduced

Only the Final Feature Implementation Report automatically receives confidential and non-confidential versions when due, while non-confidential versions of the other four report types are supplied only at the Commission's request. The final measures also remove the draft's express requirement that non-confidential versions be provided for publication when due.

medium
A consent safeguard is deleted and integrity conditions gain a carve-out

The draft safeguard governing user consent and agency prompts is removed. Remaining integrity conditions add an 'unless specified otherwise in this Annex' qualification that accommodates the new Restricted Features regime; that textual accommodation does not itself establish that the exception is legally justified under the DMA.

medium
The proactive-suggestions architecture is folded into a narrower feature

Draft §2.2's standalone donation-and-egress architecture is removed. Proactive suggestions become a use case within the shorter, restricted context-aware-intelligence feature, which also adds opt-out and non-replacement provisions.

medium

Proceeding and implementation timeline

The timeline distinguishes procedural acts from the published measures analysed in this dossier and identifies the principal implementation milestones.

27 April 2026

Preliminary Findings adopted; draft measures published

The Commission adopted Preliminary Findings and separately published the draft measures annex analysed in this dossier.
16 July 2026

Article 8 decision adopted; final measures published

The Commission adopted an Article 8(2) decision and published the final measures analysed in this dossier. The linked publication is not the full decision or its complete reasoning.
1 February 2027

Draft certification programme terms

Deadline for draft terms of both programmes and the opening of Trusted Certification Authority applications. Paragraph 136(d) gives those applications a four-week assessment deadline and states no high-volume extension.
1 May 2027

Final programme terms

Deadline for final programme terms and opening of Qualified AI assistant applications. Paragraph 136(c) ordinarily allows four weeks for assessment, except for delays outside Alphabet's control, and allows eight weeks for an unusually high volume of applications.
1 August 2027

Main implementation deadline — Android 18

Most feature-level interoperability obligations are due with the next major Android release, identified as Android 18.
1 August 2028

AOHD concurrency deadline — Android 19

The guarantee that AOHD from multiple services can run concurrently is due with Android 19.

Comparison overview

The comparison overview covers every section of the draft and final measures. Feature names link to the complete assessment and semantic redline below.

Download CSV

Feature or obligation	Draft reference	Final reference	Access status	Effects	Deadline movement	Type of change
Long-press home / Long-press navigation handle (LPH/LPNH) contextual invocation	Draft §1.1 (paras 1-8)	Final §1.1 (paras 1-9)	General access conditions	Clarified; Preserved	Later deadline	Minor
Always-on hotword detection (AOHD)	Draft §1.2 (paras 9-20)	Final §1.2 (paras 10-18)	General access conditions	Removed; Narrowed; Preserved	Later deadline	Substantive
Centralised access to apps' data stored on-device (AppSearch)	Draft §2.1 (paras 21-28)	Final §2.1 (paras 19-28)	Restricted feature	Conditional; Narrowed; Preserved	Later deadline	Substantive
Draft §2.2 — Proactive suggestions (DROPPED as a standalone section)	Draft §2.2 (paras 29-38)	No standalone counterpart; see Final §2.2	General access conditions	Relocated; Narrowed	Later deadline	Dropped
Context-aware intelligence	Draft §2.3 (paras 39-47)	Final §2.2 (paras 29-38)	Restricted feature	Conditional; Removed; Narrowed; Expanded	Later deadline	Substantive
Access to ambient data	Draft §2.4 (paras 48-56)	Final §2.3 (paras 39-47)	General access conditions	Narrowed; Added; Preserved	Later deadline	Minor
Structured on-device integration	Draft §3.1 (paras 57-65)	Final §3.1 (paras 48-59)	Restricted feature	Conditional; Narrowed; Added; Preserved	Later deadline	Substantive
Screen automation (agent-controlled app interactions)	Draft §3.2 (paras 66-74)	Final §3.2 (paras 60-69)	Restricted feature	Conditional; Narrowed; Preserved	Later deadline	Substantive
Draft §3.3 — Integration with first-party services / read-write access (DROPPED as a standalone section)	Draft §3.3 (paras 75-84)	No standalone counterpart; see Final §3.1	General access conditions	Relocated; Narrowed	Later deadline	Dropped
System integration	Draft §3.4 (paras 85-93)	Final §3.3 (paras 70-79)	Restricted feature	Conditional; Removed; Narrowed; Preserved	Later deadline	Substantive
System-level on-device models (ODM)	Draft §4.1 (paras 94-102)	Final §4.1 (paras 80-89)	General access conditions	Narrowed; Clarified; Preserved	Later deadline	Substantive
On-device model (ODM) implementation	Draft §4.2 (paras 103-111)	Final §4.2 (paras 90-98)	General access conditions	Removed; Narrowed; Preserved	Later deadline	Substantive
Background execution	Draft §4.3 (paras 112-120)	Final §4.3 (paras 99-107)	General access conditions	Narrowed; Expanded; Preserved	Later deadline	Substantive
Measures for all features (chapeau)	Draft §5 (para 121)	Final §5 (para 108)	General access conditions	Clarified; Preserved	No deadline change	Editorial
Implementation across the Google Android ecosystem	Draft §5.1 (paras 122-124)	Final §5.1 (paras 109-111)	General access conditions	Expanded; Preserved	No deadline change	Editorial
User consent	Draft §5.2 (paras 125-126)	Final §5.2 (paras 112-113)	General access conditions	Added; Narrowed; Expanded; Preserved	No deadline change	Minor
Integrity	Draft §5.3 (paras 127-131)	Final §5.3 (paras 114-118)	General access conditions	Removed; Narrowed; Conditional; Expanded	No deadline change	Substantive
Eligibility of beneficiaries, applications and use cases (chapeau + §5.4.2 "Other restrictions and requirements")	Draft §5.4 (paras 132-137)	Final §5.4 chapeau (para 119) + §5.4.2 (paras 139-140)	General access conditions	Conditional; Narrowed; Relocated; Preserved	No deadline change	Substantive
NEW — Restricted features / Qualified AI Assistant Programme / Trusted Certification Authorities	— no draft counterpart —	Final §5.4.1 (paras 120-138)	General access conditions	Added; Conditional; Expanded	New deadline	New
Equal effectiveness	Draft §5.5 (paras 138-144)	Final §5.5 (paras 141-147)	General access conditions	Clarified; Preserved	No deadline change	Editorial
Free of charge	Draft §5.6 (para 145)	Final §5.6 (para 148)	General access conditions	Preserved	No deadline change	No change
Documentation and APIs	Draft §5.7 (paras 146-147)	Final §5.7 (paras 149-150)	General access conditions	Preserved	No deadline change	No change
Assistance and testing	Draft §5.8 (paras 148-149)	Final §5.8 (paras 151-154)	General access conditions	Added; Expanded; Preserved	No deadline change	Minor
Future updates and new functionalities	Draft §5.9 (paras 150-151)	Final §5.9 (paras 155-156)	General access conditions	Relocated; Preserved	No deadline change	Editorial
Reporting	Draft §5.10 (paras 152-157)	Final §5.10 (paras 157-164)	General access conditions	Added; Expanded; Removed; Narrowed	No deadline change	Substantive
Waiver	Draft §5.11 (para 158)	Final §5.11 (para 165)	General access conditions	Clarified; Preserved	No deadline change	Editorial

Draft reference: Draft §1.1 (paras 1-8)
Final reference: Final §1.1 (paras 1-9)
Access status: General access conditions
Effects: Clarified; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §1.2 (paras 9-20)
Final reference: Final §1.2 (paras 10-18)
Access status: General access conditions
Effects: Removed; Narrowed; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §2.1 (paras 21-28)
Final reference: Final §2.1 (paras 19-28)
Access status: Restricted feature
Effects: Conditional; Narrowed; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §2.2 (paras 29-38)
Final reference: No standalone counterpart; see Final §2.2
Access status: General access conditions
Effects: Relocated; Narrowed
Deadline movement: Later deadline
Sources

Draft reference: Draft §2.3 (paras 39-47)
Final reference: Final §2.2 (paras 29-38)
Access status: Restricted feature
Effects: Conditional; Removed; Narrowed; Expanded
Deadline movement: Later deadline
Sources

Draft reference: Draft §2.4 (paras 48-56)
Final reference: Final §2.3 (paras 39-47)
Access status: General access conditions
Effects: Narrowed; Added; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §3.1 (paras 57-65)
Final reference: Final §3.1 (paras 48-59)
Access status: Restricted feature
Effects: Conditional; Narrowed; Added; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §3.2 (paras 66-74)
Final reference: Final §3.2 (paras 60-69)
Access status: Restricted feature
Effects: Conditional; Narrowed; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §3.3 (paras 75-84)
Final reference: No standalone counterpart; see Final §3.1
Access status: General access conditions
Effects: Relocated; Narrowed
Deadline movement: Later deadline
Sources

Draft reference: Draft §3.4 (paras 85-93)
Final reference: Final §3.3 (paras 70-79)
Access status: Restricted feature
Effects: Conditional; Removed; Narrowed; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §4.1 (paras 94-102)
Final reference: Final §4.1 (paras 80-89)
Access status: General access conditions
Effects: Narrowed; Clarified; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §4.2 (paras 103-111)
Final reference: Final §4.2 (paras 90-98)
Access status: General access conditions
Effects: Removed; Narrowed; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §4.3 (paras 112-120)
Final reference: Final §4.3 (paras 99-107)
Access status: General access conditions
Effects: Narrowed; Expanded; Preserved
Deadline movement: Later deadline
Sources

Draft reference: Draft §5 (para 121)
Final reference: Final §5 (para 108)
Access status: General access conditions
Effects: Clarified; Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.1 (paras 122-124)
Final reference: Final §5.1 (paras 109-111)
Access status: General access conditions
Effects: Expanded; Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.2 (paras 125-126)
Final reference: Final §5.2 (paras 112-113)
Access status: General access conditions
Effects: Added; Narrowed; Expanded; Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.3 (paras 127-131)
Final reference: Final §5.3 (paras 114-118)
Access status: General access conditions
Effects: Removed; Narrowed; Conditional; Expanded
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.4 (paras 132-137)
Final reference: Final §5.4 chapeau (para 119) + §5.4.2 (paras 139-140)
Access status: General access conditions
Effects: Conditional; Narrowed; Relocated; Preserved
Deadline movement: No deadline change
Sources

Draft reference: — no draft counterpart —
Final reference: Final §5.4.1 (paras 120-138)
Access status: General access conditions
Effects: Added; Conditional; Expanded
Deadline movement: New deadline
Sources

Draft reference: Draft §5.5 (paras 138-144)
Final reference: Final §5.5 (paras 141-147)
Access status: General access conditions
Effects: Clarified; Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.6 (para 145)
Final reference: Final §5.6 (para 148)
Access status: General access conditions
Effects: Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.7 (paras 146-147)
Final reference: Final §5.7 (paras 149-150)
Access status: General access conditions
Effects: Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.8 (paras 148-149)
Final reference: Final §5.8 (paras 151-154)
Access status: General access conditions
Effects: Added; Expanded; Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.9 (paras 150-151)
Final reference: Final §5.9 (paras 155-156)
Access status: General access conditions
Effects: Relocated; Preserved
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.10 (paras 152-157)
Final reference: Final §5.10 (paras 157-164)
Access status: General access conditions
Effects: Added; Expanded; Removed; Narrowed
Deadline movement: No deadline change
Sources

Draft reference: Draft §5.11 (para 158)
Final reference: Final §5.11 (para 165)
Access status: General access conditions
Effects: Clarified; Preserved
Deadline movement: No deadline change
Sources

Provision-by-provision comparison

Each entry records the aligned draft and final paragraph ranges, change magnitude, deadline movement, substantive assessment and a provision-body redline with separately identified source notes.

Draft deadline: 1 January 2027
Final deadline: 1 August 2027 (Android 18)

The core obligation is preserved: third parties receive the LPH/LPNH access point, contextual data on invocation and the ability to be selected by the user. The draft does not contain eight lettered items in the two relevant lists: paragraph 4 lists three functionalities and paragraph 6 lists four measures. The final reorganises those lists without an evident loss of operative coverage.

Draft paragraph 2's description of Circle to Search is shortened, but this is background rather than an operative guarantee. The deadline moves from 1 January 2027 to 1 August 2027 and is tied to Android 18.

Compare provision wording

View

Draft ¶ 1 Final ¶ 1

Alphabet shall provide effective interoperability with the Long-press home (LPH)/Long-press navigation handle (LPNH) contextual invocation feature.

Draft ¶ 2 Final ¶ 2

The LPH/LPNH contextual invocation feature is an access point feature described in Section 8.2.2 of the ~~Preliminary Findings. The feature enables Alphabet to use Google Android access points such as LPH and LPNH~~Decision. ~~These access~~Access points enable Alphabet's services ~~and hardware~~ to be invoked by users at any time while using the device. ~~Invocation~~The ~~through~~LPH/LPNH access point, depending on the ~~LPH~~configuration ~~and~~of ~~LPNH~~the ~~functionalities~~device, ~~enables~~invokes Google Search's Circle to Search solution to overlay on top of the screen and offer a service based on contextual data, such as screen content. ~~Alphabet advertises the implementation of this feature as Circle to Search, allowing users to circle parts of their screen to search for the content.~~

Draft ¶ 3 Final ¶ 3

Alphabet shall implement an interoperability solution that provides third parties ~~^{Draft measures note 1}~~^{Final measures note 1} with access to the ~~same~~LPH/LPNH ~~Google~~contextual ~~Android~~invocation feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services, ~~including~~such toas Google Search via the Circle to Search solution, and in a way that is equally effective as the solution available to ~~Alphabet~~Alphabet's services.

Draft ¶ 4 Final ¶ 4

These functionalities are: (a) Ability to be invoked system-wide through the LPH/LPNH access ~~points~~point and any other access ~~point.~~points available to Alphabet's services, such as Google Search (b)via ~~Ability~~the Circle to ~~receive,~~Search ~~upon~~solution); (b) Upon invocation, ability to receive contextual data, including but not limited to a current screenshot, information about the open apps, information provided by ~~open~~ apps in the foreground, such as a URL, picture, or additional data. ~~(c)~~as ~~Upon~~available ~~invocation~~to Alphabet's services, such as Google Search (via the ~~ability~~Circle to ~~overlay content~~Search ofsolution); ~~any~~and ~~current~~(c) ~~activities~~Upon oninvocation, the ~~user's~~ability ~~device~~to overlay content.

Draft ¶ 5 Final ¶ 5

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with ~~the feature referred to~~LPH/LPNH incontextual ~~paragraph~~invocation ~~(2)~~feature.

Draft ¶ 6 Final ¶ 6

To provide third parties with an interoperability solution for the LPH/LPNH contextual invocation feature and functionalities ~~referred to in paragraphs (2) and (4)~~ that is equally effective as that available to ~~any of~~ Alphabet's own services ~~or hardware~~, ~~Alphabet~~such ~~shall~~as ~~implement~~Google Search, the following measures shall apply: (a) Alphabet shall make ~~any APIs relied upon by Google's Circle~~available to ~~Search~~third ~~(including~~parties ~~Contextual~~the ~~Search~~means ~~APIs,~~for asinvocation ~~well~~through asLPH/LPNH and any other ~~API~~access ~~relied~~point. ~~upon~~Alphabet byshall ~~Alphabet's~~ensure ~~services,~~that ~~such~~third-parties ascan ~~Google~~receive ~~Search,~~upon toinvocation bethrough ~~invoked~~an ~~through~~access point the ~~LPH/LPNH~~same ~~access~~contextual ~~point~~data oras ~~Circle~~available to ~~Search access~~Alphabet's ~~point)~~services, ~~public~~such ~~and~~as ~~accessible~~the data made available to ~~all~~Google ~~apps,~~Search ~~regardless~~when ofinvoked ~~whether~~via ~~pre-installed~~Circle orto ~~user-installed.~~Search; (b) Alphabet shall ensure that the user can customise the LPH/~~LPHN~~LPNH access point and any other access point, subject to the possibility of OEMs to reserve one access point ~~^{Draft measures note 2}~~ other than the LPH/~~LPHN~~LPNH to the default assistant role.; (c) Subject to point (b) above, Alphabet shall not reserve, including through technical or contractual means, any access point on Google Android mobile devices for its services ~~(subject to paragraph~~; ~~(6)(b).~~and (d) Alphabet shall ensure that ~~the user~~users can easily select which app is invoked through any ~~such~~ access point. The mechanism allowing the user to exercise this choice must be non-discriminatory, including in terms of user interface. Alphabet shall ensure that when a third-party app gets invoked through such an access point, it can receive contextual data. Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the LPH/LPNH contextual invocation feature insofar as they are available to Alphabet's own services or hardware.

Draft — Final ¶ 7

The future-update obligation is separated from the unlettered closing text of draft paragraph 6.

Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the LPH/LPNH contextual invocation feature insofar as they are available to Alphabet's own services.

Draft ¶ 7 Final ¶ 8

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 8 Final ¶ 9

Alphabet shall implement the measures for the LPH/LPNH contextual invocation feature in the next major Android release, i.e. Android 18, and by 1 ~~January~~August 2027 at the latest.

Source-note comparison

Wording changed

Draft

Draft measures note 1

The terms "third parties" and "third-party apps" across this Annex refer to all apps, including user-installed apps, pre-installed apps without system privileges, and apps of original equipment manufacturers (OEMs).

Final

Final measures note 1

The terms "third parties", and "third-party services" across this Annex include all apps, including user-installed apps, pre-installed apps without system privileges, and apps of original equipment manufacturers (OEMs). User-installed apps are apps that are only installed following a decision by the user. Apps that are pre-installed on the Google Android mobile device without the user making such decision (pre-installed apps) are not user-installed apps.

Removed note

Draft

Draft measures note 2

For access point which can be invoked in different ways, such as long press, single tab and double tab, each such way of invocation constitutes a different access point.

Final

Not present in the final text.

Draft deadline: 1 January 2027 (third-party sound models) / 1 July 2027 (user-customised hotwords)
Final deadline: 1 August 2027 (Android 18) / 1 August 2028 (Android 19, concurrency only)

The final retains generic sound-model enrolment, DSP loading and execution, validation and testing, plus contextual-data parity, settings, protected operation and eventual concurrency. It omits the draft's more detailed guarantees for model documentation and autonomous development, explicit APIs, testing without prior approval, OpenHST and customised or branded hotwords.

The dates must be compared obligation by obligation. Most final AOHD measures are due 1 August 2027: that is one month after the draft's 1 July 2027 customised-hotword track and seven months after its 1 January 2027 third-party-model track. Only the separate concurrency guarantee moves to 1 August 2028, which is respectively 13 and 19 months later. The 13- and 19-month figures do not describe the main August 2027 deadline.

Compare provision wording

View

Draft ¶ 9 Final ¶ 10

Alphabet shall provide effective interoperability with the always-on hotword detection (AOHD) feature ~~including through third-party sound models and user customised hotword~~.

Draft ¶ 10 Final ¶ 11

The AOHD feature is described in Section 8.3.2 of the ~~Preliminary Findings~~Decision. The feature enables Alphabet services, ~~and~~such ~~hardware~~as Gemini, to be invoked ~~through~~when the user ~~uttering~~utters a hotword or(also known as "wake word"). Hotwords allow users to invoke and interact, hands free, with ~~their~~Alphabet's ~~favourite~~services, ~~assistant~~such as Gemini. The feature is implemented in aan ~~power~~energy-saving manner that allows ~~always-on hotword detection~~AOHD to run continuously, even when the phone screen is turned off and when the phone is in battery saver mode. The feature ~~can~~is becurrently implemented based on ~~specific hardware, i.e.~~ a digital signal processor (DSP) which depends on the characteristics of the device ~~or through~~, aas ~~user~~decided ~~customised~~by ~~hotword~~OEMs.

Draft ¶ 11 Final ¶ 12

Alphabet shall implement an interoperability solution that provides third-party ~~parties~~services with access to the AOHD ~~Google Android~~ feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services, and in a way that is equally effective as the solution available to ~~Alphabet~~Alphabet's services, such as Gemini.

Draft ¶ 12 Final ¶ 13

~~The~~These functionalities are: (a) Sound model enrolment. The ability to enrol a sound model in the Android operating system to persistently store and retrieve the sound model upon request. An enrolled sound model can be loaded on the DSP when the app starts ~~always-on hotword recognition.~~AOHD; (b) First-stage detection on the DSP. The ability to load and execute its enrolled sound model on the DSP, and to ensure that the DSP performs the first stage hotword detection on the app's behalf.; (c) Second-stage validation. The ability to run a second stage validation after the DSP sound model has recognised the hotword in the first-stage detection, to confirm that the hotword was detected correctly. The second stage ~~runs~~may run in a secure and isolated process, disallowing to extract audio data before the hotword was validated.; (d) Invocation of the app. The ability of the app to be invoked ~~(once the second stage validation confirms the hotword detection)~~ and to handle the request of the user~~. This includes showing a user interface that overlays any previously shown user interface on the device. In addition, the app receives contextual data on~~; ~~invocation.~~and (e) Continued access to record audio. The ability, after invocation, to receive the audio of the hotword detection and to continue to record the audio until the user decides to finish its request or conversation.

Draft ¶ 17 Final ¶ 14

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the ~~always-on hotword detection~~AOHD feature ~~referred to in paragraph (10)~~.

Draft ¶ 13 Final —

To provide third parties with an interoperability solution for the AOHD feature referred to in paragraph (10) that is equally effective as that available to any of Alphabet's services, Alphabet shall implement the measures in paragraphs (14), (15) and (16) below.

Draft ¶ 14 Final —

To that end, Alphabet shall implement the following measures to enable always-on hotword detection using third-party sound models supporting hotwords defined by the third-party developer. (a) Alphabet shall prepare and provide developers with a detailed documentation which is required on how to create a first stage DSP sound model compatible with Alphabet's DSP library. As part of this documentation, Alphabet shall specify the TFLM operators that the DSP library on Google Android supports, which input the model receives and how the model must structure its outputs. Alphabet shall enable third-party developers to implement custom first stage DSP sound models solely based on the documentation. Alphabet may provide sample implementations to aid developers. (b) Alphabet shall not hinder third-party developers to autonomously innovate on their DSP sound models by building a custom model training pipeline that can be used create these sound models. Alphabet shall not hinder developers to implement a specific model. This does not preclude that third-party developers may need to meet certain implementation criteria that are necessary to preserve integrity, e.g. that their model must use TFLM operators that are supported by the DSP library. (c) Alphabet shall create an API or open existing APIs to allow third-party developers to enrol these first stage sound models for always-on hotword detection within Google Android. (d) Alphabet shall create an API or open existing APIs to allow third-party developers to load their DSP sound models onto the Google Android mobile device DSP and to run them using Alphabet's DSP library, to facilitate always-on hotword detection for the third-party app. (e) Alphabet shall enable third-party developers to test their custom DSP sound models on their Android mobile devices, without any prior agreements and prior validation from any other party. (f) Alphabet shall enable third-party developers to implement a second stage hotword detection. Equally to Alphabet's implementation, the second stage must receive an audio snippet to validate the detected hotword. Alphabet shall enable the second stage hotword detection to run in a secure and isolated process, disallowing to extract audio data before the hotword was validated. (g) Alphabet shall enable third-party developers to invoke their app after the app validated the hotword in the second stage. Alphabet shall ensure that the third-party app also receives the audio snippet of the detected hotword and that the app has continued access to the microphone. (h) Alphabet shall make available to third-party developers testing tools, such as Alphabet's open source hotword stress test tool,^{Draft measures note 3} that allow third-party developers to test always-on hotword detection on the third-party's Google Android mobile devices, enabling third parties to verify that their sound models correctly recognise the hotword phrase. Alphabet shall continue to support this tool.

Draft ¶ 15 Final —

In addition, Alphabet shall implement the following measures enabling always-on hotword detection using user-customised hotwords. (a) Alphabet shall make available to third-party developers a functionality that allows their users to create a custom hotword without leaving the developer's app. (b) Alphabet shall ensure that the procedure to set up the user-customisable hotword must be frictionless and may not be cumbersome. In addition, the user interface, text, and wording must be in control of third-party developers. (c) Alphabet shall allow a third-party app to suggest a custom hotword phrase, allowing the app to use a branded hotword. (d) Alphabet shall ensure that two custom sound models can be created based on the user's voice recordings: one for the first stage hotword detection on the DSP and one for the second stage hotword validation. Alphabet shall ensure that the first stage sound model can be loaded onto the DSP and that the model will run using Alphabet's DSP library. Alphabet shall ensure that Google Android will run the second stage model in an isolated process to validate the hotword detection. (e) Once the hotword is detected at both stages, Alphabet shall ensure that Google Android activates the third-party app. In addition, Alphabet shall ensure that the app receives the audio snippet of the hotword detection and that the app has continued access to the microphone.

Draft ¶ 16 Final ¶ 15

~~With~~To ~~respect~~provide tothird ~~both~~parties ~~implementations~~with ofan ~~third-party~~interoperability ~~always-on~~solution ~~hotword~~for ~~detection,~~the AOHD feature that is ~~(15)~~equally ~~and~~effective ~~(16)~~as that available to Alphabet's services, ~~Alphabet~~such ~~shall~~as ~~implement~~Gemini, the following measures. shall apply: (a) Alphabet shall ~~ensure~~make ~~that~~available ~~always-on~~to ~~hotword~~developers ~~detection~~testing ~~from~~tools ~~multiple~~enabling ~~third-party~~developers ~~apps~~to ~~and~~verify, ~~first-party~~amongst ~~apps~~others, ~~are~~that ~~able~~their toAOHD ~~run~~implementation ~~concurrently.~~correctly ~~Therefore,~~recognises the hotword phrase; (b) Alphabet shall ensure that ~~multiple~~, ~~first~~upon ~~stage~~invocation, ~~DSP~~the ~~sound~~third ~~models~~party ~~can~~receives ~~run~~access atto the same ~~time. This~~contextual ~~means~~data that ~~a third-party hotword~~is ~~may~~available ~~run~~to ~~alongside~~Alphabet's ~~the~~services, ~~existing~~such ~~Google~~as ~~hotwords.~~Gemini; ~~Concurrent~~(c) ~~always-on~~Alphabet ~~hotword~~shall ~~detection~~ensure ~~may~~that beGoogle ~~limited~~Android byusers ~~the~~have ~~capabilities~~control ofover the ~~DSP on~~apps ~~the~~using ~~Google~~AOHD ~~Android~~on ~~mobile~~their device. ~~(b) Alphabet shall enable third-party~~through ~~developers~~mechanisms tosuch ~~use~~as ~~always-on~~central ~~hotword~~settings. ~~detection~~The ~~while~~mechanism ~~the~~allowing ~~Google~~users ~~Android~~to ~~mobile~~enable ~~device~~or isdisable inAOHD ~~battery~~shall ~~saver~~be ~~mode~~non-discriminatory, ~~as available~~including toin ~~Alphabet's~~terms ~~always-on~~of ~~hotword~~user ~~detection.~~interface; (cd) Alphabet shall ensure that, ~~upon~~AOHD ~~invocation,~~for ~~the~~third ~~app~~parties ~~receives~~can ~~access~~continue to ~~all~~run ~~data~~while ~~and~~the ~~context~~screen ~~available~~is tolocked ~~Gemini,~~or ~~Google~~the ~~Assistant~~device oris ~~any~~in ~~other~~battery ~~Alphabet~~saver ~~services.~~mode; (de) Alphabet ~~shall~~may ~~ensure~~apply ~~that~~technical ~~users~~measures ~~have~~such ~~control~~that ~~over~~audio ~~which~~data ~~apps~~for ~~use~~the ~~always~~first-~~on hotword~~stage detection, ~~such as through user consent~~and tosecond-stage ~~enable~~validation ais ~~hotword.~~processed ~~Alphabet~~in ~~shall~~accordance ~~implement~~with aprinciples ~~centralised~~of ~~settings~~process ~~page~~isolation, ~~must~~and ~~allow~~that ~~the~~continuous ~~user~~access to ~~enable or disable hotword detection for~~audio ~~any~~data ~~app.~~is ~~The~~only ~~mechanism~~granted ~~allowing~~after the ~~user~~hotword tohas ~~exercise~~been ~~this~~detected ~~choice~~and ~~should~~validated; beand ~~non-discriminatory,~~(f) ~~including~~Alphabet inshall ~~terms~~ensure ofthat ~~user~~AOHD ~~interface.~~from Inmultiple ~~particular~~services, ~~the setting page~~including ~~must~~services ~~include~~belonging ~~both~~to third~~-party~~ ~~apps~~parties and ~~Alphabet's~~Alphabet, ~~apps.~~are ~~(e)~~able ~~Alphabet~~to ~~shall~~run ~~not~~concurrently, ~~reserve~~within the ~~always-on hotword access~~technical ~~points~~capabilities toof the ~~default assistant role~~device.

Draft ¶ 18 Final ¶ 16

Alphabet shall provide effective interoperability with any future updates or implementations, including new functionalities, of the ~~always-on hotword detection~~AOHD feature insofar ~~and~~ as ~~soon as~~ they are available to Alphabet's ~~own~~ services, such as Gemini, or hardware.

Draft ¶ 19 Final ¶ 17

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 20 Final ¶ 18

Alphabet shall implement the measures ~~with respect~~(15)(a) to ~~third-party~~15(e) for the always-on hotword detection ~~using third-party sound models~~feature ~~for~~in the ~~always-on~~next ~~hotword~~major ~~detection~~Android ~~feature~~release, ~~as defined in~~i.e. ~~paragraphs~~Android ~~(14)~~18, and ~~(16)~~ by 1 ~~January~~August 2027 at the latest. Alphabet shall implement the ~~measures with respect to third-party always-on hotword detection using user-customised~~measure ~~hotwords~~15(f) ~~for~~in the ~~always-on hotword detection~~following ~~feature~~major asAndroid ~~defined~~release, ini.e. ~~paragraphs~~Android ~~(15)~~19, and ~~(16)~~ by 1 ~~July~~August ~~2027~~2028 at the latest.

Draft deadline: Android 17 QPR2 / 1 January 2027
Final deadline: Android 18 (next major release) / 1 August 2027

New gate: final para (21) newly designates this feature "as implemented in AppSearch" a Restricted feature: "Consequently, access to the functionalities referenced below in this section may be limited to Qualified Services." No such gate existed in the draft — draft §5.4 gave all third parties (subject only to generic, non-discriminatory conditions) the right to the feature. See §5.4.1 below for the new certification regime this triggers.

The comparator benchmark also narrows: draft measured equal effectiveness against "Alphabet's services" generally; final measures it against "Alphabet's AI-powered services, such as Gemini" (final paras 22, 25). If Alphabet has non-AI services that also read/write centrally-shared app data, third parties are no longer explicitly entitled to parity with those services — only with the AI-powered ones.

Functionally the core measures (opt-in role-based access, parity for data shared with Gemini, concurrent access) are preserved almost word-for-word (final (25)(a)-(c) tracks draft (25)(a)-(c)).

Deadline: draft tied this to "the release of Android 17 QPR2 and, in any case, by 1 January 2027 at the latest" — i.e., potentially available well before January 2027 via a quarterly platform release. Final ties it only to "the next major Android release, i.e. Android 18, and by 1 August 2027 at the latest" — a single, later date with no quarterly-release acceleration option.

Compare provision wording

View

Draft ¶ 21 Final ¶ 19

Alphabet shall provide effective interoperability with the centralised access to apps' data stored on-device feature.

Draft ¶ 22 Final ¶ 20

The centralised access to apps' data stored on-device feature is described in Section 9.2.2 of the ~~Preliminary Findings~~Decision. The feature enables access to on-device-stored apps' data that isapps ~~stored~~choose ~~on-device~~to share in a centralised manner through on-device databases or data sharing platforms, thereby allowing efficient cross-app data access, search and retrieval. ~~For~~The ~~instance,~~feature ~~AppSearch~~is currently ~~enables centralised access to apps' data stored on-device on Google Android, but only for the one app holding~~implemented ~~the~~by ~~default~~Alphabet ~~assistant~~as ~~role~~AppSearch.

Draft — Final ¶ 21

As described in Section 12.4.5 of the Decision, the centralised access to apps' data stored on-device feature, as implemented in AppSearch, meets the requirements of a restricted feature. Consequently, access to the functionalities referenced below in this section may be limited to Qualified Services.

Draft ¶ 23 Final ¶ 22

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google Android~~centralised ~~feature~~access ~~(as~~to ~~described~~apps' indata ~~the~~stored ~~preceding~~on-device ~~paragraph)~~feature and ~~all~~ its functionalities, as ~~used by and~~ available to Alphabet's AI-powered services, such as Gemini, and in a way that is equally effective as the solution available to ~~Alphabet~~Alphabet's AI-powered services, such as Gemini.

Draft — Final ¶ 23

These functionalities are: (a) Ability to search the on-device data that apps choose to share on an opt-in role-based basis; and (b) Ability to retrieve the on-device data that apps choose to share on an opt-in role-based basis.

Draft ¶ 24 Final ¶ 24

Alphabet shall ~~provide~~grant ~~effective~~third ~~interoperability~~parties ~~with~~access ~~all~~to additional functionalities ofavailable to Alphabet's services if necessary to enable effective interoperability with the centralised access to apps' data stored on-device feature ~~which are available to Alphabet's services and hardware~~.

Draft ¶ 25 Final ¶ 25

To provide third parties with an interoperability solution for the centralised access to apps' data stored on-device feature that is equally effective as that available to Alphabet's AI-powered services, ~~Alphabet~~such ~~shall~~as ~~implement~~Gemini, the following measures shall apply: (a) Alphabet shall ensure access by third ~~parties, including third~~-party ~~apps,~~services to ~~data that is stored centrally~~ on-device ~~and~~data that isapps ~~shared~~choose to share on an opt-in role-based basis., in a centralised manner; ~~^{Draft measures note 4}~~^{Final measures note 2} (b) Alphabet shall ensure that data that is stored on device by Alphabet's apps and that is shared with Alphabet's AI-powered services, issuch ~~equally~~as ~~accessible~~Gemini, byfor ~~third~~the ~~parties.~~purposes ~~(c)~~of ~~Alphabet~~answering ~~shall~~a ~~ensure~~user ~~that~~query ~~access~~is toaccessible ~~data~~by ~~covered~~third-party inservices ~~paragraph~~under ~~(25),~~the ~~letters~~same ~~(a)~~conditions; and (bc) ~~is possible~~Alphabet onshall aenable concurrent ~~basis and in a manner that~~use ~~ensures~~of ~~equal~~the centralised access to apps' data stored on-device ~~as is available to Alphabet's services~~feature.

Draft ¶ 26 Final ¶ 26

Alphabet shall provide effective interoperability with any future updates or implementations, including new functionalities, of the centralised access to apps' data stored on-device feature insofar and as soon as they are available to Alphabet's ~~own~~AI-powered services, orsuch ~~hardware~~as Gemini.

Draft ¶ 27 Final ¶ 27

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 28 Final ¶ 28

Alphabet shall implement the measures for the centralised access to apps' data stored on-device feature in the ~~release~~next ofmajor Android ~~17 QPR2 and~~release, ini.e. ~~any~~Android ~~case~~18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: Android 17 QPR2 / 1 January 2027
Final deadline: No standalone section; related duties: Android 18 / by 1 August 2027

Draft §2.2 was a free-standing, heavily detailed feature section governing proactive suggestions (for example, Pixel's Magic Cue). It specified an input-and-output architecture for donated app data, actions, screen context and other data; egress surfaces and egress data; control over suggestion placement; granular consent; and concurrent participation by multiple third-party apps.

The final measures contain no free-standing proactive-suggestions section. Instead, final §2.2 treats proactive suggestions as one use of context-aware intelligence. Final (33)(a)(4) retains generic access to data and actions that apps choose to donate, and final (35)(c) preserves the ability for a third party to contribute to decisions about when, where and how an experience is surfaced. The draft's more detailed donation-and-egress architecture, however, is not reproduced.

This is therefore a major narrowing and restructuring, not a complete disappearance of the underlying functionality. The final context-aware-intelligence section has nine lettered measures, is designated a Restricted feature, and must be read together with final §3.1: paragraph 56 expressly retains semantic search for the listed first-party-app functionalities.

The related final context-aware-intelligence duties are due with Android 18 and by 1 August 2027, later than the draft section's Android 17 QPR2 / 1 January 2027 deadline.

Compare provision wording

View

Draft ¶ 29 Final —

~~Alphabet shall provide effective interoperability with the proactive suggestions feature.~~

Draft ¶ 30 Final —

The proactive suggestions feature is described in Section 9.3.2 of the Preliminary Findings. The proactive suggestions feature surfaces relevant information and recommends helpful actions across different apps. These suggestions are based on the user's data collected from apps, recently viewed content, and the user's context in general. For instance, Pixel's Magic Cue can surface the relevant flight number when calling an airline or suggest helpful actions such as "View calendar" when a friend sends an invitation to dinner via a message. Currently, apps which can participate in proactive suggestions, either by donating input to be surfaced in other apps, or by being themselves the apps that surface a proactive suggestion, are mainly Alphabet's first-party apps and services, including Gemini.

Draft ¶ 31 Final —

Alphabet shall implement an interoperability solution that provides third parties with access to the same Google Android feature (as described in the preceding paragraph) and all its functionalities, as available to Alphabet's services and in a way that is equally effective as the solution available to Alphabet's services.

Draft ¶ 32 Final —

These functionalities are: (a) The ability to be part of inputs for proactive suggestions: (1) The ability to donate app data, including structured data. For example, an email app can donate its emails, which are later used to retrieve a flight number to suggest. (2) The ability to donate actions to be used in generating proactive suggestions. For example, a calendar app can donate the action "view calendar", which is later suggested when the user receives an event invitation. (3) The ability to provide screen context, including by having their screen content captured. For example, the chat app's on-screen chat messages asking about an upcoming event can be used to suggest the location of that event. (4) The ability to donate additional data while proactive suggestions are being generated. For example, a phone app can donate the currently dialled phone number (even if not shown on screen), which is used to determine that the user is calling an airline and therefore suggest the flight number. (b) The ability to be part of outputs for proactive suggestions: (1) The ability to surface (i.e. display) proactive suggestions, on any surface inside apps, outside apps, and on top of apps (e.g., context menu, overlay, notifications) available to Alphabet's first-party apps. For example, a phone app can show the flight number that is suggested (e.g. being relevant for the ongoing call). (2) The ability to be the egress action of proactive suggestions, via any mechanism (e.g. through an overlay or by being directed to the app) available to Alphabet's first-party apps. For example, Magic Cue can suggest "search restaurants in Gemini", prompting the user to open Gemini. In this case, Gemini is the egress action. As another example, a calendar app can be opened or presented in an overlay as part of a suggestion to "View calendar". (3) The ability to receive the egress data (i.e. output) of a proactive suggestion. For example, a chat app can receive the suggested text to copy it into a chat message.

Draft ¶ 33 Final —

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the proactive suggestions features referred to in paragraph (30).

Draft ¶ 34 Final —

To provide third parties with an interoperability solution for the proactive suggestions feature referred to in paragraph (30) that is equally effective as that available to any of Alphabet's services, Alphabet shall implement the following measures: (a) Alphabet shall allow third-party apps to donate any type of app data or additional data (both in terms of the type of raw data or the type of insight derived from it) and any type of actions, in an equally effective manner (e.g. via equally effective donation channels) as Alphabet's apps. (b) Alphabet shall allow third-party apps to consent to or withdraw from donating app data, actions, screen context, and additional data for proactive suggestions and to becoming surfaces for proactive suggestions, in an equally effective and granular manner as Alphabet's apps. (c) Alphabet shall ensure that, when proactive suggestions are surfaced inside apps, the surfacing app is able to control the positioning of the proactive suggestion in relation to the surfacing app's own user interface. (d) Alphabet shall allow third-party apps to combine being the egress action and receiving the egress data for proactive suggestions. For example, a suggestion could result in opening an assistant in an overlay with a prepared prompt. (e) Alphabet shall allow that, when third-party apps are part of outputs in any of the ways described in Section 9.3.3.1 of the Preliminary Findings, they must be able to receive data/input from Alphabet's first-party apps, in an equivalent manner as Alphabet's first-party apps can. (f) Alphabet shall allow end users, for the purpose of receiving proactive suggestions, to consent with an equivalent level of granularity for the types of proactive suggestions experiences, as allowed with respect to the proactive suggestions experiences enjoyed by Alphabet's first-party apps. (g) Alphabet shall allow users, for the purpose of receiving proactive suggestions, to consent with an equivalent level of granularity and via an equivalent user interfaces and user journeys for the usage of data from specific apps and surfaces and on specific apps and surfaces, as allowed for Alphabet's first-party apps. (h) Alphabet shall allow users, whenever third-party apps are part of inputs or outputs of proactive suggestions, to interact with the proactive suggestions in an equivalent manner and via an equivalent user interfaces and user journeys as users can interact with the proactive suggestions where Alphabet's first-party apps are part of inputs or outputs. (i) Alphabet shall ensure that, when proactive suggestions are generated, third-party apps, whether they are part of inputs or outputs, are treated non-discriminatorily, in particular by intelligence components, and benefit from an equivalent experience of proactive suggestions as Alphabet's first-party apps. (j) Alphabet shall ensure that third-party apps are able to surface app data or actions from Alphabet's first-party apps, in an equivalent manner as Alphabet's first-party apps can surface suggestions based on app data or actions from other Alphabet first-party apps. This includes the ability to combine the screen context and additional data from the third-party app with the app data or action from the Alphabet first-party app. (k) Alphabet shall ensure that Alphabet's first-party apps can surface suggestions based on app data or actions from third-party apps, in an equivalent manner as Alphabet's first-party apps can surface suggestions based on app data or actions from other Alphabet first-party apps. This includes the ability to combine the screen context and additional data from the Alphabet first-party app with the app data or action from the third-party app. (l) Alphabet shall allow multiple third-party apps must be able to be part of inputs and outputs, at any time, regardless of the number of other apps that are already part of inputs and outputs, simultaneously and concurrently, in an equivalent and non-discriminatory manner as Alphabet's first-party apps.

Draft ¶ 35 Final —

Alphabet may implement technical measures such that proactive suggestions are provided in line with principles of process isolation, encryption, anonymous and aggregated telemetry, and user control (e.g. requiring user interaction before data egress to a surfacing app), insofar as they are based on transparent, objective, precise, and non-discriminatory conditions that also apply to Alphabet's services and hardware.

Draft ¶ 36 Final —

Alphabet shall provide effective interoperability with any future updates or implementations, including new functionalities, of the proactive suggestions feature insofar and as soon as they are available to Alphabet's own services. For the avoidance of doubt, such future updates of the proactive suggestions feature include any updates concerning the: (a) Ability to donate or surface any type of input needed for generating proactive suggestions, irrespective of whether such input is stored on a cloud service. (b) Advanced assistant capabilities allowing assistants to surface, read, receive, and/or interact with the proactive suggestion. (c) Ability to display multiple proactive suggestions concurrently in one surface. (d) Ability for the user to interact with the proactive suggestion (e.g., provide feedback, edit the suggestion).

Draft ¶ 37 Final —

~~Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.~~

Draft ¶ 38 Final —

~~Alphabet shall implement the measures for the proactive suggestions feature in the release of Android 17 QPR2 and, in any case by 1 January 2027 at the latest.~~

Draft deadline: Android 17 QPR2 / 1 January 2027
Final deadline: Android 18 / 1 August 2027

New gate: final para (31) designates context-aware intelligence a Restricted feature — "access to the functionalities referenced below in this section may be limited to Qualified Services."

Dropped functionalities (final (33) vs draft (42)):

Draft (42)(b)(1) guaranteed on-device model access "with the same level of model availability (in particular if already present), hardware access and background execution (in particular selected and brought by the service) as Alphabet's services." Final (33)(b)(1) drops this explicit equal-level guarantee, reducing to a bare statement that models "already present on the device" and those "implemented by third parties" may be used.
Draft (42)(c)(1)-(2) guaranteed the "ability to discover the channels and surfaces that are available for proactive suggestions ... and be aware of newly available channels and surfaces," and the "ability to decide on the most relevant channel or surface, including through accessing the properties of channels and surfaces (e.g. their size or location)." Both are absent from the final's output-channel functionality list (final (33)(c) only lists presenting, transmitting, and triggering integrations). Final (35)(c) does preserve a right to contribute to the decision about when, where and how an experience is surfaced, but it does not restore the draft's express discovery, channel-properties and independent-selection guarantees.

New carve-outs (final (35)):

Final (35)(f) (new): "Alphabet may enable apps to opt out of the ability for components offering proactive suggestions and intelligent experiences to access that app's digital context and/or to appear in a surface in/on that app ... where that opt-out applies ... on a non-discriminatory basis." This gives individual apps (Alphabet's or third parties') a lever to block context-aware intelligence integrations entirely — a mechanism the draft did not contain.
Final (35)(h) (new): "Alphabet shall not be required to enable the replacement of existing intelligence components, such as Android System Intelligence." This is an explicit new boundary on the interoperability duty — third parties can plug into context-aware intelligence but cannot displace Android System Intelligence as the orchestrating component.

Concurrency: draft (44)(d) required non-discriminatory access "in particular when access cannot be provided concurrently" (implying concurrency is otherwise the default). Final (35)(g) reframes this as concurrency "within the technical capabilities of the inputs, resources, and outputs," falling back to non-discriminatory (not necessarily concurrent) access when "not possible or is limited" — a more openly conditional formulation.

Future-proofing: draft (45) listed non-exhaustive examples of covered future updates (additional inputs/processing/output channels; "further integration with cloud-based AI services and AI assistants that contribute data to and retrieve data from the user's context"). Final (36) drops both illustrative examples, retaining only the generic forward-looking duty.

Addition: final (35)(e) is new and reciprocal — it requires Alphabet to give third parties non-discriminatory access to surfaces in/on Alphabet's own first-party apps for surfacing suggestions, which was not spelled out as such in the draft.

Compare provision wording

View

Draft ¶ 39 Final ¶ 29

Alphabet shall provide effective interoperability with the context-aware intelligence feature.

Draft ¶ 40 Final ¶ 30

The context-aware intelligence feature is described in Section 9.43.2 of the ~~Preliminary Findings~~Decision. Context-aware intelligence allows ~~to provide third-party versions of~~providing proactive suggestions and "intelligent experiences", i.e. experiences that are personalised to the user's context and can be continuously active to enhance the user experience. This relies, for example, on accessing inputs from device sensors and processing those inputs to enable proactive actions~~, such as live translation or song recognition~~. ~~Currently, most context-aware intelligence experiences are implemented through Alphabet's Android System Intelligence component.~~

Draft — Final ¶ 31

As described in Section 12.4.5 of the Decision, the context-aware intelligence feature meets the requirements of a restricted feature. Consequently, access to the functionalities referenced below in this section may be limited to Qualified Services.

Draft ¶ 41 Final ¶ 32

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google~~context-aware ~~Android~~intelligence feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services, and in a way that is equally effective as the solution available to Alphabet's services.

Draft ¶ 42 Final ¶ 33

These functionalities are: (a) Access to inputs: (1) Access to the user's physical context, as used by or available to Alphabet's services. This includes ambient data, ~~i.e. data from device sensors, which includes but is not limited~~such ~~to,~~as data from the camera, microphone, accelerometer, proximity sensor, GPS, and any other location signals (see Section 2.3 of the Annex); (2) Access to the user's digital context, as used by or available to Alphabet's services. This includes, but is not limited to, device audio, screen contents and context, screenshots, ~~data~~relevant ofinformation on the foreground app, notifications, app launches, contacts, shortcuts, SMS, and app package details.; (3) The ability to retrieve data ~~from~~provided ad hoc by an app, service, or the OS to the proactive suggestion or intelligent experience, ~~which~~as ~~may~~used ~~include~~by ~~retrieving~~or ~~the~~available ~~data~~to ~~from~~Alphabet's ~~the~~services; ~~cloud.~~and (4) Global access to apps' data and actions stored on-device, ~~including data from Alphabet apps, OEM apps, and third-party~~that apps, ~~as donated~~choose byto ~~apps~~donate, including ~~but not limited to,~~ through an on-device database or data sharing platforms allowing for centralised data access and sharing, as used by or available to Alphabet's services (see Section 2.1 of the Annex). (b) Access to processing resources: (1) Ability to use an on-device ~~model~~models to process the input data and generate the outputs, both those already present on the device ~~and those selected~~(see ~~and~~Section ~~brought~~4.1 byof the ~~service, with~~Annex) ~~the~~and ~~same~~those ~~level~~implemented ofby ~~model~~third ~~availability~~parties (~~in particular if already present),~~see ~~hardware~~Section ~~access~~4.2 ~~and~~of ~~background~~the ~~execution~~Annex). (~~in particular selected~~2) ~~and~~Ability ~~brought~~to byuse ~~the~~communication ~~service)~~channels asto ~~Alphabet's~~send ~~services.~~and ~~(2)~~receive ~~Ability~~data to ~~use~~the solution's cloud-based models to process the input data and generate the outputs, ~~and to use communication channels to receive and~~in ~~send~~accordance ~~such~~with ~~data.~~paragraph (335) ~~Ability to access and write to dedicated and shared storage and databases.~~ (4i) ~~Ability to access low-power processors and~~of the ~~runtime environments thereof~~Annex, ~~allowing~~and toas ~~process~~used ~~data,~~by ~~such~~or asavailable ~~ambient~~to ~~data,~~Alphabet's ~~efficiently.~~services; (53) Ability to use protected execution environments allowing to process particularly sensitive data, such as ambient data, in isolation~~. (c) Access to output~~, ~~channels~~in ~~and~~support ~~display~~of ~~surfaces:~~paragraph (135) ~~The ability to~~(i) ~~discover~~of the ~~channels~~Annex, and ~~surfaces that are available for~~as ~~proactive~~used ~~suggestions~~by or ~~intelligent experiences and be aware of newly~~ available ~~channels~~to ~~and~~Alphabet's ~~surfaces~~services. (2c) ~~The ability~~Access to ~~decide on the most relevant channel or surface, including through accessing the properties of~~output channels and ~~surfaces (e.g. their size or~~display ~~location).~~surfaces: (31) ~~The ability~~Ability to present proactive suggestions or intelligent experiences on a surface visible and/or audible to the user in the UIuser interface, mediated by the OS~~. Such surfaces can take many forms. For instance~~, ~~such surfaces may appear inside Alphabet's apps and third parties' apps,~~ as ~~part of system interfaces (e.g. lock screen or notifications), as~~used ~~"chips"~~by or ~~small insets in keyboards, as a~~available ~~screen~~to ~~overlay,~~Alphabet's ~~etc.~~services; (42) ~~The ability~~Ability to transmit data from ~~the~~a proactive suggestion or intelligent experience to an app, service, or the OS, ~~which may~~as ~~include~~used ~~transmitting~~by ~~the~~or ~~data~~available to ~~the~~Alphabet's ~~cloud.~~services; and (53) ~~The ability~~Ability to trigger integrations and interactions with apps and the OS from the proactive suggestion or intelligent experience, such as redirecting to another app, opening an app in an overlay, or deep linking to parts of the OS such as settings.

Draft ¶ 43 Final ¶ 34

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the context-aware intelligence feature ~~referred to in paragraph (40)~~.

Draft ¶ 44 Final ¶ 35

To provide third parties with an interoperability solution for the context-aware intelligence feature ~~referred to in paragraph (40)~~ that is equally effective as that available to any of Alphabet's services, ~~Alphabet shall implement~~ the following measures shall apply: (a) Alphabet shall ~~offer~~enable access to device sensors, outputs, and data as specified under paragraph (4233)(a) of the Annex on a continuous basis and in the background, as are used by or available to Alphabet's services.; (b) Alphabet shall grant access to device sensors, outputs, and data as specified under paragraph (4233)(a) of the Annex with the same degree of granularity, frequency, and recency, as are used by or available to Alphabet's services.; (c) Alphabet shall allow third parties tooffering ~~design~~proactive suggestions and intelligent experiences to tailor the surfacing experience, when accessing display surfaces as specified under paragraph (4233)(c) of the Annex, for instance in terms of including the branding, icon, or link tofor the apps the surfaced information has been sourced from., or in terms of contributing to surfacing decisions such as which surface to use, and as used by or available to Alphabet's services; (d) Alphabet shall ~~offer~~enable access to ~~inputs~~digital context, as specified under paragraph (4233)(a)(2) of the Annex, todata ~~processing~~provided ~~resources~~ad hoc, as specified under paragraph (4233)(ba)(3) of the Annex, apps' data and actions stored on-device, as specified under paragraph (33)(a)(4) of the Annex, of Alphabet's first-party apps, as used by or available to ~~output~~Alphabet's ~~channels~~services; ~~and~~(e) ~~display~~Alphabet shall enable access to surfaces in/on Alphabet's first-party apps, as specified under paragraph (4233)(c)(1) of the Annex, on a non-discriminatory basis between Alphabet and third parties offering proactive suggestions and intelligent experiences; (f) Alphabet may enable apps to opt out of the ability for components offering proactive suggestions and intelligent experiences to access that app's digital context and/or to appear in a surface in/on that app, either for the whole app or for specific parts of the app, where that opt-out applies to all such components on a non-discriminatory basis between Alphabet's own services and third-party services. (g) Alphabet shall enable concurrent use of the context-aware intelligence feature, inwithin ~~particular~~the ~~when~~technical ~~access~~capabilities ~~cannot~~of bethe ~~provided~~inputs, ~~concurrently~~resources, and outputs. Where such concurrent use is not possible or is limited, Alphabet shall enable the use of the context-aware intelligence feature on a non-discriminatory basis between Alphabet's own services and third-party services; (eh) Alphabet shall not be required to enable the replacement of existing intelligence components, such as Android System Intelligence; and (i) Alphabet may implement ~~technical~~ measures requiring that, when accessing inputs as specified under paragraph (4233)(a) of the Annex, processing resources as specified under paragraph (4233)(b) of the Annex, and output channels and display surfaces as specified under paragraph (4233)(c) of the Annex, third parties must do so in line with principles of process isolation, encryption, anonymous and aggregated telemetry, and user control and awareness, insofar as this is based on transparent, objective, precise, and non-discriminatory conditions that also apply to Alphabet's services ~~and hardware~~.

Draft ¶ 45 Final ¶ 36

Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the context-aware intelligence feature insofar as they are available to Alphabet's services. For the avoidance of doubt, such future updates of the context-aware intelligence feature include any updates concerning: (a) Additional inputs, processing resources, or output channels and display surfaces. (b) Further integration with cloud-based AI services and AI assistants that contribute data to and retrieve data from the user's context.

Draft ¶ 46 Final ¶ 37

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 47 Final ¶ 38

Alphabet shall implement the measures for the context-aware intelligence feature in the ~~release~~next ofmajor Android ~~17 QPR2 and~~release, ini.e. ~~any~~Android ~~case~~18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027
Final deadline: Android 18 / 1 August 2027

Not designated a Restricted feature — ambient data remains open to all third parties under the general §5.4 rules (subject to the general integrity/consent conditions).

Mostly faithful restatement. Two points worth flagging:

Comparator narrows from "Alphabet's services" to "Alphabet's AI-powered services" throughout (final paras 41, 43, 44) — the same pattern seen in §2.1 and §2.2.
Addition: final (44)(d) is new: "Where Alphabet's AI-powered services rely on dedicated apps, running on runtime environments for low-power processors, to access ambient data, Alphabet shall provide third parties with access to those dedicated apps" — a concrete technical guarantee not present in the draft.

Deadline: 1 January 2027 → 1 August 2027 (Android 18), consistent with the document-wide pattern.

Compare provision wording

View

Draft ¶ 48 Final ¶ 39

Alphabet shall provide effective interoperability with the access to ambient data feature.

Draft ¶ 49 Final ¶ 40

The access to ambient data feature is described in Section 9.54.2 of the ~~Preliminary Findings~~Decision. Access to ambient data ~~provides access~~consists toof the ~~continuous~~ability ~~stream~~to ofaccess ~~real-time~~data ~~inputs/outputs~~produced ~~from~~or collected via a device's core sensors ~~for~~and ~~example~~data ~~microphone,~~presented ~~camera,~~via ~~screen,~~the ~~speakers~~device's main output channels. The access enables AI services to deliver personalised, context-aware experiences such as sound detection, live screen guidance, or object recognition ~~by processing raw sensor data~~.

Draft ¶ 50 Final ¶ 41

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google Android feature (as described~~access into ~~the~~ambient ~~preceding~~data ~~paragraph)~~feature and ~~all~~ its functionalities, as available to Alphabet's AI-powered services and in a way that is equally effective as the solution available to Alphabet's AI-powered services.

Draft ¶ 51 Final ¶ 42

These functionalities are: (a) the ability to ~~continuously collect and process~~access the ~~same real-time inputs as well as outputs from a device's core~~microphone ~~sensors~~input, ~~as are available to Alphabet's services including in particular:~~ (ab) the ~~microphone~~ability ~~input,~~to ~~(b)~~access speaker output (system audio), (c) the ability to access the camera, (d) the ability to access the screen contents, (e) the ability to access location data, and (f) the ability to access environmental sensors such as the accelerometer or proximity sensor.

Draft ¶ 52 Final ¶ 43

Alphabet shall grant third parties access to additional functionalities available to Alphabet's AI-powered services if necessary to enable effective interoperability with the access to ambient data feature ~~as referred to in paragraph (49)~~.

Draft ¶ 53 Final ¶ 44

To provide third parties with an interoperability solution for the access to ambient data ~~referred to in paragraph (49)~~feature that is equally effective as that available to any of Alphabet's AI-powered services, the following measures shall apply.: (a) Alphabet shall provide access to ~~the same~~ambient data under ~~equally effective~~equal conditions as ~~available~~those that apply to Alphabet's AI-powered services, including in terms of continuous availability, quality, frequency, latency, and availability in the background., and any other technical characteristics necessary to enable equivalence in collection, transmission, access to, and processing of such data; (b) Alphabet shall provide access under equivalent consent flows asand ~~for~~indicators that apply to Alphabet's AI-powered services, including in terms of frequency. of prompts, and in terms of the level of continuous availability, availability in the background, and the mechanism of processing; (c) Alphabet shall allow third~~-party~~ ~~apps~~parties to access ambient data related to Alphabet's applications (such as screen content), whenever such functionality is enabled for Alphabet's AI-powered services; (d) Where Alphabet's AI-powered services rely on dedicated apps, ~~such~~running ason ~~Gemini.~~runtime environments for low-power processors, to access ambient data, Alphabet shall provide third parties with access to those dedicated apps; and (de) Alphabet may implement ~~technical~~ measures requiring that, when accessing ambient data, third parties must do so in line with principles of process isolation, encryption, anonymous and aggregated telemetry, and user control and awareness, insofar as this is based on transparent, objective, precise, and non-discriminatory conditions which also apply to Alphabet's ~~services and~~AI-powered ~~hardware~~services.

Draft ¶ 54 Final ¶ 45

Alphabet shall also provide effective interoperability with any future updates, including new functionalities, of the access to ambient data insofar as they are available to Alphabet's ~~own~~AI-powered services or hardware.

Draft ¶ 55 Final ¶ 46

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 56 Final ¶ 47

Alphabet shall implement the measures for the access to ambient data feature in the next major Android release, i.e. Android 18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027
Final deadline: Android 18 / 1 August 2027

Final paragraph 50 makes only the App Functions implementation of structured on-device integration potentially subject to the Restricted Features framework. Paragraph 55 then guarantees Qualified Services enumerated actions in eight named first-party apps. That list is closed as to this specific guarantee, but it is not an exhaustive ceiling on all of §3.1: paragraphs 51, 53, 54 and 57 preserve general parity, additional-functionality, all-channel and future-update duties.

The draft's standalone general read/write feature in §3.3 is not preserved as such, and the feature-specific documentation clause in draft paragraph 62(d) disappears, although final §5.7 retains cross-cutting documentation and API duties. Certification is not absolute: paragraph 135 supplies a per-service, per-device end-user opt-out and paragraph 137 applies the relevant processes to services that are not AI assistants. The deadline moves to 1 August 2027 (Android 18).

Compare provision wording

View

Draft ¶ 57 Final ¶ 48

Alphabet shall provide effective interoperability with the structured on-device integration feature.

Draft ¶ 58 Final ¶ 49

The structured on-device integration feature is described in Section 10.2.2 of the ~~Preliminary Findings~~Decision. This feature enables, anin AIresponse to a user request, a service to take actions ~~inside~~on other apps on the device ~~in response to a user's~~. ~~request~~This ~~and~~feature is currently implemented through on-device integration channels, such as App Actions and App Functions.

Draft — Final ¶ 50

As described in Section 12.4.5 of the Decision, the structured on-device integration feature includes an implementation, namely App Functions, that meets the requirements of a restricted feature. Consequently, insofar as the functionalities referenced below in this section pertain to this implementation, access to the functionalities may be limited to Qualified Services.

Draft ¶ 59 Final ¶ 51

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same~~structured ~~Google~~on-device ~~Android~~integration feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services and in a way that is equally effective as the solution available to Alphabet's services.

Draft ¶ 60 Final ¶ 52

These functionalities are: (a) The ability ~~for apps~~ to discover all available structured on-device integrations, including metadata necessary to determine which actions to trigger.; (b) The ability ~~for apps~~ to execute structured on-device integrations.; (c) The ability to let the user be aware of and observe that a structured on-device integration is being executed.; and (d) The ability to execute the structured on-device integration within the app, i.e. without app switching (unless that is the intent of the structured on-device integration).

Draft ¶ 61 Final ¶ 53

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services, if necessary to enable effective interoperability with the structured on-device integration feature ~~referred to in paragraph (58)~~.

Draft ¶ 62 Final ¶ 54

~~The~~To provide third parties with an interoperability solution for the structured on-device integration feature ~~referred to in paragraph (58) must~~that beis equally effective as that available to any of Alphabet's ~~own~~ services~~. To that end~~, ~~Alphabet shall implement~~ the following measures shall apply: (a) Alphabet shall make available to third parties all channels of structured on-device integration ~~to third parties~~, including App Actions and App Functions, in a manner that is equally effective as that available to ~~any of~~ Alphabet's own services.; (b) Alphabet shall enable third~~-party~~ ~~apps~~parties to discover all structured on-device integrations exposed by apps that are installed on the user's device, including a mechanism that ensures third~~-party~~ ~~apps~~parties can retrieve all metadata necessary to determine which actions to trigger.; and (c) Alphabet shall enable third~~-party~~ ~~apps~~parties to execute all structured on-device integrations exposed by other apps, including ~~apps of other~~ third~~-party~~ ~~developers, OEM apps~~parties, system apps, and Alphabet apps. (d) Alphabet shall make public the documentation necessary for third parties to access, integrate and execute structured on-device integration. This requirement captures documentation regarding how a third party can execute an App Action using the information provided through the new discovery mechanism described in paragraph (62)(a).

Draft — Final ¶ 55

Through the structured on-device integration feature, Alphabet shall enable Qualified Services to execute specific functionalities in the relevant Alphabet's first-party apps. The relevant Alphabet apps and functionalities are as follows: (1) Gmail: Retrieve and return relevant emails and draft, edit, and reply to emails; (2) Google Calendar: The ability to retrieve information about events and to create and manage events; (3) Google Drive: The ability to retrieve relevant information from files and return information about their content; (4) Google Docs: The ability to retrieve relevant information from files and return information about their content; (5) Google Maps: The ability to trigger navigation to a general public place in Google Maps or to the end user's designated home or work address, or to other labelled places, and the ability to control the navigation; (6) YouTube: The ability to play a video in YouTube, the ability to control the video playback, and the ability to answer user queries regarding recent watch history activity; (7) Messages: The ability to retrieve relevant information from SMS, MMS, and RCS messages in the user's Android app and write SMS, MMS, and RCS messages; and (8) Phone: The ability to initiate phone calls.

Draft — Final ¶ 56

For the functionalities in the previous paragraph, Alphabet shall ensure that third parties can use the functionalities as effectively as Alphabet's services, including in terms of scope of the data and in terms of supported use cases, such as semantic search and similar use cases that enable contextual interaction between the user and the service using natural language.

Draft ¶ 63 Final ¶ 57

Alphabet shall ~~also~~ provide effective interoperability with any future updates, including new functionalities, of the structured on-device integration feature insofar as they are available to Alphabet's own services or hardware.

Draft ¶ 64 Final ¶ 58

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 65 Final ¶ 59

Alphabet shall implement the measures for the structured on-device integration feature in the next major Android release, i.e. Android 18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027
Final deadline: Android 18 / 1 August 2027

New gate: final para (62): "the screen automation feature, as implemented in Computer Control, meets the requirements of a restricted feature. Consequently, access to the functionalities ... may be limited to Qualified Services." No equivalent existed in the draft.

The nine functionalities (draft (69)(a)-(i) / final (64)(a)-(i)) are preserved almost verbatim. Several measures, however, are consolidated or dropped as freestanding obligations:

Draft (71)(c): "Alphabet shall enable third-party apps to imitate the same user interactions that are available to Alphabet ... including, but not limited to, the interactions available to Computer Control API" — this explicit API-parity guarantee does not reappear as a discrete measure in final (66); it is left to be inferred from the general equal-effectiveness principle.
Draft (71)(f): the explicit duty to let the user "observe and intervene if the controlling app is misbehaving or not able to achieve the ask" is not restated as a standalone measure (functionality (64)(e) preserves the ability to "stop" the controlling app, but not the "misbehaving" intervention framing).

New carve-out: final (66)(c) is new: "Alphabet may enable any third party to restrict automation of their app for certain parts of the app, insofar as it applies across all services that use the screen automation feature" — an app-level opt-out from automation for specific UI regions.

Deadline: 1 January 2027 → 1 August 2027 (Android 18).

Compare provision wording

View

Draft ¶ 66 Final ¶ 60

Alphabet shall provide effective interoperability with the screen automation feature.

Draft ¶ 67 Final ¶ 61

The ~~agent-controlled~~screen ~~interactions~~automation feature is described in Section 10.3.2 of the ~~Preliminary Findings~~Decision. The feature enables ~~Alphabet's services, including~~ Gemini, to take control of other apps on the Android mobile device to automate multi-step tasks on behalf of the user. Gemini can imitate user behaviour and observe the controlled app's screen to automate the user interface and to perform most tasks a user would be able to do. Gemini ~~will run~~controls the ~~controlled~~ app in a separate virtual window, allowing the assistant to complete the task in the background, while the user can do something else.

Draft — Final ¶ 62

As described in Section 12.4.5 of the Decision, the screen automation feature, as implemented in Computer Control, meets the requirements of a restricted feature. Consequently, access to the functionalities referenced below in this section may be limited to Qualified Services.

Draft ¶ 68 Final ¶ 63

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google~~screen ~~Android~~automation feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services and in a way that is equally effective as the solution available to Alphabet's services, such as Gemini.

Draft ¶ 69 Final ¶ 64

These functionalities are: (a) ~~Take~~Taking control over apps. Ability for an app (controlling app) to take over control of other apps (controlled apps) including those of third parties, the OEM, and Alphabet. The controlling app can perform interactions with the controlled apps by imitating user interactions, such as taps, clicks, and typing.; (b) ~~Access~~Accessing tothe on -screen content. Ability for anthe AIcontrolling ~~service~~app to access the screen content of the controlled app to understand its ~~UI, allowing the AI service to control the~~user ~~app.~~interface; (c) ~~Discovery of~~Discovering apps. Ability for anthe AIcontrolling ~~service~~app to determine which apps are installed on the device and retrieve ~~metadata that may be~~ relevant information to decide which app to automate.; (d) ~~Control~~Controlling apps in background. Ability for ana AIcontrolling ~~service~~app to fully ~~execute~~ control of other apps in background. The process of controlling apps is not visible to the user. byThe ~~default~~controlled ~~and~~app ~~can~~will be ~~fully~~run ~~executed~~on ina virtual display to enable background execution. The controlling app can complete the task while the user uses the phone otherwise or decides not to use their phone; (e) User observation. Ability for the user to surface the controlled app and observe the AIcontrolling ~~service~~app ~~controlling~~interacting with it. In addition, the user can stop the ~~AI service from~~ controlling ~~or take~~app ~~over~~from ~~control~~interacting ~~from~~with the AIcontrolled ~~service.~~app; (f) Seamless transition. Ability to transition ~~seamless~~seamlessly between background and foreground when the user chooses to observe the controlled app ~~or the AI service, surfaces the app to the user for required input, the transition between background and foreground is seamless.~~; (g) OS indicators. Ability for OS indicators to demonstrate to the user ~~that an~~a AIcontrolling ~~service~~app is currently ~~controlling~~interacting with another app.; (h) Concurrency management. Ability for ~~the~~ Google Android OS to manage concurrent access, including scheduling or preventing multiple accesses. This can include user-facing mechanisms, such as greying out the app icon of the controlled app so that the user cannot use the same app at the same time as the controlling app.; and (i) Blocking sensitive areas. Ability for controlled apps to block sensitive views from access of the controlling app. This functionality allows apps to protect sensitive user data, critical settings, or purchase decisions from being automated by the controlling app.

Draft ¶ 70 Final ¶ 65

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the screen automation feature ~~referred to in paragraph (67)~~.

Draft ¶ 71 Final ¶ 66

~~The~~To provide third parties with an interoperability solution for the screen automation feature ~~referred to in paragraph (67) must~~that beis equally effective as that available to ~~any of~~ Alphabet's ~~own~~ services~~. To that end~~, ~~Alphabet~~such ~~shall~~as ~~implement~~Gemini, the following measures. ~~(a) Alphabet~~ shall enable third-party apps to take control of other apps, including apps of other third-party developers, OEM apps, system apps, and Alphabet's apps. Developers must be allowed to perform interactions with the apps by imitating user behaviour.apply: (ba) Alphabet shall enable ~~third-party apps~~ to discover all apps that are installed on the user's device. Alphabet shall ensure that third~~-party~~ ~~apps~~parties can retrieve ~~metadata that is~~ relevant information to decide which app to automate~~, including but not limited to app name, the package name, and the app developer's name.~~; (cb) Alphabet shall enable ~~third-party~~multiple apps to ~~imitate the same user interactions that are available to Alphabet. This includes, but is not limited to,~~have the ~~interactions available~~capability to ~~Computer Control API. (d) Alphabet~~take ~~shall~~control ~~enable~~over ~~third-party~~other apps ~~to access the screen content of the controlled app~~. ~~(e)~~ Alphabet shall ~~enable third-party apps to control other~~not ~~apps~~limit ~~using~~this ~~imitated~~capability ~~user~~to ~~interactions~~one insingle ~~the~~app ~~background~~such onas a ~~virtual display. The controlling~~default app ~~can complete the task, while the user can use their phone~~; ~~otherwise.~~and (fc) Alphabet ~~shall~~may enable any third~~-party~~ ~~apps~~party to ~~mirror or otherwise present the ongoing~~restrict ~~interactions~~automation of their app ~~to the user. Alphabet shall enable the user to observe and intervene if the controlling app is misbehaving or not able to achieve the ask. (g) Alphabet shall ensure that the transition between~~for ~~the~~certain ~~observation~~parts of the ~~controlled~~ app ~~and controlling the app in background should be~~, ~~seamless.~~insofar ~~(h)~~as ~~Alphabet~~it ~~shall~~applies ~~enable~~across ~~multiple~~all ~~apps~~services tothat ~~have~~use the ~~capability to take control over other apps. Alphabet shall not limit this capability to one single app such as a~~screen ~~default~~automation ~~app~~feature.

Draft ¶ 72 Final ¶ 67

Alphabet shall ~~also~~ provide effective interoperability with any future updates, including new functionalities, of the screen automation feature insofar as they are available to Alphabet's own services or hardware.

Draft ¶ 73 Final ¶ 68

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 74 Final ¶ 69

Alphabet shall implement the measures for the screen automation feature in the next major Android release, i.e. Android 18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027 (read) / 1 June 2027 (write)
Final deadline: No standalone section; related duties: Android 18 / by 1 August 2027

Draft §3.3 supplied a standalone, generally framed read/write-access feature. It disappears as a section. Final paragraph 55 instead guarantees specified actions in eight named first-party apps to Qualified Services, and Google Keep is not listed. Paragraph 56 expressly preserves uses such as semantic search.

The enumerated app guarantee is narrower than the deleted standalone provision, but it does not exhaust the final structured-integration obligation: final paragraphs 51, 53, 54 and 57 retain general parity, additional-functionality, all-channel and future-update duties. Nor is certification an absolute access condition, because paragraphs 135 and 137 provide an end-user opt-out and a route for services that are not AI assistants.

The related final structured-integration duties are due with Android 18 and by 1 August 2027, later than both the draft read deadline of 1 January 2027 and write deadline of 1 June 2027.

Compare provision wording

View

Draft ¶ 75 Final —

~~Alphabet shall provide effective interoperability with the read and write access feature for integration with first-party services.~~

Draft ¶ 76 Final —

The read and write access features are described in Section 10.4.2 of the Preliminary Findings. The read access feature allows a service to retrieve information from another service, which can be displayed to the user as-is or after processing. The write access feature allows a service to perform operations in another service that modifies the data held in that service and execute actions with it.

Draft ¶ 77 Final —

Draft ¶ 78 Final —

These functionalities are: (a) Semantic search. The read access feature can be used to search for and retrieve information in a way that understands, on one hand, the user's intent and, on the other hand, the contextual meaning of terms and concepts in the dataset where the information is searched. For example, a user can ask an AI assistant "When is my trip to Spain?" and the AI assistant will be able to find the calendar event with title "Flight to Barcelona", which contains neither "trip" nor "Spain". (b) Creating and editing user data. The most prominent functionality of the write access feature is the ability to create and edit user data. For example, Gemini assistant can create and edit notes in Google Keep. (c) Sending data to other users. The write access feature can be used to allow the user send or share content with other users. For example, Gemini assistant can send emails and SMS/RCS messages on behalf of the user. (d) Changing state and settings. The read and write access can be used to control another service and to change its settings. For example, users can invoke Gemini assistant when watching a YouTube video to pause or play the video. They can also invoke Gemini assistant while navigating in Google Maps to retrieve information about the estimated time of arrival without looking at the screen (read access) or modify the final destination (write access). (e) Interactive access. Both read access and write access can happen through an interactive mechanism, such as interactive interfaces. For example, the user can ask Gemini assistant to find Italian restaurants nearby. Gemini assistant will then use the read access feature to retrieve the information from the Google Maps online services and provide the user with an "interactive card" that provides an interactive map and list of restaurants.

Draft ¶ 79 Final —

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the read and write access features referred to in paragraph (76).

Draft ¶ 80 Final —

To provide third parties with an interoperability solution for the read and write access features referred to in paragraph (76) that is equally effective as that available to any of Alphabet's own AI assistants, Alphabet shall implement the following measures: (a) Read access: Alphabet shall allow third parties to access, find, and process data from Alphabet's services provided together with, or in support of, Google Android – in a way that is equally effective to what is available to Alphabet's services, such as Gemini assistant. (b) Write access: Alphabet shall allow third parties to perform operations that modify the data held in services that are provided together with, or in support of, Google Android and execute actions within such services – in a way that is equally effective to what is available to Alphabet's services, such as Gemini assistant. (c) For all measures above, Alphabet may require user consent, compatibly with the measures specified in Section 5 of this Annex, and particularly in Section 5.2. (d) In cases where it is not technically feasible to provide access immediately, Alphabet shall provide access without undue delay, following a transparent and non-discriminatory process that includes clear deadlines for Alphabet and third parties.

Draft ¶ 81 Final —

~~All the measures above should apply regardless of whether the relevant features are part of Google Android, and in particular regardless of whether they rely on server-based integrations.~~

Draft ¶ 82 Final —

Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the read and write access features insofar as they are available to Alphabet's own AI assistant services.

Draft ¶ 83 Final —

~~Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.~~

Draft ¶ 84 Final —

~~Alphabet shall implement the measures for the read access functionality by 1 January 2027, and the measures for the write functionality by 1 June 2027.~~

Draft deadline: 1 January 2027
Final deadline: Android 18 / 1 August 2027

Partial new gate: final para (72): "certain functionalities of the system integration feature, if implemented via App Functions, would meet the requirements of a restricted feature. Consequently, insofar as the functionalities ... are made available through this implementation, access ... may be limited to Qualified Services."

Dropped anti-discrimination guarantee — and it is dropped at the same time a certification gate is introduced for the same feature. Draft (90)(b)-(d) provided:

"Alphabet shall not restrict third-party apps to access the App Functions for the system integration feature. ... Alphabet shall ensure that third-party apps have the same capabilities for system integration that are available to Alphabet's services. Alphabet shall ensure that third-party apps are not subject to access restrictions that require preinstallation, privileged permissions, or any other OEM controlled access restriction."None of this text survives in final §3.3. The explicit ban on preinstallation/privileged-permission/OEM gating for App-Functions-based system integration is gone in the very same section where the final introduces its own privileged, certification-based access gate (Qualified Services) for that same App-Functions channel.

Also dropped: draft (90)(c)'s specific metadata guarantee — "Alphabet shall make available metadata on installed apps to third-party apps, including but not limited to the app name, the package name, and the app developer's name" — is not restated in final (76)(a), which only preserves the general discovery duty.

Deadline: 1 January 2027 → 1 August 2027 (Android 18).

Compare provision wording

View

Draft ¶ 85 Final ¶ 70

Alphabet shall provide effective interoperability with the system integration feature.

Draft ¶ 86 Final ¶ 71

The system integration feature is described in Section 10.54.2 of the ~~Preliminary Findings~~Decision. The feature enables Alphabet's services, ~~including~~such as Gemini, to interact and integrate with the operating system on behalf of the user. The user may request the assistant amongst other things to change a specific setting, control media playback, or open an app.

Draft — Final ¶ 72

As described in Section 12.4.5 of the Decision, certain functionalities of the system integration feature, if implemented via App Functions, would meet the requirements of a restricted feature. Consequently, insofar as the functionalities referenced below in this section are made available through this implementation, access to the functionalities may be limited to Qualified Services.

Draft ¶ 87 Final ¶ 73

Alphabet shall implement an interoperability solution that provides third parties with access to ~~the same Google Android feature (as~~and ~~described~~interoperability inwith the ~~preceding~~system ~~paragraph)~~integration ~~and~~feature ~~all~~and its functionalities, as available to Alphabet's services and in a way that is equally effective as the solution available to Alphabet's services, such as Gemini.

Draft ¶ 88 Final ¶ 74

These functionalities are: (a) Ability to interact with Google Android OS settings. These settings include turning on/off Bluetooth, turning on/off battery saver mode, turning on/off do not disturb, reading the current battery level.; (b) Ability to interact with ongoing activities on the Google Android mobile device. These activities include controlling playing media and volume.; (c) Ability to interact with Google Android OS-level functionalities. These functionalities include restarting the device, turning the device off, taking screenshots, and integrate with notifications.; and (d) Ability to integrate with common functionalities of Google Android. These functionalities include setting timers, managing alarms, integrate with text messaging functionalities.

Draft ¶ 89 Final ¶ 75

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the system integration feature ~~referred to in paragraph (86)~~.

Draft ¶ 90 Final ¶ 76

~~Alphabet shall implement an interoperability solution that~~To ~~provides~~provide third parties with ~~access to the same Google Android feature as available to Alphabet (as~~an ~~described~~interoperability insolution ~~paragraph~~for ~~(86)~~the insystem aintegration ~~way~~feature that is equally effective as ~~the solution~~that available to ~~Alphabet. To that~~Alphabet's ~~end~~services, ~~Alphabet~~such ~~shall~~as ~~implement~~Gemini, the following measures: ~~(a) Alphabet~~ shall implement interoperability for system integration through App Functions that contain all functionalities for system integration. (b) Alphabet shall not restrict third-party apps to access the App Functions for the system integration feature.apply: (ca) Alphabet shall enable ~~third-party apps~~the todiscovery ~~discover~~of all apps that are installed on the user's device, and to understand user queries that demand to open specific apps.; (b) Alphabet shall make available ~~metadata on~~the ~~installed~~information ~~apps~~necessary to ~~third-party~~open ~~apps,~~specific ~~including~~apps ~~but~~as ~~not~~are ~~limited~~available to ~~the app~~Alphabet ~~name~~services, ~~the~~such ~~package~~as ~~name,~~Gemini; and ~~the app developer's name.~~ (dc) Alphabet shall ensure that ~~third-party apps have the same capabilities for~~all system ~~integration that~~integrations are ~~available to Alphabet's~~made ~~services.~~available ~~Alphabet~~in ~~shall~~the ~~ensure~~same ~~that~~manner ~~third-party~~as ~~apps~~they are ~~not subject~~available to ~~access restrictions that require preinstallation, privileged~~Alphabet's ~~permissions~~services, ~~or any other OEM controlled~~such ~~access~~as ~~restriction~~Gemini. ~~(e)~~In ~~Alphabet~~particular, ~~shall~~the ~~ensure~~user ~~that~~should ~~all~~be ~~system~~able ~~integrations,~~to ~~including~~execute the ~~changing of settings, must~~integrated befunctionalities directly ~~done~~ inside the third-party ~~app~~service, rather than ~~requiring~~be ~~switching~~required ~~the~~to ~~user~~switch to the settings app or another app~~. This applies~~, to ~~all~~the ~~capabilities~~extent ~~that~~this ~~are~~capability is available to Alphabet's services, ~~for~~such ~~direct~~as ~~change~~Gemini.

Draft ¶ 91 Final ¶ 77

Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the system integration feature insofar as they are available to Alphabet's own services or hardware.

Draft ¶ 92 Final ¶ 78

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 93 Final ¶ 79

Alphabet shall implement the measures for the system integration feature in the next major Android release, i.e. Android 18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027
Final deadline: Android 18 / 1 August 2027

Final paragraph 81 narrows the definition of system-level ODMs to Gemini Nano and models implemented through AICore or a successor or similar software, rather than the draft's broader reference to on-device models forming part of Google Android and exposed to Alphabet services outside the OS. Paragraph 86 newly excludes functionalities available only to internal operating-system components.

The carve-out is textual. A risk that Alphabet might classify functionality strategically is an analytical concern, not a unilateral legal power conferred by the words; any classification remains subject to Commission interpretation and enforcement. The low-rank-adaptation example disappears but the general customisation duty remains, and two "should" formulations become "shall". The deadline moves to 1 August 2027 (Android 18).

Compare provision wording

View

Draft ¶ 94 Final ¶ 80

Alphabet shall provide effective interoperability with the system-level on-device models (ODM) feature.

Draft ¶ 95 Final ¶ 81

The system-level ODM feature is described in Section 11.2.2 of the ~~Preliminary Findings~~Decision. The system-level ODM feature ~~allows~~covers ~~Alphabet~~the toGemini ~~discover,~~Nano ~~access,~~model ~~use~~family, ~~and~~including ~~customise~~its ~~all~~variants ~~on-devices~~and ~~models~~any ~~that~~successor ~~are~~models ~~part~~performing ofa ~~Google~~similar ~~Android~~role (including Gemma ODMs), and any other ODMs implemented via AICore or a successor or software performing a similar role to AICore on Google Android ~~middleware)~~mobile ~~and~~devices ~~that~~("system-level ~~are~~ODMs"). ~~made~~The ~~accessible~~feature allows Alphabet to ~~Alphabet's~~discover, ~~services~~access, ~~outside~~use ~~the~~and ~~operating~~customise the system-level ODMs.

Draft ¶ 96 Final ¶ 82

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google~~system-level ~~Android~~ODM feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services and in a way that is equally effective as the solution available to Alphabet's services.

Draft ¶ 97 Final ¶ 83

These functionalities are: (a) Discovery of ~~all~~ system-level ODMs. The ability to discover system ~~system~~-level ODMs.; (b) Access to ~~all~~ system-level ODMs. The ability to ~~all~~ access and use system-level ODMs and all their functionalities, including specialized APIs for specific tasks.; and (c) Ability to customise functionality. The ability to customise the system-level ODMs, its functionalities, and output~~, including by low rank adaption~~.

Draft ¶ 98 Final ¶ 84

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the system-level ODM feature ~~referred to in paragraph (95)~~.

Draft ¶ 99 Final ¶ 85

To provide third parties with an interoperability solution for the system-level ODM feature ~~referred to in paragraph (95) hat~~that is equally effective as that available to any of Alphabet's services, ~~Alphabet shall~~or ~~implement~~hardware, the following measures shall apply: (a) Access subject to the same restrictions. Alphabet shall allow third-party services or hardware to use the system-level ODMs without restrictions, ~~which~~except dofor ~~not~~those permissible under paragraph (86) and those that equally apply to Alphabet's services and hardware using the system-level ODM feature.; (b) Ability to use functionality for all use cases. Alphabet shall allow third-party services orand hardware to use the system-level ODMs for all use cases, including those that Alphabet supports at the system level.; and (c) Access conditions. Alphabet shall ensure access to the system-level ODM feature for third-party services ~~and hardware~~ according to transparent, objective, precise, and non-discriminatory rules that also apply to Alphabet's services, including for use cases that Alphabet does not offer.

Draft — Final ¶ 86

Alphabet shall not be required to make accessible to third parties functionalities that are available only to internal operating system components.

Draft ¶ 100 Final ¶ 87

Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the system-level ODM feature insofar as they are available to Alphabet's own services or hardware. For the avoidance of doubt, such future updates of the system-level ODM feature include any updates concerning the: (a) The ~~inclusion~~implementation of new system-level on-device models in AICore or a successor or similar Alphabet solution to AICore, such as those related to image or video creation.; and (b) Updates to existing system-level ODMs such as ~~the~~ Gemini Nano ODMs on-device models.

Draft ¶ 101 Final ¶ 88

Alphabet ~~should~~shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 102 Final ¶ 89

Alphabet ~~should~~shall implement the measures for the system-level ODM feature in the next major Android release, i.e. Android 18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027
Final deadline: Android 18 / 1 August 2027

Three explicit pro-competitive obligations are dropped outright, with no substitute:

User right to reassign preferential resource access (dropped). Draft (108)(b): "if Alphabet's own on-device models ... are granted preferential access to hardware resources, it shall allow the user to remove such preferential access from Alphabet's on-device models ... and grant it to third-party on-device models ... Such preferential access may consist in Alphabet's own on-device models ... being granted access to memory resources which are not equally accessible by third-party on-device models." This user-facing remedy for memory/resource self-preferencing has no counterpart in final (95).
API parity for AICore's own system-privileged APIs (dropped). Draft (108)(f): "Alphabet shall allow third-party apps to use the same system-privileged APIs that Alphabet's AICore uses, or APIs that provide equivalent functionalities." Not restated.
Non-discrimination in extending AICore hosting to additional third parties (dropped). Draft (108)(g): "If Alphabet allows any third party, including OEMs, to provide on-device models via AICore, it shall allow other third parties to also provide on-device models via AICore." This anti-cherry-picking guarantee is gone.

The remaining measures (final (95)(a)-(e)) track draft (108)(a),(c),(d),(e) closely, with the comparator consistently narrowed from "Alphabet's own on-device models and software" to the newly defined "AICore ODMs and related software" — the same AICore-channel narrowing seen in §4.1.

New carve-out: final (95)(e) adds "with the exception of functionalities that are available only to internal operating system components" (mirroring the new §4.1 carve-out).

Deadline: 1 January 2027 → 1 August 2027 (Android 18). Not designated a Restricted feature.

Compare provision wording

View

Draft ¶ 103 Final ¶ 90

Alphabet shall provide effective interoperability with the on-device model (ODM) implementation feature.

Draft ¶ 104 Final ¶ 91

The ODM implementation feature is described in Section 11.3.2 of the ~~Preliminary Findings~~Decision. The feature allows Alphabet to install, run and use ~~on-device~~AICore ~~models~~and ODMs implemented via AICore (including Gemini Nano and Gemma ODMs), as well as any future ODMs implemented via AICore or a successor or software toperforming ~~implement~~a ~~such~~similar ~~models~~role to AICore on Google Android mobile devices ("AICore ODMs and related software"). The feature relies on access to hardware resources such as the CPU, GPU, NPU and RAM (including RAM residency), background execution capabilities, and the ability to make functionality of Alphabet's ODMs available to all or some apps running on the device to enable broad adoption.

Draft ¶ 105 Final ¶ 92

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google~~ODM ~~Android~~implementation feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to ~~Alphabet's~~AICore ~~services~~ODMs and related software and in a way that is equally effective as the solution available to ~~Alphabet's services, including its Gemini Nano models, machine learning~~AICore ~~models,~~ODMs and ~~AI Core, as well as any future Alphabet ODMs or~~related software ~~to implement such models~~.

Draft ¶ 106 Final ¶ 93

These functionalities are: (a) Operation of on-device models. The ability to install, run and use on-device models and software to implement such models.; (b) Hardware resources. The ability to timely and reliably access to hardware resources ~~that are necessary~~ to run on-device models or software to implement such models. This includes access to specialised chips to run on-device model tasks, such as the TPU/APU/NPU, access to the Graphics Processing Unit (GPU), the CPU, and ~~access~~ to RAM (incl. RAM residency) and other memory.; (c) Centralised availability. The ability for an app to centrally expose on-device models and software that implements such models to another app, and the ability for the other app to use such models and software. This includes the ability to exchange information between the service implementing the on-device model and the service making use of the on-device model.; and (d) Background execution. The ability to provide and use on-device models or software to implement such models in the background, i.e. when the app hosting the model and the app using the model are not in the foreground.

Draft ¶ 107 Final ¶ 94

Alphabet shall grant third parties access to additional functionalities available to ~~Alphabet's~~AICore ~~services~~ODMs and related software if necessary to enable effective interoperability with the ODM implementation feature ~~described in paragraph (104)~~.

Draft ¶ 108 Final ¶ 95

To provide third parties with an interoperability solution for the on-device model implementation feature that is equally effective as that available to ~~Alphabet's~~AICore ~~services~~ODMs and related software, Alphabet ~~should~~shall implement the following measures shall apply: (a) Alphabet shall allocate hardware resources to ~~its own on-device~~AICore ~~models~~ODMs and ~~software to implement such~~related ~~models~~software and third-party on-device models and software to implement such models according to transparent, objective, precise, and non-discriminatory rules. Alphabet may do this by, for example, implementing an appropriate system-level scheduler that ~~comply~~complies with these requirements. ~~(b) Regardless~~Such ofrules ~~the~~may ~~rules~~distinguish ~~referred~~between tothe ~~under~~use ~~paragraph~~of ~~(108)(a),~~hardware ifresources ~~Alphabet's~~for ~~own~~critical onsystem-~~device~~level ~~models~~functionality and ~~software to implement~~other ~~such~~functionality ~~models~~where ~~are~~appropriate; ~~granted~~(b) ~~preferential~~Alphabet ~~access~~shall toapply ~~hardware~~any ~~resources~~restrictions, ittime ~~shall~~windows, ~~allow~~and ~~the~~resource ~~user~~limitations to(e.g. ~~remove~~on ~~such~~CPU, ~~preferential~~GPU ~~access~~or ~~from~~NPU/APU/NPU ~~Alphabet's~~execution) on~~-device~~ ~~models~~background ~~and~~execution ~~software~~according to ~~implement~~transparent, ~~such~~objective, ~~models~~precise, and ~~grant it to third~~non-~~party~~discriminatory ~~on-device~~rules ~~models~~that ~~and~~also ~~software~~apply to ~~implement such models. Such preferential access may consist in Alphabet's own~~AICore ~~on-device~~ODMs ~~models~~and orrelated software, toincluding ~~implement~~for ~~such~~use ~~models~~cases ~~being~~that ~~granted~~AI ~~access~~Core toODMs ~~memory~~and ~~resources~~related ~~which~~software ~~are~~do not ~~equally accessible by third-party on-device~~support. ~~models~~Such orrules ~~software~~may totake ~~implement~~into ~~such~~account ~~models.~~aspects ~~(c)~~of ~~Alphabet~~system ~~shall~~stability ~~apply~~and ~~any~~device ~~restrictions~~health, ~~time~~such ~~windows,~~as ~~and~~battery ~~resource~~and ~~limitations~~thermal ~~(e.g~~management. ~~on CPU, GPU~~The orrules ~~NPU/APU/NPU~~may ~~execution)~~also ontake ~~background~~into ~~execution~~account ~~according~~the toneed ~~transparent,~~of ~~objective,~~system ~~precise,~~components ~~and~~– ~~non-discriminatory~~both ~~rules~~Alphabet's ~~that~~and ~~also~~OEM's ~~apply~~– to ~~Alphabet's on-device models~~access ~~and~~background ~~software~~execution to ~~implement~~preserve ~~such~~the ~~models,~~internal ~~including~~functioning ~~for~~of ~~use~~the ~~cases~~operating ~~that~~system, ~~Alphabet~~such ~~does~~as ~~not~~system-level ~~offer.~~hardware scheduling; (dc) Any limitation or choice on the background execution capabilities of, or access to hardware resources for third-party on-device models or software to implement such models as a result of a user action shall only be permissible if the user ~~can~~is allowed to take the same action with the same limiting effect regarding ~~Alphabet's on-device~~AICore ~~models~~ODMs and ~~software to implement such~~related ~~models.~~software; (ed) If Alphabet allows OEMs to customise or otherwise ~~changes~~change the level of access to hardware resources or background execution for ~~on-device models or software~~AICore toODMs ~~implement~~and ~~such~~related ~~models~~software, Alphabet shall ensure that such customisation complies with all the measures specified in this Annex. In particular, any such customisations or changes granted to ~~Alphabet's~~AICore ~~on-device~~ODMs ~~models~~and orrelated software ~~to implement such models~~ must also be granted to third-party on-device models or software to implement such models.; and (fe) Alphabet shall allow third-party ~~apps to use the same system~~on-~~privileged~~device ~~APIs~~models ~~that~~and ~~Alphabet's~~software ~~AICore~~to ~~uses,~~implement orsuch ~~APIs~~models ~~that~~access ~~provide~~to ~~equivalent~~the ~~functionalities.~~same ~~(g)~~functionalities Ifto ~~Alphabet~~install, ~~allows~~run ~~any~~and ~~third~~use ~~party,~~them ~~including~~as ~~OEMs,~~available to ~~provide~~AICore ~~on-device~~ODMs ~~models~~and ~~via~~related ~~AICore~~software, itwith ~~shall~~the ~~allow~~exception ~~other~~of ~~third~~functionalities ~~parties~~that toare ~~also~~available ~~provide~~only ~~on-device~~to ~~models~~internal ~~via~~operating ~~AICore~~system components.

Draft ¶ 109 Final ¶ 96

Alphabet ~~should~~shall provide effective interoperability with any future updates, including new functionalities, of the ~~on-device~~ODM ~~model~~implementation feature insofar as they are available to ~~Alphabet's~~AICore ~~own~~ODMs ~~services~~and orrelated ~~hardware~~software.

Draft ¶ 110 Final ¶ 97

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 111 Final ¶ 98

Alphabet shall implement orthe ~~ensure~~measures for the ODM implementation offeature in the ~~measures~~next ~~for~~major ~~the~~Android ~~ODM~~release, ~~implementation~~i.e. ~~feature~~Android 18, and by 1 ~~January~~August 2027 at the latest.

Draft deadline: 1 January 2027 (user-prompt measure) / 1 June 2027 (remaining measures)
Final deadline: Android 18 / 1 August 2027 (all measures, unified)

Interpretive/illustrative content dropped from the functionality definitions (final (102) vs draft (115)):

The concrete "resource allocation" example — an API that "could guarantee that an AI service can synchronise data in the background for at least 10 seconds without showing a visible notification ... or for longer if a notification is shown," and the connected-device/earbud example ("a connected device (e.g. earbuds) maintains a persistent connection ... that allows the user to invoke an app ... using a hotword detected on the connected device"), plus the accompanying point that narrow purpose-built APIs "typically do not enable every use case, for which a more generic way of requesting resource allocation is needed" (draft (115)(b)) — all deleted. The final's functionality (b) is reduced to one generic sentence.
Device-configuration functionality (d) loses its concrete examples ("persistently stored in memory," "exempted from power management mechanisms") and, more importantly, the specific user-choice guarantee: draft (115)(d) explicitly included "the ability for the user to make choices on the level of background execution to a service, including regarding time, place, and cadence, and the presentation and effect of any prompt or user interface for that purpose." Final (102)(d) only says configuration settings may be "configurable by the end user" — the specific time/place/cadence granularity guarantee is gone.

Hardening: "Alphabet should define" → "Alphabet shall define" (measure (a)); "Alphabet should publish developer documentation" → "shall publish" (measure (b)); "the user should be able to grant access" → "shall be able to" (measure (d)).

Deadline and wording effect: the draft split deadlines: the user-prompt measure (117)(d) was due by 1 January 2027, while the remaining §4.3 measures were expressed as "should" obligations due by 1 June 2027. The final unifies all measures at 1 August 2027 (Android 18). Both tracks therefore move later—by seven months and two months respectively—while the former "should" language is hardened to "shall".

Compare provision wording

View

Draft ¶ 112 Final ¶ 99

Alphabet shall provide effective interoperability with the background execution feature.

Draft ¶ 113 Final ¶ 100

The background execution feature is described in Section 11.4.2 of the ~~Preliminary Findings~~Decision. The feature allows to execute tasks in a timely manner, including when the ~~app or~~relevant ~~service~~app is not in the foreground. This ability relies on the OS providing adequate interfaces to start and resume tasks, and allocating sufficient system resources (including CPU, GPU, NPU, and RAM) to the app or service.

Draft ¶ 114 Final ¶ 101

Alphabet shall implement an interoperability solution that provides third parties with access to the ~~same Google~~background ~~Android~~execution feature ~~(as described in the preceding paragraph)~~ and ~~all~~ its functionalities, as available to Alphabet's services and in a way that is equally effective as the solution available to Alphabet's services.

Draft ¶ 115 Final ¶ 102

These functionalities are: (a) Access to hardware resources. This consists in the ability to access hardware resources – including CPU, GPU, NPU, and RAM – to execute tasks. Access to the same background execution capabilities entails, in particular, being exposed and subject to the same limitations of these capabilities as a result of a user action. This includes the effect of an end user terminating an Android app in the app switching menu ("force-quitting" or "force-killing").; (b) Requesting resource allocation. This consists in the ability to indicate to the OS that the service requests allocation of a certain amount of resources, e.g. for a certain period of time or while a certain process is active. This can be done through pre-defined OS interfaces (APIs) that guarantee a certain degree of access to resources, typically under certain conditions that are tied to specific use cases. For example, such an API could guarantee that an AI service can synchronise data in the background for at least 10 seconds without showing a visible notification for the user, or for longer if a notification is shown. It could also guarantee that a connected device (e.g. earbuds) maintains a persistent connection with the Google Android mobile device that allows the user to invoke an app (e.g. an AI assistant) using a hotword detected on the connected device. While such interfaces can be generally useful for specific use cases, they typically do not enable every use case, for which a more generic way of requesting resource allocation is needed.; (c) Starting or resuming a task while the app is in the background. This can depend on external conditions (e.g. an instruction received by another app; time-based conditions; a user approaching a certain location, such as their home; the user taking a picture) or internal conditions (e.g. the app concluding a task, such as the summarisation of a long audio recording). The task can be executed by the app itself (e.g. an AI assistant displaying a reminder notification at a given time) or by another app (e.g. an AI assistant sending a message via another messaging app at a given time).; and (d) Device configurations. This consists in the ability of an app or service to be treated preferably by the OS, directly or indirectly, in terms of access to resources because of configuration settings~~. This includes configuration settings that allow an app to be persistently stored in memory or that allow an app to be exempted from power management mechanisms.~~, ~~These~~including settings ~~can be defined by Alphabet and/or the OEM but can also be~~ configurable by the end user. This functionality therefore includes the ability for the user to make choices on the level of background execution to a service, including regarding time, place, and cadence, and the presentation and effect of any prompt or user interface for that purpose.

Draft ¶ 116 Final ¶ 103

Alphabet shall grant third parties access to additional functionalities available to Alphabet's services if necessary to enable effective interoperability with the background execution feature ~~referred to in paragraph (113)~~.

Draft ¶ 117 Final ¶ 104

To provide third parties with an interoperability solution for the background execution feature ~~referred to in paragraph (113)~~ that is equally effective as that available to ~~any of~~ Alphabet's ~~own AI assistants~~services, ~~Alphabet~~such ~~shall~~as ~~implement~~Gemini, the following measures shall apply: (a) Alphabet shall ensure that third~~-party~~ ~~apps~~parties have the same access to background execution as Alphabet's services ~~(including Alphabet's apps) have access to~~, directly or indirectly. To this end, Alphabet ~~should~~shall define transparent, objective, precise and non-discriminatory rules that also apply to Alphabet's services, including for use cases that Alphabet does not offer. ~~The~~To ~~same~~that end, Alphabet shall ensure that, in particular, the following conditions are met: (1) The rules ~~should~~may ~~apply~~take tointo ~~non-Alphabet~~account ~~services~~aspects of system stability and ~~Alphabet~~device ~~services~~health, ~~regardless~~such as battery and thermal management. The rules may also take into account the need of ~~whether~~system components – both Alphabet's and OEM's – to access background execution to preserve the ~~apps~~internal ~~providing~~functioning of the ~~relevant~~operating ~~services~~system, ~~are~~such ~~pre~~as system-~~installed.~~level ~~Such~~hardware scheduling; and (2) The rules may not treat any specific service differently, for example by restricting or exempting a specific service, unless the user has provided consent for the specific service (e.g. by exempting the corresponding app from power restriction). (b) Alphabet shall ensure that third parties can offer always-on hotword detection on connected devices to invoke an app or perform other operations on the Google Android mobile device, using the same access to background execution that is available to ~~Alphabet~~Alphabet's services for the same purpose. Alphabet ~~should~~shall publish developer documentation explaining how third parties can use the relevant Google Android APIs to implement this use case.; (c) If Alphabet allows OEMs to customise background execution rules, Alphabet shall ensure that such rules comply with all measures pertaining to the ~~measures~~background execution feature specified in this Annex. In particular, such rules ~~should~~shall be transparent, objective, precise and non-discriminatory ~~rules that~~and ~~also~~equally apply to pre-installed services.; (d) Alphabet shall ensure that third~~-party~~ ~~apps~~parties may prompt the user to grant ittheir services access to the same level of background execution that other services – including Alphabet's services – have access to. In particular, granting this access ~~should~~shall provide the app the same level of background execution that Alphabet requires OEMs to grant to its own ~~apps~~services (also with respect to proprietary OEM restrictions) or similar requirements. The user ~~should~~shall be able to grant access with a single inlow-~~app~~friction ~~step~~option, without having to navigate to ~~settings~~ or ~~back~~change tomultiple ~~the~~settings; ~~app.~~and (e) If Alphabet allows any limitation or choice on the background execution capabilities of user-downloaded apps as a result of a user action, Alphabet shall ensure that the user can take the same action with the same limiting effect regarding other apps, including pre-installed services. This includes the action of a user terminating an app in the app switching menu ("force-quitting").

Draft ¶ 118 Final ¶ 105

Alphabet shall provide effective interoperability with any future updates, including new functionalities, of the background execution feature insofar as they are available to Alphabet's ~~own~~ services ~~or hardware~~.

Draft ¶ 119 Final ¶ 106

Alphabet shall implement the measures above in compliance with the measures for all features in Section 5 of this Annex.

Draft ¶ 120 Final ¶ 107

Alphabet shall implement the measures ~~in paragraph (117)(d) on user prompts~~ for the background execution feature ~~by 1 January 2027. Alphabet should implement~~in the ~~rest of~~next ~~the~~major ~~measures~~Android ~~laid~~release, ~~down~~i.e. inAndroid ~~paragraph~~18, ~~(117)~~and by 1 ~~June~~August 2027 at the latest.

The Section 5 chapeau is substantively preserved. Draft paragraph 121 states that the following measures apply "in relation to" all features in Sections 1–4; final paragraph 108 shortens this to "apply to" those features. It is treated as a separate group so its text and paragraph coverage are not embedded in the background-execution entry.

Compare provision wording

View

Draft ¶ 121 Final ¶ 108

The following measures shall apply ~~in relation~~ to all features referred to in Sections 1- to 4 of this Annex.

Substance preserved. Enforcement language is broadened, not narrowed: draft "Alphabet shall ensure, including by technical and contractual means" becomes final "Alphabet shall take all necessary actions, including of technical, contractual, and legal nature" (final para 109) — an additional enforcement modality (legal action) is named. The footnote defining "Google Android mobile device" (draft footnote 5 / final footnote 3) is essentially identical.

Compare provision wording

View

Draft ¶ 122 Final ¶ 109

Alphabet shall ~~ensure~~take all necessary actions, including byof technical, contractual, and ~~contractual~~legal ~~means~~nature, to ensure that ~~the~~all measures in this Annex ~~(including in Section 5)~~ are complied with on ~~all~~ Google Android mobile devices, ~~^{Draft measures note 5}~~^{Final measures note 3} including on devices supplied by third-party OEMs~~. Specifically~~, ~~Alphabet shall ensure that, for each feature in this Annex,~~provided the ~~measures in this Annex are implemented on all Google Android~~ mobile devices ~~that~~ meet the following conditions: (a) The relevant feature exists on the device, and (b) The device still receives Android AOSP, Google Play system, or Google system services updates.

Draft ¶ 123 Final ¶ 110

Alphabet shall implement all interoperability solutions in a way that avoids ~~ecosystem~~differences ~~fragmentation~~within the Android ecosystem, as Alphabet does for other Android SDK APIs. In particular, Alphabet shall ensure that third~~-party~~ ~~apps~~parties can use the interoperability solutions consistently via the same APIs across Google Android versions, devices, and form factors. This requirement applies regardless of how the solution is implemented on the specific Google Android mobile device or Android version. Alphabet may achieve this, for example, by defining Android SDK APIs and using Android support libraries, such as Android Jetpack, to define a consistent API across different Android versions and potentially different implementations.

Draft ¶ 124 Final ¶ 111

If Alphabet allows OEMs to apply any customisations that affect the features in Sections 1- to 4 of this Annex or their effective implementation, Alphabet shall take all actions necessary to ensure that the custom implementation complies with all the measures specified in this Annex.

Addition: final (112) expands what Alphabet is not prevented from doing with technical consent measures to a three-part list: "(i) ensure that features are accessible subject to user consent; (ii) inform users about feature access (such as dashboards or indicators); and (iii) allow the user to revoke access to the feature for any specific service" — (ii) and (iii) are new, explicit latitude for Alphabet-built consent/revocation UX.

Dropped: draft (126)'s explicit sentence "In particular, such requirements shall apply equally to user-installed apps and pre-installed apps" does not reappear in final (113) as a standalone clause (the general non-discrimination principle is retained, but this specific installed-app-type parity clause is gone — the same pattern recurs in §5.3 below).

"They should also comply" → "They shall also comply" (hardened).

Compare provision wording

View

Draft ¶ 125 Final ¶ 112

Alphabet shall not be prevented from implementing technical measures (e.g. system-level prompts) to: (i) ensure that features are accessible ~~only~~subject ~~with~~to user consent; (ii) inform users about feature access (such as dashboards or indicators); and (iii) allow the user to revoke access to the feature for any specific service.

Draft ¶ 126 Final ¶ 113

Any ~~requirements~~measures ~~for~~subjecting feature access to any requirements, such as user consent and the use of privacy indicators, as well as any corresponding technical measures shall be based on transparent, objective, precise, and non-discriminatory conditions that ~~also~~equally apply to Alphabet's services and hardware. ~~In particular, such requirements shall apply equally to user-installed apps and pre-installed apps.~~ They ~~should~~shall also comply with the other measures in this Annex, particularly the measures in Section 5.5 on equal effectiveness.

Draft paragraph 130(d)'s consent-and-agency safeguard is deleted, as is the express pre-installed/user-installed parity sentence from paragraph 130(b). Final paragraph 117(d) and (f) add "unless specified otherwise in this Annex" to two anti-restriction rules. That wording accommodates the certification exception within the annex, but does not by itself establish that the regime is legally justified under the DMA. Paragraph 115 hardens "should" to "shall" for the independent-verifiability requirement.

For the broader question of how these conditions constrain Alphabet’s reliance on integrity, see Integrity under the DMA: sources, interpretation and safeguards. That dossier distinguishes the underlying statutory tests from the Commission’s specification language and compares the Android approach with the Apple interoperability decisions.

Compare provision wording

View

Draft ¶ 127 Final ¶ 114

Alphabet may take strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, hardware and software features.

Draft ¶ 128 Final ¶ 115

Any integrity measure shall be duly justified and based on transparent, objective, precise, and non-discriminatory conditions that also apply to Alphabet's services and hardware. Alphabet can only impose conditions and take integrity measures that reflect a genuine integrity risk and do so in a consistent and systemic manner. Similarly, Alphabet ~~should~~shall only apply such conditions with which compliance is capable of being independently verified and not exclusively within the gatekeeper's control. An integrity measure cannot be considered strictly necessary and proportionate if it seeks to achieve a higher integrity standard than the one that Alphabet requires or accepts in relation to its own services or hardware. Alphabet shall not impose a higher level of integrity on third parties than it applies to itself.

Draft ¶ 129 Final ¶ 116

Any integrity measure shall be implemented in a way that does not undermine effective compliance with these measures and Alphabet's obligations with Regulation 2022/1925 including for instance by subverting end users' or third parties' autonomy, decision-making, or free choice via the structure, design, function or manner of operation of a user interface or apart thereof.

Draft ¶ 130 Final ¶ 117

Alphabet shall ensure that the following conditions apply to any integrity measures: (a) The measures must be consistent with the approach that Alphabet already applies in similar or comparable cases.; (b) The measures shall apply equally to ~~the~~ Alphabet's services and to third parties~~' services. Moreover, measures must apply equally to pre-installed and user-installed apps.~~; (c) The measures shall be based on objective and verifiable evidence showing the existence and magnitude of the integrity risk and ~~showing that the measures will be effective~~effectiveness in reducing such risk. Alphabet shall retain such evidence.; (d) The measures ~~that concern informed consent and agency for the user, such as prompts,~~ shall ~~be supported by the necessary technical measures to appropriately inform the user or ask their consent. (e) The measures shall~~ not impose limits on the purpose, beneficiaries, apps, technologies used or use cases for feature access., unless specified otherwise in this Annex; (fe) The measures ~~must~~shall not impose any commercial or financial requirements on the beneficiaries.; (gf) The measures ~~must~~shall not impose functional requirements beyond those strictly necessary to preserve integrity. In particular, they ~~must~~shall not assume or require that a certain technology is used., unless specified otherwise in this Annex; (hg) The measures ~~must~~shall be enacted only for as long as is necessary, and be adapted to technological evolution, including changes to the operating system.; and (ih) The measures shall be grounded in established industry standards and practices.

Draft ¶ 131 Final ¶ 118

Alphabet shall inform the Commission in writing of any integrity measure that Alphabet intends to take in relation to the features covered by this Annex, providing a justification of their strict necessity and proportionality at least 4 weeks in advance of their implementation, or without undue delay in case of urgency, unless the measure meets each of the following cumulative conditions: (a) it is not user-facing, (b) it is exclusively of a technical nature, (c) it is implemented for Alphabet and third parties in precisely the same way, and (d) Alphabet has determined that the change will have no or only insignificant impact of any nature on third parties, including technical or commercial impact. Alphabet shall retain written documentation on how any such determination was made.

Final paragraph 119 makes the ordinary open-access principles expressly subject to the Restricted Features regime. Draft paragraph 134's neutral and independent beneficiary-verification and dispute-resolution guarantee is deleted; final §5.4.1 instead creates TCA and direct-certification routes and specified appeals decided by Alphabet. This is a materially different access-control structure, while final paragraph 115 separately preserves independent verifiability of integrity conditions.

The certification condition is not absolute: paragraph 135 allows an informed end-user opt-out per service and device, and paragraph 137 applies the relevant processes to services that are not AI assistants. Final §§5.4.2 paragraphs 139–140 otherwise preserve the anti-undue-restriction and anti-degradation duties.

Compare provision wording

View

Draft ¶ 132 Final ¶ 119

Final paragraph 119 consolidates draft paragraphs 132, 133 and 135 as subparagraphs (b), (a) and (c), subject to the new Restricted-feature qualification.

Unless a feature constitutes a Restricted feature within the meaning of paragraph (120) below, Alphabet shall comply with the following measures: (a) Alphabet shall make the features listed in Sections 1 to 4 of this Annex, and interoperability solutions to implement these features pursuant to the measures in this Annex, accessible to all third parties, including user-installed apps, pre-installed apps without system privileges, and apps of original equipment manufacturers (OEMs). (b) Alphabet shall make available the interoperability solutions and measures implemented in compliance with these measures to all ~~providers of services and providers of~~third ~~hardware~~parties without undue delay, to the extent they indicate, including through the use of APIs, an interest in making use of any or all of the features listed in Sections 1 to 4 of this Annex, including for use cases that Alphabet does not offer. (c) Alphabet shall not impose any restrictions on the type or use case of the software application that can access or make use of the features listed in Sections 1 to 4 of this Annex.

Draft ¶ 133 Final —

Consolidated into final paragraph 119(a); not simply deleted.

Alphabet shall make the features in Sections 1-4 of this Annex, and interoperability solutions to implement these features pursuant to the measures in this Annex, accessible to all apps, including user-installed apps and pre-installed apps without system privileges. ^{Draft measures note 6}

Draft ¶ 134 Final —

The registration/independent-verification provision is removed. Final section 5.4.1 establishes a different certification regime for Restricted features.

Alphabet shall not impose any restrictions as to the beneficiaries; any verification or registration process shall, at a minimum, be strictly necessary and proportionate for the specific feature, apply only on the Google Play Store, be conducted by neutral and independent third parties, be based on transparent and non-discriminatory conditions, apply equally to all developers – including Alphabet – and irrespective of pre-installation, and have an independent dispute resolution mechanism.

Draft ¶ 135 Final —

Consolidated into final paragraph 119(c), subject to the new Restricted-feature qualification.

~~Alphabet shall not impose any restrictions on the type or use case of the software application that can access or make use of the features listed in Sections 1 to 4 of this Annex.~~

Draft ¶ 136 Final ¶ 139

Moved to final section 5.4.2.

Alphabet shall not impose any undue restrictions, including by requiring third parties to use other Alphabet products or services unless required for the functioning of the feature, or by requesting third parties to make choices in situations where such choice is not justified (for example, choosing between using the interoperability solution and continuing to use the same application ID), ~~require~~requiring third parties to use other Alphabet products or services in order to access and use the feature unless required for the functioning of the feature, or ~~prevent~~preventing third parties from benefitting from access to other features, including using the feature in combination with other features within the scope of Article 6(7) of Regulation 2022/1925.

Draft ¶ 137 Final ¶ 140

Moved to final section 5.4.2.

Alphabet shall not undermine effective interoperability with the features listed in Sections 1 to 4 of this Annex by behaviour of a technical, commercial, contractual or any other nature. In particular, Alphabet shall: (a) enable third parties to make use of the interoperability solution in their existing apps via an automatic update of such apps, without being in any way disadvantaged for doing so, such as by having to reacquire or migrate existing users to a separate app; and (b) not degrade, remove, disable, or otherwise make ineffective the interoperability solution, or prevent or impede updates, including security updates, for the end user as long as the end user is eligible to benefit from the functionalities allowed by these interoperability solutions; before taking any such measure in this respect, Alphabet shall notify the end user explaining how the measures Alphabet intends to take will affect the interoperability solution relied on by third~~-party~~ ~~services~~parties on the end user's Google Android mobile device.

Draft deadline: —
Final deadline: Draft terms 1 Feb 2027 / final terms 1 May 2027 / applications from 1 Feb-1 May 2027

Final §5.4.1 creates a certification architecture with no draft counterpart. Paragraph 120 identifies five Restricted feature categories or implementations. Paragraph 121 permits the Commission, on Alphabet's reasoned request showing good cause, to add another feature or part of one. Paragraph 122 requires eligibility conditions to apply to and treat Alphabet and third-party services equally.

Paragraphs 123–129 establish the Qualified AI Assistant and Trusted Certification Authority programmes, including direct Alphabet certification. Paragraphs 130–134 govern revocation, emergency suspension and appeals. Paragraph 135 allows users to opt out of certification per service and device without enabling developer mode, so certification is not an absolute condition. Paragraph 137 extends transparent, objective, precise and non-discriminatory eligibility conditions and the relevant processes to services that are not AI assistants.

The timelines differ by route. Under paragraph 136(c), Qualified AI assistant applications are accepted from 1 May 2027 and ordinarily assessed within four weeks, subject to delays outside Alphabet's control and an eight-week allowance for unusually high application volumes. Under paragraph 136(d), TCA applications are accepted from 1 February 2027 and have a four-week deadline with no stated high-volume extension. Draft programme terms are due 1 February and final terms 1 May 2027.

Alphabet retains substantial control over programme terms, direct certification, emergency suspension and specified appeals, balanced by the TCA route, equal-treatment duty, user opt-out, non-AI-service route and pre-certification testing guarantee in paragraph 154.

Compare provision wording

View

Draft — Final ¶ 120

Prior to enabling access to restricted features ("Restricted feature"), Alphabet may require the developer to demonstrate that its service meets certain eligibility conditions. The Restricted features are: (a) Centralised access to apps' data stored on-device; (b) Context-aware intelligence; (c) Structured on-device integration; (d) Screen automation; and (e) System integration. If doing so, Alphabet shall comply with the measures set out below in this section.

Draft — Final ¶ 121

Request to expand the list of Restricted features. The Commission may, in response to a reasoned request from Alphabet showing good cause, include another feature (or part thereof) among the ones in scope of this Decision to the group of Restricted features.

Draft — Final ¶ 122

Alphabet shall ensure that the eligibility conditions to access Restricted features apply to and treat equally all services, including Alphabet's services, and third-party services.

Draft — Final ¶ 123

Qualified AI Assistant Programme. Alphabet shall create a Qualified AI Assistant Programme to certify AI assistants as meeting the eligibility conditions ("Qualified AI assistants") to access Restricted features. Alphabet shall grant Qualified AI assistants access to all Restricted features listed in paragraph (120).

Draft — Final ¶ 124

Alphabet shall define the terms that govern the Qualified AI Assistant Programme – which shall consist of (i) eligibility conditions subject to the requirements set out in paragraphs (125)-(126) and (ii) processes subject to the requirements set out in paragraphs (127)-(135) below.

Draft — Final ¶ 125

Eligibility conditions to be certified as Qualified AI assistant. Alphabet shall define a single set of transparent, objective, precise and non-discriminatory eligibility conditions that apply to AI assistants (including Alphabet's AI assistants) and are sufficient for them to be certified as Qualified AI assistants. The eligibility conditions for AI assistants may only include the following requirements: (a) functional eligibility conditions, requiring the candidate AI assistant to have (i) advanced reasoning capabilities, such as through the use of Large Language Models ("LLMs"), that enable it to interpret and act on user intent autonomously; (ii) capability to seek information, nuanced understanding and the reliable execution of complex, multi-step instructions; and (iii) capability to perform a range of tasks including tasks relating to other apps installed on the device; (b) user intent conditions, requiring that the candidate AI assistant's agentic capabilities (i) honour user intent; (ii) are only triggered with the user's intent; and (iii) must reconfirm user intent before executing sensitive, irreversible actions; (c) agent and model functional risks conditions, requiring that the candidate AI assistant, and the advanced reasoning used, are adequately hardened against key agentic risks that would negate user intent, such as input, supply chain, integration, model integrity, and infrastructure risks; (d) agent privacy, safety, and transparency conditions, requiring that the candidate AI assistant (i) accesses and processes data only to the extent necessary for the user's intent, (ii) minimises inadvertent data disclosure, and (iii) enables informed user consent including through user transparency and control mechanism; (e) agent app security conditions, requiring that the candidate AI assistant meets baseline mobile application security requirements, showing that the agent app guards against key vulnerabilities; and (f) developer reputability conditions, requiring that the developer of the candidate AI assistant (i) implements relevant technical and organisational measures, policies, and processes to preserve agent and model safety, privacy, transparency, and security, (ii) remains abreast of emerging AI-based vulnerabilities, and (iii) implements policies and processes to monitor and assess the resilience of its AI assistant in light of these developments.

Draft — Final ¶ 126

Alphabet may further specify the eligibility conditions, including by specifying feature-specific conditions, but shall not introduce additional conditions without consulting the Commission. Alphabet shall ensure that the feature-specific conditions are strictly necessary and proportionate to the specific feature. Alphabet shall not require the AI assistant to support all Restricted features to be certified as Qualified AI assistant but may subject interoperability with a Restricted feature to the feature-specific conditions.

Draft — Final ¶ 127

Trusted Certification Authorities Programme. Alphabet shall create a Trusted Certification Authorities ("TCA") Programme and define the terms of the programme, which shall include: (i) the eligibility criteria and (ii) the process for a third party to be approved or revoked as TCA by Alphabet, free of charge. The terms of the programme must be reasonable, non-discriminatory, and in line with existing schemes for certification authorities.

Draft — Final ¶ 128

Obtaining certification from Trusted Certification Authorities. Alphabet shall entrust the selected TCAs to certify services as Qualified AI Assistants, i.e. to approve them as beneficiaries of the interoperability measures set out in this Annex. To this end, Alphabet shall ensure that AI assistants meeting the eligibility conditions can obtain certification as Qualified AI Assistants from TCAs. Alphabet shall accept certifications issued by TCAs without imposing further requirements. Alphabet shall not revoke certifications issued by TCAs.

Draft — Final ¶ 129

Obtaining certification from Alphabet. In addition to the Trusted Certification Authorities Programme, Alphabet shall allow third-party services to be certified as Qualified AI assistants by Alphabet, free of charge.

Draft — Final ¶ 130

Revocation. If Alphabet intends to revoke a certification as a Qualified AI Assistant issued by Alphabet, Alphabet shall inform the provider of the certified Qualified AI assistant sufficiently in advance to allow the provider to address Alphabet's concerns, and in any case at least one month before the revocation. Alphabet shall communicate to the provider a complete description of the reasons for the intended revocation and the steps that the provider should take to avoid the revocation.

Draft — Final ¶ 131

Unilateral suspension by Alphabet. Alphabet may temporarily suspend a Qualified AI assistant from accessing Restricted features on end users' devices, subject to Alphabet being in possession of a consistent body of evidence that a Qualified AI assistant has been engaging in practices that can cause severe and immediate harm to users. When applying such a suspension, Alphabet shall take the following steps: (a) No later than at the time of the suspension, Alphabet shall inform the provider of the Qualified AI assistant and indicate the steps that the third party has to take for Alphabet to revert the suspension or to avoid the suspension if it has not yet entered into effect. Alphabet shall provide the third party with a direct and continuous channel of communication for a prompt resolution of the issue; and (b) Alphabet shall inform the Commission and the relevant TCAs without undue delay.

Draft — Final ¶ 132

When informing the third party, the TCAs, and the Commission pursuant to the previous paragraph, Alphabet shall transfer the body of evidence that led to the suspension for reasons of severe and immediate harm to users.

Draft — Final ¶ 133

Alphabet shall reinstate the Qualified AI Assistant's access to Restricted features as soon as the grounds justifying the suspension are no longer present.

Draft — Final ¶ 134

Appeal. Alphabet shall provide third parties with a mechanism to appeal the following decisions by Alphabet: (a) A decision by Alphabet not to approve the third party as a TCA; (b) A decision by Alphabet to revoke the approval of the third party as a TCA; (c) A decision by Alphabet not to certify a service as Qualified AI assistant; (d) A decision by Alphabet to revoke a certification as Qualified AI assistant issued by Alphabet; and (e) A decision by Alphabet to unilaterally suspend a Qualified AI assistant's access to Restricted feature, per paragraph (131) above. Alphabet shall issue a decision on the appeal within one month.

Draft — Final ¶ 135

Alphabet shall allow end users to give informed consent to opt out of the certification requirement for their device, on a per-service basis, in line with existing opt-out mechanisms for advanced users. Alphabet may put in place measures that support transparency to the user before granting consent, such as information screens and short delays. Alphabet shall not require the end user to enable developer mode or other options that can interfere with the functioning of the Restricted features or any other feature.

Draft — Final ¶ 136

Timeline. (a) By 1 February 2027, Alphabet shall publish the draft terms of the Qualified AI Assistants Programme and of the Trusted Certification Authorities Programme for consultation by third parties and by the Commission. In the final terms, Alphabet shall take utmost account of the comments received; (b) By 1 May 2027, Alphabet shall publish the final terms; (c) Alphabet shall accept applications for certification as a Qualified AI assistant as of 1 May 2027 and shall conclude the assessment within four weeks upon receipt of the application, except where delays are outside of Alphabet's control. If Alphabet received an unusually high number of requests within a single time period, Alphabet shall conclude the assessment within 8 weeks; and (d) Alphabet shall accept applications for certification as a Trusted Certification Authority as of 1 February 2027 and shall conclude the assessment within four weeks upon receipt of the application.

Draft — Final ¶ 137

Qualified services that are not AI assistants. Alphabet shall ensure that services ("Qualified Service") that are not Qualified AI assistants can access Restricted features under transparent, objective, precise, non-discriminatory eligibility conditions that apply also to Alphabet's own services. Alphabet shall not impose any restrictions on the type or use case of the software application that can access Restricted features under such conditions. Alphabet shall ensure that the eligibility conditions are strictly necessary and proportionate to the specific feature and the specific type of service. Alphabet shall apply the same processes set out in (127)-(135) above. Alphabet shall allow the same Trusted Certification Authorities to certify both AI assistants and services that are not AI assistants.

Draft — Final ¶ 138

Updates to the terms. Alphabet shall keep the programmes specified in this section under regular review to ensure that its criteria and their application are suitable to enable access to future generations of services – including AI Assistants – and are in line with developments in the relevant technology. If Alphabet plans to define or update the terms for Qualified AI assistants or any other Qualified Service, or if Alphabet plans to update the terms of the Trusted Certification Authority Programme, Alphabet shall consult the Commission at least 2 months prior to updating the terms.

Largely a reordering/renumbering of the same content (the word-diff is noisy because paragraphs were resequenced, not because substance changed). Two minor points:

Draft (138) referenced equal effectiveness "including Alphabet's connected physical devices" as comparator hardware; this parenthetical is dropped in final (141) (the general "hardware" reference remains).
Draft (141)(a)'s anti-FUD clause referred to misrepresenting risks of using "the third-party connected physical device"; final (144)(a) generalises this to "the third-party service" — broader in wording, though it drops the specific connected-hardware framing.

All nine friction-avoidance sub-rules (dark patterns, recurring prompts, deep-linking, bundled consent prompts, etc.) and the quantitative-limitation and centralised-exposure/dynamic-asset provisions are preserved.

Compare provision wording

View

Draft ¶ 138 Final ¶ 141

Alphabet shall ensure that any interoperability solution implemented for the ~~features~~measures listed in Sections 1 to 4 of this Annex is equally effective to the solution available to Alphabet's services and hardware ~~(including Alphabet's connected physical devices)~~. Alphabet shall apply such equal effectiveness across all dimensions, including, but not limited to, the end user journey, ease of use for end users, device and software setup, data transmission speed, and energy consumption.

Draft ¶ 139 Final ¶ 142

Alphabet shall make all interoperability solutions accessible in a manner that is technically sound, stable, and workable in practice for third parties without unnecessary hurdles.

Draft ¶ 140 Final ¶ 143

Alphabet shall design ~~all~~ interoperability solutions ~~enabling~~so ~~the~~that ~~concurrent~~all ~~use~~apps ofcan ~~the~~use features byin ~~all~~a ~~apps~~concurrent inand a non-discriminatory way. Alphabet shall not subject access to features to the app holding a default role, including the default assistant role.

Draft ¶ 141 Final ¶ 144

To ensure access is equally effective to the solution available to Alphabet's own services and hardware in terms of end user journey, Alphabet shall not decrease the ease, convenience and speed of using third-party services and hardware from the end user perspective. In particular, Alphabet shall refrain from adding friction by: (a) Offering choices to, or requesting permission from, the end user in a non-neutral or leading manner, including by using design patterns, dark patterns, or misrepresenting or exaggerating any risks of using the third-party ~~connected physical device~~service or granting a permission.; (b) Preventing the third party from explaining to end users in their own language the relevance of any system prompts shown, immediately before the prompt is shown or within the prompt.; (c) Showing unnecessary recurring prompts or notifications that the end user cannot easily and permanently disable in the same prompt or notification.; (d) Preventing the third party from triggering a permission prompt again in the future, unless the end user has so decided.; (e) Preventing third parties from obtaining user consent for any required permissions (i) from inside the application itself or with a simple system prompt or (ii) by indicating the user to follow a link directly pointing to and highlighting the relevant item in the system settings (so-called "deep-linking").; and (f) Requiring end users to process multiple successive permission prompts that could be presented in a single prompt.

Draft ¶ 142 Final ¶ 145

In particular, Alphabet shall apply the same end user journey and ease of use for end users in order to obtain the necessary consent for its own and third-party services and hardware, including: (a) showing the same user consent prompts (in terms of, inter alia, number, content, format and design) as Alphabet,; (b) showing the same information screens (in terms of, inter alia, number, content, format and design) as shown to users by Alphabet,; and (c) limit the necessary user engagement to the same level as adopted by Alphabet, including the number of prompts and information screens.

Draft ¶ 143 Final ¶ 146

Alphabet shall base any quantitative limitations (e.g., quotas and rate limits) on third-party access to a feature on transparent, objective, precise, and non-discriminatory conditions that also apply to Alphabet's services and hardware, including for use cases that Alphabet does not offer.

Draft ¶ 144 Final ¶ 147

Alphabet shall enable third~~-party~~ ~~apps~~parties to centrally expose ~~and access~~ their functionalities to other apps, and shall enable third parties to access such functionalities – in a way that is equally effective to what is available to Alphabet's services and hardware. ~~^{Draft measures note 7}~~^{Final measures note 4} Alphabet shall also enable third~~-party~~ ~~apps~~parties to dynamically provide and retrieve assets – including but not limited to executable modules – at runtime, including from other apps, in a way that is equally effective to what is available to Alphabet's services and hardware. ~~^{Draft measures note 8}~~^{Final measures note 5} If the app providing the assets is not installed when another app requests those assets, Alphabet shall enable the user to install the app via a low-friction in-app mechanism, in a way that is equally effective to what is available to Alphabet's services and hardware. ~~^{Draft measures note 9}~~^{Final measures note 6}

Source-note comparison

Same wording

Draft

Draft measures note 7

For example, Google Play Services APIs are exposed centrally to other apps.

Final

Final measures note 4

For example, Google Play Services APIs are exposed centrally to other apps.

Wording changed

Draft

Draft measures note 8

For example, Gemini Nano is downloaded via AI Core when the user takes an action that triggers the download, e.g. by using a feature in Alphabet's apps that requires Gemini Nano.

Final

Final measures note 5

For example, Gemini Nano is downloaded via AICore when the user takes an action that triggers the download, e.g. by using a feature in Alphabet's apps that requires Gemini Nano.

Same wording

Draft

Draft measures note 9

For example, in Google Play, Alphabet implements the Play Auto Install and Google Play Inline Installs mechanisms.

Final

Final measures note 6

For example, in Google Play, Alphabet implements the Play Auto Install and Google Play Inline Installs mechanisms.

Identical in substance; renumbered only.

Compare provision wording

View

Draft ¶ 145 Final ¶ 148

Alphabet shall provide the interoperability solutions and measures implemented to allow for effective interoperability with the features listed in this Annex free of charge, irrespective of their beneficiary, app, service, product, and use case. Alphabet shall also not charge any fees indirectly for any of the measures set out in this Annex.

Identical in substance; renumbered only.

Compare provision wording

View

Draft ¶ 146 Final ¶ 149

Alphabet shall make available complete documentation of all interoperability solutions it will be making available in the context of the implementation of the measures set out in this Annex. This includes Alphabet making available complete, accurate, and well-documented APIs to the extent that access to such APIs is relevant for the implementation of the measures set out in this Annex.

Draft ¶ 147 Final ¶ 150

Alphabet shall maintain this documentation and these APIs in line with Alphabet's internal processes and policies, so that effective access for the purpose of ensuring interoperability is guaranteed over time.

The two draft paragraphs (technical assistance free of charge; usual-practices/beta-testing duty) are preserved unchanged. Two new paragraphs are added:

Final (153) (new): Alphabet must ensure third-party engagement/communication "is carried out effectively, promptly, and without undue delay."
Final (154) (new): Alphabet may not impose "undue restrictions" on developing and testing services using the interoperability solutions, "including not preventing the ability to develop and test services that access Restricted features without having been certified yet as a Qualified Service" — a protective provision that mitigates part of the new §5.4.1 certification gate by guaranteeing pre-certification development/testing access.

Compare provision wording

View

Draft ¶ 148 Final ¶ 151

Alphabet shall provide reasonable technical assistance, free of charge, to third parties to implement and achieve effective interoperability with the features in this Annex.

Draft ¶ 149 Final ¶ 152

Alphabet shall ensure that all interoperability solutions implemented to address the measures specified in this Annex are subject to Alphabet's usual practices, including beta testing.

Draft — Final ¶ 153

Alphabet shall ensure that any engagement with, and communication to, third parties for the purpose of implementing the measures specified in this Annex is carried out effectively, promptly, and without undue delay.

Draft — Final ¶ 154

Alphabet shall not impose any undue restrictions on the ability for third parties to develop and test services that use the interoperability solutions implemented to address the measures specified in this Annex. This includes not preventing the ability to develop and test services that access Restricted features without having been certified yet as a Qualified Service.

Substantively identical; only renumbering and relocation of two explanatory footnotes (Gemini Nano / Play Auto Install examples, now final footnotes 5-6).

Compare provision wording

View

Draft ¶ 150 Final ¶ 155

Should Alphabet make changes to a feature listed in in this Annex, including adding new functionalities to the feature or making updates, Alphabet shall: (a) Develop such new functionalities or updated features ~~or functionalities~~ in a way that they are interoperable with third-party services or hardware.; (b) Include the interoperability solutions at an appropriate time in the beta version of the new functionalities or updated features or; ~~functionalities.~~and (c) Make accessible the updated interoperability solution on a Google Android mobile device and documentation for the relevant feature no later than at the time the new functionality or updated feature becomes accessible to any Alphabet service or hardware on the same Google Android mobile device.

Draft ¶ 151 Final ¶ 156

Alphabet shall maintain the interoperability solution over time such that the solution and its documentation continue being available, functional, usable, and effective for all ~~developers~~third parties without interruption. If, in exceptional circumstances, Alphabet wishes to deprecate an interoperability solution or parts of it, Alphabet shall submit a reasoned request in accordance with the procedure described in paragraph (~~158~~165) of this Annex.

New reporting duties (additions):

Final (162) (new): each of the five report types must now explicitly include "any changes [Alphabet] plans to make or has made ... in relation to any feature ... including any new functionality."
Final (164) (new): Alphabet must "cooperate with the Commission to test specific technical solutions and report on the results of the tests with sufficient frequency and granularity."
"Alphabet should provide" the Semi-annual Implementation Report → "Alphabet shall provide" (hardened, final para 161).

Express publication duty removed: draft (157) required non-confidential versions of all five report types to be provided to the Commission for publication when the report is due. Final (163) requires confidential and non-confidential versions of each Final Feature Implementation Report when due, and non-confidential versions of the other reports on request. It does not expressly require publication of any of those versions. The final text therefore removes the draft's express publication obligation altogether, while preserving differentiated duties to prepare or provide non-confidential versions.

Compare provision wording

View

Draft ¶ 152 Final ¶ 157

Alphabet shall communicate to the Commission shortly after the notification of the ~~decision~~Decision pursuant to Article 8(2) of Regulation (EU) 2022/1925 in the present proceedings, and in any event within two months of the date of notification of such ~~decision~~Decision, all measures that it intends to take to comply with this Annex and the ~~decision~~Decision in sufficient detail to enable the Commission to assess whether the measures are prima facie suitable to address the requirements of the ~~decision~~Decision ("Initial Implementation Report"). The Initial Implementation Report shall, for each specified measure, include, in particular, the following information: (a) a detailed description of the interoperability solutions that Alphabet intends to make available; (b) a description of how these solutions address all of the measures in ~~the~~this ~~decision~~Annex and how it will provide third parties with effective interoperability under equal conditions to those available to Alphabet's services; (c) if applicable, a description of any integrity measures that Alphabet intends to apply; and (d) a detailed timeline for the design, development, implementation and release of each of the effective interoperability solutions.

Draft ¶ 153 Final ¶ 158

Following the Initial Implementation Report and until the expiry of the implementation deadlines for all features, Alphabet shall provide, on a monthly basis, a report ("Monthly Implementation Report") providing, in detail, for each specified measure, the following information: (a) the envisaged interoperability solutions that Alphabet intends to make available to address each of the specified measures; (b) status on the design, development, implementation and release of each of the interoperability solutions, including whether progress is on schedule and, if not, why not; (c) if necessary, an updated detailed timeline for the design, development, implementation and release of each of the interoperability solutions, including, for instance, beta testing; (d) any potential issue that Alphabet may have encountered during the design, development, implementation or release of each of the envisaged interoperability solutions; (e) a description (including, where necessary, the relevant supporting documents) of Alphabet's engagement with third parties for the purposes, and in the context of, the design, development, implementation and release of each of the interoperability solutions. This shall include: (1) a description of the issues raised by third~~-party~~ ~~developers~~parties that relate to the features and an assessment of whether such issues will require a modification of the interoperability solution, including any relevant rules (e.g. rules on background execution); ~~^{Draft measures note 10}~~^{Final measures note 7} (2) any information and feedback provided to Alphabet by third parties regarding the betas of Alphabet's interoperability solutions; and (3) all interoperability requests made by third parties with regards to all features referred to in Sections 1- to 4 of this Annex. (f) any relevant changes that Alphabet has made or intends to make to policies, requirements and agreements, including the CDD, the GMS requirements, placement agreements, etc.; and (g) a description of how OEMs will apply or have applied customisations, if any, to the interoperability solutions, including any relevant rules (e.g. rules on background execution).

Draft ¶ 154 Final ¶ 159

At least 10 working days prior to any public release in relation to a feature or functionality within the scope of these Proceedings, be it beta testing or the final solution, Alphabet shall communicate its plans to the Commission ("Pre-release Feature Implementation Report").

Draft ¶ 155 Final ¶ 160

Upon expiry of the implementation deadline for each feature, Alphabet shall provide a report ("Final Feature Implementation Report") to the Commission explaining all the measures that it has taken to comply with ~~the~~this ~~final~~Annex ~~decision~~and with the Decision and confirming the date of ~~its~~the public release. Under this obligation, Alphabet shall describe the interoperability solution made available to third parties, including all technical details and potential APIs, as well as any potential integrity measures.

Draft ¶ 156 Final ¶ 161

For two years after expiry of the implementation deadlines for all features, Alphabet ~~should~~shall provide to the Commission, every six months, a report ("Semi-annual Implementation Report") containing the same information as the Monthly Implementation Report in relation to any change that Alphabet has made or intends to make to the interoperability solutions, OEM customisation, and engagement with third parties.

Draft — Final ¶ 162

Alphabet shall include in particular in each of the five types of reports (Initial Implementation Report, Monthly Implementation Report, Pre-release Feature Implementation Report, Semi-annual Implementation Report, and Final Feature Implementation Report) any changes it plans to make or has made, respectively, in relation to any feature listed in the Decision, including any new functionality it plans to add or has added to the feature or any updates it plans to make or has made to such feature or functionalities thereof.

Draft ¶ 157 Final ¶ 163

Alphabet shall provide the Commission with a confidential and a non-confidential version of the Final Feature Implementation Report when each report is due. Upon the Commission's request, Alphabet shall provide the Commission with a non-confidential version of any of the ~~abovementioned~~other reports (Initial Implementation Report, Monthly Implementation Report, Pre-release Feature Implementation Report, ~~Final Feature Implementation Report~~ and Semi-annual Implementation Report) ~~for publication when the report is due~~.

Draft — Final ¶ 164

Alphabet shall cooperate with the Commission to test specific technical solutions and report on the results of the tests with sufficient frequency and granularity to allow the Commission to properly assess the specific technical solution and the test results.

Substantively identical (Commission may modify/substitute measures on Alphabet's reasoned request; request does not suspend implementation deadlines). The final drops the draft's explanatory clause "To ensure the effectiveness and timely implementation of the measures, it is important that ..." in favour of a more direct "The request shall not have the effect of suspending ..." — a stylistic tightening with no substantive difference.

Compare provision wording

View

Draft ¶ 158 Final ¶ 165

The Commission may, in response to a reasoned request from Alphabet showing good cause, modify or substitute one or more of the measures or a part of them. ~~To ensure the effectiveness and timely implementation of the measures, it is important that the~~The request ~~does~~shall not have the effect of suspending the implementation of the measures and, in particular, of suspending the expiry of any time period in which the measure has to be complied with.

Method

The comparison uses the separately published draft measures annex and the Commission's 32-page publication of the final measures. The latter contains the measures adopted in the Article 8(2) decision, but is not the full decision and does not contain the Commission's complete reasoning. All 158 draft and 165 final numbered paragraphs were transcribed and checked against those publications, including the Section 5 chapeau and waiver.

The 26 groups cover all numbered provision bodies. Paragraphs are aligned before words are compared; each source paragraph must occur exactly once. Automated validation reconstructs both sides and checks them against the transcriptions, including whitespace boundaries and footnote references. It rejects omitted or duplicated paragraphs, altered text, stale fingerprints and incomplete note mappings. Page furniture, section headings and terminal ornaments are outside the provision-body redline. PDF line wrapping is removed; subclauses retain separate lines; quotation marks and apostrophes are consistently normalized to straight forms. Source spelling and other punctuation are preserved, including apparent source errors such as “single tab and double tab” in draft note 2.

Paragraph numbers appear outside the word diff. Typography-only changes and matched footnote references are distinguished from substantive insertions and deletions. Earlier-text and final-text views show the respective transcription in source order. Paired source notes allow their wording to be compared. Alignment notes identify split, consolidated and relocated provisions; removal of a standalone provision is not treated as proof that every related entitlement disappeared.

Magnitude concerns the significance of the textual change: “No change” means the obligation is unchanged; “Editorial” covers wording or structure without an identified independent effect; “Minor” covers limited changes in detail; and “Substantive” covers material changes to scope, conditions, protections or duties. “New” and “Dropped” identify provision groups introduced or removed as standalone units. Separate effect labels describe additions, removal, narrowing, expansion, relocation, conditions, clarification and preservation. Deadline movement is recorded independently, so a limited wording change can still carry a material delay. The comparison's material filter includes substantive changes, new or dropped groups, and changed implementation deadlines. The Android timeline retains the calendar dates expressly stated in the measures.

Sources

Legislation

European Parliament and Council Regulation (EU) 2022/1925 of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act) [2022] OJ L 265/1

European Parliament and Council · EU regulation · 14 September 2022

https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng

The dossier concerns the interoperability obligation in Article 6(7).

Administrative proceedings

European Commission, ‘DMA.100220 — Annex — Measures’ (draft measures annex, 27 April 2026)

European Commission · Draft measures annex published with the Preliminary Findings · 27 April 2026

https://ec.europa.eu/competition/digital_markets_act/cases/202619/DMA_100220_2145.pdf

This is the separately published draft measures annex, not the full Preliminary Findings. Pinpoints refer to the annex's sections and numbered paragraphs.
European Commission, ‘DMA.100220 — Alphabet — OS — Google Android — Art 6(7) — SP — AI: Decision of 16 July 2026 — Final Measures’ (provisional non-confidential version, 16 July 2026)

European Commission · Published final-measures extract from the Article 8(2) decision · 16 July 2026

https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100220_2683.pdf

The Commission states that this provisional text was adapted for publication, contains only the final measures and does not constitute the full decision. Only the adopted decision is legally binding. Pinpoints refer to the published measures' sections and numbered paragraphs.
European Commission, ‘Case DMA.100209 — SP — Alphabet — Article 6(11): Decision of 16 July 2026 — Final Measures’ (provisional non-confidential version, 16 July 2026)

European Commission · Published final-measures extract from the Article 8(2) decision · 16 July 2026

https://ec.europa.eu/competition/digital_markets_act/cases/202629/DMA_100209_2712.pdf

Cross-dossier source used only for the balanced comparison in the overview. The publication contains the final measures, not the full decision.

Five feature categories become conditionally subject to certification

Detailed custom-model and customised-hotword guarantees are removed

The standalone read/write rule gives way to an enumerated app guarantee

Implementation deadlines move to later Android releases

Three on-device-model resource guarantees are removed

The express ban on privileged and OEM-controlled restrictions disappears

Neutral access verification and independent dispute resolution are removed

Default public transparency of ongoing reporting is reduced

A consent safeguard is deleted and integrity conditions gain a carve-out

The proactive-suggestions architecture is folded into a narrower feature

Preliminary Findings adopted; draft measures published

Article 8 decision adopted; final measures published

Draft certification programme terms

Final programme terms

Main implementation deadline — Android 18

AOHD concurrency deadline — Android 19

Legislation

Administrative proceedings