Compatibility

Compatibility

Back to the README.

Tested on exactly one build:

Property	Value
Train	MHI2_ER_AU37x_P5089
MU	MU1326
Part number	8V1035036A
Car	Audi A3 8V Sportback e-tron (2017), Virtual Cockpit (KI_FPK_AU37X)
iAP2 stack	HARMAN (mm-ipod + libiap2client.so.1), Media 1.0.61.9

Reported working by users (not tested here):

Train	MU	Car	Where
MHI2_ER_AU37x_P5089	MU1326	Audi S3 8V	#12
MHI2_US_AU37x_K5512	MU1484	US model	#5
MHI2_US_AU37x_P5107	MU1363	Audi S3 8V (2017)	#21
MHI2_ER_AU37x_P5153	MU1326	Audi A3 8V facelift (2019)	#23
MHI2_CN_AU37x_P0916		Audi S3 8V sedan MY18	#7
MHI2_CN_AU37x_P0817		Audi S3 8V	#13
MHI2_ER_AU37x_P3620	MU0875	Audi S3 8V (2017)	#64
MHI2_ER_AU37x_P4203	MU1168	Audi S3 8V (2018)	#72
MHI2_ER_AU276_P5088	MU1325	Audi Q2 81A	#66
MHI2_ER_AU276_P4206	MU1171	Audi Q2	#66

Not supported: European builds up to MHI2_ER_AU37x_P3242 (MU0679). Their HMI is older than the classes replaced here: on P3242 the D-pad and route guidance do not compile (#70), and installers newer than v1.1.10 refuse every ER build up to it. P3620 works; builds between the two have not been checked. Build numbers are counted per region, so this does not apply to CN or US builds. Update the firmware first.

The installer only accepts MHI2_*_AU37x_* and MHI2_*_AU276_* (Audi Q2). The Q2 runs the same versions of the stock classes replaced here. The installer reads the train the way M.I.B. does (CachedTrain.txt on the RCC, otherwise the EEPROM) and on any other train it stops before changing anything. Other trains carry other versions of the stock classes replaced here: on MHI2_US_AUG22_K3347 (Q7 4M) the D-pad and route guidance do not even compile against the HMI (#17). If it cannot read the train at all, it stops too; open an issue with the log.

Another HMI mod on the unit. Remove it before installing this one. Other CarPlay or cluster mods replace the same stock classes; whichever jar the HMI loads first wins, and a mix of two versions of one class can keep the HMI from starting — a black main screen, with the M.I.B. menu gone with it. Since v1.0.0 the installer looks before it writes anything and stops on:

• MIBSI (its directories, its jars, or lsd.sh changed to put other code on the HMI classpath);
• mib2q-carplay-rgi and its forks (carplay_hook.jar, /mnt/app/root/hooks/);
• a script in place of mm-ipod that is not this project's;
• another mod's LD_PRELOAD inside dio_manager. v1.0.0 stops on this too, but only after it has copied the jars; the next release checks before it writes anything;
• jars in /mnt/app/eso/hmi/lsd/jars/ that it does not recognise. If you know they are harmless, install with IGNORE_CONFLICTS=1, or put an empty IGNORE_CONFLICTS file in mod/carplay/ on the card.

The check is the same whichever parts you install. Turning off route guidance or the cluster map does not let this project sit next to another CarPlay mod, because every part, including the ones that are always installed, replaces a class the other mods replace too:

Part of this project	Stock classes also replaced by mib2q-carplay-rgi, yuedizhibo's CarPlay AltScreen, MMI-Mirror and MIBSI
Touchpad as D-pad (always installed)	CarplayDSILifecycleController
Cover art (always installed)	AppConnectorTerminalMode, TerminalModeBapCombi
Route guidance (RGI)	ClusterService, and in all but MMI-Mirror's RGI build also DisplayManagerMIB2High

MIBSI also replaces dio_manager itself, which is where the cover art hook loads.

M.I.B.'s NavActiveIgnore jar is not a reason to stop, but it can't stay either: it makes every CarPlay app state read 0, so the HMI loses track of what CarPlay owns. The installer renames it to NavActiveIgnore.jar.carplay-off, and uninstalling renames it back. Turning NavActiveIgnore on again in M.I.B. brings the problem back.

Other MHI2_ER_AU37x_* builds are expected to work but are not verified, and the failure mode is worth understanding before you try:

• The jars do not add code alongside the stock HMI, they replace stock classes outright: AppConnectorTerminalMode, TerminalModeBapCombi$EventListener, CarplayDSILifecycleController$TerminalModeDSIKeyEventsController, and for route guidance DisplayManagerMIB2High, ClusterService and DSIKeyPanelDispatcher. Each carries a copy of that class from the build above. If your build's version differs, the replacement can fail when the class loads — and since one of them is constructed during HMI audio-module init, that can mean the HMI does not come up, not just a dead feature.
• The native hook resolves iap2_nowplay_getartwork / iap2_filexfer_read out of libiap2client.so.1 by name. A different driver version fails softly: a line in the log, no cover art, nothing broken.

Two checks on the unit before installing — with an iPhone plugged in:

pidin ar | grep mm-ipod          # HARMAN iAP2 stack running?
ls /ramdisk/pps/iap2/            # device, location, nowplaying, telephony

mm-ipod is started when a device is connected, and /ramdisk/pps/iap2/ only exists while it runs. With nothing plugged in, the first prints only your own grep and the second says No such file or directory — that is normal and tells you nothing.

If there is no mm-ipod and dio_manager contains NmeIAP2Message symbols, you are on the Cinemo/Qualcomm stack (MHI2Q) — these binaries are not for you; see mib2q-carplay-rgi.

Cover art additionally needs the cluster coded for it. In module 17 (instrument cluster), adaptation Picture_Upload_Download must be active. With it inactive the cluster never asks for a picture and nothing on the head-unit side can help. The D-pad patch needs no coding.

Lowest-risk option: the D-pad patch is self-contained. Copy only bin/dpad_hook.jar into /mnt/app/eso/hmi/lsd/jars/ — no native hook, no config edit, uninstall is deleting the file.

Route guidance

Route guidance needs no cluster coding, but it does have requirements of its own:

• The HARMAN iAP2 stack, i.e. an mm-ipod binary at /mnt/app/armle/usr/sbin/mm-ipod. The installer puts a small shim in front of it and keeps the original beside it as mm-ipod.orig. Units without that binary are not supported by this half of the patch set.
• About 1.5 MB free on /mnt/app for the renderer, its texture atlas and its compiled shaders. Releases before 2026-10-01 needed about 90 MB for a catalogue of pre-drawn pictures; the renderer replaced it, and the installer deletes that catalogue when it finds one.
• No GL shader compiler is required, which is just as well: this firmware ships none. The renderer's shaders are shipped already compiled, in the driver's own binary format, and it loads them through glShaderBinary. The consequence for you is only that the renderer and the files in bin/shaders/ belong together — mixing versions leaves the cluster tile empty.
• A cluster with the maneuver tile — the Virtual Cockpit's own turn-by-turn tile, the one the built-in navigation uses. That is what the patch draws into.

Which navigation apps

The patch draws what the phone publishes over CarPlay, nothing more:

App	Maneuvers in the cluster
Apple Maps	yes
Google Maps	yes
Waze	no — it publishes no route-guidance data over CarPlay

There is nothing on the head-unit side that can make Waze work: the data never leaves the phone. If a Waze release starts sending it, the maneuvers appear with no change here.

Google Maps is coarser than Apple Maps about what it sends. It publishes a sliding window of the next two maneuvers rather than a full list, its distances come in steps (500, 300, 200 m, then tens close in), and while the car is standing still it may stop publishing altogether. The patch is built around that: the last maneuver stays on screen rather than blanking when the phone goes quiet.

Lane guidance rides along with the maneuver when the phone publishes it, as a strip of arrows across the bottom of the tile: the lanes you may take highlighted, the rest dimmed, up to eight with an overflow marker past that. Both apps publish it on motorway junctions. It has been exercised against recorded and synthetic route data rather than confirmed on a live route, so treat it as the newest part of this.

CarPlay map in the cluster

The phone's own navigation map in the Virtual Cockpit, in place of the stock one. It rides on route guidance — the same jar declares its cluster context and the same supervisor starts its renderer — so everything above applies, plus:

• An iPhone by cable, or an adapter that asks for the second screen. The phone sends the cluster its map only when the head unit offers it a second screen, and the head unit offers it only to a peer that asks. An iPhone by cable always asks; wireless CarPlay adapters differ:

  Adapter	Cluster map	Where
  CarlinKit Mini Ultra 3	yes	#21
  Carlinkit CPC200-2Air (software 2025.12.29)	no: it does not ask, although it passes the offer on when made	#25
  2-in-1 Mini Wireless CarPlay (Amazon B0G1MN6NXB)	yes, after switching the adapter's audio mode to 3 in its own settings (192.168.8.1); before that CarPlay worked but the cluster map did not	#32
  Carlinkit 3 Ultra Mini	yes, with WIRELESS_MAP: comes up when navigation starts, Sport layout correct	#38
  Buddi U2AC / AutoKit (2025.12.29.1746)	partly, with WIRELESS_MAP: needed a long press of the left roller, Sport layout cropped, drops out	#38
  Junyong M2	yes, after the adapter's own firmware update from its maker; before that no cluster map	#13

  Behind an adapter that does not ask, the cluster keeps its stock map; route guidance still works.

• The head unit's hardware video decoder, libnvss_video.so, the one stock CarPlay uses for the main screen. Check before installing:

  ls /mnt/app/armle/lib/libnvss_video.so

  Without it the map does not come up and the cluster stays stock; nothing else is affected.

• The Virtual Cockpit at 1440×540. The map is sized for it, with the cluster's large, Sport and Classic views each given the area the phone should keep its car and its card in.

Which apps: whichever the phone shows — Apple Maps, Google Maps and Waze all draw their map there. The map style is the phone's choice: switching the phone's map to satellite does not carry over to the cluster, and there is no way to ask for it.