mib2q-carplay-rgi

MHI2Q CarPlay Route Guidance

CarPlay patch set for Audi MHI2Q infotainment. (Based on MHI2Q firmware, but may need rebuild for different versions.)

Disclaimer: Use at your own risk. These patches modify firmware binaries and system configurations on your infotainment unit. Always back up all original files before making any changes. The authors are not responsible for any damage, bricked devices, or warranty issues resulting from use of these patches.

Gallery

Contents

• Gallery
• Features
  • Route Guidance
    • Pipeline overview
    • HUD (BAP)
    • VC text overlays
    • VC MOST video (custom renderer)
    • Bargraph synchronization
  • Cover art
  • Touchpad input for CarPlay
  • Planned
  • Not possible - AltScreen
• Architecture
  • Patch components
  • Component map
  • Boot / init sequence
  • Threading model
  • File system layout
• Why AltScreen is impossible (deep dive)
  • Call-by-call handshake - MHI3 (works) vs MHI2Q (broken)
  • Component versions side-by-side
• Build
  • Prerequisites
  • libcarplay_hook.so (C hook)
  • maneuver_render (3D renderer)
  • carplay_hook.jar (Java patch)
  • Testing the renderer locally
• Deploy
  • Quick checklist
  • Step-by-step
• Contributing
• References

Features

What this patch makes the head unit + cluster do that stock MHI2 doesn’t:

• Full HUD route guidance from CarPlay nav (Maps, Waze, etc.) - maneuver icons, lanes, distance bargraph, ETA, destination
• Custom 3D maneuver overlay drawn into the cluster’s MOST video stream (the same video plane the HU uses for its native map)
• Album cover art forwarded to the cluster’s now-playing widget
• MMI touchpad -> DPAD bridging so finger drags navigate CarPlay menus

What it does not do, with explanations:

• CarPlay AltScreen on cluster - architecturally blocked on this HU generation, see deep dive below

Route Guidance

Pipeline overview

iOS RGD messages enter through the iAP2 hook and fan out into two independent rendering branches on the VC:

• HUD branch (BAP LSG 50) - feeds the text/icon HUD widgets the cluster firmware already knows how to draw. Cheap, always-on.
• Render branch (custom MOST-video renderer) - draws full 3D maneuver scenes into the cluster’s video pipeline. Spawned only while a route is active.

Both branches receive the same parsed state from BAPBridge and update in lock-step.

The renderer is spawned by BAPBridge when Java activates a CarPlay route-guidance session and stopped when that route guidance deactivates or the CarPlay session shuts down, so the MOST-video branch costs nothing when the user isn’t actively navigating.

HUD (BAP)

All data sent via BAP protocol (LSG 50) to the VC, which drives the HUD.

• Maneuver icons - iAP2 turn type mapped to BAP ManeuverDescriptor (FctID 23). Supports turns, roundabouts, highway exits, merges, U-turns, ferry, etc.
• Multi-maneuver list - up to 3 upcoming maneuvers sent in a single descriptor
• Side streets at intersection - computed from iAP2 junction type + turn angle
• Junction view - roundabout, highway interchange exit numbers
• Left-hand / right-hand driving - auto-detected from iAP2 driving_side, affects icon mirroring and side-street layout
• Distance to next maneuver - numeric display when far (FctID 18)
• Distance bargraph - fills up on approach, with call-for-action blink at maneuver point (FctID 18)
• Auto distance units - reads current HU setting (metric/imperial), no manual switch needed
• Lane guidance - lane arrows with active-lane highlighting (FctID 24)

VC text overlays

Sent via the same BAP path. VC renders these as text bars over the native map area.

• Turn-to street / exit name (FctID 23, part of ManeuverDescriptor)
• Current road name (FctID 19)
• Distance to destination (FctID 21)
• ETA / remaining travel time - timezone-adjusted to HU local time (FctID 22)
• Destination name (FctID 46)

VC MOST video (custom renderer)

Custom 3D renderer (c_render/) draws maneuver icons into the cluster’s MOST video pipeline (MOST150 isochronous channel - the same path the HU uses to ship its native map render to the VC’s Map tab). Renders to QNX displayable 20 (DISPLAYABLE_MAP_ROUTE_GUIDANCE, the native KOMO RG widget slot in cluster context 74) via EGL/GLES2; the frames are captured by the HU video encoder (H.264) and shipped over MOST to the VC, where the cluster’s TVMRCapture pipeline decodes them into a texture composited by the Kanzi scene.

Displayable 20 is the native KOMO RG widget’s slot — we take it over. Verified by RE of libdisplayinit.so, libdm_modMain.so (displaymanager service), libRenderSystem.so, and stock libPresentationController.so (which runs in AppStartATF):

• With stock libPresentationController, the native KOMO widget only calls display_create_window(20) when its GuidanceView state machine enters StartDrawing — which requires an active native route. In idle (CarPlay session, no native route) the native side holds no window for displayable 20, so m_surfaceSources[20] is empty before we start.
• display_create_window(displayable_id=20) creates a screen window in our process with SCREEN_PROPERTY_ID_STRING="20". Display manager’s screen_manage_window callback binds m_surfaceSources[20] to our window — there is no race because nothing else holds the slot.
• display_create_window also strips other displayables from context 74 as a side effect, so we follow up with dmdt dc 74 20 102 101 33 to re-declare the original composition (our 20 + cluster’s 102/101 + native map 33).
• setActiveDisplayable(4, 20) (called by stock cluster firmware in preContextSwitchHook for the leading displayable in context 74) wires the MOST encoder to read displayable 20 — which is now our window.
• On renderer exit screen_destroy_window vacates m_surfaceSources[20]. The slot stays empty until native nav activates a route — same as the cluster baseline before we started. restore_display() runs dmdt sc 1 74 to keep the context layout consistent.

Edge case: if the user manually launches native maps mid-CarPlay, libPresentationController would create its own ID=“20” window and displaymanager would last-writer-wins over us. The 5 s reclaim watchdog (platform_reclaim_displayable) re-binds the slot back to us within seconds via screen_manage_window.

A 30 s focus watchdog runs dmdt gs to detect if native navigation or another HMI process stole the cluster context, and re-routes via dmdt sc 1 74 (with a 30 s back-off so a stuck context doesn’t fork-bomb the system).

Renderer startup handshake (added to the TCP protocol so Java doesn’t expose the MOST video path before a deterministic frame is queued):

1. Renderer connects to Java’s listen socket on :19800.
2. After EGL + render init, sends EVT_READY (0x81).
3. Java’s BAPBridge blocks in waitForReady(2500ms) after launching the renderer; unblocks on EVT_READY.
4. Java sends a deterministic first frame (sendRendererFollowStreet).
5. Renderer swaps the frame and sends EVT_FRAME_READY (0x82).
6. Java’s waitForFrameReady(1200ms) unblocks; only now does it call csRef.activateCustomRendererPipeline() (cluster context switch) and forceGfxAvailable(true) (KOMO publishes the MOST video stream).
7. If activateCustomRendererPipeline returns FAILED: (cluster stuck on another context after retry), the renderer is killed and gfx stays disabled - no MOST video is published in a broken state.

EVT_READY and EVT_FRAME_READY are sticky: on TCP reconnect they replay immediately so a Java-side restart still gets the right state without a second renderer launch.

Note on naming. Earlier drafts of this README called this branch “LVDS video”. That was wrong for MHI2Q - LVDS exists on the platform (DISPLAYSTATUS_LVDS_DM_ACTIVE / LVDS_HMI_ACTIVE bits in DSIKombiSync) but is reserved for full-screen mirror modes (startup logo, standby). The HU->VC video for the Map tab on this generation rides MOST150, not LVDS.

• Procedural 3D maneuver icons (turns, roundabouts, U-turns, merges, lane changes, arrival)
• Side streets at junctions from iAP2 junction angles
• Animated route path with curvature-aware speed
• Smooth push transitions between consecutive maneuvers (crossfade + path chaining)
• Camera follow/settle during transitions
• Arrow-to-bulb tip morphing for arrival
• Animated destination flag sprite
• Distance bargraph overlay with blink mode
• Perspective/orthographic view with animated blend
• FXAA + 2x SSAA anti-aliasing
• Painter’s algorithm road rendering (white outline + grey fill + blue active route)
• TCP command protocol (port 19800) - Java bridge sends maneuver updates, renderer handles all animation autonomously

Bargraph synchronization

Both branches above (HUD FctID 18 bargraph and the renderer’s on-screen bargraph overlay) need continuous fill + attention-grabbing blink near the maneuver, but iOS sends 0x5202 ManeuverUpdate at sparse intervals (~1-3 s, faster on approach). BAPBridge smooths that gap with a small state machine + a dedicated blink timer thread.

Phases:

Key parameters (in BAPBridge.java):

Linear fill formula: linBargraph% = distM * 100 / prepareThreshold clamped to [0, 100]. Highway maneuvers use the wider 3000 m denominator so the bar fills more gradually on a long approach.

Blink loop runs on a dedicated BAPActionBlink daemon thread (spawned only while a route is active). Every 600 ms it toggles the bargraph between 100% and 0% and re-sends FctID 18 (HUD) plus a CMD_MANEUVER tick to the renderer (overlay). This is independent of iAP2 update cadence - even if iOS goes silent for 2 seconds, both HUD and renderer still see the blink animation in lock-step.

FSG-sync workaround. AppConnectorNavi.sendStatusIfChanged() silently drops updates when nothing in {FctID 23, 18, 49} changed. On every ManeuverDescriptor send we toggle the cosmetic exitViewNum variant on FctID 49 to force a transmission - without that toggle the cluster occasionally misses bargraph ticks during fast approach.

Cover art

Stock MHI2 CarPlay (TerminalMode) forwards track title, artist, and album to the VC, but the stock AppConnectorTerminalMode never pushes cover art to the BAP picture manager. The VC always shows a blank/default album icon.

The C hook intercepts iAP2 transport packets (read()/recv() hooks), reassembles JPEG cover art from chunked transfers, hands the complete JPEG to a dedicated async worker thread (single-slot pending queue, latest-wins coalescing) which decodes and resizes to 256x256 PNG using stb_image and writes to /var/app/icab/tmp/37/coverart.png (tmpfs - regenerated each session, lost on reboot, which is fine since the decode pipeline restarts with every CarPlay handshake). The async hand-off keeps the recv()/read() hook thread free, avoiding ~50-100 ms of synchronous decode latency per cover art that previously stalled concurrent iAP2 traffic during handshake. A TCP bus event (EVT_COVERART, port 19810) signals Java. The Java CoverArt module subscribes to the bus, and TerminalModeBapCombi$EventListener pushes the image through AppConnectorTerminalMode to the BAP picture manager with proper ResourceLocator and responseCoverArt() calls, mirroring the native AppConnectorMedia pattern. Late-arriving cover art (after track info was already sent) triggers a re-send with a modified picture ID to force the VC to refresh.

• Cover art forwarding to VC

Touchpad input for CarPlay

Stock MHI2 forwards the rotary, knob press, back and softkey buttons to CarPlay natively - those work out of the box. The MMI touchpad is the only input device that stock leaves unbridged: finger gestures on the touchpad never reach the CarPlay session.

This patch adds the missing leg of the chain:

The orange box is what this patch adds. Rotary, knob press and softkeys already reach CarPlay through stock DSI (dotted path) - only the touchpad needed bridging.

Touchpad model. A finger drag accumulates Δx / Δy; whenever either axis crosses a speed-adaptive threshold, a KEY_DPAD_* press+release pair is emitted and the threshold is subtracted. A long drag emits multiple ticks so the user can traverse several list items in one gesture.

(The class is named CursorController for legacy reasons - it once drove an on-screen cursor that was abandoned because MHI2Q’s H.264 encoder ghosted the overlay through motion compensation. See docs/ notes if curious.)

• MMI touchpad drag -> DPAD navigation
• Knob rotary, knob press, back / softkey buttons - already work via stock DSI, no patch needed

Planned

• Lane guidance on maneuver renderer (CMD_LANE_GUIDANCE protocol, arrow glyphs with status colors + dashed separators, see docs/plan_lane_guidance_renderer.md)

Not possible - AltScreen

CarPlay second screen on the instrument cluster cannot be enabled on MHI2Q - and no wireless dongle fixes it. The blocker is on the HU side (Cinemo iAP2 SDK + libairplay 210.81), not on the phone or USB transport. Full reverse-engineering write-up + diagrams in Why AltScreen is impossible below.

Architecture

Patch components

Component map

The diagram shows a single CarPlay session at steady state. Cinemo SDK is implicit - every iAP2 byte from iPhone first passes through our read() / recv() hooks, then continues into the stock SDK code underneath. We don’t bypass the stock path; we intercept and (for RGD / Identify / cover art) inject side effects.

Boot / init sequence

Important: dio_manager is not spawned at boot. It is launched on demand by the always-running smartphone_integrator process when a phone is detected on USB. That’s why our libcarplay_hook.so constructor (LD_PRELOAD) only fires when the phone is plugged in, not at QNX boot. The HMI process (lsd.jxe) does start at boot, so carplay_hook.jar class-replacements load early - the Java bus server accept()s as soon as the C hook connects.

Topology (lifetime hierarchy):

• Java HMI (long-lived, alive from boot) = TCP server on :19810 for the bus, opens :19800 for the renderer at session start.
• C hook (short-lived, per phone connect) = TCP client, connects to Java’s :19810. Idempotent reconnect on Java HMI restart.
• Renderer (short-lived, per route) = TCP client, connects to Java’s :19800. Idempotent reconnect on Java side restart.

Liveness detection:

• Bus (C hook → Java): no application-level heartbeat. Java relies on TCP FIN/RST + setKeepAlive(true) to learn the hook is gone, and the C hook’s connector_main reconnects on any send/disconnect error. A zombie TCP session (no FIN/RST) would linger until OS keepalive fires; in practice the bus is short-lived (per phone connect) and torn down cleanly when dio_manager exits.
• Renderer (maneuver_render → Java): sends EVT_HEARTBEAT (cmd=0x80) every 1 s; RendererServer accepted socket has SO_TIMEOUT=5000 ms. Hung renderer detected within 5 s, then 3 consecutive send failures (~1.8 s) trigger slay -f -Q + respawn.

Threading model

File system layout

Why AltScreen is impossible (deep dive)

Branch closed 2026-04-23 after full static reverse of iOS 26.1, MHI3 and MHI2Q. AltScreen (CarPlay second screen on the instrument cluster) cannot be enabled on MHI2Q wired CarPlay - and no wireless dongle fixes this, because every gate that breaks the negotiation is on the head-unit side, not on the phone or USB transport.

What the head unit needs to advertise

For iOS to enable AltScreen, the head unit’s iAP2 + AirPlay stack must declare two capabilities to the iPhone:

1. Themed-assets capability - a flag in the head unit’s iAP2 “introduction card” (the Identification message) saying “I can render Apple’s themed CarPlay UI elements on a second display.” In the wire format this is Param 21, sub-parameter 17. iOS reads it via _parseIdentificationParams_3() and on YES sets internal capability bit 21 in _eaAccessoryCapabilities, which CarKit later checks via setSupportsThemeAssets:YES to expose altScreen in its proposed feature array.

2. Two-screen layout - the head unit’s libairplay must answer the AirPlay /info query with a dict that contains two screens (main + alt), each with its own view areas. The library API for this is MainScreenDictCreate + AltScreenDictCreate + ScreenDictSetViewAreas, plus advertising AirPlay stream type 111 and feature bit 26 (0x04000000) so iOS opens an AltScreen video stream.

MHI2Q fails both:

A wireless adapter (Carlinkit / U2W / etc.) emulates a wired carplay accessory on the iPhone end of the link - it speaks the same iAP2 to the same dio_manager on MHI2Q, hits the same Cinemo SDK, gets stuck at the same first failure. The dongle cannot rewrite the HU’s iAP2 SDK or libairplay version. No dongle, present or future, will unlock AltScreen on this generation of HU.

Quick glossary of terms below

Call-by-call handshake - MHI3 (works) vs MHI2Q (broken)

Single sequence diagram showing the actual function calls and message exchanges during AltScreen negotiation. Both head-unit variants share the same iOS code path; the differences are in two specific HU components (Cinemo iAP2 SDK and libairplay).

Color coding inside the diagram:

• Green rect = MHI3-grade (modern SDK + libairplay 450.x) - passes
• Red rect = MHI2Q (Cinemo pre-2020 + libairplay 210.81) - fails
• No tint = shared protocol layer that runs identically on both

Static-analysis sources (offsets/strings cross-referenced):

• MHI3 — MHI3_ER_AU_P4364_8W0906961DR/libesoiap2.so (629 KB ARM64) + _swup_carplay_aa/extracted_elf_opt/libairplay.so (450.14.2)
• MHI2Q — dio_manager.i64 + libNmeSDK.so + MHI2Q appimg libairplay.so (210.81)
• iOS 26.1 — CoreAccessories.framework, CarKit.framework, AirPlayReceiver.framework, AirPlaySender.framework, carkitd

Full file/function map: docs/altscreen_gate_analysis.md.

The diagram makes the two independent failure points visually explicit:

1. Phase 1 fails on MHI2Q because Cinemo’s pre-2020 iAP2 SDK doesn’t emit Param 21 / sub17, so iOS never marks the accessory as themed-assets-capable, and CarKit’s feature array never grows the "altScreen" string.
2. Phase 2 fails independently on MHI2Q because libairplay 210.81 has no MainScreenDictCreate / AltScreenDictCreate / ScreenDictSetViewAreas helpers; even if Phase 1 magically passed, the /info response still lacks the two-screen shape, feature bit 26, and stream type 111 that iOS requires.

A wireless dongle (Carlinkit / U2W) replaces only the iPhone-side iAP2 endpoint. The HU’s Cinemo SDK and libairplay 210.81 stay the same - both red phases still fail. No dongle, present or future, will turn the red rects green on this generation of HU.

Component versions side-by-side

Build

Prerequisites

• QNX SDP 6.5 - needed for cross-compiling C hook and renderer to ARM32 QNX. Easiest way is a QNX VM with the toolchain accessible over SSH. QNX VM image: https://archive.org/details/qnxsdp-65.7z (or any other QNX SDP 6.5 VM image available online). Set up SSH on the VM and configure the IP in the build scripts.

• GLFW 3 (macOS only) - needed for local renderer development/testing. Install via brew install glfw.

• lsd.jar - original HU classes, needed to compile the Java patch against. Extract from your firmware dump:

  1. Get /mnt/app/eso/hmi/lsd/lsd.jxe from your firmware
  2. Convert with jxe2jar (../jxe2jar)
  3. Output lands in jxe2jar/out/lsd.jar (default path used by build_java.sh)

libcarplay_hook.so (C hook)

Cross-compiles on the QNX VM via SSH. Set QNX_VM IP in compile_hook.sh.

./compile_hook.sh

Output: build/libcarplay_hook.so

Build flags:

# default (logging on)
./compile_hook.sh

# silent build
LOG=0 ./compile_hook.sh

# verbose packet logging
LOG=1 LOG_RGD_PACKET_RAW=1 ./compile_hook.sh

maneuver_render (3D renderer)

For QNX (deployment): Cross-compiles on the QNX VM via SSH. Set QNX_VM IP in compile_render_qnx.sh.

./compile_render_qnx.sh

Output: build/maneuver_render

To build with the debug grid overlay:

./compile_render_qnx.sh grid

For macOS (local development): Builds natively with GLFW + OpenGL 2.1. Requires brew install glfw.

make -C c_render

Output: build/c_render (renderer) + build/test_harness (test client)

The macOS build also compiles a test harness - see Testing the renderer locally below.

carplay_hook.jar (Java patch)

Requires lsd.jar (see Prerequisites). Check paths in build_java.sh.

./build_java.sh

Output: build/carplay_hook.jar

All classes are compiled with -source 1.2 -target 1.2 for MHI2Q JVM compatibility. The bundled JDK from jxe2jar is used automatically.

Testing the renderer locally

https://github.com/luka-dev/mib2q-carplay-rgi/raw/main/docs/test_manuver_render.mov

The macOS build includes a test harness (build/test_harness) that sends TCP commands to the renderer, letting you cycle through all maneuver types and verify animations without a real device.

Run both in parallel from the repo root. The harness is the TCP server; start it first, then start the renderer in another terminal:

./build/test_harness

./build/c_render

The renderer window opens and connects to the harness on 127.0.0.1:19800.

Harness controls:

The harness auto-cycles through a built-in preset list that covers all icon types with varying directions, exit angles, junction configurations, and bargraph levels. Each arrow key press sends a CMD_MANEUVER packet triggering a push transition.

Deploy

Quick checklist

1. ./compile_hook.sh - build libcarplay_hook.so
2. ./compile_render_qnx.sh - build maneuver_render
3. ./build_java.sh - build carplay_hook.jar
4. mkdir -p /mnt/app/root/hooks on device
5. Copy build/libcarplay_hook.so to /mnt/app/root/hooks/, chmod 755
6. Copy build/maneuver_render to /mnt/app/root/hooks/, chmod 755
7. Copy c_render/resources/flag_atlas.rgba to /mnt/app/root/hooks/
8. Copy build/carplay_hook.jar to /mnt/app/eso/hmi/lsd/jars/
9. Set LD_PRELOAD in smartphone_integrator.json
10. Add 0x5200/01/02/03/04 IDs in dio_manager.json
11. Reboot (wait 30s after file changes)

Step-by-step

Step 1: Create hooks directory

The hooks directory does not exist by default. Create it on the device:

mkdir -p /mnt/app/root/hooks
chmod 755 /mnt/app/root/hooks

Step 2: Deploy libcarplay_hook.so

cp build/libcarplay_hook.so /mnt/app/root/hooks/
chmod 755 /mnt/app/root/hooks/libcarplay_hook.so

Runtime log (resets on each reboot): /tmp/carplay_hook.log

Step 3: Patch smartphone_integrator.json

File: /mnt/system/etc/eso/production/smartphone_integrator.json

Add LD_PRELOAD under $.children.carplay.envs:

"carplay": {
  "exec": "dio_manager",
  "envs": [
    "LD_LIBRARY_PATH=/mnt/app/root/lib-target:/eso/lib:/mnt/app/usr/lib:/mnt/app/armle/lib:/mnt/app/armle/lib/dll:/mnt/app/armle/usr/lib",
    "IPL_CONFIG_DIR_DIO_MANAGER=/etc/eso/production",
    "LD_PRELOAD=/mnt/app/root/hooks/libcarplay_hook.so"
  ]
}

Step 4: Patch dio_manager.json

File: /mnt/system/etc/eso/production/dio_manager.json

Add these iAP2 message IDs to the Cinemo SDK’s Identify registration:

MessagesSentByAccessory - add:

• 0x5200 = StartRouteGuidanceUpdates
• 0x5203 = StopRouteGuidanceUpdates

MessagesReceivedFromDevice - add:

• 0x5201 = RouteGuidanceUpdate
• 0x5202 = RouteGuidanceManeuverUpdate
• 0x5204 = LaneGuidanceInformation

Why this AND the C hook patches the Identify message: Cinemo’s SDK has the message-ID list compiled into its MessagesSentByAccessory / MessagesReceivedFromDevice arrays - the JSON edit registers the RGD message IDs so the SDK actually pumps them. The C hook (rgd_identify_patcher in c_hook/routeguidance/rgd_hook.c) separately patches the EAGroupComponent declaration in the outgoing Identify message at runtime - adds component 0x001E so iOS recognises the accessory as a navigation component and starts sending RG payloads. Both are required: without the JSON edit iOS sends RG but the SDK drops it; without the hook patch iOS doesn’t even start sending. The runtime patch shows up in the log as Identify patched: 535 -> 621 bytes.

Example (before):

"MessagesSentByAccessory": [
  "0x5000", "0x5002", "0xAE00", "0xAE02", "0xAE03",
  "0x4154", "0x4156", "0x4157", "0x4159",
  "0xFFFB", "0x4C00", "0x4C02", "0x4C03", "0x4C05"
],
"MessagesReceivedFromDevice": [
  "0x4E09", "0x4E0A", "0x4E0C", "0x5001", "0xAE01",
  "0x4155", "0x4158", "0xFFFA", "0xFFFC", "0x4C01", "0x4C04"
]

After:

"MessagesSentByAccessory": [
  "0x5000", "0x5002", "0xAE00", "0xAE02", "0xAE03",
  "0x4154", "0x4156", "0x4157", "0x4159",
  "0xFFFB", "0x4C00", "0x4C02", "0x4C03", "0x4C05",
  "0x5200", "0x5203"
],
"MessagesReceivedFromDevice": [
  "0x4E09", "0x4E0A", "0x4E0C", "0x5001", "0xAE01",
  "0x4155", "0x4158", "0xFFFA", "0xFFFC", "0x4C01", "0x4C04",
  "0x5201", "0x5202", "0x5204"
]

Step 5: Deploy carplay_hook.jar

cp build/carplay_hook.jar /mnt/app/eso/hmi/lsd/jars/

Step 6: Deploy maneuver_render and flag atlas

cp build/maneuver_render /mnt/app/root/hooks/
cp c_render/resources/flag_atlas.rgba /mnt/app/root/hooks/
chmod 755 /mnt/app/root/hooks/maneuver_render

The flag atlas (flag_atlas.rgba, source path c_render/resources/flag_atlas.rgba) must end up reachable from the renderer’s working directory. The renderer searches in this order: resources/flag_atlas.rgba, flag_atlas.rgba, <binary_dir>/resources/flag_atlas.rgba, <binary_dir>/flag_atlas.rgba. Placing it next to the binary (as above) hits the second/fourth path.

Launched automatically by the Java bridge (BAPBridge) when CarPlay route guidance starts. Log: /tmp/maneuver_render.log.

Step 7: Reboot

Reboot the infotainment system. Give it 30+ seconds after file changes before rebooting - otherwise changes may not be flushed to disk.

Contributing

Maneuver icon testing. The iAP2-to-BAP maneuver mapping covers all 54 CarPlay maneuver types, but has only been tested on a limited set of real-world routes. Edge cases like complex interchanges and multi-lane roundabouts need more road testing. If you see a wrong or missing icon on the HUD, a log from /tmp/carplay_hook.log of the exact moment + explanation of what’s wrong would help. Note: the log resets on each device reboot, so grab it before restarting.

The hook automatically logs unrecognised iAP2 RGD-family messages as [HOOK] Unknown 0x52xx msgid=0xNNNN dir=IN len=N followed by a hex dump - these are the most useful starting point if iOS sends a maneuver type we don’t handle yet.

References

Thanks for the previous work and knowledge that helped to figure this out.

• https://github.com/ludwig-v/wireless-carplay-dongle-reverse-engineering
• https://github.com/EthanArbuckle/iPhone18-3_26.1_23B85_Restore
• https://github.com/adi961/mib2-android-auto-vc
• @fifthBro