In a previous post we covered some personal perspectives about developing apps for car IVIs based on Android Automotive OS. In this post, we will talk about developing software in the automotive industry. We will enumerate the different stakeholders involved and their relationships. This will make it easier to understand the current ecosystem of app stores targeting Android Automotive OS. We will describe the different app store alternatives and slightly show how to create a developer account. Then, we will also summarize some of the information about car models available in the stores. Finally, we will end with some conclusions about how I foresee the evolution of this interesting ecosystem.
Software in the automotive industry
Traditionally, automotive software integration has been a highly hierarchical and controlled process, fundamentally different from the more agile software development environments most mobile developers are accustomed to. Imagine a pyramidal structure where OEMs sit at the top, meticulously controlling every aspect of vehicle software.
At the pinnacle are the OEMs like Volkswagen, BMW, and Toyota. These manufacturers have historically viewed their vehicle’s electronic systems as proprietary and mission-critical infrastructure. Software wasn’t just a feature, but a strategic asset. In this model, an OEM would typically develop core systems internally or through extremely close partnerships with Tier 1 suppliers.
Tier 1 suppliers like Bosch, Continental and Harman represent the next layer. These are massive engineering companies that work directly with OEMs to develop integrated systems. They don’t just provide components, they design entire subsystems like infotainment, driver assistance, and connectivity platforms. A Tier 1 supplier might spend years developing a specific vehicle’s electronic control unit (ECU) or infotainment system, working in close collaboration with the OEM’s engineering teams.
Third-party developers traditionally had extremely limited access in this ecosystem. Unlike the mobile app world where developers can create apps relatively freely, automotive software required extensive certifications, safety approvals, and often direct contracts with OEMs or Tier 1 suppliers. The barriers to entry were immense: complex certification processes, specialized hardware knowledge, automotive-grade software standards and significant upfront investment.
To illustrate, consider how a simple navigation app would be integrated in this traditional model. Instead of downloading an app like on a smartphone, the navigation system would be:
- Developed by a Tier 1 supplier.
- Extensively tested by the OEM.
- Potentially custom-branded for that specific vehicle manufacturer.
- Integrated deeply into the vehicle’s core systems.
- Subject to automotive-specific safety and performance standards.
This approach prioritized reliability and safety over innovation. Each software component underwent years of testing and validation, which made the development cycle incredibly slow compared to consumer software markets.
The emergence of Android Automotive OS represents a radical shift in this paradigm. By providing a standardized, open platform, it allows for:
- Faster software development.
- More flexible app integration.
- Lower barriers to entry for developers.
- More consumer-like update and deployment models.
For developers accustomed to mobile or web development, understanding this traditional automotive software ecosystem is crucial. It explains why automotive software development has been so different and why platforms like Android Automotive OS are so transformative.
However, it is hard to move OEMs from one extreme to the other. This is what we are currently seeing just in the App Store landscape. Many OEMs still want to have full control of the apps that reach customers in their vehicles. They know of the potential revenue stream that it can bring and don’t want to give this control to tech companies like Google.
Android Automotive app stores stakeholders and market purposes
To understand the complex ecosystem of app publishing for AAOS, we must examine the intricate web of interests and motivations driving each stakeholder. Each player enters this landscape with distinct strategic objectives, creating a delicate balance of collaboration and competition. Let’s try to distill the way they interrelate to each other and how market purposes shape those relationships.
As the main contributor and guardian of Android Automotive OS, Google’s primary motivation is ecosystem expansion and data collection. By providing Android Automotive OS, they’re essentially creating a standardized platform that allows them to extend their software ecosystem beyond mobile devices into vehicles. Their revenue model isn’t directly from app sales, but from:
- Collecting usage data.
- Promoting Google services.
- Creating a platform where developers can innovate.
- Establishing long-term automotive technology relevance.
OEMs
For vehicle manufacturers, the app ecosystem represents both an opportunity and a potential threat. They seek to:
- Maintain control over the user experience.
- Generate additional revenue streams.
- Differentiate their vehicles through unique software offerings.
- Reduce development costs by leveraging a standardized platform.
OEMs are walking a fine line between openness and control. They want attractive apps that enhance vehicle value, but they’re cautious about losing their traditional gatekeeping role in vehicle software. This explains why many are creating their own app stores or partnering with purchasing white-label solutions.
Android Automotive OS app developers
AAOS developers face a more complex market compared to mobile app development. The relatively small but growing market means developers must be strategic. Unlike the mobile app world with billions of potential users, automotive apps might only target hundreds of thousands of vehicles initially and therefore monetization and growth have to be well considered in advance.
The potential monetization strategies include:
- Direct app sales.
- Subscription models.
- Freemium features specific to automotive contexts.
- Corporate partnerships with OEMs or Tier 1 suppliers.
All these points involve a lot of communication with OEMs, which can be daunting. Being a small developer can be tough in this ecosystem, mostly because OEMs / Tier 1 suppliers will only pay attention if your app is a popular one, e.g., Spotify.
Tier 1 suppliers
Tier 1 suppliers like Bosch, Continental and Harman are positioning themselves as crucial intermediaries. They’re attempting to:
- Develop middleware solutions.
- Create standardization layers.
- Offer white-label app development services.
- Help OEMs and developers navigate complex integration challenges.
These suppliers recognize that they can profit by solving integration complexities that individual developers or OEMs find challenging.
Vehicle customers
Customers ultimately drive the ecosystem’s evolution. They expect:
- Seamless app experiences similar to smartphones or other experiences like Android Auto and CarPlay.
- Safety-validated applications.
- Intuitive interfaces and apps that simply work.
- Valuable features that enhance driving experience.
- Up to date apps, not clutter.
Their adoption and feedback will significantly influence the ecosystem’s development. Something that OEMs usually forget is that vehicle customers are mobile users as well. That means that they expect a similar experience to the one offered by Google Play or the App Store.
Stakeholder collaboration
Each stakeholder must find a way to extract value while contributing to the overall ecosystem’s growth. This isn’t a zero-sum game but a complex and interdependent network. In my eyes, the most successful approach will likely involve collaborative models where:
- Google provides the platform and is eager to embrace the feedback provided by OEMs.
- OEMs ensure quality and safety, without losing their branding image.
- Developers create innovative applications that can reach users fast.
- Tier 1 suppliers facilitate technical integrations.
- Customers receive valuable, safe and enjoyable experiences.
With all this information in place, let’s dig into the different AAOS App Store alternatives.
The Android Automotive OS App Store landscape
Currently the main alternatives we can find to distribute AAOS apps are: Google Play, Appning and Harman Ignite Store.
- Google Play: this is the same App Store provided by Google and used by other form factors like mobile phones and tablets.
- Appning (by Forvia): this is a third party App Store previously known as Faurecia – Aptoide. It works together with OEMs and positions itself as a white label App Store for vehicles.
- Harman Ignite Store: this is an alternative App Store developed by Harman (a Samsung subsidiary). In the same way as Appning, they work together with OEMs. One key difference is that they have extended the Car Android Library provided by Google with custom UI templates and widgets, taking advantage of their custom app review process.
Android Automotive App Store account registration
Creating an account on Google Play for publishing apps for Android Automotive OS is the same as doing it for mobile apps. In fact, android developers can reuse their existing account and target different form factors. Registering for the first time as a developer has a 25$ fee.
Registering a new account on Appning is free of charge. The process is quite straightforward and in a matter of minutes you will be able to access the developer console where you can upload your apps for later review.
Registering an account on the Harman Ignite Store is a bit different. Even it is free of charge, it currently requires an invitation to get access to it, which creates a first barrier for app developers. In their own words:
“Right now the developer console is invite only. If you’re interested, click the Join our partner ecosystem, fill out the form and one of our partner managers will get back to you. Once you get access, you will be able to use the console with the credentials you were provided.”
I personally created a new account here and 48 hours later I still didn’t have access to the developer console. Since this is a manual process, your own experience could be different.
Supported car models in Android Automotive app stores
Appning and the Ignite Store don’t offer developers a clear overview of the car models where they are deployed. This is an extreme drawback for developers willing to analyze the potential market growth of their apps. The only information available is on the marketing websites used by both stores.
Appning claims the following:
Appning is a single entry to 23 different car brands experiences. […] More than three million cars are using our Apps Market.”
Some of the brands listed on their website are BMW Group, Mercedes-Benz and the VW Group. For VW we can get a grasp of the App Store experience in this promotional video.
The Ignite Store website doesn’t give much public clue about which OEMs are integrating their App Store. We know for press releases that it is the App Store used by the VW Group in some specific vehicles. We can however see some UI details in this promo video.
Google Play is without any doubt the most transparent App Store when it comes to the amount of car models supported. At the time of writing 18 different car models are supported and developers have access to the full specification of the IVI Hardware:
| Brand | Model Name | RAM | System on Chip | GPU | Screen Sizes | Screen Densities | ABIs | Android SDK Versions |
| Polestar | Polestar | 3909-8131MB | Intel A3960 | Intel HD Graphics 500 (750 MHz) | 1152×1536 | 180 | x86_64 | 32 |
| VolvoCars | Volvo | 3909-8131MB | Intel A3960 | Intel HD Graphics 500 (750 MHz) | 768×1024 | 140 | x86_64 | 32 |
| VolvoCars | EX30 | 7847MB | Qualcomm SM8150P | Qualcomm Adreno 640 (675 MHz) | 1200×1600 | 180 | arm64-v8a | 32 |
| renault | OpenR Link | 8058MB | Qualcomm SM8150 | Qualcomm Adreno 640 (585 MHz) | 1250×1562 | 160 | arm64-v8a | 29 |
| renault | OpenR Link | 8001MB | Qualcomm SM8150 | Qualcomm Adreno 640 (585 MHz) | 1250×1562 | 180 | arm64-v8a | 32 |
| Polestar | Polestar | 7847MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 1200×1920 | 140 | arm64-v8a | 32 |
| Polestar | Polestar | 8540MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 1600×2560 | 200 | arm64-v8a | 32 |
| gm | VCU | 8271MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 974×2000 | 160 | arm64-v8a | 32 |
| gm | VCU | 6697MB | Qualcomm SA8195P | Qualcomm Adreno 680 (670 MHz) | 1134×2914 | 200 | arm64-v8a | 32 |
| VolvoCars | Volvo | 8540MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 1600×2560 | 200 | arm64-v8a | 32 |
| Honda | IVI-SYSTEM | 8060MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 720×1920 | 160 | arm64-v8a | 32 |
| nissan | NissanConnect | 8001MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 720×1920 | 160 | arm64-v8a | 32 |
| FMC | Digital Experience | 8299MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 1080×2348 | 200 | arm64-v8a | 32 |
| nissan | NissanConnect | 8014MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 720×1920 | 160 | arm64-v8a | 32 |
| Phoenix | Digital Experience | 8341MB | Qualcomm SA8155P | Qualcomm Adreno 640 (700 MHz) | 1080×2348 | 200 | arm64-v8a | 32 |
| alpine | OpenR Link | 8001MB | Qualcomm SM8150 | Qualcomm Adreno 640 (585 MHz) | 720×1280 | 160 | arm64-v8a | 32 |
| gm | Infotainment 3.8 | 5799-5801MB | Intel A3960 | Intel HD Graphics 500 (750 MHz) | 768×1280 | 160;200 | x86_64 | 29;32 |
| mitsubishi | OpenR Link | 8001MB | Qualcomm SM8150 | Qualcomm Adreno 640 (585 MHz) | 960×1280 | 160 | arm64-v8a | 32 |
These are all the models that have partnered with Google and are certified Android Automotive OS implementations. Any other OEM not listed here means that they didn’t get a valid certification yet for their IVI device or they didn’t try to get it. Using Google Play requires OEMs to become Google partners and embrace the Google Automotive Services (GAS) or Google built-in as it is named nowadays.
This is vital information for automotive app developers, since we can have a real grasp of the current ecosystem and decide where to focus our development efforts. For example, from this table we can conclude that at the time of writing no German OEM has publicly integrated the Google services in any sold vehicle yet, so the only chance to get an app on their cars is by reaching out to them directly. This is the gap that Appning and the Ignite Store are willing to fill.
Another important detail for developers to notice here is the Android SDK versions supported. The newest API level supported by AAOS public devices is API 32, however mobile devices have been already using API 35 for a while and API 36 is in developer preview at the time of writing this post. This reflects an important insight of the automotive industry: “integrations are waaaay slower here” as already explained earlier.
Conclusion
The emerging Android Automotive OS app ecosystem represents a microcosm of digital platform evolution, where technology, business strategy, and user experience intersect in fascinating ways. It is clear that app stores play a crucial role in this ecosystem. However, the lack of a standard solution makes it really difficult for developers willing to enter the automotive ecosystem.
The existence of Google Play and white-label alternatives offered by suppliers, just depicts the current tensions between Google and car OEMs. In the context of automotive, this has a bigger impact on final users, because vehicle customers cannot change the app store solution that comes with their car. This is something that it is possible in Android mobile devices though. So, whoever controls the app store in the car, will have control over the apps that will be available there.
In my eyes, this “conflict” makes no sense at all. If the reason is to have full control and ban tech companies like Google and Apple from the vehicles, then why do OEMs integrate projected solutions like Android Auto and CarPlay in the first place? By simply doing so, OEMs are contradicting themselves. On the one side, they enable projected solutions, which by the way, allow drivers to install any supported app they wish, without OEMs having any decision on that process. On the other hand, they don’t want Google Play (and therefore other Google Automotive Services) integrated in their vehicles. From the UI/UX perspective apps look identical for Android Auto (projected) and Android Automotive OS (embedded), because of the usage of templates, so this cannot be the reason.
I firmly believe developers would extremely benefit if Google and OEMs could sort out their differences and remove any kind of fragmentation affecting automotive app distribution. Developers have already enough burden when dealing with always changing APIs and the potential differences between vehicles. In this sense, having a unique point of app distribution offering as much information as possible about the supported vehicles and usage statistics, will definitely facilitate the task of developers since we can simply focus our effort in a single place.
In my personal opinion, all OEMs integrating Android Automotive OS will sooner or later embrace Google Play as their app store. The reason is very simple. This is the place where Android app developers are, but also what most of the users out there have on their mobile devices.
OEMs can try to prolong this fight as much as they want, but in the end their customers have the final word.