Growing Popularity of AAOS Among Automakers and Developers

The rising popularity of AAOS is evident in Google’s recent announcement of over 70 AAOS apps being added to Google Play. Another indicator is its adoption within the Volkswagen Group, specifically by Audi, which first introduced it in the Audi Q6 e-tron. The new Audi A6 e-tron also features AAOS. Based on further steps and statements from the Group's representatives, we assume that some other brands will follow.

‍

At Etnetera Flow, we also believe in the potential of Android Automotive OS and its expansion into more vehicles. The entire ecosystem of templates, supported app categories, and customization options are still in its early stages. New templates and additional supported apps are yet to come. We have been exploring AAOS for some time now. For more details, check out our previous articles:

• Development for Android Automotive OS? We are ready
• Testing Android Automotive OS application in a Volvo XC60

Core Principles and Use of AAOS Google Templates

AAOS generally enables application UI development in a way similar to mobile environments, for example, using the Jetpack Compose library. We tested this approach by developing a simple Shared Car app, for monitoring vehicle usage by employees. The app runs in the car and functions correctly, but it is not the preferred approach aligned with Android’s documentation and Google Play requirements.

‍

Official Google documentation recommends using predefined Templates, optimized for automotive infotainment systems to ensure compliance with UX requirements. These guidelines aim to simplify app interactions and enhance safety by reducing driver distractions.

‍

The requirements are categorized into three levels:

• MUST (NOT): These requirements must/must not be met. For example, each app action must be completed in no more than five steps.
• SHOULD: These are recommended requirements. For example, navigation apps should update time and distance estimates during a drive.
• MAY: These requirements are optional but can enhance user experience. For example, a search field may include a hint.

Additionally, the following requirement categories are defined:

• General requirements apply to all applications.
• Application-specific requirements are currently defined only for weather and navigation apps.
• Template-specific requirements dictate and restrict how a template is used. For instance, the *List template* requires each section to have a header if items are grouped.

Google defines the following core components and templates:

• Currently available components include: Action strip, Map action strip, Button, Floating action button (FAB), Header, Row.
• Available templates include Grid template, List template, Map + Content template, Message template, Long Message template, Navigation template, Pane template, Place List (map) template, Search template, Sign-in template, Tab template.

‍

Using the Android for Cars App Library in Development

The templates, components, and other building blocks for developing AAOS applications with UI templates are part of the AndroidX – Android for Cars App library, which is available in the official Google Maven repository. In a project, they can be defined using the following Gradle dependencies.

The library provides an interface for configuring templates using the builder pattern, which allows developers to set only what the given component supports. If a combination of parameters is invalid, the application will crash at runtime (throw an exception). The main disadvantage of this approach is its limited ability to meet the requirements of the application, UI designers, and clients. I also miss the use of Kotlin DSL, which could simplify the code.

‍

The builder pattern is a design pattern that enables the step-by-step and readable construction of complex objects without requiring a large constructor. Instead of passing many parameters to a constructor, builder methods return an instance of the builder.

Core Components of Template-Based AAOS Applications

Developing AAOS applications using templates differs significantly from traditional app development. One key difference is the absence of Activity, one of the fundamental building blocks of Android applications. Instead, the Android for Cars App library defines its own components.

The Host component is not implemented by developers when building automotive applications. It is part of Android Automotive OS and manages the entire AAOS application lifecycle—from discovery and lifecycle management to rendering templates as Android Views and handling user interactions.

‍

The CarAppService is an abstract Service class that every template-based AAOS application must implement. It defines the primary connection to the application. Its main function is to validate whether a connection to the CarAppService is trusted and to provide a Session for each new connection.

‍

The Session is another abstract class that every template-based AAOS application must implement. This class provides the application's entry Screen and has access to the application's lifecycle, allowing it to determine, for example, whether the app is visible to the user.

‍

The Screen class is responsible for delivering the user interface using predefined templates. It also has access to ScreenManager, which allows navigation between screens. The primary method of the Screen class is  *fun onGetTemplate(): Template* This method is called when a new template is created with the current state.

How We Update UI Templates at Etnetera Flow

We develop applications following Clean Architecture principles. To present the application data, we use ViewModel, which provides an observable state. When the state changes, the UI is redrawn. However, in AAOS applications, the rendering process must be divided into several steps.

‍

Mobile Applications:

• The UI layer observes new states and renders them immediately.

AAOS Applications:

• The Screen observes state change events.
• The Screen is informed that a new template needs to be created.
• When creating a new template, the ViewModel provides the current state, which is then rendered.

During AAOS development, we often encounter limitations that do not align with the requirements of UI teams, analysts, or product owners. Examples include adding a button to a specific location on the screen, applying rounded corners to UI components, or changing colours.

‍

Want to learn more about Android Automotive OS development? Follow our blog or contact us. We’d be happy to share our experiences and explore potential collaboration!