Android Automotive, the Real Android Fragmentation
Automotive infotainment systems are being taken over by Android. A lot of companies are jumping on the technology without really understanding the risks. The automotive industry is following a similar path that other industries have already gone through. Understanding history can help one predict the future. In this post, we highlight some of the dangers of Android Fragmentation we see happening in the automotive industry and provide some thoughts on how to avoid potential pitfalls.
How Did We Get Here?
If you were an Android developer in the early 2010s, you’ll remember the horror stories about Android Fragmentation. You likely remember seeing an image like this presented to you as a proof that Android as a platform was either doomed or impossible to write great software for:
In reality, Android was built to handle all that. Unlike Apple’s iOS, from the very beginning Android developers were provided tools to adapt to variation in screen sizes, densities, and software versions.
Google Play Services - Hello, Vendor Lock-In
Android handset manufacturers were, and still somewhat are, reluctant to spend money to support their older devices. It was quite common for phones not to receive new Android versions after launch. In the early days this led to older devices getting left behind and their users missing the latest Android features introduced in the annual OS updates. Phones sold in stores like Walmart often had OS versions from 3,4 or even 5 years ago.
Google had to do something. They started to decouple functionality from OS releases and found ways to backport APIs and functionality to older releases. Android Support Libraries allowed developers to bundle new features with their app distribution and let the library take care of backward compatibility. At the same time, a portion of the functionality was moved to Google Play Services, a package of libraries distributed and maintained directly by Google bypassing OEMs and their slow OS updates.
This change as well as Google moving many previously core apps from the OS distribution into Play Store distribution had a big impact on users. The version of Android your phone was running became much less significant. Many of the improvements Google introduced in newer Android versions became available to older phones via Play Services updates or the app-bundled Android Support Library.
To gain the advantage of some new and backported services developers were advised to start using Google Services APIs over the platform ones. For example, Google introduced a new and improved way to get device locations via Play Services which has become the default way to use location in Android devices.
Outside China, where Google wasn’t available, there was just one Android system to care about if you were a business. The Google one. There were no significant handsets that didn’t have Google Services on them so only targeting Google wasn’t an issue. It wasn’t even discussed.
With this move Google had achieved a full vendor lock-in, intentionally or not. The millions of apps developers are producing do not run on any device not shipping with Google Services.
Companies like Amazon and Huawei are facing the tough reality of this. Maintaining apps on non-Google devices might not be a huge amount of work. There are replacement APIs for the Google APIs for almost every function. But to call these replacements would require developers to maintain and test different app builds as well as monitor, understand and integrate to different app store systems. In reality, this overhead just isn’t worth it for a huge portion of companies. A simple search to Amazon app store, which is the app distribution system for millions of Amazon Fire devices as well as available for Windows 11 devices, shows the grim reality. There’s no Spotify…
Automotive Android Is Fragmented, Really
Today's automotive Android world is in a similar place to the handheld Android world of the late 2000s and early 2010s. Manufacturers are looking to replace their outdated systems with modern systems and Android is emerging as the winner. A huge majority of cars will soon run Android-based infotainment systems, and many already do. Manufacturers are benefiting from the modern OS as well as all the development tools available. There’s a huge pool of Android app developers who can help build the systems. The benefits are clear.
But…
Misconceptions About Android Ecosystem
There are more than 3,5 million apps available in the Google Play Store. So once our car runs Android, we’ll have millions of apps. Right?
No. You will have 0 apps available for your car from 3rd party developers. To get access to the apps in the Play Store, you need to enter into a commercial agreement with Google and make sure your distribution passes the required compatibility requirements. (read Casper’s blog post about this topic)
Android is an operating system. Google Play is the developer ecosystem.
Automotive Android without Google
At the moment, a big portion, probably most, automotive manufacturers are building their own Android systems to ship without Google Automotive Services (GAS). GAS is the automotive counterpart of Google Play Services discussed above. At this point, you already know where this is heading. There is going to be a huge split in the automotive industry. Google vs. non-Google systems.
API and App Store Fragmentation
For developers, the scariest type of fragmentation is API fragmentation. Either in the form of missing functionality or missing APIs. This is where the code has to be forked to prevent crashes or patch functional differences. Even if the only change is a call to a different package / SDK with identical API the added work in the form of testing and maintenance is going to have a real impact. The realistic scenario is likely to be much worse than this.
There’s going to be multiple app stores. White label ones, in-house built ones and 3rd party ones. Where, and how, should a developer deploy their app? Which APIs are supported by which store? How is quality and compatibility managed in these stores? How can I be sure that my app won’t be crashing in a car I have never seen? Will my brand’s reputation be safe?
What is causing a crash?
If you were building Android apps using camera APIs in the early 2010s, you’re all too familiar with the differences between OEM camera implementations. If you received error reports from the field that your app didn’t behave correctly on certain devices, it was likely that you could find someone with that brand of device and try to see what’s happening. In the worst case, you might have to go and buy a testing device to get to the problem and to find a solution. But what do you do if your app is crashing in a certain car?
In the early years of Android, phone manufacturers were quite nonchalantly changing the Android code running on their phones. In addition to making it difficult for them to update to newer versions of Android, this also created some uncertainty for app developers about causes of crashes. In general there were three different areas that could cause a crash: your code, the Android system from Google (AOSP) or the changes made by the OEM to the Android code.
At the moment automotive manufacturers are behaving much like the early phone OEMs and freely making changes to their systems as they see fit, potentially making Android systems behave inconsistently between different manufacturers. For an app developer this can turn into a nightmare. It’s not as easy to get access to a car as it is to a phone just to test what is going on. Additionally, even if you have access to a car, you won’t be able to enable developer mode on it to test new builds quickly.
You can try to argue that the cause is the car manufacturer modifications as your app is working just fine on the automotive Android emulator you’ve been using. You might even have tried some emulators provided by car manufacturers. But how can you prove it? If your media app is crashing but others aren't, the car manufacturer is going to dismiss your claims and point to other apps that work as a proof that the media controls are working. Eternal finger pointing starts.
In the Google Android world, CTS (Compatibility Test Suite) is used to ensure (at least in theory) that anything called Android behaves the same way. Developers can rely on their apps working consistently in different phones. CTS isn’t perfect and issues still arise but they’re much less frequent than in the wild west of car manufacturer built infotainment systems.
ROI of Maintaining a Car Manufacturer Build
In 2023, Volkswagen Group sold 9,24 million vehicles. Samsung sold 9 million Galaxy A14 5G phones in the first half of 2023. Samsung’s total phone sales in 2023 was 226,6 million phones.
Even in a scenario where every single VW, Audi, Skoda, Porsche and Bentley would run Android, they would not reach 50% of the numbers of a single Samsung smartphone sold. And that’s not even the most popular Samsung phone.
This context must be kept in mind when thinking about the app ecosystem ambitions car manufacturers have. The incentive is difficult to find in many cases. Building an app store is not difficult, getting developers to put and maintain their apps there is.
What is Google Doing?
With all these problems, is going with Google the only way forward for car manufacturers? No, I don’t think so. At the time of writing this, Google seems to be doing the bare minimum in the automotive domain to capture the market. The GAS-based Android Automotive OS is far from what it could be. For example, Google Maps is currently very poorly integrated into the car. While the in-car app knows your battery levels etc, Google Maps in your browser has a limited or no connection to your car. Google could be doing much more to create a seamless user experience for users using Google apps across devices. Looking from the outside, I sometimes wonder if Google is interested in being in cars long term or are they happy to rely on the projected mode, Android Auto, solution. Google hasn’t, yet, won the in-car game.
What is Apple doing
I’ve learned not to trust Apple rumours. There’s a lot of misinformation, misunderstanding and false information out there. That said, there is a good chance that Apple will enter the car space at some point. Currently, Apple’s strategy is to control hardware and software together to create the best user experience. Apple doesn’t licence their operating systems to 3rd parties. If you want Apple software, you have to buy Apple hardware.
If Apple builds a car, it will run CarOS in the infotainment system. This would create ripples in the automotive industry and likely drive attention to user experience the same way the iPhone forced everyone to up their game. It might even be that Apple changes their strategy and allows select car brands to put Apple’s infotainment software in their cars. If that happens, you can be sure that Apple is strictly in control of the experience. We won’t see a mass adoption of the OS in the industry.
If Apple releases a car, the automotive industry will look a lot like the mobile industry. Apple won’t be the market leader but would quickly become the thought leader. The Apple product would be where the much larger Android-based market would be compared to.
It’s a Do-or-Die Moment for Non-Google Android in Cars
The automotive industry is in a decisive moment at the moment. There is an opportunity to create a viable alternative to Google Android. There is a real possibility for an alternative developer ecosystem to emerge to rival Google Play in the automotive space. But that window is closing quickly. If Google Play is allowed to become dominant in the space, it will be difficult to, if not impossible, to gain traction with an alternative.
The time is now or never.
Fight Together or Die Alone
The opportunity is there but none of the car manufacturers are big enough to gain enough traction alone. To survive, they must come together. The only viable alternative to Google Play ecosystem will be a single, common, compatible developer ecosystem spanning across all non-Google Android car makers. A developer won’t be maintaining a separate build flavour just for BMW. But to have the same, unmodified code, running and easily distributed to BMWs, VW group cars, Daimler’s cars, GM’s cars etc, becomes a proposition worth considering.
There are some positive signs that some car manufacturers are waking up to this reality. It remains to be seen if they can act fast enough. Initiatives like COVESA App Framework Standardisation led by BMW, GM and FORVIA is exactly what is needed.
Unfortunately, committee driven initiatives tend to progress slowly, very slowly. The COVESA effort, which aims to produce a set of standard APIs and compatibility tests, will always lag behind developments done by a single entity like Google. Additionally, finding the funds to develop common components in a committee environment will take a lot of time and effort.
A Tighter, Faster Cooperation Is Needed
If car manufacturers want to build a viable app ecosystem for their non-Google Android infotainment systems, I believe tighter cooperation is needed. In practice, this would likely mean a manufacturer-independent entity providing a standard replacement for the Google APIs. This is likely going to be the only way to keep the ecosystem viable long term.
This is not to say that all manufacturers need to end up using the same payment system, the same app store etc in their cars. That would defeat the purpose of staying independent from Google.
Standard APIs, Reference Implementations, Emulators and Testing Tools
Google has hundreds of engineers and other people working on Google Play services. Google Automotive Services (GAS) builds on Google Mobile Services (GMS). Replacing GAS alone is not enough, we have to replace relevant portions of GMS as well, which is not a small task. Some companies like Amazon and Huawei have built their own and there’s an open source project, MicroG, doing something similar. So there’s a lot to do and maintain.
APIs and even the code is actually just a small portion of the work needed to build and maintain a viable ecosystem. Developers need tools like documented reference implementations, emulators and other testing tools to build and test their apps. This is where the COVESA initiative might have a weak point. The initiative aims to define APIs and leave the implementation to the car manufacturers using building compliant infotainment systems. But who will provide the required reference implementations and other tools? Car manufacturers are not experts in developer relations and outreach. Their priorities will be elsewhere.
A Central Entity for non-Google Automotive Android Development
I believe that a central entity for providing the core of non-Google Android Automotive to all interested car manufacturers is needed. An entity that can absorb requirements from the automotive industry and implement, share and verify standardised solutions without committee involvement can operate quickly and efficiently enough. The same entity could deal with community outreach, white label app store support and standardisation and requirement management for future releases. I believe that without a setup like this the future of the non-Google Android developer ecosystem in cars is bleak.
Do We Need Apps in Cars?
Let’s take a step back. Do we need an app ecosystem for cars for Android infotainment systems to be useful? Maybe, but maybe not on the scale some people seem to be aiming towards.
In some ways what is going on in cars now, reminds me of what happened in the early iterations of Android smart TVs over a decade ago. After the initial push to make everything available on the big screen, companies soon realised that most stuff didn’t make much sense. We now have a healthy number of apps in TVs of which almost all are content streaming and some gaming. I predict we’ll end up with something similar in cars.
When you think if your app should be running in a car there’s few simple things you can ask yourself first:
Is the normal use of your app safely done during driving? - Apps like navigation, music streaming, audiobooks would fall into this category.
Is your app’s user experience improved if it gets more accurate context data directly from the car? - Apps like EV charging planning or routing could fit here.
Why would your user want to use the in-car app instead of their phone? - 99% of apps will fail at this point. If your app doesn’t need the car context, it’s likely going to be used on the user's phone instead.
Things like “Entertainment while waiting for the car to charge” or “Autonomous driving is coming” are often quoted as reasons for apps in the car. I don’t buy these use cases. Rapid charging is already very quick, the time your car needs to be parked doesn’t extend much over a needed bio-break and coffee. In the cases it does, an iPad serves the need just fine, and Autonomous driving isn’t here yet. Once it is, the infotainment systems need much bigger changes than apps.
One thing I wish car manufacturers would acknowledge more consciously is the fact that most people don’t actually want to spend time in cars, which has been the case since cars were invented. When they arrive at their destination, they get out. The use case for apps while parked can be limited. However, when done right, while parked the infotainment system is effectively just a tablet. So maybe there’s real use cases there. I also see solid use cases for passenger entertainment being easily accessible in the car infotainment and rear seat entertainment systems.
Conclusion
We at Snapp Automotive feel that we’ve seen all this before. First in Mobile, then in TVs and now in Automotive. We work with small, medium and large car manufacturers. We have great relationships with App Store providers and have been part of the Android app developer community for decades. We play in all teams and are hoping that everyone wins. Some of the thoughts above might sound harsh and maybe even scary if you’re deeply invested in the industry. But hiding from reality doesn’t change the facts, acknowledging them allows you to react. We believe that software in cars is about to get much better, quickly. A lot of people are learning, building and adapting. We hope to help and offer our expertise to support where we can. The automotive industry stands on a knife’s edge at the moment. There’s potential for greatness or danger of darkness.