The Case of Android Auto – New Developments in the Essential Facilities Doctrine in Digital Markets

As niche as the essential facility doctrine has been in EU competition law, it has recently made a reappearance in the preliminary procedure in the case of Google Android Auto, which carries forward its application to the context of digital platforms. 

• So, what are essential facilities? The Bronner doctrine 

The Bronner case dates back to 1998, when newspaper publisher Oscar Bronner brought action against his rival Mediaprint to request access to its delivery service. The ECJ ruled that under art 86 of the EC Treaty – now article 102 TFEU - Mediaprint’s denial did not amount to an abuse of dominant position. Indeed, the ECJ held that for an abuse of dominant position to exist, it was necessary that: 

(i) the refusal of the service was likely to eliminate all competition in the relevant market,  

(ii) such refusal was incapable of being objectively justified, and  

(iii) the service was indispensable to carrying on that person’s business, as there was no actual or potential substitute for it. 

Over time, the Bronner Doctrine has been developed through case law regarding infrastructure, such as in Lithuanian Railways, which argued that Bronner may not apply if the facility was not created through entrepreneurial risk. Since the Bronner criteria aim to incentivize investment in such facilities, public funding or other means of creation would remove the need for its application.  

In Slovak Telekom, the court ruled that Bronner would not apply where the restriction of access is not the result of an outright refusal but rather of a “constructive refusal” consisting of unfair trading conditions that make access to the respective facility economically non-viable. Indeed, the choice of dominant undertakings to deal with third parties is protected by fundamental rights. However, this protection does not extend to situations where a company imposes unfair or exploitative trading conditions. 

• Essential Facilities in Digital Markets. The case of Microsoft 

In the context of digital markets, also interoperability has been deemed an essential facility if the technical means of access to a dominant company’s platform were seen as indispensable for competitors to operate in the same market. This is best exemplified by the Microsoft Interoperability Case.  

The main issue was Microsoft's refusal to provide competitors with the necessary interoperability information for its Windows operating system. The Commission argued that this refusal prevented competitors from developing software that could effectively work with Microsoft's software, thus maintaining Microsoft's monopoly in the market for workgroup server operating systems. The Commission ruled that Microsoft had violated EU competition law, specifically Article 82 EC (now Article 102 TFEU), which prohibits the abuse of a dominant market position. It served as a landmark case, establishing significant principles concerning refusal to deal and the obligation of dominant undertakings to provide access to certain essential facilities or information that are indispensable for competition, especially when the refusal harms consumers. 

In this case, the concept of interoperability became central to the argument. Interoperability refers to the ability of different systems or software to work together, exchange data, and function effectively in a shared environment. In the context of the Microsoft case, it was argued that Microsoft’s refusal to share certain technical information with competitors meant that those competitors were unable to ensure their products worked smoothly with Microsoft’s dominant Windows operating system. By refusing to grant access to interoperability information, Microsoft was considered to be using its control over a critical resource. 

• Android Auto and AG Medina’s proposal 

The recent preliminary ruling1 on the Android Auto Case is likely to become part of this developmental process, further applying the Bronner Doctrine to digital platforms. 

The conflict in Google Android Auto centres on Google's refusal to grant ENEL access to its Android Auto platform for its Juicepass app, which allows electric vehicle owners to find charging stations, navigate to them, and manage the charging process. Android Auto, by design, is open to third-party apps but requires access to certain technical resources (APIs or templates) for third-party developers to integrate their apps. At the time of the request, the only available templates were those for media and messaging apps, as well as for Google’s own navigation apps (Maps and Waze). Even though ENEL's app was compatible with Android OS on smartphones, Google informed ENEL that it could not grant access to Android Auto because the needed technical templates had not been developed. ENEL filed a complaint, and the AGCM (Italian competition authority) found that Google’s refusal constituted an abuse of its dominant position under Article 102 TFEU. The AGCM imposed a €102 million fine. Google appealed, and the case was referred to the ECJ for clarification on the application of the essential facility doctrine in this context. 

Much like Microsoft at the time, Android Auto holds a dominant position in its specific sector—in-car connectivity. For third-party developers to create apps that work seamlessly with Android Auto, they need access to certain interoperability information (such as technical specifications or APIs). The central question is whether Google, as a dominant platform operator, should be forced to share this information with developers who wish to create competing or complementary apps. 

The Italian Authority's decision on Android Auto against Google is based on criteria from the ECJ judgment in the Bronner – and later Microsoft Case.  

However, Advocate General Medina, in her Opinion, concluded that the Bronner conditions would not apply, as the platform in question was not developed by the dominant undertaking for its exclusive use, but was instead created with the intention of being populated by third-party developers' apps. 

Unlike Microsoft, Google Android is, in essence, an open-source software platform intended for development with the collaboration of third parties and, crucially, was created to encourage third-party participation. In this regard, the success and sustainability of the platform depend on its popularity with third parties, and by extension, on their access to it. In other words, the Android Auto platform's nature and the logic of its business model are fundamentally based on third parties developing apps for it. Therefore, according to the AG, the decision to grant third-party access was effectively made when Google chose to create the platform. 

The reasoning here is that if a platform is designed to serve third parties and may not survive without their participation, it can be assumed that access to it is inherently granted as a matter of principle. Referring back to the balancing test in Bronner, this would suggest that the dominant undertaking—in this case, Google—exercised its fundamental right by opening the platform to third parties, rather than denying them access. As a result, there would be no need to apply the Bronner test if access is later refused. Moreover, in such situations, the refusal cannot be aimed at reserving the facility (the Android Auto platform) exclusively for the dominant undertaking. 

According to the AG, this shift in the competitive dynamic requires a different legal approach. The refusal should be evaluated by determining whether the platform owner is excluding, hindering, or delaying a third-party app's access, resulting in anti-competitive effects that harm consumers and cannot be objectively justified. The AG concluded that, even if Enel X has survived and remained operational in the market, Google cannot use this as a basis to avoid liability. 

The Opinion emphasizes that exceptions to EU law must be interpreted narrowly. In the context of Article 102 TFEU, this means that exceptions to the prohibition of abuse of a dominant position must also be interpreted restrictively. 

Regarding the refusal to grant access to a platform, where such refusal results in anti-competitive effects—which the AG assumes in her Opinion—only justifications that directly affect the platform's functioning and purpose will be accepted. This means that any objective justification put forward by Google that does not relate to the platform's proper operation or purpose cannot be upheld. However, the AG acknowledges that, if the development of a specific template is technically impossible, this would serve as a valid objective justification. 

The AG outlines the burden of proof in cases involving objective justifications. It is the responsibility of the competition authority to establish the existence of an infringement under Article 102 TFEU. However, once an infringement is identified, the dominant company must present any objective justifications and support them with concrete evidence and reasoning. Only after this does it fall back on the competition authority to demonstrate that the company’s arguments and evidence are insufficient, and that the justification cannot be accepted.  

Google had argued that creating the required template would take time and resources, and that immediate integration of JuicePass was not feasible. The AG clarified that an undertaking can invoke an objective justification for refusing access, provided it is necessary and proportionate. On the issue of time constraints, Google cannot merely claim time limitations. It must demonstrate that it has informed the third-party requesting access about the time required to develop the necessary template. This time can be as long as objectively needed. Other factors, (such as the impact of COVID-19), may also be considered when assessing the time frame. If the competition authority determines the time frame is unjustified, it cannot serve as a valid objective justification for refusing access. 

Similarly, the AG noted that resource constraints must be evaluated in terms of the costs involved in developing the template and who bears them. While the costs must be estimated objectively, the dominant company is not required to bear them—it is acceptable for the requesting entity to cover these costs. However, if the competition authority finds them to be excessive or disproportionate, the dominant company's justification based on resources will not be accepted. 

Medina’s reasoning goes beyond the approach taken in Google Shopping, where the CJEU distinguished between outright refusals of access and discriminatory conditions. Instead, Medina focuses on the nature of the platform itself—namely, its openness. For Android Auto, the platform is designed to be "open" to in-car apps, making a refusal to grant access contrary to its business model and competitive purpose. However, the concept of openness is not always clear-cut. While some platforms are designed with the express goal of facilitating external contributions, others may exhibit more closed characteristics, selectively allowing third-party involvement. 

This raises the concern that AG Medina’s binary approach—distinguishing between "open" and "closed" platforms—may fail to account for the nuances of different platforms. Platforms may vary in terms of their degree of openness, and requiring access in all cases could interfere with their ability to maintain quality or focus on its core purpose. 

Furthermore, the AG’s proposed model is based on the assumption that all parties would act in good faith – which is unlikely to always be the case. This model would not prevent litigation, but shift it to a later point in time, for example the requesting party could try to argue that costs are unreasonable in an attempt to lower them.  

Overall, AG Medina’s Opinion appears to circle back to contract law, as she envisions a formalised trade-off between platform operators and developers, where tailored access to develop interfaces is granted in exchange for financial compensation.  Just like a contract, this arrangement establishes specific terms—namely, the provision of access and the monetary contribution—that would govern the relationship between the parties involved. The platform operator is effectively agreeing to facilitate access under certain conditions, much like a contractual obligation, just as the developer is bound to pay the due compensation.   

It very much follows the basic principles of a contract, where the rights and obligations of the parties are determined by negotiation and agreement, and the enforcement of those obligations can be pursued if terms are not met. 

The contents of the article represent solely the ideas and opinions of the author and in no way the opinions of Bocconi University or the IUS@B association.