How We Found the Perfect Android Automotive Developer Kit Solution

When we started Snapp Automotive we identified multiple ways to help the automotive ecosystem create great Android based experiences in vehicles. These ranged from processes, to tooling and software technologies, that would allow folk to create these experiences faster, iterate on them more quickly, and arrive at a delightful experience that everyone could enjoy.

One of the pieces of the puzzle we identified was the lack of a reasonably priced development platform. We initially made builds for the Raspberry Pi, and have used Android tablets with some of our customers, all to ensure that we have a cost-effective solution to allow folk to try out, and provide feedback on, automotive experiences.

Last year we took the decision to create a “Development Kit”. Android for phones had the Android Dev Phone 1, which was a great help to developers getting started on the newly released Android OS. Android for TVs has the ADT-1 which serves a similar purpose. Unfortunately, for Android Automotive OS, the recommendation was to repurpose some of Google’s Pixel Phone models to act as AAOS devices, but, to us, this missed the mark for what was needed. 

Phones (and tablets) don't allow you to try different screen sizes and aspect ratios. They don’t work well for arms-length testing of UIs. They also can’t be easily expanded to provide access to the CAN bus, don’t support multiple screens, and other hardware configurations which are commonplace in vehicles.

So we began our search for something which would give us the flexibility we wanted, performance that reflected in-vehicle hardware (i.e. not an emulator), and in a package which was affordable enough to be widely usable (unlike the bench units automotive companies currently use today).

Today, after a lot of research and discussion, we are excited to share that we can best make this available by supporting the community efforts around an existing piece of hardware; The Khadas VIM3.

The Journey

When we started looking for the right piece of hardware we, wrongly, assumed that it would be a short search. We thought we could find an off-the-shelf head unit that would allow us to create AAOS builds which included things that aren’t in the AOSP (e.g. a Map provider), and package it in a way which would be useful to developers.

After gathering some hard data around the interest in an automotive dev kit, and talking to various companies, we’ve realised that a low-volume, low-cost, off-the-shelf automotive head-unit doesn’t currently exist, and, from a cost perspective, creating one isn’t, for us, feasible.

The two main hurdles were Intellectual Property and Sales Volumes. We talked to several companies who had existing head units that could be customisable, but, they either couldn’t give us access because the head unit hardware because it had been created for a specific customer, wanted thousands of euros per unit for small runs, or could not give us the ability to build our own firmware for the units due to licensing restrictions on the relevant Android BSP.

We also had discussions with companies who would design something for us, to see if that would be viable, but that would cost hundreds of thousands of euros, and the end product would not fit within our cost budget. 

We are still talking to some of these companies about solutions for our customers who are producing vehicles and need in-vehicle hardware, but, to us, this has led us to the conclusion a solution designed for use in vehicles, and on developers desks, might not make the best dev-kit.

The VIM3

Using the VIM3 was an idea originally suggested to us by Chris Simmonds. Chris, for those who don’t know him, is a much admired member of the Linux and Android communities who frequently organises tracks at conferences, and has a wide knowledge of Android, and Linux, at a low level in the software stack.

The VIM3 isn’t, on its own, suitable for use in vehicles. It’s designed for the maker community, and so has features that would allow third parties to alter the firmware of vehicles on the road, which is something most vehicle manufacturers do not want. It also, natively, lacks some of the features an infotainment system board would have (e.g. a CAN bus interface), but some of those can be worked around (e.g. USB CAN bus dongle, thanks again Chris!). So it looks like a good fit for a desk based dev kit.

The VIM3 is supported in Google’s Android Open Source Project, which avoids the redistribution issues around custom builds for Google Pixel phones and tablets (which comes from their BSP licence agreement). It can support different display sizes, and dual displays, allowing folk to simulate multiple passenger displays, or a central display and cluster arrangement, and it’s widely available from online retailer, such as Amazon, in the UK, Germany, the USA, and others countries, meaning we side-step having to be involved in physical shipment logistics.

One of the groups Chris is part of, the AOSP devs, have already made instructions on building firmware for the VIM3 available, and they’re not the only folk who’ve already “kicked the tyres” on Android on the VIM3. There are folk such as BayLibre who are actively pushing improvements to Google that will improve Android on the VIM3 for everyone, and we’ve recently contributed a change which makes it easier to build firmware for the device.

Overall its specifications are pretty solid, it has near global availability, strong community support, and has the ability to be expanded to meet our check-list of needs for a dev kit, and so we decided to recommend it for AAOS development and make builds of AAOS 12, 12.1, 13, 14, and 15 available to folk who want to get involved in automotive development, but don’t want to build their own firmware images.

Next Steps

Chris and the AOSP devs community have already created technical documentation around buying, and creating builds for the VIM3, and we’ve created our own version of that, so we’re going to focus on the needs of automotive developers who don’t want to build firmware, but, instead, just want an Android Automotive OS device to develop against. We’re also going to help Chris, the AOSP devs, Baylibre, and everyone else involved in the communities to ensure the VIM3 stays relevant, and useful, to all types of developers.

We’re looking forward to helping the community build an open solution, and helping companies get started with AAOS development in a cost effective manner. Thanks to everyone who expressed interest in the dev kit, you can find our free Android Automotive builds for the VIM3 and the details on how to get started on our website.