Competition Law And Vehicle Operating System Competition Issues

 

Competition Law and Vehicle Operating System Competition Issues

Introduction

A Vehicle Operating System (Vehicle OS) is the software layer that manages or coordinates vehicle infotainment, navigation, applications, connectivity, voice assistants, vehicle functions, data flows and, increasingly, software-defined vehicle functions. Examples of relevant technological ecosystems include Android Automotive/Google Automotive Services, Apple CarPlay, BlackBerry QNX, Huawei HarmonyOS and manufacturer-developed operating systems.

Competition-law issues arise because a Vehicle OS can become a gateway between vehicle manufacturers, application developers, service providers, consumers and vehicle data. Control over that gateway may permit an operator to exclude rivals, impose defaults, bundle services, restrict interoperability, exploit data advantages or make switching difficult.

The most directly relevant modern authority is the Google Android Auto/Enel X litigation, culminating in the 2025 judgment of the Court of Justice of the European Union in Alphabet and Others, C-233/23.

1. Meaning of Vehicle Operating System Competition

A Vehicle OS may perform several functions:

  1. Infotainment management
  2. Navigation and mapping
  3. Voice-assistant integration
  4. Application distribution
  5. Smartphone integration
  6. EV charging applications
  7. Vehicle-data management
  8. Over-the-air software updates
  9. Digital-payment integration
  10. Interfaces with ADAS and autonomous-driving systems
  11. Integration with cloud services
  12. Interfaces for third-party developers.

The competitive problem arises when the OS operator controls an essential digital gateway through which competing applications or services must reach vehicle users.

For example, Google Automotive Services can combine Google Maps, Google Play and Google Assistant with Android Automotive OS. The German Bundeskartellamt identified concerns about bundling, default settings, preferential presentation and interoperability in relation to Google's automotive services.

2. Relevant Competition Markets

Several overlapping markets may need to be considered.

A. Vehicle OS market

Competition may exist between:

  • Android Automotive;
  • QNX;
  • Huawei HarmonyOS;
  • proprietary manufacturer systems;
  • Linux-based systems;
  • other specialised automotive operating systems.

B. Automotive application-platform market

The OS can constitute a platform through which:

  • navigation apps;
  • charging apps;
  • entertainment apps;
  • payment apps;
  • voice assistants;
  • parking applications

reach consumers.

C. Vehicle data market

Vehicle OS operators may obtain access to:

  • location data;
  • driving data;
  • charging data;
  • vehicle-condition data;
  • infotainment preferences;
  • energy-consumption data.

Control over such data may create competitive advantages in downstream markets.

D. Digital services markets

The OS may be used to extend market power into:

  • mapping;
  • advertising;
  • music;
  • charging;
  • insurance;
  • repair;
  • navigation;
  • digital payments.

3. Major Competition-Law Issues

I. Dominance of the Vehicle OS

A Vehicle OS operator may acquire substantial market power because manufacturers and consumers face:

  • network effects;
  • high development costs;
  • safety certification requirements;
  • compatibility requirements;
  • developer dependence;
  • long vehicle lifecycles;
  • data advantages.

A dominant OS operator does not automatically violate competition law. The concern arises when dominance is used to exclude competitors or restrict market access.

4. Refusal of Interoperability

One of the most important issues is whether a Vehicle OS operator can refuse to make its platform interoperable with competing applications.

For example:

A charging-service provider develops an EV charging application but the dominant Vehicle OS refuses to provide the technical interface necessary for the application to operate through the vehicle display.

The issue can involve:

  • refusal to deal;
  • denial of access;
  • essential-facility principles;
  • interoperability obligations;
  • exclusionary abuse.

The modern legal significance of this issue is demonstrated by Alphabet and Others v AGCM.

5. Case Law 1 — Alphabet Inc. and Others v AGCM, C-233/23

Court

Court of Justice of the European Union, Grand Chamber, 25 February 2025.

Facts

Enel X developed the JuicePass application for EV charging services. It requested interoperability with Google's Android Auto platform.

Google initially did not provide the necessary interoperability solution. Google Maps, however, was available on Android Auto.

The Italian Competition Authority found an infringement of Article 102 TFEU and imposed a substantial fine and interoperability-related remedies.

Legal Issue

Whether a dominant undertaking's refusal to ensure interoperability between its digital platform and a third-party application can constitute an abuse of dominance.

Decision

The CJEU held that Article 102 TFEU must be interpreted in a manner allowing competition authorities to examine whether refusal of interoperability can hinder competition.

Importantly, the Court stated that the downstream market potentially affected by the refusal does not necessarily have to be defined with the same precision required in every conventional market-definition exercise.

Significance for Vehicle OS

This is the most directly relevant authority for Vehicle OS competition.

It demonstrates that:

  • interoperability can be a competition-law issue;
  • technical access may be commercially important;
  • digital platforms can constitute gateways to downstream markets;
  • exclusion may occur even where the platform itself is not the conventional downstream product;
  • competition authorities can examine potential downstream competitive effects.

6. Case Law 2 — Bronner v Mediaprint, C-7/97

Court

Court of Justice of the European Union.

Principle

The case established important principles concerning refusal to provide access to an infrastructure controlled by a dominant undertaking.

An obligation to supply is exceptional and traditionally requires consideration of factors including:

  1. indispensability;
  2. absence of realistic alternatives;
  3. potential elimination of competition;
  4. objective justification.

Application to Vehicle OS

A Vehicle OS provider may argue:

"Developers can use other platforms, so we have no obligation to provide access."

The competitor may respond that the dominant OS has become indispensable because:

  • it is installed in a large proportion of vehicles;
  • users cannot easily change the OS;
  • vehicle manufacturers are locked into long-term contracts;
  • competing applications cannot independently access the vehicle display;
  • safety certification makes duplication expensive.

Thus, Bronner remains relevant to Vehicle OS interoperability disputes, although modern digital-platform cases have developed the analysis further.

7. Case Law 3 — IMS Health v NDC Health, C-418/01

Court

Court of Justice of the European Union.

Principle

The case concerned access to a commercially important infrastructure and the exceptional circumstances under which refusal of access may constitute abuse.

The Court examined whether refusal of access could prevent the emergence of a new product for which consumer demand existed.

Vehicle OS relevance

This principle is particularly important where a Vehicle OS prevents innovative applications from entering the market.

For example:

A Vehicle OS allows only its own charging application to access vehicle-level charging controls while excluding independent charging platforms.

The competitor could argue that denial of access prevents a new or improved product from reaching consumers.

The case therefore supports analysis of:

  • innovation;
  • access;
  • indispensability;
  • new products;
  • consumer demand.

8. Case Law 4 — Microsoft Corp. v Commission, T-201/04

Court

General Court of the European Union.

Principle

Microsoft involved interoperability information and the ability of competing products to operate effectively with a dominant platform.

The case is highly important for understanding how a dominant technology platform can affect competition in neighbouring markets through technical interfaces.

Vehicle OS relevance

A Vehicle OS can similarly become the technical environment upon which competing products depend.

Potential examples include:

  • third-party voice assistants;
  • navigation applications;
  • charging platforms;
  • music applications;
  • payment systems;
  • vehicle-data applications.

If the OS operator supplies its own downstream service while restricting interoperability for competing services, competition authorities may examine whether the technical architecture is being used to protect or extend market power.

9. Case Law 5 — Google Android, Case AT.40099

Authority

European Commission.

Subject

The Commission examined Google's conduct concerning the Android mobile operating-system ecosystem.

The investigation involved issues including:

  • tying;
  • pre-installation;
  • default settings;
  • restrictions concerning competing Android versions;
  • leveraging OS-related market power into adjacent services.

Vehicle OS relevance

The legal reasoning has strong relevance to automotive ecosystems.

A Vehicle OS provider might condition access to:

Android Automotive → Google Play → Google Maps → Google Assistant

or require manufacturers to adopt particular combinations of services.

This can create concerns about:

Tying

The manufacturer wants the operating system but must also take particular services.

Default bias

The manufacturer's vehicle displays the OS operator's services more prominently.

Anti-forking restrictions

A manufacturer may face contractual restrictions on supporting alternative versions or competing operating systems.

Leveraging

Market power in the OS is used to strengthen a position in:

  • mapping;
  • advertising;
  • voice assistance;
  • application distribution;
  • payments.

The Android case therefore provides an important analytical framework for automotive OS competition.

10. Case Law 6 — United States v Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001)

Court

U.S. Court of Appeals for the District of Columbia Circuit.

Core Issue

Microsoft's control over the Windows operating-system platform and its conduct affecting competing technologies were examined under U.S. antitrust law.

Importance

The case illustrates the danger of using control over a platform to disadvantage technologies that might become competitive threats.

Vehicle OS application

A dominant Vehicle OS could potentially use:

  • technical restrictions;
  • contractual restrictions;
  • APIs;
  • developer access;
  • default settings;
  • proprietary interfaces

to prevent competing services from developing.

For example, an OS provider could theoretically prevent a competing voice assistant from controlling navigation or vehicle functions while permitting its own assistant to do so.

The relevant question would be whether such restrictions constitute legitimate product design or exclusionary conduct.

11. Case Law 7 — Intel Corp. v Commission, C-413/14 P

Court

Court of Justice of the European Union.

Principle

The case concerns exclusionary rebates and the assessment of whether conduct by a dominant undertaking is capable of restricting competition.

Vehicle OS relevance

Vehicle OS companies may negotiate with automobile manufacturers through:

  • exclusivity arrangements;
  • preferential placement;
  • revenue sharing;
  • long-term contracts;
  • rebates;
  • technical incentives.

For example:

An OS supplier provides financial incentives to a vehicle manufacturer on condition that competing operating systems or voice assistants are not installed.

This could raise questions concerning exclusionary effects, depending on market structure, duration, coverage and actual contractual conditions.

The case is therefore relevant to exclusive Vehicle OS agreements, even though it does not itself concern vehicles.

12. Bundling of Vehicle OS and Services

Bundling can occur at several levels:

Vehicle OS + App Store

Vehicle OS + Maps

Vehicle OS + Voice Assistant

Vehicle OS + Cloud

Vehicle OS + Advertising

Vehicle OS + Payment System

Competition concerns arise if competitors cannot obtain the OS without accepting the dominant firm's complementary products.

The German Bundeskartellamt's 2023 preliminary assessment concerning Google Automotive Services specifically examined bundling and the possibility that bundling could extend Google's power into markets that remained competitive.

13. Default-Setting and Self-Preferencing

A vehicle's interface is extremely important because consumers generally interact with only a limited number of applications while driving.

A Vehicle OS provider could give its own service:

  • first position;
  • larger display;
  • automatic activation;
  • default navigation status;
  • default voice-assistant status;
  • preferential API access.

This can produce self-preferencing concerns.

For example:

Google Maps appears automatically while competing navigation services require several additional steps.

Even without an explicit exclusion, user behaviour may shift toward the default.

The Bundeskartellamt specifically identified concerns about Google requiring Google services to be set as defaults or displayed ahead of competing applications in automotive infotainment systems.

14. Anti-Forking Restrictions

A Vehicle OS may be open-source at one level while proprietary services remain controlled by the OS provider.

This produces an important competition question:

Can a vehicle manufacturer create a competing version of the operating system?

Anti-forking restrictions may prevent manufacturers from:

  • modifying the OS;
  • creating alternative versions;
  • supporting competing platforms;
  • developing an independent ecosystem.

Such restrictions may become problematic if they substantially restrict the emergence of competing Vehicle OS ecosystems.

The issue is analogous to the anti-fragmentation concerns examined in the Android competition proceedings.

15. Application Programming Interface (API) Access

APIs are critical to Vehicle OS competition.

An API may allow a third-party application to interact with:

  • navigation;
  • vehicle display;
  • battery information;
  • charging;
  • climate controls;
  • voice controls;
  • payment functions.

A dominant OS provider could provide extensive APIs to its own applications but limited APIs to competitors.

This produces a potential input foreclosure problem.

Example

Suppose:

Manufacturer's OS → Full battery API → Manufacturer charging service

but:

Independent charging app → Limited API → Cannot access essential charging information.

This could disadvantage independent competitors.

16. Data Advantage and Competition

Vehicle OS operators may obtain enormous quantities of data.

Relevant information may include:

  • vehicle location;
  • charging behaviour;
  • route history;
  • energy consumption;
  • vehicle diagnostics;
  • driver preferences;
  • application usage;
  • purchasing behaviour.

Data can generate competitive advantages through:

Network effects

More vehicles → more data → better service → more users → more vehicles.

Economies of scale

A larger dataset may improve:

  • navigation;
  • predictive maintenance;
  • advertising;
  • charging optimisation.

Leveraging

Data gathered through the OS could potentially be used to compete in adjacent markets.

Competition law may therefore intersect with data-access, privacy and interoperability regulation.

17. Switching Costs

Vehicle OS competition differs from ordinary software markets because vehicles may remain in service for many years.

Switching may require:

  • replacing hardware;
  • re-certification;
  • redesigning vehicle architecture;
  • retraining developers;
  • changing cloud infrastructure;
  • renegotiating supplier agreements.

Consequently, a manufacturer choosing one OS may effectively commit to that ecosystem for a long period.

High switching costs can make incumbent market power more durable.

18. Network Effects

Vehicle OS platforms benefit from two-sided or multi-sided network effects.

More manufacturers

↓

More vehicles

↓

More users

↓

More developers

↓

More applications

↓

Greater consumer attraction

↓

More manufacturers adopt the OS.

This creates a feedback loop.

Once a platform reaches significant scale, a rival may find it difficult to compete even if its technology is technically superior.

19. Interoperability as a Competition Remedy

Competition authorities may impose remedies such as:

  1. mandatory API access;
  2. interoperability requirements;
  3. non-discriminatory developer access;
  4. prohibition of exclusive contracts;
  5. removal of default restrictions;
  6. data-portability requirements;
  7. prohibition of tying;
  8. separation of services;
  9. transparent technical standards;
  10. monitoring by an independent trustee.

The Alphabet/Enel X case is particularly important because the remedy required Google to make tools available for applications interoperable with Android Auto.

20. Vehicle Manufacturer as a Dependent Customer

Competition analysis should not focus exclusively on consumers.

Vehicle manufacturers may themselves be dependent on an OS provider.

A manufacturer may require:

  • a ready-made OS;
  • app ecosystem;
  • cloud connectivity;
  • navigation;
  • voice recognition;
  • cybersecurity updates;
  • developer support.

This creates vertical bargaining power.

A powerful OS supplier could potentially impose:

  • high licensing costs;
  • exclusivity;
  • revenue-sharing requirements;
  • data-access requirements;
  • restrictions on alternative software;
  • technical conditions.

21. Competition Between Apple and Google Ecosystems

The Vehicle OS environment can involve several layers:

LayerCompetitive issue
Vehicle OSMarket concentration
App storeAccess discrimination
MapsSelf-preferencing
Voice assistantTying
ChargingInteroperability
AdvertisingData leverage
Vehicle dataData foreclosure
CloudBundling
PaymentsPlatform access
APIsTechnical discrimination

Therefore, Vehicle OS competition is not merely competition between operating systems. It is competition between entire digital ecosystems.

22. Safety as an Objective Justification

Vehicle OS operators may legitimately argue that restrictions are necessary for:

  • road safety;
  • cybersecurity;
  • driver distraction;
  • system reliability;
  • protection against malicious applications;
  • functional compatibility.

Competition law does not require unlimited interoperability.

The important question is whether the restriction is:

  1. genuinely necessary;
  2. proportionate;
  3. consistently applied;
  4. technologically justified;
  5. non-discriminatory.

A safety argument becomes more problematic where the OS provider permits its own application to perform a function while refusing substantially equivalent access to competitors.

23. Competition and Autonomous Vehicles

Vehicle OS competition becomes even more significant with autonomous and software-defined vehicles.

The OS may eventually control:

  • perception systems;
  • sensor integration;
  • vehicle decision systems;
  • navigation;
  • autonomous-driving applications;
  • cloud-to-vehicle communication;
  • vehicle-to-infrastructure communication.

This creates potential competition concerns involving control over technological infrastructure.

A dominant OS could potentially become a gatekeeper for an entire autonomous-driving ecosystem.

24. Competition Issues in EV Charging

EV charging provides a particularly clear example.

A Vehicle OS could integrate:

Vehicle → Navigation → Charging station → Reservation → Payment.

If the OS gives its own charging service preferential access, competing charging providers could be disadvantaged.

The Alphabet/Enel X litigation demonstrates precisely why interoperability between vehicle-facing platforms and charging applications can become a competition issue.

25. Vertical Foreclosure

Vehicle OS competition can involve two forms of foreclosure.

Input foreclosure

A dominant OS prevents competitors from obtaining necessary technical access.

Customer foreclosure

A dominant OS prevents manufacturers or consumers from using competing services.

Example:

OS provider → vehicle manufacturer → exclusive voice assistant

This could make entry into the vehicle voice-assistant market more difficult.

26. Relevant Competition-Law Theories

ConductPossible competition concern
Refusal of API accessAbuse of dominance
Refusal of interoperabilityExclusionary conduct
Mandatory bundlingTying
Exclusive contractsForeclosure
Preferential defaultsSelf-preferencing
Discriminatory APIsInput foreclosure
Anti-forking provisionsRestriction of platform competition
Data withholdingData foreclosure
Preferential rankingLeveraging
Exclusive app-store accessPlatform foreclosure
Loyalty rebatesExclusionary rebates
Technical degradationDiscriminatory treatment
Excessive switching costsEntrenchment of dominance

27. Indian Competition-Law Perspective

For India, Vehicle OS disputes can principally be examined under the Competition Act, 2002, particularly:

Section 3

Anti-competitive agreements, including:

  • exclusive arrangements;
  • restrictive vertical agreements;
  • tying;
  • refusal-to-deal arrangements.

Section 4

Abuse of dominant position, including:

  • unfair conditions;
  • discriminatory conditions;
  • limiting technical development;
  • denial of market access;
  • leveraging dominance into another market.

Section 5

Combination regulation becomes relevant when major technology companies, automobile manufacturers or automotive software providers undertake acquisitions.

Section 19

The Competition Commission of India may investigate alleged contraventions.

The Indian analysis would therefore require examination of both the technology market and the relevant downstream automotive-service market.

28. Hypothetical Example

Assume Company A operates a dominant Vehicle OS.

It owns:

  • navigation;
  • app store;
  • voice assistant;
  • charging application.

An independent company develops a superior EV-charging application.

Company A:

  1. refuses API access;
  2. makes its own charging app the default;
  3. gives its own application privileged vehicle-data access;
  4. requires manufacturers to accept its voice assistant;
  5. prohibits manufacturers from supporting a competing OS.

Potential issues include:

  • refusal to deal;
  • interoperability foreclosure;
  • tying;
  • self-preferencing;
  • exclusive dealing;
  • leveraging;
  • discriminatory access;
  • data foreclosure.

The strongest legal analysis would examine dominance, foreclosure effects, indispensability, objective justification, efficiencies and proportionality rather than treating every restrictive practice as automatically unlawful.

29. Six Core Case Laws — Quick Revision Table

CasePrincipleVehicle OS relevance
Alphabet v AGCM, C-233/23 (2025)Digital-platform interoperability and refusal of accessDirect Android Auto/EV charging precedent
Bronner, C-7/97Exceptional conditions for compulsory accessOS/API access
IMS Health, C-418/01Access to indispensable infrastructure and new productsInnovative vehicle applications
Microsoft v Commission, T-201/04Interoperability and platform leverageOS interfaces and competing services
Google Android, AT.40099Tying, defaults, anti-fragmentation and leveragingAutomotive OS ecosystem
United States v Microsoft, 253 F.3d 34Platform power and exclusion of technological rivalsCompeting Vehicle OS technologies
Intel v Commission, C-413/14 PExclusionary effects of dominant-firm rebatesExclusive automotive OS arrangements

30. Key Legal Principles Emerging from the Cases

Principle 1 — OS dominance can extend beyond the OS itself

Market power in the operating system can affect downstream services.

Principle 2 — Interoperability can be competitively significant

The Alphabet/Enel X litigation establishes the importance of access to a dominant digital platform in the automotive context.

Principle 3 — Defaults matter

A service may gain substantial market advantage simply by being pre-installed or automatically selected.

Principle 4 — Bundling can extend market power

Combining OS, maps, app stores and voice assistants can potentially disadvantage competing services.

Principle 5 — Technical restrictions may constitute exclusion

APIs, templates and software interfaces can become competition-law instruments.

Principle 6 — Safety does not automatically justify discrimination

Safety and cybersecurity can be legitimate justifications, but their application must be assessed objectively.

Principle 7 — Data can reinforce OS dominance

Access to vehicle data can create significant economies of scale and network effects.

Principle 8 — Remedies may require interoperability

Competition authorities may require technical access rather than merely imposing monetary penalties.

Conclusion

Vehicle Operating System competition is emerging as a major branch of digital and automotive competition law. The critical issue is the transformation of the Vehicle OS from a technical software component into a gateway controlling access to consumers, applications, data and vehicle functions.

The most important direct authority is Alphabet and Others v AGCM, C-233/23 (2025), arising from Google's Android Auto and Enel X's EV-charging application. The judgment demonstrates how traditional Article 102 TFEU principles concerning dominance and refusal of access can operate in a modern automotive digital ecosystem.

The principal competition risks are therefore interoperability restrictions, API discrimination, tying and bundling, default bias, self-preferencing, anti-forking restrictions, exclusive agreements, data foreclosure, switching barriers and leveraging of Vehicle OS power into adjacent markets. As vehicles become increasingly software-defined, these issues are likely to involve not only infotainment but also charging, payments, autonomous driving, vehicle data and cloud-based services.

 

 

LEAVE A COMMENT