In 2015 Google revealed Android Auto—a system that can mirror specific apps on a car’s screen by connecting an Android device to the car. Although this was a giant step into the automotive industry, it was not properly designed for cars, but rather adapted to use Android on a different platform. It was not until 2017 that Google announced Android Automotive OS (AAOS) which offers Android integration with the car. In a nutshell, Android is now “part of the car”.
Photo by Kenny Leys on Unsplash
Android Auto vs Android Automotive
The basic concept behind Android Auto and AAOS appears to be the same, therefore the question remains, why was there a need to create a separate platform from mobile phones when an already workable solution existed?
Android Auto was designed by Google to mirror features of an Android device, such as a smartphone on the car’s dashboard head unit. Once an Android device is paired with the car’s head unit, the system can mirror certain apps on the vehicle’s display.
AAOS differs completely from Android Auto since it is an entertainment system itself so it does not rely on the user’s smartphone to be connected to the vehicle. It is installed within the car’s computer storage as a separate dedicated car device. In addition, the system is not only limited to viewing maps and using media applications, but also includes many more car settings. Its version of the Play Store allows the user to download applications directly to their vehicle.
Android Car App Library
The Android Car App library was released in its Beta version 1.2 for Automotive OS this past January. Categories of apps currently supported include: navigation, parking, and charging apps with more being introduced in the future.
The library has a very concise set of templates to implement your app design. These templates allow for consistency across any OEM (Original Equipment Manufacturer) and also ensure that developers work within certain UI parameters so that driver distraction is avoided.
Car App Architecture
To understand how an Android Automotive app works, it is important to understand the following app components:
- CarAppService: This is an important class that allows the app to be discovered and managed by the Host.
- Session: This class allows the display of information on the car screen and has a lifecycle that updates the current state of the app.
- Screen: A screen is the user interface provided by the Car App library that allows developers to present information to the users in accordance with the template restrictions (must be followed for driver safety).
The diagram below demonstrates an example of a session.
.png?width=1277&height=390&name=image%20(17).png)
An example session in an Android Automotive app
Developer Guidelines
To create a user-friendly Android Automotive app using the Car App library, the following guidelines should be adhered to:
- Define user tasks to provide the maximum required information in a simple format to not distract the driver. Giving dense information or too many options for the user will make the app time-intensive and confusing.
- Define task flows in the shortest pathway possible. These task flows must utilize templates that allow the user to complete a task logically from beginning to end. Too many flows or incorrect choice of templates will decrease the app’s efficiency and create an undesired experience for the user.
- Communication with users within the app can be done via notifications, toasts, or Message templates. To inform the user of simple information, toasts can be used which will be displayed for a few seconds (ex. a network error).
- Notifications can also be used but must be within certain restrictions, such as the Parking state or Driving state of the user.
- Message templates allow the user to view short messages and Long Message templates can be used for large amounts of data equivalent to paragraphs.
Car App Library Template Limitations
Current limitations for the templates in the Car App library include:
- Each template allows a limited number of elements based on the type of template and the OEM.
- Custom styling of screens and their elements will be restricted according to the OEM-defined styling.
- The task flows must be short to avoid driver distraction; maximum task flows allowed are up to 5 or ideally fewer (between 2 to 3 steps).
Sebastian Valencia and Sehrish Shoaib are Agile Software Engineers at TribalScale who have been working together on Android Automotive development projects. They have been researching and implementing the latest Android Car App library and have made a lot of progress in this new domain.