Table of contents
I recently had an opportunity to work on adapting a media application to Android Automotive OS. This was challenging for unusual reasons, which I’ll try to outline in the rest of this article. First, though I’ll try to explain what Android Automotive OS is and how it is different from Android Auto.
The most significant difference is that Android Automotive is an operating system running directly on your car’s infotainment hardware, while Android Auto is an application projected from smartphone to Head Unit. This means applications run directly on Automotive without connecting your smartphone to it.
If you had an opportunity to use Android Auto, you might be aware of its limitations when it comes to supported application types - only media, messaging and navigation apps are available. Initially Automotive will support exactly the same application types, but Google already announced plans to extend this.
On a side-note, currently, it’s possible to run any Android app on Automotive by installing it via ADB. This shouldn’t be a surprise, because Automotive is nothing more than modified Android OS, but it also raises some questions about types of restrictions Google will impose to limit this on actual infotainment systems in the future.
Coming back to the topic, because with Android Automotive your smartphone is out of the picture, some things that were previously managed by your mobile device will have to be done directly on the Head Unit. For instance, you will have to add sign in and settings screens to the app running on HU. The same goes for managing user permissions and requesting them from the user and showing notifications - this will have to be done directly by an app running on Automotive.
Google revealed Android Automotive OS in March 2017 and since then few car manufacturers officially announced adapting Automotive to their infotainment systems. The first one was Volvo in 2018 with their Polestar 2. So far it looks like they are going to meet their 2020 release schedule. If you are interested in trying it out, you can find the Polestar 2 emulator in the stable Android Studio release.
Next was Renault-Nissan-Mitsubishi Alliance in September 2018. At first, 12 car models will come equipped with Automotive, and sales are planned to start in 2021. Alliance predicts at least 14 million sales by the end of 2022.
We then had to wait a full year for the next announcement, which came from General Motors in September 2019. There is not much information available here, other than the known release date planned for 2021. General Motors and Renault-Nissan-Mitsubishi Alliance didn’t provide any official emulator yet to test your apps on.
It’s hard to measure how big will be the interest in cars equipped with Automotive. Unfortunately, I wasn’t able to find the usage statistics of Android Auto, so the only data we can refer to is sales figures. The only information I found on this topic is a study done by Canalys in 2018. According to their data, 46% of cars sold in Europe and 52% of cars sold in the USA in Q1 2018 came with Head Unit that supports Android Auto and/or Apple CarPlay. This gives a total of 8.4 million new cars in the first quarter of 2018 alone. Now, it’s not possible to tell what percentage of drivers actually use those capabilities, but the market is potentially quite big.
It’s difficult to estimate current Android Auto usage for one more reason. There are lots of radios, which you can find on e-commerce websites, that offer Android Auto and Apple CarPlay capabilities. Those sales are not included in Canalys’ study, as it covers only new car sales. On the other hand, people who use this hardware in their 30 years old Audi 100 might not be the target audience of brand new cars with Automotive on-board.
I can only speak from my experience with media applications. It already had integration with Android Auto in place, which made lots of work much easier. We worked on this for a few months in a team of 3 developers, 1 QA engineer, product owners, and with assistance from the UI design team.
When it comes to UI, Google gave us mock-ups of sign in flow and settings screen. Those were then adjusted by designers to fit different, known at that time, automotive screen configurations and to match the brand. I’m sure those instructions for designers also had to be taken into consideration. Google didn’t take them out of the blue, in fact, they are a direct result of guidelines proposed by different countries and regions in the world, i.e. by NHTSA in the USA.
Now, you might have noticed that I used the word “guidelines” and not “law” or “regulations”. You are indeed not required to follow them, but at the same time, the whole industry tries to do so. Actually lots of the guidelines proposed by NHTSA were first introduced by car manufacturers.
You can tell Google paid lots of attention to them when designing Android Auto and Automotive. This is why lots of actions are forbidden when driving and your interaction with a Head Unit sometimes is interrupted by a full-screen modal asking you to focus on the road for a moment. This is also why fonts are so big, images are so scarce, animations are non-existent, and so on. You should also consider that Google has a final say if your application is fit for their system and if it blatantly isn’t, then it’s more than likely your app will be taken down from Play Store or not even admitted to it.
To sum this part up, try your best to follow the instructions provided by Google when designing screens, it will save you some troubles in the future.
With QA the challenge was a little bit different. At the time, it wasn’t always clear if issues or bugs were the result of dev team errors or problems with the platform itself. Especially since there were some differences between the emulators provided by various car manufacturers. This required close cooperation between QA and developers for most efficiency, but it also increased the effort required to implement new features.
You might consider this as an additional tax when working on a platform in its early stages. Right now the situation might be different - emulators are available in the stable channel of Android Studio instead of beta and documentation is much more detailed. One thing won’t change for sure - QA is needed on all available types of emulators and their number will most likely increase in the near future.
Product owners also had an important role in mitigating issues. Any time we were stuck, encountered potential platform problems, or were not sure if our approach was acceptable, product owners had to manage those issues with 3rd parties in a timely manner. This resolved lots of potential showstoppers, improved the app, and also provided valuable feedback to Google and car manufacturers. This was at early beta stages, so lots of the issues we encountered are probably already addressed in documentation as well.
Speaking purely from the developer’s perspective, most of the stuff works exactly the same way it does on Android Auto right now. There is some additional overhead due to testing on different emulators, but it’s no different than verifying your standard Android app on various devices. Emulators worked pretty smoothly and most issues could be resolved by wiping their data and cold boot.
New sign in and settings screens shouldn’t be complex, at least if you followed guidelines, so this on its own makes implementing those screens quite easy. I think it’s also very helpful to go through the official documentation. From what I see, the UAMP sample has also been updated with the Automotive target. I think checking those places is valuable because some things on Automotive are done a little bit differently than what Android developers might be used to.
UAMP sample sign-in screen
It’s also important to remember that an Automotive app is built as a separate target in your project. Depending on the structure of the existing codebase, the project can be prepared for this better or worse. It’s best if the codebase is already split into business logic and view modules at least. This way you can add an Automotive target as a new module which will reuse the business logic one. This will vary from project to project of course and depends on the approach the team has chosen. Still I think it's an important factor when trying to estimate the effort of adapting your app to Automotive.
In the end, working with the Automotive platform went pretty smoothly. The team had some challenges to overcome, but they mainly stemmed from the fact that this wasn't a stable and fully documented product at the time of integration. To me, it’s interesting how many car manufacturers are switching over to Automotive. It’s gradual of course and might be just an attempt to test the waters. Still, the potential market is quite big here. It’s unfortunate that applications will be limited to the same types as on Android Auto, but at the same time I’m curious what direction Google will take here in the future.
Cover image: Polestar
