The Android Automotive Operating System (AAOS) has opened up new frontiers for app developers, offering the exciting opportunity to create applications specifically designed for in-vehicle experiences. However, as with any emerging technology, the path for third-party developers is not without its challenges.
This post aims to shed light on the current state of the AAOS app development ecosystem, focusing on my experiences and insights as a third-party developer.
Understanding the AAOS Landscape: GAS vs Non-GAS
Before delving into specific challenges and recommendations, it’s crucial to understand the two main avenues available for distributing AAOS apps:
- GAS (Google Automotive Services): This refers to the Google Play ecosystem for automotive apps. This is without any doubt the biggest market, with most of the car OEMs that support AAOS and eventually the best bet for developers, given that reluctant OEMs that don’t want to use Google’s services today could eventually change their mind in the near future.
- Non-GAS: This encompasses third-party app stores specifically designed for automotive environments. Some car OEMs using this alternative are Mercedes, BMW and the VW Group. A couple of app stores worth mentioning are:
While non-GAS options present interesting alternatives, particularly for certain markets or car manufacturers, my post will primarily focus on my experiences with Google Play and Android Automotive apps within the GAS ecosystem.
As I navigate through the various aspects of AAOS development, I’ll highlight both the challenges I’ve encountered and the solutions I’ve discovered or propose. My goal is to provide fellow developers with insights that can help streamline their AAOS development journey and to spark a dialogue about potential improvements to the ecosystem.
Whether you’re a seasoned Android developer looking to expand into the automotive space or a newcomer curious about the landscape, I hope my experiences and observations will provide valuable guidance as you embark on your own AAOS development adventures.
Limited Development Options
In my experience with AAOS development, I’ve found that the development options are quite constrained, primarily due to safety considerations and the use of templates. Let me explain.
Template-Based Development
AAOS apps published on Google Play are required to use templates. These templates are provided by the Car App Library, which is the same library used for Android Auto (the projected mode). This standardization ensures a consistent user interface across different apps and vehicles.
Safety First
The use of templates is not just a design choice; it’s a critical safety measure. Templates are designed to minimize driver distraction, which is crucial when developing applications for use while driving. They provide a familiar, easy-to-navigate interface that drivers can interact with quickly and safely.
Car App Library as the Solo Player
Currently, the Car App Library is the only way to publish AAOS apps on Google Play. While this ensures consistency and adherence to safety standards, it does come with some limitations:
- Limited Customization: The templates, while ensuring safety and consistency, can feel restrictive from a developer’s perspective. There’s less room for unique, branded experiences compared to regular Android app development.
- Constrained Functionality: Not all features that might be desirable in a car app can be implemented within the confines of the provided templates. While I understand and appreciate the need for safety, I can’t help but feel that the current setup might be limiting innovation to some degree. There could be potential for safe, yet more flexible development options that allow for greater customization and functionality.
Future Considerations
I believe Google could explore options to expand development possibilities while still maintaining the necessary standards for in-vehicle applications. This could involve:
- Introducing more diverse templates that cater to a wider range of app types.
- Allowing for more customization within the safety parameters.
- Potentially opening up a review process for custom interfaces that meet strict safety guidelines.
The challenge lies in striking the right balance between safety, consistency, and developer freedom. As the AAOS ecosystem matures, I hope to see evolution in this area that allows for more innovative apps while keeping driver safety at the forefront.
At the time of writing, Google has a beta program for Car Ready Mobile apps:
The Car ready mobile apps program is an upcoming program to distribute eligible mobile apps in the video, games, and browsers categories without any developer work.
This looks quite promising, since it will allow the distribution of apps on AAOS without having to use the templates. The main limitation is that the app’s usage will only be allowed while parking.
Outdated Sample Code and Documentation
The official GitHub repository for car samples has not been maintained for years. While the actual samples exist in the AndroidX repository, this information is not easily accessible to developers.
In order to facilitate the communication and give feedback on found issues to Google, I created a mirror of the car samples repository.
Suggestion for Google
Regularly update the official GitHub repository or provide clear documentation pointing to the current location of sample code. Additionally, improve documentation on how to use templates, as currently, developers must dig through APIs to understand implementation details.
Some major caveats that I found in the documentation, or better said, some information that I didn’t easily found or was lacking is the following:
- A clear statement with many exclamations and clarifying that the only possible way to publish apps for cars on Google Play is by using the Car App Library for the UI/UX.
- There are different categories that developers can target when building an app for cars, i.e., navigation, point-of-interest, media, etc. Each of these categories is obviously supported by the Car App Library with specific templates. One of the major issues here is that regardless of the category, you could use templates and APIs that belong to a different category without any impediment. This will work only until you face the Google rejection during the Google Play review process (more details in the next section).
Google Play Review Process
One of the most significant pain points for developers is the Google Play review process for AAOS apps. The feedback provided during rejections is often vague, making it difficult for developers to identify and fix issues. This lack of clarity leads to frustration and delays in the app release cycle. A few examples of these can be easily found here and here.
Proposed solution
Establish a more collaborative approach between Google and developers. Implementing a system for more detailed, actionable feedback would greatly improve the review process and help developers address issues more effectively.
Tight Coupling of Automotive and Mobile Releases
Currently, the Automotive form factor is tightly coupled with mobile releases on Google Play. This coupling can create unnecessary dependencies and slow down the release cycle for mobile apps, even when the AAOS version faces issues.
Developers face a dilemma when choosing between reusing the mobile app’s package name or creating a new one for the AAOS version. While reusing the package name offers a unified Google Play listing, it can lead to release blockages if the AAOS version faces rejection.
Based on experience, using different package names for mobile and AAOS versions is recommended. This approach allows for independent release cycles and mitigates the risk of the mobile app being affected by AAOS app rejections.
Recommendation
Google should consider decoupling the Automotive and mobile form factors on Google Play. This separation would allow developers to update their mobile apps independently of the AAOS bundle, streamlining the release process for both platforms.
Conclusion
As I reflect on my journey through the Android Automotive OS landscape, I’m filled with excitement. The potential for innovation in this space is immense, offering us, as third-party developers, unprecedented opportunities to shape the future of in-vehicle experiences.
However, my experiences have also highlighted several challenges that need addressing to truly unlock the full potential of this ecosystem. From streamlining the review process to providing more flexible development options, there’s significant room for improvement.
I believe that by tackling these challenges head-on, we can create a more vibrant and efficient AAOS development environment. This isn’t just about making our lives as developers easier – though that’s certainly a plus! More importantly, it’s about enabling us to push the boundaries of what’s possible in automotive apps.
The end result? A richer, more diverse range of high-quality apps that will not only delight AAOS users but also contribute to safer, more enjoyable driving experiences. As we continue to navigate this evolving landscape, I’m optimistic about the road ahead and excited to be part of this transformative journey in automotive technology.