Considering Google Automotive Services? What you should be aware of.

In the previous article in our series, we went into detail about the features and benefits that make Google Automotive Services (GAS) an attractive option for solving many of the problems that OEMs need to overcome in order to launch an infotainment system based on Android Automotive OS. However, there are always trade-offs to the benefits provided by a full solution platform. In the case of GAS, these can be best summarized along 3 distinct vectors – conformance requirements, financial and engineering resource requirements, and risks to partnering with Google itself.

Google’s Certification Process

By licensing GAS, an OEM agrees to certain conformance standards that must be met to meet Google approval for production use. The key requirement that GAS imposes along these lines is its certification process – it requires the OEM to pass a variety of Google-maintained testing suites. It starts with the traditional test suite that all Android device manufacturers are very familiar with, the Compatibility Test Suite (CTS). For GAS certification, there are a few more automotive-specific test suites that come into play. There is the Automotive Test Suite (ATS), meant to ensure that a device can run GAS applications successfully. In addition, there is the Drivable Test Suite (DTS), a supplementary test suite that ensures the system behaves as expected under driving conditions. These, alongside additional requirements, come together to form the certification process that must be passed to launch a vehicle with GAS. Passing this means requires dedicated development and testing resources.

Financial Resources

Then there are the financial and engineering resources required in the integration process. There are three ways one could quantify the costs associated with utilizing GAS – the base licensing costs, the hardware specification costs, and the software conformance costs. The base licensing cost is the most obvious – the standard known business model for GAS is a per-vehicle license fee, the exact number of which being specific to the contracts between Google and the individual OEMs. Regardless of the negotiated price, that is still an additional cost per vehicle that must be considered.

Then there are the hardware specification costs. One requirement imposed by Google in using Google Automotive Services is for all target hardware to meet a certain minimum specification. This specification covers quite a few categories. One such category is memory and storage, including minimum nonvolatile storage and minimum RAM. Another is available connectivity options – it is required to have Wi-Fi connectivity and Bluetooth connectivity (both classic and LE). Yet another requires sensors such as GPS (or GNSS). The list goes on from there.

So in order to meet these requirements, a certain minimum amount of money must be invested into any infotainment hardware target that will install GAS. Depending on the price point desired, this may entirely preclude the use of GAS with lower trims on certain nameplates. This is probably a key factor in why we see the solution present mostly in premium EVs and only the more costly trims of more affordable vehicles like Lincoln’s Nautilus or Navigator. Having to account for GAS on some trims and non-GAS on others leads to development fragmentation, which can have a knock-on effect to development costs needed to maintain multiple infotainment builds.

Finally, there are the software development costs. Alongside the hardware requirements mentioned above, you must consider the additional resources required to pass the GAS certification process mentioned previously. And while GAS provides many components that cover many common functionalities in an IVI, it does not provide the whole system for the OEM. Regardless of what AAOS infotainment solution is selected, there will always be effort on the OEM’s part to expose information to the system from elsewhere in the CAN network via the VHAL (Vehicle Hardware Abstraction Layer), for example.

Dependency on Google

A final consideration to account for is taking on Google as the key partner in the development of your infotainment system. Google, of course, owns Google Automotive Services. As of the writing of this article, there is no way to gain access to Google Maps, Google Assistant, and the Google Play Store in an AAOS context without signing on for GAS. But to do so, you must meet all the requirements we have discussed here that Google defines – including UX, performance, safety standards, and so on. In this way, you are somewhat beholden to design and software decisions that Google makes, with no implicit guarantee that any one OEM will have a significant impact on the platform’s roadmap.

And we would be remiss to not mention some of the additional external factors impacting Google and their efforts in this space that may give an OEM pause. One such factor is Google’s limitations in China. Android Automotive does not have meaningful market share in the region, and furthermore, Google services themselves are famously limited in the region. This has lead to scenarios where even OEMs who have partnered with Google to use GASare finding themselves developing parallel infotainment solutions for the China region.

There has also been explicit legal pushback to GAS and its practices – the most explicit case being the German government’s legal notices describing its investigationsinto potential anti-competitive practices by Google, which it describes as such:

• Google offers vehicle manufacturers the services Google Maps, Google Play, and Google Assistant as a bundle only (referred to as “Google Automotive Services”).
• Google grants certain vehicle manufacturers a share of the advertising revenue on condition that they refrain from pre-installing other voice assistants next to Google Assistant.
• Google Automotive Services license holders must set Google services as a default or display them prominently.
• Google limits or refuses to allow interoperability of the services included in the Google Automotive Services with third-party services

To Google’s credit, they have proposed solutions to these claims that very well may go into practice to resolve the anti-competition claims levied against them – but for now, it remains a factor that must be considered before taking the plunge.

And ultimately, there are always drawbacks to depending on a single external supplier for infotainment, whether it’s Google or others – especially one that imposes specific requirements like Google and other solution providers do. By meeting enforced software and hardware needs, an OEM has less overall freedom in how they design their IVI systems.

Summary and Conclusion

Every aspect we have discussed has an impact on one key characteristic – flexibility. By integrating GAS, an OEM is trading in some of the flexibility to determine its infotainment designs. By meeting hardware specifications, constraints are placed on what physical components can be used. By meeting software conformance requirements, constraints are placed on what UI / UX can be developed.

Ultimately, meeting these necessities may preclude GAS from being used entirely. The immediate reasons are obvious – too expensive to source the required hardware, too resource-intensive to pass the testing suites, etc. But there are less obvious reasons as well. One entire category of vehicles points to this – small form factor (or entirely “headless”) infotainment. GAS requires a touchscreen available to the user, but it is certainly not unheard of for an infotainment solution to only be controlled by hard keys, especially in small screen (or entirely screenless) contexts such as motorcycles and lower car trims. So before the step to use GAS is taken, it must be determined if all of the above trade-offs are worth it.

Now that we have laid out the pros and cons of signing up for the Google Automotive Services ecosystem, we hope that the picture is clearer on whether the solution is the best fit for a particular infotainment environment. But we would also like to show what else is available in the world of Android Automotive platform solutions – in the next article in this series, we will be exploring alternatives to GAS that are available on the market.

Nick Dedenbach, Manager Android Automotive Team