The Top 9 Misconceptions About Apple and Google in the Car

If you watched Apple’s latest Worldwide Developers Conference (WWDC2022), you likely heard that the next generation of Apple CarPlay® is designed to run on multiple car screens, including the instrument cluster. Google also announced during last year’s Google I/O conference that the Polestar 2 is the first car shipping with Android Automotive OS. These announcements with their interpretations and predictions by media outlets and armchair pundits alike have created a lot of confusion about the relationship between automakers and these consumer-electronics giants, and the role of operating systems such as Android Automotive and QNX® in the car.

QNX is a high-performance real-time operating system (RTOS) that offers automakers the highest level of functional safety for automotive, which is why it is the OS of choice in safety-critical applications in the car. This Includes digital Instrument clusters as well as advanced driver assistance systems (ADAS) and Autonomous Drive applications in software-defined vehicles.

Operating systems such as Android Automotive OS, on the other hand, are not certified to the highest level of functional safety, but instead provide automakers with a powerful foundation for non-safety critical applications, particularly infotainment.

As a longstanding trusted supplier and collaborator with most of today’s automakers, we know that it’s easy to misunderstand these announcements and their impact. Because we’ve been fielding many questions about the future and status of the automotive software landscape, we thought it might be helpful to put together the following list of common misconceptions.

Misconception #1: You can use the new Apple CarPlay without bringing your phone into the car

The new Apple CarPlay works the same as the old CarPlay; the feature is still phone-powered, and it still requires that the user has a CarPlay-capable iPhone® for it to work. If you forget your phone, forget using CarPlay.

Misconception #2: Apple CarPlay or Android Auto is a replacement for the automaker’s infotainment system

This is not the case. Both Apple CarPlay and Android Auto™ use projection technology, meaning that the phone sends screen images to the car’s infotainment system, which in turn sends screen touches and button presses back to the phone where it processes these interactions. Automakers don’t want their customers left without entertainment, navigation, or other services if the user forgets their phone, leaves behind a connecting cable, or hasn’t kept the phone fully charged. In fact, battery use is a big factor for both automakers and consumers. These phone applications use a lot of processing power and can drain battery reserves quickly if the phone is not being charged. This is especially true with commonly needed applications like navigation. In addition, there are many vehicle-specific infotainment system functions that don’t exist in CarPlay or Android Auto like audio equalizer and front/rear fader, for example.

For many customers, it’s a matter of convenience. While some may prefer the consistency of transposing their phone’s interface to the vehicle, others prefer not to mess with connections and settings before their car is fully functional. Most people expect their car’s features to be immediately available as soon as they get in their car rather than fumble with their phone connection or wait for phone apps to appear on the car’s infotainment system.

Misconception #3: Apple CarPlay and Android Auto replace the need for an automotive OS

The car still needs an automotive OS to support projection mode features. Even if the car screen stays blank except when Apple CarPlay or Android Auto is activated, the software in the vehicle’s infotainment system is still responsible for handling the phone connection (with Bluetooth®, Wi-Fi, and USB software stacks), bidirectional data transfer, video stream decoding, touch screen and microphone input, graphics and audio output, and the gathering and packaging of car-specific data for the phone.

Moreover, the infotainment system has many other responsibilities that support important features. Some of them are hidden (such as an in-vehicle Wi-Fi hot spot or in-vehicle acoustics processing), associated with using the car (like EV/hybrid power flow or user manuals), related to other car systems (telematics or body modules, for example), or safety-related (backup cameras, ADAS displays, and the like). These features require specialized software stacks to access the CAN, LIN, MOST, FlexRay, and EAVB vehicle buses. Many also require consistent real-time responses and depend upon components like an automotive-grade or real-time operating system, and/or a hypervisor designed to offer a protected environment that operates alongside a consumer-grade infotainment software stack.

Misconception #4: Apple CarPlay and Android Auto can take over the in-vehicle displays without cooperation from the automaker

This simply isn’t true. Phone projection solutions only work if the car includes the required software support for phone connectivity; they don’t “hack” or “take-over” the display. Since the automaker controls in-vehicle software, any vehicle that supports a phone projection solution is one where the automaker has made agreements with Apple and/or Google to do so and has included all the necessary software components on their side.

Misconception #5: If the phone displays information in the instrument cluster, that must mean the phone is running safety-critical software

The phone isn’t considered a safety-critical system, period, and it doesn’t run safety-critical software, even in the case of projecting information to the instrument cluster. That said, this situation is admittedly a bit tricky.

The safety standard that applies to car software is ISO 26262, which determines the risk level (the Automotive Safety Integrity Level or ASIL) for each safety-critical software component in the car. ISO 26262 describes differing levels that range from quality management (QM) for items without safety concerns to ASIL D – the highest safety classification for features like airbags, anti-lock brakes, or power steering. Each component is assigned either QM or an ASIL level based on the severity, exposure, and controllability of potential failures. Unlike most infotainment software that has no safety implications, and thus can support phone projection technology without significant risk, the instrument cluster is normally safety certified.

To understand why instrument clusters are considered safety-critical, consider what happens if the display hangs or glitches. While not knowing your speed may not seem too detrimental, improperly understanding safety alerts (such as blind spot detection or lane drift warnings), losing backup-camera video, and misunderstanding gear settings (PRNDL) could all cause a crash and injury. Frozen, blank, or erratic cluster displays can also distract an attentive driver and it could be lethal to try to fix or diagnose a cluster malfunction at high speeds. It’s for these reasons that the instrument cluster is safety-certified and normally built with highly reliable automotive-grade software components.

So how does relocating the instrument cluster’s display generation logic to the phone impact the car’s software architecture and safety-certification ratings? Similar to the infotainment system, the car’s instrument cluster requires a full software stack that can show driving gauges when the phone isn’t present or connected. And just like infotainment projection, the cluster also requires software to manage the connection and display when the phone is taking over the cluster screen real estate. Neither the severity nor the controllability of an instrument cluster malfunction changes regardless of whether the display is currently being controlled by the phone or not. However, using a phone as the underlying implementation will certainly impact the exposure risk. While a failure might be an exceptionally rare occurrence for a built-in cluster, a failure is orders of magnitude more likely when the car’s display is driven by a connected consumer device.

Although the full details for the next-gen Apple CarPlay have yet to be released, it’s clear that safely integrating CarPlay into the instrument cluster will require collaboration between the automaker and Apple. To minimize the impact of phone reboots, crashes, or power-downs, the automaker can provide a hot-failover mechanism to allow the car’s cluster software to take over the instant the car loses a phone connection. Certain safety features like ADAS notifications and visualization or backup cameras will almost certainly be prevented from running on the CarPlay display unless they are controlled by the automaker and bypass the phone. (For example, the phone might dictate where on the display those features need to be, and the car would overlay safety-critical elements in blank areas reserved by the phone-supplied cluster graphics). The phone may also require a hard-wired USB connection rather than Wi-Fi or Bluetooth connectivity when the user wants instrument cluster functionality. Accommodations like these can maintain a level of safety and allow a phone to project to the instrument cluster without the impossible task of safety-certifying the phone.

Misconception #6: Android Auto and Android Automotive OS are different names for the same thing

While Google has unfortunately named these products with very similar-sounding names, they’re about as different as they could be.

Android Auto is Google’s equivalent of Apple CarPlay – a projection solution that lets the phone “take over” the infotainment display. As mentioned previously, while the core software application runs on the phone, it still requires the automaker to have important software components on their infotainment system to support Android Auto projection technology and many other vehicle infotainment functions.

Android Automotive OS (AAOS) is a version of Android™ OS that Google has customized to run in the car. That is, it runs directly in the car and doesn’t need a phone. Although it replaces a traditional automotive infotainment software stack, it isn’t an “aftermarket” load that can be dropped into any car. The car infotainment system must still be designed and built specifically to run AAOS and any additional automaker applications. Google provides this as an option for automakers who want a pre-integrated infotainment stack baseline software package so that automakers can customize it and leverage the Android tools and developer ecosystem.

AAOS doesn’t include core Google® applications, like Google Maps™, Google Assistant™, and Google Play™ store by default. Automakers can choose to supply their own navigation applications, voice assistants, and application stores. If they want to use Google’s apps and tap into the Google Play app ecosystem, then they’ll need to license Google Automotive Services (GAS) too.

Misconception #7: Android Automotive OS can run anywhere in the car

Android Automotive OS is designed as an infotainment stack, and as it’s essentially phone software (AAOS uses the same code base as Android phones), it’s best used for this purpose. It can’t meet many of the safety-critical requirements of instrument cluster software, such as real-time responsiveness, deterministic execution, high reliability, safety certifiability, or fast booting.

As a result, we think it’s very unlikely that any credible automaker would consider AAOS for the software stack in an instrument cluster. While some smaller companies may experiment with this for low-volume or developing markets, these would be exceptional cases and are unlikely to be acceptable in markets with strong transportation oversight and government regulations.

Misconception #8: The bulk of car software will be controlled by Google and Apple 

With projection technologies like Apple CarPlay and Android Auto, a relatively small proportion of the infotainment system software is dedicated to handling projection-related features. In the case of Android Automotive OS, which replaces the automaker’s infotainment system software, there is a much bigger contribution; once AAOS is adopted, it forms the basis of the automaker’s infotainment system software.

However, it is important to remember that besides infotainment, the car consists of a great many discrete modules (also called ECUs) with their own software. Advanced driver assistance systems (ADAS), autonomous driving, body modules, engine control, V2X, active suspension, noise suppression, electric vehicle systems, and diagnostics add to the car’s unique software load. While the infotainment system may have an outsized representation from the user’s point of view, it is not the bulk of the car’s software. 

Misconception #9: If an automaker embraces Android Automotive OS, they have no way to differentiate themselves

All automakers that use the Android Automotive OS will certainly have a similar look and feel to their infotainment system. However, Google provides ways for automakers to customize their look and feel with unique icons, color palettes, layout templates, screens, and typography so each car’s user interface can have an individual appearance. These visual cues can become part of the unique identity of the car.

In addition to these surface elements, automakers can also provide their own bespoke applications and services or offer unique custom features that depend on the car’s hardware. They can also enter into special partnerships with app providers, allowing them to augment popular apps with automaker-labeled, customized services or automaker-specific features. All these things allow the automakers to differentiate themselves against other AAOS-using manufacturers.

Dispelling the Misconceptions

We know there’s a lot of confusion around the relationship between automakers and consumer-electronics giants Apple and Google. It’s easy to understand why given the buzz around recent announcements, the changing technology landscape, and complexity of in-vehicle software architectures. Hopefully, this blog dispels some of the misconceptions and helps clarify the rightful role Apple CarPlay, Android Auto, and AAOS perform in the car. If you have any other questions, please get in touch.

Related Reading

• Streamlining Automotive Acoustics Design: Hands-On, Part 1 [Video]
• Why Mixed Criticality is the Future of Automotive Architectures
• Get In: The Software-Defined Vehicle Podcast From BlackBerry (Episode 12)