LIVI, an open source CarPlay and Android Auto head unit for Linux and macOS

A head unit that speaks CarPlay and Android Auto natively

LIVI, Linux In-Vehicle Infotainment, is an open source Apple CarPlay and Android Auto head unit. It runs on Linux, including the Raspberry Pi 4 and 5, and on macOS, on both ARM and x64. The description calls it a standalone cross-platform head unit with a native, zero-copy GStreamer video pipeline and hardware-accelerated decoding, low-latency audio, multitouch plus D-pad navigation, and support for very small embedded and OEM displays.

The audience is narrow and specific: people building a car infotainment system who want to run their own head unit rather than buy one. The list of CarPlay functions is long and specific rather than generic. Main and instrument cluster video in H.264 and H.265/HEVC is hardware decoded and zero-copy, the cluster content is configurable between a map or a maneuver card with compass, ETA and speed limit, and the audio side covers playback, phone calls, microphone uplink and Siri. There is volume control in both directions between the phone and the head unit, now-playing metadata including album art, turn-by-turn navigation data, GPS forwarding, clock synchronization, day and night mode, and a dock that can sit left, right or bottom with right-hand drive support.

Some of these are marked as CarPlay Ultra only, which includes climate control, extended vehicle data, car maker themes, and video in the car for AirPlay content while parked, with no FairPlay-protected content.

An Electron shell over a native Rust core

The repository layout shows how the project is put together. There is a src/ directory and an assets/ directory alongside an electron-builder.yml and a vite.config.mts, which is the shape of an Electron application with a web front end built by Vite. Alongside that sits a native/ directory with a rust-toolchain.toml and rustfmt.toml at the root, and the primary language for the repository is listed as Rust. The native half is where the GStreamer pipeline and the CarPlay and Android Auto stacks sit, while the Electron half is the settings interface, the device list and the surrounding shell.

The build scripts make the split explicit. The app build is vite build, the native build runs a script per architecture, build:native:arm64 and build:native:x64, and the platform packages are assembled by electron-builder for mac and linux targets, with AppImage named for the linux x64 target. The two halves are combined rather than merged: the native binary is built first, then the app is built, then electron-builder packages them together.

The rest of the tooling is a modern JavaScript workspace. pnpm-lock.yaml and pnpm-workspace.yaml sit at the root, biome.json handles formatting and linting, and vitest.config.mts and a set of tsconfig files cover type checking for node, web and tests. It is a project with real release engineering rather than a script, and the presence of a native/ directory is the first thing to check if you want to understand where the video work happens.

The MFi coprocessor is the hard requirement for CarPlay

CarPlay requires the accessory to authenticate against the phone. The documentation is blunt about how that happens: it normally requires an Apple MFi authentication coprocessor, a hardware chip that cannot be emulated and that LIVI neither ships nor bypasses. Two routes are described. The coprocessor can sit on the board, wired to the I2C bus, or authentication can happen over the network through a LIVI Link, a separate accessory that brings its own radios.

On the board route, two configuration keys in config.json tell LIVI where the chip is. carPlayMfiI2cBus defaults to 2 and names the I2C bus number the coprocessor is on, and carPlayMfiPowerGpio defaults to 21 and names the GPIO that powers it. Without one of these routes, native CarPlay is unavailable, and the documentation is explicit that all Android Auto paths work regardless.

A Mac has no I2C bus to put a coprocessor on, so there the LIVI Link is the only option. There is a second limitation in the same area: LIVI does not support Apple's Basic Accessory Authentication on macOS, though it may in the future. That single sentence defines the boundary of the project. LIVI is not a way to get CarPlay on a Mac without a licence, it is a way to build a head unit that satisfies the same authentication requirement a factory unit does.

Its own Wi-Fi access point instead of the car's router

Wireless sessions do not need a router. LIVI brings up its own Wi-Fi access point and the phone joins it, with Bluetooth carrying the pairing and the handover while the session itself runs over Wi-Fi. Wireless CarPlay and wireless Android Auto are enabled separately, so a head unit can offer one, both or neither. With Auto Connect on, a phone that has been paired before is picked up again on its own, and the name configured on the head unit is what the phone shows when it lists nearby vehicles.

The Wi-Fi page sets the band, password, channel and country for the access point and picks the Wi-Fi interface, and the Bluetooth adapter is selected next to it under Connections. The Dedicated Interface option is the interesting one. When it is on, the Wi-Fi adapter is reserved for the access point and brought up during boot, outside NetworkManager's control. When it is off, the access point starts on demand and the interface is handed back afterwards, which keeps the adapter available for normal networking at the cost of a moment on the first connection.

That trade-off is the sort of detail that decides whether a head unit fits a particular car. A dedicated interface gives predictable behaviour at boot and removes the adapter from the normal network stack. The on-demand mode keeps the adapter usable for internet access in the car, at the price of a slower first connection.

Handover between phones instead of a reconnect

Several phones can be connected at once, and all of them are tracked live. Every session keeps its state, its battery and signal readings, its media metadata and its turn-by-turn navigation up to date in the background, not only the session currently on screen. Switching between them is described as a handover rather than a reconnect: the drivers stay armed and the video and audio paths stay open, so bringing another phone forward takes milliseconds instead of multiple seconds.

There are device limits, and they are worth reading carefully. Wireless CarPlay, wired CarPlay and wireless Android Auto each take several devices at once, while wired Android Auto is currently limited to one device. Within those limits the transports can be combined freely, so a mixed set of CarPlay and Android Auto phones over cable and Wi-Fi is a normal case rather than an exception.

The device list shows each device with its transport, its battery level and its carrier or signal strength, and the numbered badge is the slot it occupies, with the active session highlighted and the others marked as available. You can switch from that list, or bind a key under Settings, General, Key Bindings, Cycle Session to step through connected phones. Removing a device ends its session and forgets the pairing.

Building the app and the native halves separately

The package scripts in package.json describe the developer workflow, and the project pins its package manager at [email protected] with the version field at 9.5.0. A clean checkout installs with a frozen lockfile, and the standard build runs the type checks and the app build together:

pnpm install --frozen-lockfile
pnpm run typecheck && pnpm run build:app

The typecheck step is two separate invocations, one over tsconfig.node.json and one over tsconfig.web.json, which reflects the split between the Electron main process and the web front end. The native binaries are built separately per architecture through a script that takes an --arch argument, and the platform packages are produced by electron-builder, which is where the AppImage for linux x64 and the mac arm64 and x64 bundles come from. The dev script is vite, and start runs vite preview.

There is also a maintainer-side cleanup path that removes node_modules, the lockfile and the build output before reinstalling without a frozen lockfile. Nothing in the scripts requires a display to install dependencies, but running the head unit obviously does. Two housekeeping details suggest an active project: a prepare script that wires husky for git hooks, and a postinstall step that syncs the Biome schema.

Colour correction for panels that are not colour accurate

Car displays are rarely colour accurate, and the documentation names the usual failures: cheap panels wash out blacks, run cold or warm, or crush the shadows once sunlight hits them. LIVI can correct this in software. Gamma, contrast and the red, green and blue channels are adjustable independently, and the correction is applied by the compositor as a single pass over the finished frame, which covers everything on screen, including the LIVI interface, the dashboards and the projected CarPlay or Android Auto video alike.

The pass only runs while a value differs from its default, so a display that needs no correction costs nothing. The controls live under Settings, Appearance, Contrast and Gamma, and Settings, Appearance, Color.

This is a small feature that says something about the audience. A phone app cannot do it, since the correction happens in the compositor after the frame is composited, and it is the kind of detail that only matters to someone who has installed a panel into a car and then looked at it in daylight. It is also where the limitations of the project become visible. Wireless CarPlay needs both a Bluetooth and a Wi-Fi interface, wired CarPlay works on any USB port, video in the car excludes FairPlay-protected content, and a set of features including climate control, extended vehicle data and car maker themes are marked as CarPlay Ultra only.

Editorial conclusion

LIVI suits hobbyists and automotive developers who want to run a phone-projected head unit on a Raspberry Pi or a spare Mac and can obtain an MFi coprocessor or a LIVI Link, and it does not suit installers who need a certified, licensed head unit or a guaranteed path to FairPlay content. Before you build, check whether you can put an MFi coprocessor on the I2C bus, since without it native CarPlay is unavailable even though every Android Auto path still works, and confirm the device limits, because wired Android Auto is currently limited to a single device while wireless sessions take several.

Frequently asked questions

Official sources

1. f-io/LIVI on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases