The Hidden Constraint: Models, Chips, and Background Time
The Android interoperability measures do not treat AI capability as a matter of permissions alone. This chapter focuses on the less visible resources that determine whether a third-party assistant can actually deliver what the action layer promises: access to system-level on-device models, the ability to install and run other models, timely CPU/GPU/NPU and memory allocation, and enough background execution to finish a task. Readers can use that distinction to judge parity in practice, where latency, reliability, battery use, and thermal limits matter as much as an API's existence.
An assistant might know which app to open and which function to call, yet still fail because the model is unavailable, the needed memory is not resident, or the operating system pauses the process while the user is looking elsewhere. In the Commission's design, those are not merely engineering inconveniences. They are part of the operating system's allocation of capability between Google's service and its competitors.
Two ways to share the model layer
The first route is access to system-level on-device models. The final measures cover the Gemini Nano model family, including variants and successor models performing a similar role, Gemma on-device models, and other models made available through AICore or a successor Android solution. Third-party services must be able to discover these models, access and use them, and customise their functionality and output under conditions comparable to Google's services.
This is different from giving an assistant a generic cloud-model endpoint. A system-level model is already part of the device's software and hardware environment. Its availability can affect how quickly an assistant responds, whether it can work when the phone is offline, and how much data needs to leave the device. The supplied measures do not establish the performance or privacy outcome of any future implementation, but they make the underlying model layer part of the parity question rather than allowing Google's service to depend on it invisibly.
The decision is broad about use cases. Alphabet must allow third-party services or hardware to use system-level on-device models for all use cases that Alphabet supports at the system level, subject to restrictions that apply equally to Alphabet's own services and hardware. Access conditions must be transparent, objective, precise, and non-discriminatory, including for uses that Alphabet itself does not offer. That last point matters: a competitor is not limited to copying the exact product features Google has already chosen to expose.
There is still a boundary around internal operating-system components. Alphabet is not required to make available functionality that is available only to those internal components. This prevents the parity rule from being read as a demand to expose every private implementation detail. The requirement concerns the system-level model feature and its functional access, not an unlimited claim on everything Android uses internally.
The second route is for a provider to bring an on-device model of its own. The measures cover the ability to install, run, and use models and the software that implements them, to obtain timely access to specialised hardware, and to make a model available centrally to other applications. A service might therefore host a model and allow another app to use it, rather than forcing every app in the ecosystem to maintain a separate copy or a separate private integration.
That distinction separates model choice from model hosting.