Introduction
Recent reports from Ford Authority claim that nearly one-third of car buyers would not buy a vehicle that didn’t offer phone integration. This trend continues, as only 35% of buyers said they would be willing to learn the infotainment system, and 52% of buyers mentioned they would just opt to use their smartphone instead of infotainment.
It’s been more than a decade now since the debut of Android Auto, the smartphone-based system that replicates their already familiar user experiences. It also leverages the phone’s data plan for connectivity, doesn’t require a separate subscription, and seamlessly updates as new apps and features become available.
Given how essential smartphone integration has become for drivers, we decided to take a closer look at what’s really involved in developing Android Auto apps.
Maxim Leykin, PhD, Chief Technology Officer at Bamboo Apps, brings over 20 years of experience in software development, including building mobile apps for major automotive brands.
Joining the conversation were other expert developers from Bamboo Apps, deeply engaged in automotive software development:
- Katerina Soroka, with over 11 years of experience in Android app development,
- and Andrei Mukamolau, who brings more than 8 years in this field.
Together, they provided valuable insights into the practical aspects of Android Auto app development: technical hurdles and emerging trends.
Navigating Google guidelines
Developers should rely heavily on Google’s official guidelines for Android Auto apps. From your experience, what are some critical aspects or challenges these guidelines present?
Maxim: The main problem with the so-called “template-based” approach is that it can be too restrictive. It is challenging to create a truly unique or branded experience when you’re limited to predefined layouts and components. Developers often find themselves wanting to add more visual flair or unique interactions but are prevented by the strict rules.
Another thing is that, even with the “template-based” approach, there can be subtle variations in how different car manufacturers implement Android Auto. This can lead to unexpected UI glitches, rendering issues, or inconsistent behavior that is not easily reproducible in development environments: a button might look slightly off, or touch responsiveness might vary.
Katerina: Google’s official Android Auto guidelines provide a good base, but there are some nuances. Because of UI limitations – buttons, fonts, animations – everything must match the system. Therefore, you need to think about the architecture and navigation in advance, taking into account data updates from the server. You should also set aside time for improvements after the review from Google. Their team often gives vague rejection statements, and you have to guess what exactly needs fixing.
Have you ever found yourself needing to bend these guidelines to improve user experience or functionality?
Andrei: The most limiting part of the guidelines is the list of allowed app categories. Google has good reasoning behind these limitations, i.e., ensuring the safety of the drivers and passengers. However, if your app does not fit into these categories but still makes total sense to be in the car, you will need to jump through hoops only to get the publication rejected. It scares a lot of devs off.
Katerina: We usually build everything according to the guidelines. Applications for cars today are not about “beautiful,” but about “convenient” and “safe.” Google will not approve distracting animations and long texts while driving. It also strictly monitors the requested permissions.
Maxim: I would mention that Google guidelines are not the only source of restrictions and limitations. Sometimes, restrictions can be even location-dependent. For example, recently, a client from the US came to us with the requirement to build an Android Auto app providing video streaming while driving. After some investigation, it was discovered that in several states it was explicitly prohibited (e.g., Georgia, Washington), while in others it was still allowed (e.g., Montana). Thus, we need to consider many factors, including the targeted location, when planning Android Auto app user experience and functionality.
You emphasised safety a lot. How do you personally balance its strict safety requirements with the desire to innovate or provide richer features?
Andrei: Short answer: you don’t. If your app is not a media player or a map, you will need to force it into being one to allow it to be published in the Play Store.
Katerina:
“Safety comes first. We are not thinking about how to break the restrictions; we are looking for ways to present our feature in conditions when the user is not looking at the screen.”
Even a cool feature is a failure if the driver has to stare at the screen for more than 2 seconds. Some of the information can be taken out and made available to the user before driving (on the car screen or on the phone screen), and some can be implemented in the form of voice commands.
Maxim: There is no doubt that “safety first” should become the main principle when designing and developing automotive apps. At the same time, modern technologies still give us enough ways to innovate. For example, Android Auto apps are aware of the driving state (parked, idling, or moving), and this is where the bulk of “richer features” or “innovative experiences” can reside (including complex UI, video, advanced feature configuration, and detailed reports). When the car starts moving, the app must gracefully transition to a more restricted, safety-compliant state. This often means hiding certain features or simplifying the UI.
The challenge is making this transition seamless and intuitive for the user. Going further with this concept, we can adjust map detalisation depending on the speed of the car. I.e., if we run through a highway, we don’t need particular POIs and building numbers; it will be just a visual clutter distracting the driver. But when a car reaches an urban block and speed decreases, it probably means that the driver is looking for something particular, and having a more detailed map here with voice-based suggestions can be of great help.
Technical challenges and optimisation in Android Auto apps
Android Auto apps demand very fast response times. What business or user experience issues have you seen arise from performance lags or crashes, and how have you tackled them?
Maxim: Performance lags and crashes in Android Auto apps are not only frustrating for the user but can also have serious implications. Lags in navigation, music playback, or voice commands force users to try to resolve an issue while looking away from the road, increasing distraction and the risk of accidents. From the business side, it can cause high uninstallation rates, low user engagement, and negative app store reviews, which in turn lead to reduced opportunities for monetisation. Besides that, nowadays the quality of the app can affect the overall reputation of the company that provides it.
As an example of a performance challenge we successfully overcame, I would mention the case when a fuelling app communicated with the server via FCM (push notifications). At some point, it appeared that push notification delivery was not reliable enough, and we had to switch to web socket-based communication.
Katerina: Android Auto screens operate differently: they have a distinct lifecycle and a different screen refresh rate. It is crucial to plan during the architecture stage which data should be loaded and cached in advance, so that when a screen opens, the user doesn’t encounter loading screens. This approach to architecture is somewhat similar to the offline-first principle.
Testing Android Auto apps without access to real cars can be tricky. What strategies, tools, or environments have you found most effective?
Maxim: If we speak about Android Auto, it is not as tricky as with Android Automotive; at least we have a quite good DHU (Desktop Head Unit emulator) that can be connected to a physical smartphone. For sure, we can use typical tools like unit and integration testing. And if we know in advance which particular car models our app is targeted for, we can still try to access them (or very similar models) physically via car rental or car-sharing services.
Andrei:
“Android Auto is quite well abstracted from the real hardware, so emulation works well and is not that different from the reality. There are also aftermarket infotainment systems for embedding into older vehicles; they can be used for testing on real hardware to assess performance, but they might not be configurable for development.”
There might also be some specific test rigs, but they are likely too expensive and/or bespoke-made for the vendor.
Are there any limitations or gaps in the Android Auto SDK or tooling that pushed you to develop creative workarounds? What improvements would you like to see from Google?
Maxim: Besides the already mentioned UI/UX restrictions, I would also pay attention to limited access to car data and car sensors. While Android Auto provides some vehicle data (speed, gear, parking brake), access to a wider range of vehicle sensors (e.g., tire pressure, precise fuel consumption, window status, advanced driver-assistance systems data) is highly restricted. This prevents the development of more sophisticated, context-aware applications that could provide real-time vehicle diagnostics, automate tasks based on car state, or enhance the driving experience with rich data.
As a workaround, sometimes we can use data from phone sensors (e.g., GPS or accelerometer) or data from additional external hardware (e.g., OBD-II dongles). Thus, I would expect from Google deeper integration with cars by providing some kind of unified API for accessing more vehicle data.
Balancing feature requests and constraints
How do you prioritise and negotiate feature sets with clients, especially given the strict UI/UX and safety guidelines that can limit functionality?
Maxim:
“We need to be very transparent in such negotiations, as it will be frustrating for the client to spend time and money on app development and get banned on Google Play because of some violations (which can be a real situation).”
So, the strategy is to discuss required feature sets in advance and split them into several blocks:
- Functionality that can be obviously implemented and supported in Android Auto.
- Functionality that needs to be adjusted in requirements to align with safety regulations but still be feasible.
- Functionality that is hardly feasible or explicitly restricted.
Katerina: Feature prioritisation is a balance between customer desires, technical constraints, and security. App development is a team effort. Personally, I show the designers the official guidelines, provide testers with examples of violations that Google does not miss, and make sure the client is primarily informed about their responsibility to drivers. After that, we can decide what is “must-have” and what is “nice-to-have”, and figure out how to adapt those features for the Android Auto format. If you are not sure about any features, then we are doing a phased release, starting with the MVP.
From a user experience standpoint, what are the most common complaints reported by real drivers using Android Auto apps? How have you worked to improve those?
Maxim: I would say that most of the complaints are about restrictions and limitations of the Android Auto app compared to the same app for smartphones. This is natural because of safety regulations, and the only thing we can do is to properly explain the reason to the user instead of trying to replicate a full smartphone app experience in the car.
Also, there are many complaints about connectivity issues, like “Android Auto randomly disconnects,” “My phone won’t connect at all,” etc. This can sometimes be improved by caching important and often-used data in the app. Also, the Android Auto app should provide robust error handling and graceful degradation, as users are more forgiving of temporary issues if the app communicates clearly what happened and recovers functionality smoothly, at least partially.
According to the 2024 Vehicle Dependability Study, infotainment systems remain the most problematic area for car owners across nine major vehicle categories. The study reports 49.1 problems per 100 vehicles (PP100) related specifically to infotainment. Notably, Android Auto and Apple CarPlay connectivity issues lead the list of complaints, with 6.3 PP100. Close behind are frustrations with built-in voice recognition systems, registering 6.1 PP100.
Accessibility and trends
Accessibility is crucial in many apps, but the in-car environment poses unique challenges. How do you approach it in Android Auto apps?
Maxim: Accessibility in Android Auto apps is not just a feature, as in regular mobile apps; it is a fundamental design principle driven by the critical need to minimise driver distraction and ensure safety.
Among the best practices to approach accessibility, I would start with voice-first interaction, which requires designing the app’s core functionalities to be fully voice-addressable. Also, it is worth mentioning that Android Auto leverages Android’s core accessibility services where appropriate.
Katerina: The app must not assume the driver’s full attention. And at the same time, we want our app to be useful even in noisy conditions and with limited driver attention. Any important information must remain accessible to the user: spoken messages should be repeatable, warnings should be displayed on the screen, and updates or changes should be communicated through notifications.
Some argue Android Auto development is just mobile app development adapted for cars, while others see it as a distinct discipline. What is your perspective based on your experience?
Maxim: I think nowadays, when we can often run the same application on a great variety of devices from laptops to IoT terminals and HMI displays, it doesn’t make any sense to explicitly split development by areas into mobile, desktop, automotive, etc. It is really more about adapting to different devices and providing specific functionality.
Katerina: Android development covers many areas. Some aspects are common to almost all projects: client-server communication, caching, UI rendering, testing, logging, publishing, analytics, authentication. Others come up only in specific projects: Bluetooth, Maps, wearables, telephony, AI, voice interfaces.
I would put Android Auto in that second group – it is a distinct area that requires dedicated focus. It comes with its own Car UX Guidelines, a different emulator, a unique lifecycle, separate architectural considerations, and different priorities and metrics.
In that sense, Android Auto feels like a hybrid of embedded and mobile development, with its own philosophy and approach.
Looking to the future, what emerging trends, technologies, or changes in Android Auto development excite or concern you the most?
Maxim: I would expect that AI agents will contribute significantly to Android Auto by eliminating some of the restrictions and enabling more functionality without compromising safety.
Katerina: Personally, I like these trends:
- The car as part of the Smart Home ecosystem. When all devices are connected within a single system, users get visibility into the status of each device and can control them remotely – for example, turning on the lights or heating, checking fuel levels.
- The growth of voice assistants as a voice interface for apps. Voice control reduces distraction and makes interaction safer and more convenient while driving.
- Active development of Android for Cars by Google. By introducing restrictions, Google helps make driving safer, which builds respect for and trust in the Play Store.
Partner with us to create Android Auto solutions drivers trust
About Bamboo Apps
Bamboo Apps is an automotive software development company based in Tallinn, Estonia, with more than two decades of expertise in the industry. Trusted by such brands as Jaguar Land Rover, Mitsubishi Electric, Škoda, and Rinspeed, we specialise in cutting-edge solutions including car connectivity, Android Auto integration, HMI design, shared mobility, and fleet management.
Our team rigorously follows specialised safety guidelines and standards for human-machine interfaces. Combined with deep knowledge of automotive operating systems, protocols, and frameworks, Bamboo Apps is a reliable partner for OEMs worldwide looking to deliver safe and innovative in-car experiences.
