A Developer’s Intro to CarPlay
CarPlay has flown under the radar these past years but as more and more cars get equipped with it, developers are going to start using it more and more.
For those who want to learn about a technology that is still early in its adoption stages, keep reading!
First of all, what is CarPlay at a high level? If you really boil it down, it’s a technology that communicates with the car’s built-in system to allow the driver to use some of the apps on their phone that are useful when driving. Think of apps that do navigation, audio, telephony as some examples. In case you’re wondering, no TikTok and Instagram are not apps that are suitable for CarPlay because you shouldn’t be on them while you drive. 🤓
But how does all that work under the hood? This blog post will explain that by going over the first two WWDC talks on CarPlay that go back to 2016. I recommend you watch them here!
As we said earlier, CarPlay allows you to use some of the apps on your device while you drive.
In order to do that the driver needs to connect their phone to the car (via USB or Bluetooth/WiFi) which creates a CarPlay session allowing information to be sent bi-directionally between the connected device and the car’s head unit.
☝️ Just a side note, you probably know what a head unit is but you may not have heard it called that way before. Here’s Wikipedia’s definition:
An automotive head unit, sometimes called the infotainment system, is a component providing a unified hardware interface for the system, including screens, buttons and system controls for numerous integrated information and entertainment functions.
Other names for automotive head units include car stereo, car receiver, deck, in-dash stereo, and dash stereo.
Once the CarPlay session is established, various communication protocols are used to let the iPhone and head unit exchange. When the iPhone is first connected, it asks the head unit to show its screen on the car’s display. A video stream is created and the iPhone’s Home screen is shown on the display.
If the driver then taps on the Music app and plays a track, the iPhone will send the head unit the “Now Playing” screen for that song along with its audio so that it can be played on the car’s speakers.
The point we’re trying to drive home here is that CarPlay allows the head unit and device to exchange data (audio and video in this case) using communication protocols.
Before we get into how all that works, it’s good to back up to understand the bigger picture of how the car’s system is set up. You can think of this system as having 3 entities:
- The head unit’s CarPlay sub-system: used for communication between the iPhone and head unit.
- The head unit’s native sub-system: which has its own UI and logic for things like playing FM Radio, making calls, navigation with the native GPS app, etc.
- The car’s hardware resources: microphone, speakers, display, vehicle sensors, user input elements (control knobs, steering wheel buttons, etc).
The CarPlay sub-system and the native sub-system together make up the head unit. Add the hardware resources and you have the vehicle’s complete system.
Both sub-systems are similar in that they both have an audio component to play/record audio, a video component to render the video screen (and provide an input-output user interface), and an implementation of their own logic for communicating data.
All that is to show that when we’re talking about CarPlay, it can be helpful to think of it as a sub-system of the head unit that is communicating with the car’s resources in order to provide the driver with the overall experience.
Let’s take a closer look at the CarPlay sub-system.
Data goes over an IP-based link from the iPhone to the head unit (USB for a wired connection and Bluetooth/WiFi for wireless). The data is wrapped into an IP client for data exchange. An instance of Apple’s Communication Plug-in receives the incoming audio and video streams as well as user input from the controls (touch screen, knob, buttons or touch pad). Audio and video frameworks communicate data to the head unit’s infrastructure connected to and from the car’s hardware resources: speakers, microphone and display. We also have a component responsible for communicating information from vehicle sensors as well as audio, telephony, and turn-by-turn metadata to the Communication Plug-in. This is done over iAP2 Communication Protocol.
☝ There is a slight difference in architecture between wireless and wired connections. For wired connections, the iAP2 component communicates directly with the IP client instead of going through the plug-in.
Now that we understand how the CarPlay sub-system works and how it fits in to the broader picture, let’s get into specifics and talk about resource management.
Resource management just means deciding which resources take control of the user interface and audio of the vehicle.
As mentioned before, the car has multiple resources: microphone, speakers, display, vehicle sensors, user input elements (control knobs, steering wheel buttons, etc). Only two of these however are managed: the main screen (i.e. the display) and the main audio.
☝️ On CarPlay audio is separated into two channels:
- Main: for phone calls, voice recognition (Siri), audio playback.
- Alternate: for higher priority prompts and sounds used in navigation or new message notifications.
The alternate audio channel doesn’t need to be managed. Since it’s high priority it’s always available so CarPlay doesn’t need any logic to determine when it can use it.
Let’s look at a real life example to clarify all that.
Here we have the native user interface which has taken the display.
Apple uses the verb taken to define a use for an undetermined period of time. The resource owner changes permanently (i.e. until further notice).
If the driver taps the CarPlay icon, CarPlay “permanently” takes over the display.
Some apps only need to borrow a resource temporarily.
Apple uses the verb borrow to define a use for a limited period of time. The resource owner is transferred temporarily until the action completes. When the action completes, the resource returns to the previous owner.
For example if the display is owned by the native UI and the driver gets a call through CarPlay, the CarPlay UI will borrow the display and temporarily become the owner of that resource until the phone call ends and it gives it back to the previous owner: the native UI.
So how is the logic of resource management implemented?
With a resource manager. This manager lives on iOS, not on the native system, and is responsible for the following tasks:
- Holding the current state of the whole system (both the CarPlay and native sub-systems).
- Following a set of rules to determine which system will get the requested resource.
- Assigning the resource based on the two tasks above.
In this example, both the native and CarPlay UI want to show something on the screen so they both make a request to the resource manager to obtain ownership of the display. The resource manager will then check the system’s internal state and based on defined rules will decide to whom it will allocate the resource.
Apple has made interaction with the resource manager quite simple using two commands.
The changeModes command is used to request or release a resource. The modesChanged command is to describe the current state.
Let’s look at what happens when the driver is listening to CarPlay playback audio and wants to switch over to listening to FM radio from the native sub-system. When the driver taps the radio icon the head unit sends a changeModes request to the manager to get ownership of the speakers. Since the head unit wants to permanently obtain ownership, the transfer type is take.
☝️ Apple refers to the resource manager as the controller and the head unit as the accessory.
The controller assigns the audio resource and sends a modesChanged notification to the accessory, allowing the accessory to become the new permanent owner of the resource and play the FM radio.
To sum up, CarPlay interacts with the vehicle’s resources and shares ownership of them with the native-subsystem of the head unit. A resource manager built in to iOS dictates which sub-system should have ownership of requested resources and sends notifications to inform each each of them when ownership may be taken or borrowed.
This concludes our basic introduction to CarPlay. Please leave comments if you would like to discuss this topic!
