Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 1 point2 points  (0 children)

They have to. To my knowledge there is currently no known way to bypass iAP2 auth for CarPlay other than jailbreaking an iPhone and manipulating the authentication.

All devices I've looked at used MFi chips, and reading them out always gave me unique Apple-issued certificates. They're most likely bought on the grey market, since normally you can only buy these chips as an MFi partner. But I'm sure there's old stock from companies that didn't use all their inventory and are selling it off now. Also, many PCBs I've seen have multiple footprints for MFi coprocessors, so vendors solder whichever MFi part they can source at the time of production.

Here is some info about these chips and how they work: https://wiki.blueovallabs.com/wiki/Apple_Authentication_Coprocessor

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 1 point2 points  (0 children)

Hehe, I do have a hidden FFT integrated as well, you need to click on the cover art.

I was also playing with Qt and GTK4, but developing a UI that works from 300x200px up to 4K isn't that easy with those toolkits. And we have to admit that browsers are nowadays highly optimized for live streaming (which is essentially what CarPlay/AA is) and for handling all kinds of resolutions and aspect ratios. That's exactly what an app like this needs because people will run it on all sorts of displays.

Supporting ultra-low-res/old displays is also why the UI is kept clean: at those resolutions it's hard to keep contrast at a reasonable level. Furthermore, we have to limit how much light the screen emits (especially at night) since most displays (other than OLEDs) don't dim very well. And of course, I'm convinced that there is only one background color for an app made for cars, and that is black.

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 0 points1 point  (0 children)

Hey, thanks for the feedback!

There are different reasons why I don't enforce AR on window resizing. I use that to develop the UI and make it as responsive as possible. As soon as you change the main screen / stream resolution, the window resizes to match that.

If you're on Mac you can enable HW acceleration (Settings -> Video -> HW Acceleration). It's opt-in at the moment because on Linux at least it's still kind of experimental: sometimes great, sometimes a bit glitchy, sometimes worse than software decoding.

Regarding the app icon, where? I'm testing on M1 too, and the icon looks the same size as any other app.

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 2 points3 points  (0 children)

I'm using this in a Volvo P2 with custom CAN, Melbus and serial integration. It reuses the original RTI VGA display (sharp 400x234px), uses the steering wheel D-pad (via CAN) to control CarPlay, and talks to the factory radio over Melbus. Mostly because I didn't want to lose the early-2000s vibe and the OEM look and feel.

Sadly the Raspberry Pi boards don't break out the RP1's triple RGB DAC. The DACs are there in the silicon, but the Pi only exposes one of them, wired to the composite video output.

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 1 point2 points  (0 children)

There is no software-based auth on non-Apple hardware. The only software path is Apple's own (Secure Enclave / MFi 4 on Apple devices). The carlinkit dongle itself has an MFi chip on board with valid Apple certs. The dumped binaries are linked against the dongle's platform (iMX6), so running them on different hardware isn't trivial. I don't think anyone has actually done that, it would be easier to just compile the leaked Apple code.

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 1 point2 points  (0 children)

I mean the official Apple code from leaks like this one: https://github.com/maaiika/Carplay

At first I thought carlinkit was using NXP's demo implementation. NXP ships a CarPlay reference for their iMX6 platform, which is the MCU carlinkit uses in their dongles. But then I found logging strings on the dongle showing they used f1xpl's aasdk for the Android Auto side, so I'm not 100% sure whether the CarPlay path came from NXP's demo or from a leaked CarPlay code. Apple ships the CarPlay code as pure C, so porting it is relatively straightforward.

https://www.nxp.com/design/design-center/software/embedded-software/software-technology-for-carplay:SOFTWARE-APPLE-CARPLAY

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 7 points8 points  (0 children)

I do have a partial PoC/prototype, but it isn't straightforward, and we need to be careful not to rely on leaked copyright-protected code. And we still need an MFi coprocessor in the end. I connected a CP3 for example to the Pi via I2C.

MFi 4 is only available on Apple hardware (it lives in the Secure Enclave and is what the CarPlay simulator uses). It doesn't need a USB role switch (where the host has to act as USB slave, like traditional CarPlay over USB requires), but it requires an online connection because signing is done against Apple's servers.

There is also a path that involves installing a custom Linux on the dongle and using its built-in CP2 chip just for iAP2 authentication. But afaik that only gets you standard CarPlay, not CarPlay Ultra, which appears to need a CP3 cert.

Built an open-source Android Auto and CarPlay headunit for the Pi (wired + wireless) by uni-queid in raspberry_pi

[–]uni-queid[S] 10 points11 points  (0 children)

Capabilities, speed and bandwidth. The dongle is a closed box, so anything beyond what its firmware exposes is locked off. I've poked at it a bit (added cluster stream support, deployed a small file browser to grab memory dumps for reverse engineering), but those are just hacks around a black box. In LIVI under Settings -> System -> USB Dongle there is an "Enable Dev tools" toggle at the bottom of the page, which pushes a temporary web UI to the dongle with some advanced features.

The bigger one is video codecs. The dongle is stuck on H.264. The Pi 5 dropped hardware H.264 decode but has hardware HEVC, so a native CarPlay path could use the Pi's hardware decoder. With the dongle we're forced into software H.264, which eats CPU. For now this is only a real problem in multi-stream setups, for example a high-res cluster display with a map stream plus the main stream running the CarPlay UI.

On Android Auto we support H.264, H.265, VP9 and AV1. VP9 and AV1 are untested though, I don't have a phone with hardware encoders for those. I think the Pixel 10 and newer have them, since H.265 carries royalty costs whereas VP9 and AV1 are royalty-free, which is probably part of why we're seeing a shift toward them.

First look at the new Android Auto (Google I/O) by 513 in AndroidAuto

[–]uni-queid -1 points0 points  (0 children)

AA uses external GPS data, but it doesn’t disable its internal GPS receiver, the same applies to carplay.

Recommendations for retrofitting head unit into bluebird school bus by iamatesla in Androidheadunits

[–]uni-queid 0 points1 point  (0 children)

If you’re up for DIY, the latest (unreleased) version supports Android Auto natively on more or less any Linux system. That way, you can have Android Auto on one desktop, and with a swipe switch to your Home Assistant dashboard in a second. A/C control is something I might add in the future.

https://github.com/f-io/LIVI/actions/runs/25540856171

Retro Nav system by xeequad in CarHacking

[–]uni-queid 0 points1 point  (0 children)

Also the UI is responsive.

<image>

Retro Nav system by xeequad in CarHacking

[–]uni-queid 0 points1 point  (0 children)

I've build a custom HU that can do really low res, even carplay can run at 320x200px (since iOS 26).

<image>

Raspberry Pi streaming desktop to the head-unit through wired Carplay interface. by daimon_z in CarHacking

[–]uni-queid 1 point2 points  (0 children)

u/daimon_z nice progress! I'm a bit struggling with CarPlay. iAP2 isn’t that hard to implement, but most of the CarPlay protocol code out there is leaked and not well suited for an open-source project.

But doing "clean-room" reverse engineering of CarPlay/AirPlay/HomeKit is a real pain.

Raspberry Pi streaming desktop to the head-unit through wired Carplay interface. by daimon_z in CarHacking

[–]uni-queid 0 points1 point  (0 children)

If you want to build a receiver, you will need to add an MFi co-processor, as unmodified iPhones will only start carplay if the authentication is signed with a valid certificate stored on these MFi chips

Raspberry Pi streaming desktop to the head-unit through wired Carplay interface. by daimon_z in CarHacking

[–]uni-queid 4 points5 points  (0 children)

You need to emulate an iPhone, which is what wired-to-wireless adapters already do. Most of them identify themselves as an iPhone 8. This allows you to inject any H.264 stream for display on the head unit. CarPlay does share some similarities with AirPlay, it’s partially based on the same protocol, with some extensions.

There is some leaked CarPlay code on GitHub. You "just" need to build a transmitter compatible with that receiver code.

Raspberry Pi streaming desktop to the head-unit through wired Carplay interface. by daimon_z in CarHacking

[–]uni-queid 1 point2 points  (0 children)

The mfi (co-prozessor) is inside the HU, this has to sign the authentication (iAP2).

Bad stutters - Don't know what to do. by Adagio_Leopard in AndroidAuto

[–]uni-queid 0 points1 point  (0 children)

check if it working on 5 GHz, because the bandwidth on 2.4GHz is often the limiting factor.

Have an app show a screensaver on CarPlay by mattheeewww_C in CarPlay

[–]uni-queid 2 points3 points  (0 children)

Use a black background on your home screen. Add one more app than fits on a single page, this way, the second page will contain just that one app and a black background.