Android Automotive Development Challenges
Written by: Sehrish Shoaib, Agile Software Engineer, TribalScale
📫 Subscribe to receive our content here.
💬 Have any questions about our development capabilities? Click here to chat with one of our experts!
Google has been working on the Android Automotive domain since 2017 and there have been significant additions. As a result, Android developers can now create a variety of apps that can be directly accessed from the infotainment system of a vehicle, removing the need to connect your mobile device to the car system.
Check out this previous article where we gave a general overview of Android Automotive. ⤵️
This has enabled Android developers to use their existing skills for development of car apps and has opened up many opportunities for apps from various categories.
Let’s do a deep dive into the challenges faced in the Android Automotive domain and how development of apps in AAOS differs from mobile Android app development.
App Architecture for AAOS Apps
The basics of building an app for AAOS is similar to that of creating one for mobile, however, the app architecture will differ. The following architecture must be followed for Automotive apps using Android for Cars App Library:
- This includes a Screen and Session.
- CarAppService must be included.
- ScreenManager must be used to navigate between screens.
The lifecycles for CarAppSevice, Session and Screen differ from the generic lifecycle of an Android mobile app. As a developer it is important to understand the differences in order to create a stable working AAOS app.
The Android for Cars App Library is a set of Jetpack modules designed to support the writing of apps that can be used for Android Auto and Automotive OS. It does this by providing a set of templates that are designed to meet driver distraction standards across the world and are capable of adapting to different car screen sizes and input modalities.
Pre-defined Templates in AAOS
The Android for Car App 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 stay within the bounds of a UI that is optimized for driver distraction.
However, the templates can become restrictive in terms of user experience and there are very limited options when making changes to the user interface, hence resulting in apps that look very similar to each other.
All templates are provided by Google which have little to no room for customization. Custom styling of Screens and their elements are restricted according to the OEM defined styling.
Template Restrictions
There is a template limitation of 5 maximum applied to a given task, of which the last template of the 5 must be one of the following types: NavigationTemplate, PaneTemplate or MessageTemplate. If the app attempts to send a new template, the host will display an error message and close the app.
For example, if each Screen is structured to send a single template, then the app can push 5 Screen instances onto the ScreenManager stack. There are special cases to these restrictions: template refreshes, back and reset operations.
Template Refreshes
Template refreshes allow the app to refresh the templates without crossing the maximum template limit. If the current template is of the same type and contains the same main content with some values updated, the template will not be counted against the quota.
Back Operations
The ScreenManager stack of screens is monitored by the host for detecting if a screen is being popped; this keeps an update on the quota of screens still available for the app to show.
The app is restricted to use the same template when popping back a screen, sending a different template will cause an error.
The Car UI Library
To develop a fully customizable app, a developer can make an app directly integrated into the OEM. For that purpose the Car UI library can be used, which is a statically linked library that provides a set of components and resources you can use to implement the following:
- System and OEM apps (Gerrit)
- Android Automotive (AAOS) apps
However such an app will not be available on Google Play store and direct collaboration with the car manufacturer will be required.
More Challenges
Android Automotive Emulators
Another challenge currently faced is that AAOS emulators only run on Intel based Macs. A significant decrease in performance can be seen while running AAOS apps on the system.
Google Maps Integration
Google Maps cannot be easily integrated into Android Automotive apps with Navigation categories. As an alternative, we can use third party apps.
Supported Libraries
Some libraries are not supported by Android Automotive apps, however this is not properly documented anywhere. This leads to significant confusion and developers having to do trial and error to see which ones are working properly.
Sample AAOS Apps
The sample apps provided by Google are all in Java whereas in documentation we have references to Kotlin code snippets. The complete sample apps have yet to be updated.
Sehrish is an Agile Software Engineer at TribalScale working on innovative and futuristic Android apps. She has a Masters degree in Computer Engineering and is greatly passionate about working on the UI side of Android. She loves writing code and building innovative apps. Outside of work she is an avid reader who loves books and libraries!
TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!
