xcertplay for Android head units: setup and deployment considerations

What xcertplay solves in an Android head unit

xcertplay targets a specific embedded problem: receiving CarPlay on an Android head unit rather than on an iPhone or an ordinary consumer Android tablet. The repository provides separate host applications for Android and Android Automotive OS, with shared CarPlay code in `common/` and implementation modules in `shared/`. It is intended for integrators, automotive developers, and experimenters who need to connect an iPhone to a vehicle interface under their own control.

The project supports more than a basic video connection. Its documented capabilities include voice, navigation, and multi-channel music output, vehicle head-unit location reporting, automatic re-handshaking after an Activity resolution changes, and separate browser pages for a main display and an instrument display. The main display can accept touch input and route phone audio, while the instrument display is view-only and depends on the iPhone supplying a second video stream.

The hardware boundary is narrow. The documentation requires a physical Android device with USB Host or OTG, an MFI chip, and either a CH341 I2C bridge or access to a native `/dev/i2c-N` device. That makes xcertplay closer to an embedded receiver project than a general Android application that can be installed on any phone.

MFI authentication paths and certificate handling

The authentication model is one of xcertplay's most consequential design choices. The README lists three supported arrangements: an MFi chip attached through a CH341 bridge, a local MFI certificate and private key, or a Remote MFI service. The native Android I2C controller is also supported through `/dev/i2c-N` devices. This gives integrators several ways to connect the receiver to hardware or to an external signing service, but it also means that deployment depends on correctly provisioned credentials.

For local files, the app expects a DER PKCS#7 certificate with the `.p7b` extension and a matching, unencrypted DER PKCS#8 private key with the `.pk8` extension. Android's document picker selects both files, and the app validates that they match before starting the iPhone connection. It reloads them when the MFI connection reconnects. According to the README, the files are not copied into app preferences. The app saves Android's persistent read permission and the document URI, so file access depends on the original protected storage location and Android's permission state.

The Remote MFI client exposes `GET /mfi/certificate`, `POST /mfi/sign`, and `POST /mfi/reset`. The signing endpoint accepts `challenge` and `requestId`, while the reset endpoint sends an empty JSON object. Standard Bearer Authentication is optional. The documentation explicitly says that only BAA Authentication has been tested, so a production integrator should not treat the other remote authentication path as equally validated.

Wired, wireless, and browser display behavior

xcertplay supports wired and wireless CarPlay connections. The documented user flow begins with Bluetooth pairing between the iPhone and the head unit. Before video starts, the operator opens the app's Settings page, either through the lower-right Settings button or through a configurable gesture. Settings are saved with `Save & Reconnect`, after which the selected MFi connection method is used and the receiver waits for the phone connection to complete.

For browser output, Settings contains `Main display` and `Instrument display` options under `Web displays`. After enabling a display and setting its resolution, the browser device must be on the same LAN as the Android device. The page is then opened at the address shown in Settings, using paths such as `https://<IP>:8080/main` or `/cluster`. The browser decodes H.264 and H.265 directly rather than receiving a conventional media-player stream.

The HTTPS certificate is self-signed, so a browser will show a warning once. The main page supports touch with up to two fingers and requires a tap before browser audio can play because of browser autoplay requirements. The microphone remains on Android. The instrument page does not accept touch and requires the iPhone to provide a second display stream. If a browser cannot decode H.265, the documentation says to disable `HEVC (H.265)` in Settings.

Building xcertplay with the Gradle targets

The first engineering task is building the shared code and both Android targets. The README requires JDK 17 or newer, Android SDK Platform 37, Android NDK `28.2.13676358`, and Android 9, API 28, or newer. The project also states that physical USB Host or OTG hardware and MFI hardware are required for hardware validation.

On macOS or Linux, the documented development command runs shared unit tests, lint tasks for the common and application modules, and debug assemblies for the mobile and automotive targets. It does not produce a signed release artifact. The command is:

./gradlew :shared:testDebugUnitTest :common:lintDebug :mobile:lintDebug :automotive:lintDebug :mobile:assembleDebug :automotive:assembleDebug

A successful build should produce debug outputs for the `mobile` and `automotive` applications while also running the documented verification tasks. The repository also documents an unsigned release build for those two targets:

./gradlew :mobile:assembleRelease :automotive:assembleRelease

The release command is explicitly unsigned, so signing, packaging, permissions, and device deployment remain separate engineering tasks. The README gives a Windows PowerShell equivalent, but the command above follows its documented macOS or Linux path.

Project boundaries, maintenance, and upgrade cost

xcertplay is not archived, and the last push was on 2026-10-15. Recent release entries include `1.4.0` on 2026-10-10, `1.3.3` on 2026-10-01, and `1.3.2` on 2026-09-30. The repository therefore shows recent project activity, although that does not establish compatibility with every head unit. The README says the project has been tested on car head units and phones, but it also asks users to report incompatible hardware with a log from `/sdcard/Android/data/com.shilapi.xcertplay/files/logs/xcertplay.log`.

The largest upgrade cost is hardware integration. An integrator must select the MFI connection method, provide local credential files or a tested remote service, configure browser displays and codecs, and validate Bluetooth pairing, audio routing, touch input, resolution changes, and reconnection on the actual vehicle hardware. Android 9 also has a documented networking constraint: Wi-Fi P2P 5 GHz mode is unavailable there, so LocalOnlyHotspot is used instead.

The project is licensed under GNU General Public License v3.0. That designation matters for redistribution and integration planning, although the repository does not provide legal interpretation. There is no documentation here for rollback procedures, migration of saved certificate URIs between Android versions, or compatibility guarantees across releases. Those points require project-specific verification.

Where xcertplay is the wrong choice

The clearest limitation is that CarPlay Ultra is not a complete implementation. The README says the protocol stack is untested and incomplete, although it can trigger the CarPlay Ultra prompt on an iPhone. A product that depends on the full CarPlay Ultra behavior should treat this as an unresolved boundary, not a supported feature.

The browser display design also creates operational constraints. It requires a browser on the same LAN, accepts a self-signed certificate warning, and depends on the browser decoding H.264 or H.265 directly. A vehicle design that cannot tolerate that browser requirement, or that needs instrument-display input, does not match the documented feature set. The instrument page is view-only, and the second display stream depends on the iPhone.

Compared with an application that delegates all CarPlay work to a known host environment, xcertplay requires direct control over Android hardware, MFI credentials, display routing, and browser decoding. Compared with a conventional native Android media app, it offers CarPlay-specific protocols and head-unit functions but introduces certification, reconnect, and vehicle-compatibility work. The project is therefore best for a controlled engineering prototype or an integrator prepared to own hardware validation, not for an install-and-use consumer workflow.

Editorial conclusion

xcertplay fits integrators who can validate Android head-unit hardware, provide compatible MFi authentication, and accept an incomplete protocol stack. It is a poor fit for a generic Android phone, a browser-only CarPlay experiment, or a deployment requiring confirmed CarPlay Ultra behavior. Before adoption, verify the exact head-unit I2C or CH341 path, Android version, display resolution, browser codec support, and authentication backend against the intended vehicle hardware.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. shilapi/xcertplay on GitHub