# DiPlay 0.2.20 — 2026-10-15

Public preview for compatible BYD Android head units. Android 7.1+ (API 25) remains the minimum; Android 7.1–8.1 still needs vehicle testing. This update keeps music playing on head units whose audio clock drifts, plays calls that a head unit sent to an earpiece on the loudspeaker, starts wired CarPlay on more head units and after **Save and reconnect**, turns the car hotspot on by itself on more head units, puts the CarPlay map on more BYD dashboards, and records more of what happens in the diagnostic report.

## Highlights

- Music no longer pauses every minute or so on head units whose audio clock runs fast or slow: DiPlay adjusts the music's playback rate by up to 1.5 % to keep its buffer steady. DiPlay's audio threads run at Android's audio priority, so music crackles less while the head unit opens its 360° camera, and wireless and USB keep separate music buffers. [#788](https://github.com/shihabal3amri/DiPlay/pull/788), [#740](https://github.com/shihabal3amri/DiPlay/pull/740), [#746](https://github.com/shihabal3amri/DiPlay/pull/746)
- A CarPlay call that a head unit sends to its earpiece now plays on the loudspeaker, and **Settings → Audio → Calls on the loudspeaker** does the same on phones and tablets used as head units. App voice messages can use the microphone, one press of BYD's wheel voice key opens Siri once, and with **Car phone audio for CarPlay calls** on, the other person no longer hears a distorted voice. [#797](https://github.com/shihabal3amri/DiPlay/pull/797), [#704](https://github.com/shihabal3amri/DiPlay/pull/704), [#698](https://github.com/shihabal3amri/DiPlay/pull/698), [#774](https://github.com/shihabal3amri/DiPlay/pull/774), [#770](https://github.com/shihabal3amri/DiPlay/pull/770)
- Wired CarPlay starts on head units whose USB audio driver held the iPhone, comes back within seconds after **Save and reconnect**, no longer stops with `Invalid USBMUX frame length 0`, and starts on Android 17. [#699](https://github.com/shihabal3amri/DiPlay/pull/699), [#714](https://github.com/shihabal3amri/DiPlay/pull/714), [#744](https://github.com/shihabal3amri/DiPlay/pull/744), [#708](https://github.com/shihabal3amri/DiPlay/pull/708)
- **Automatically turn on the car hotspot** works on more head units: through the system shell where the firmware has no hotspot command over ADB, and without ADB on head units that aren't BYD on Android 8.0–10. **Connect** in the **Car hotspot is off** dialog now connects, and Wi-Fi Direct drivers can keep the car's Wi-Fi search on. [#699](https://github.com/shihabal3amri/DiPlay/pull/699), [#748](https://github.com/shihabal3amri/DiPlay/pull/748), [#775](https://github.com/shihabal3amri/DiPlay/pull/775), [#777](https://github.com/shihabal3amri/DiPlay/pull/777), [#789](https://github.com/shihabal3amri/DiPlay/pull/789), [#768](https://github.com/shihabal3amri/DiPlay/pull/768)
- **CarPlay map on dashboard (experimental)** finds the cluster on more BYD firmware (controllers 13 and 17, the Leopard 5 Ultra), and DiLink 3 no longer offers the DiLink 4 routes that kept its dashboard map off. HEVC falls back to H.264 without a hardware decoder, and the settings menu inside CarPlay is grouped by goal. [#714](https://github.com/shihabal3amri/DiPlay/pull/714), [#734](https://github.com/shihabal3amri/DiPlay/pull/734), [#710](https://github.com/shihabal3amri/DiPlay/pull/710)
- The diagnostic report records DiPlay's last crash, the wheel and media keys DiPlay received, each step of the car Bluetooth pause, music rebuffers, and the USB devices Android lists while DiPlay waits for a CH341 adapter. [#700](https://github.com/shihabal3amri/DiPlay/pull/700), [#702](https://github.com/shihabal3amri/DiPlay/pull/702), [#788](https://github.com/shihabal3amri/DiPlay/pull/788), [#740](https://github.com/shihabal3amri/DiPlay/pull/740), [#759](https://github.com/shihabal3amri/DiPlay/pull/759), [#793](https://github.com/shihabal3amri/DiPlay/pull/793)

## Connection setup and recovery

- Wired CarPlay can switch the iPhone to CarPlay mode on head units whose kernel binds its USB audio driver to the iPhone, such as the 8227L in [#518](https://github.com/shihabal3amri/DiPlay/issues/518). DiPlay detached the driver by claiming each interface, but Android's `releaseInterface()` asks the kernel to attach the driver again, so it was back before the switch (`usbfs: interface 0 claimed by snd-usb-audio while … sets config #6`). DiPlay now keeps those claims, then closes and reopens its connection to the iPhone, which drops the claims without reattaching the driver, and switches after that. The report still logs `USB configuration select target=6 ok=… detached=…`. Pending in-car acceptance. [#699](https://github.com/shihabal3amri/DiPlay/pull/699)
- **Automatically turn on the car hotspot** can start it on head units whose firmware offers no hotspot command over ADB. Android refuses DiPlay's own request there: `No field mService` on an Android 10 head unit and `NoSuchMethodException … startTethering` on an Android 12 DiLink 5.0 Song L, both in [#616](https://github.com/shihabal3amri/DiPlay/issues/616). With network ADB approved, DiPlay now asks the shell to start Wi‑Fi tethering with the car's saved hotspot, which Android allows: through the connectivity service on Android 7.0–10 and the tethering service on Android 11 and newer. The report logs `car hotspot: shell tethering request …`. Pending in-car acceptance. [#699](https://github.com/shihabal3amri/DiPlay/pull/699)
- **Settings → Connection** now has the authentication choice (**Local offline** or **USB/CH341**), so a driver who removed the CH341 adapter can switch back to Local without connecting first. That choice was only in the menu inside CarPlay, which cannot be reached when CarPlay cannot connect ([#696](https://github.com/shihabal3amri/DiPlay/issues/696)). CarPlay reads the choice again each time it starts. [#699](https://github.com/shihabal3amri/DiPlay/pull/699)
- Wired CarPlay comes back within seconds after **Save and reconnect**. DiPlay ended its session and started a new one at once, and the iPhone, still in CarPlay mode from the old session, accepted iAP2 and StartSession but opened no CarPlay connection until it reset USB 30–150 s later ([#335](https://github.com/shihabal3amri/DiPlay/issues/335)). When the iPhone is still in the mode of a session DiPlay started on the same USB connection, DiPlay now asks for CarPlay mode again first, as a fresh connection does. The report shows `previousSessionOnThisEnumeration=true action=request-transition`. Pending in-car acceptance. [#714](https://github.com/shihabal3amri/DiPlay/pull/714)
- With Wi-Fi Direct on **Auto**, a head unit whose Wi-Fi reports no 5 GHz band is no longer asked for a 5 GHz channel first. An i.MX8 head unit (Android 8.1) in [#582](https://github.com/shihabal3amri/DiPlay/issues/582) was asked for channel 36 on every attempt, and the request never answered. Auto now starts with the 2.4 GHz channels there, and the report logs `Wi-Fi P2P 5 GHz skipped`. On that head unit the channel call also never answered the reset, so Wi-Fi Direct may still not start there. [#740](https://github.com/shihabal3amri/DiPlay/pull/740)
- Wired CarPlay no longer stops with `Invalid USBMUX frame length 0` when the iPhone sends a VERSION reply right after the four extra bytes that end its previous reply. On an Android 10 tablet with iOS 27 this failed every wired attempt for about 25 minutes ([#100](https://github.com/shihabal3amri/DiPlay/issues/100)). DiPlay already skipped those four bytes before a TCP or diagnostic reply. It now also skips them before a VERSION reply whose header matches exactly. [#744](https://github.com/shihabal3amri/DiPlay/pull/744)
- Wired CarPlay starts on Android 17 head units that drop the iPhone's USB network connection without local network access, such as a Raspberry Pi 5 running emteria's Android 17. The iPhone's connection reached DiPlay over USB and was never answered. DiPlay now asks for local network access before a wired start, as it already did before a wireless one. A refusal is logged and the start goes on as before. Android 16 and older see no change. Pending a re-run on the Pi with this version. Contributed by @j1z4 ([#708](https://github.com/shihabal3amri/DiPlay/pull/708)).
- On a head unit whose Android Bluetooth gives apps no way to open connections, wireless CarPlay stops with the cause instead of retrying under "Your iPhone isn't available". On a Changan CS35 Plus (Allwinner T7, Android 9), every attempt failed 3 ms into the Bluetooth connect ([#709](https://github.com/shihabal3amri/DiPlay/issues/709)). The connecting screen now says that wireless CarPlay cannot work on this head unit and suggests USB. The report logs `Bluetooth socket manager missing`. Contributed by @Boring206 ([#725](https://github.com/shihabal3amri/DiPlay/pull/725)).
- Before the car hotspot details are saved, the home screen and **Connection setup** no longer print an empty hotspot name (`The car hotspot “” is off`, `Edit saved hotspot · `). They ask the driver to save the hotspot details instead. Contributed by @Boring206 ([#726](https://github.com/shihabal3amri/DiPlay/pull/726)).
- **Connection setup → Wi-Fi Direct** has a switch for pausing the car's Wi-Fi search during CarPlay. It's on by default. The pause stops the stutter every 10 s, but it also stops the car joining a known network, such as the phone's hotspot, by itself while CarPlay runs. Since 0.2.17 a Leopard 5 owner whose car uses the phone's hotspot for data had to join it by hand ([#755](https://github.com/shihabal3amri/DiPlay/issues/755)). With the switch off, the report logs `Wi-Fi scan pause off in Settings`. [#768](https://github.com/shihabal3amri/DiPlay/pull/768)
- On a head unit where Android has no Bluetooth for apps, **Choose iPhone** says that wireless CarPlay can't work there and suggests USB, instead of sending the driver to a Bluetooth switch that does nothing. A connection attempt stops with that cause instead of retrying under "Connection interrupted". If Bluetooth is only off and still off after **Open Bluetooth**, the dialog adds that some head units keep Bluetooth for their own calls and music ([#703](https://github.com/shihabal3amri/DiPlay/issues/703), [#581](https://github.com/shihabal3amri/DiPlay/issues/581)). Contributed by @Boring206 ([#745](https://github.com/shihabal3amri/DiPlay/pull/745)).
- **Automatically turn on the car hotspot** is offered on head units that aren't BYD, on Android 8.0 to 10, without ADB: it needs only Android's **Modify system settings** access, which the card asks for. A BOS Mini A1 (MediaTek, Android 9) turned its hotspot on by itself after a full restart, and wireless CarPlay connected. BYD head units keep the ADB route. Android 7.1 refuses the request from every app, so the switch isn't offered there. When the access is missing, Home asks for it with **Allow access** instead of pointing to ADB, and the hotspot starts as soon as it's allowed. Contributed by @maxim4ik163 ([#748](https://github.com/shihabal3amri/DiPlay/pull/748)) and @Boring206 ([#775](https://github.com/shihabal3amri/DiPlay/pull/775), [#777](https://github.com/shihabal3amri/DiPlay/pull/777)).
- Before an iPhone is chosen, **Choose iPhone** no longer shows the English placeholder "Your iPhone" in every language; it says only **Choose iPhone**. Contributed by @Boring206 ([#778](https://github.com/shihabal3amri/DiPlay/pull/778)).
- In car hotspot mode, **Connect** in the **Car hotspot is off** dialog connects. It opened the same dialog again, so a head unit that reports its hotspot off while it is on could never connect: the Geely Galaxy E8 in [#604](https://github.com/shihabal3amri/DiPlay/issues/604) always reports it off. After **Connect**, DiPlay stops treating that report as final until the head unit reports the hotspot on once, and the report logs `car hotspot: Android reports it off; connecting anyway, as the driver chose`. Pending in-car acceptance. [#789](https://github.com/shihabal3amri/DiPlay/pull/789)

## Display

- **CarPlay map on dashboard (experimental)** finds the cluster on BYD firmware that names it `fission_magicsentry` (controller 13) or `sission_magicsentry` (controller 17), at the same 1920×720 size as DiLink 4's `fission_bg_xdjaVirtualSurface`. A controller-13 car listed it as a presentation display, but DiPlay looked only for the DiLink 4 name, so nothing appeared on the cluster. A build that accepted the name drew the map there ([#552](https://github.com/shihabal3amri/DiPlay/issues/552)). Pending in-car acceptance on the release build. [#714](https://github.com/shihabal3amri/DiPlay/pull/714)
- On DiLink 3, the settings card for the dashboard map no longer offers the two DiLink 4 cluster routes (**DiLink 4 cluster video via ADB** and **Platform 21 cluster task**). Either one stops DiLink 3 from creating its dashboard display, so the map stayed off, and only the ADB route showed a warning ([#722](https://github.com/shihabal3amri/DiPlay/issues/722)). When either is on, the card and the setup guide show the warning with a button that turns both off. [#714](https://github.com/shihabal3amri/DiPlay/pull/714)
- **CarPlay map on dashboard (experimental)** uses the same full-map and side-map layers on the Leopard 5 Ultra (system 34.1.23) as on the measured DiLink 5.1 firmware. It drew into a layer this cluster never shows ([#301](https://github.com/shihabal3amri/DiPlay/issues/301)). Pending in-car acceptance. [#714](https://github.com/shihabal3amri/DiPlay/pull/714)
- With **Efficient video** (HEVC) on, a head unit without a hardware HEVC decoder now gets H.264. Android had picked its own software decoder instead: a Spreadtrum SC7731E head unit (Android 8.1) decoded every session in software with `OMX.google.hevc.decoder` while DiPlay logged `decoder=hardware`, and music skipped ([#727](https://github.com/shihabal3amri/DiPlay/issues/727)). The report says `HEVC is on, but no hardware decoder plays it`. **HEVC software decoder** still keeps HEVC on Android 10 and later. [#734](https://github.com/shihabal3amri/DiPlay/pull/734)
- While CarPlay runs over USB, the home screen card is titled **CarPlay over USB** and hides the Wi-Fi hint. It said **Wireless CarPlay** with the Wi-Fi Direct hint over every USB session, so drivers thought a wireless connection was competing with the cable ([#742](https://github.com/shihabal3amri/DiPlay/issues/742)). [#744](https://github.com/shihabal3amri/DiPlay/pull/744)
- CarPlay video shows on a Raspberry Pi 5 running emteria's Android 17. Its default decoder, `c2.ffmpeg.h264.decoder`, reports itself as hardware, but DiPlay's usual video view cannot draw its pictures, so DiPlay stopped at the first frame (`RenderThread: Invalid GrBackendTexture`). With that decoder family, DiPlay now uses the same output as **Direct video output**. Picture adjustments are unavailable in that mode. Pending a re-run on the Pi with this version. Contributed by @j1z4 ([#707](https://github.com/shihabal3amri/DiPlay/pull/707)).
- Typing into **Settings → Search settings** no longer stops DiPlay on Android 7.1–9. The result list called a method that exists only from Android 10 (`NoSuchMethodError … setIsLaidOutInScreen`), since 0.2.19. Contributed by @Boring206 ([#705](https://github.com/shihabal3amri/DiPlay/pull/705)).
- The swipe-down settings menu inside CarPlay is split into pages by goal: Connection, Display, Navigation, Vehicle, Diagnostics, Advanced and More. Wide screens show the pages in a side rail, narrow screens as a row of buttons. **Save and reconnect** stays below the page, and **Exit** is at the end of More. Not yet tested in a car. Contributed by @serein-morii ([#710](https://github.com/shihabal3amri/DiPlay/pull/710)).
- The **Connect your iPhone** screen follows DiPlay's app theme (Dark, Light or Auto) instead of the day/night mode sent to CarPlay, so it's no longer light on a head unit that stays in day mode while DiPlay is set to Dark. Contributed by @maxim4ik163 ([#747](https://github.com/shihabal3amri/DiPlay/pull/747)).
- The ambient light settings show the car's 31 colors as swatches instead of numbers, have a brightness slider, and start with a summary of what the lamps do while music plays, pauses or stops. Controls that only apply while following music are hidden when it's off. Not yet checked in a car. Contributed by @sa3eedo12 ([#749](https://github.com/shihabal3amri/DiPlay/pull/749)).
- When no music plays, the ambient lamps now hold the chosen color by default (**Steady glow**), or hand the lamps back to the car's own lighting after 15 s, or drop to the lowest level as before. On a 2023 Han the lowest level switches the lamps fully off, so they went dark in every quiet moment. The summary at the top of the dialog now matches what the car does. Contributed by @sa3eedo12 ([#772](https://github.com/shihabal3amri/DiPlay/pull/772)).

## Audio, calls and Siri

- An app voice message can use the head unit's microphone. DiPlay opened the microphone only after the iPhone's first audio packet, and an app that records a voice message (Douyin on a Leapmotor T03, [#566](https://github.com/shihabal3amri/DiPlay/issues/566)) asks for the microphone without playing anything, so recording never started. When no audio arrives within 0.5 s, DiPlay now opens the microphone anyway. Calls still wait for the call audio. The report logs `Audio: microphone started without downlink audio`. Pending in-car acceptance. [#698](https://github.com/shihabal3amri/DiPlay/pull/698)
- When the head unit's microphone returns no audio for 1 s, DiPlay restarts recording up to three times, and no longer reads the empty microphone in a tight loop. On the same Leapmotor T03 (Android 7.1), some recordings started with no input device and returned nothing for the whole Siri request or call ([#566](https://github.com/shihabal3amri/DiPlay/issues/566)). The report logs `Microphone: recording restarted … reason=no-audio routedDeviceType=…`. Pending in-car acceptance. [#698](https://github.com/shihabal3amri/DiPlay/pull/698)
- **Settings → Audio → Calls on the loudspeaker** is for an Android phone or tablet used as the head unit. It plays CarPlay calls on the device's loudspeaker and uses its hands-free microphone. Android plays calls on such a device's earpiece and records them with the handset microphone, so the driver heard calls only close to the screen and had to speak into it (Xiaomi MIX 2S, Android 10, [#701](https://github.com/shihabal3amri/DiPlay/issues/701)). It is off by default and applies from the next call. The report adds `loudspeaker=true|false` to `Audio: mode entered communication`. Pending acceptance. [#704](https://github.com/shihabal3amri/DiPlay/pull/704)
- DiPlay's audio threads (receiving, playing and the microphone) run at Android's audio priority instead of the default. When the head unit opened its 360° camera for the turn signal or reverse gear, an Allwinner T507 head unit (Android 10) handled single audio packets 45–138 ms late, its audio reads stalled for up to 0.5 s, and music crackled, then caught up quickly ([#737](https://github.com/shihabal3amri/DiPlay/issues/737)); a Song Plus DiLink 4.0 shows the same ([#733](https://github.com/shihabal3amri/DiPlay/issues/733)). Pending in-car acceptance. [#740](https://github.com/shihabal3amri/DiPlay/pull/740)
- **Settings → Audio** has separate music buffers for wireless and USB. USB offers short buffers (50–200 ms) as well, so music starts and pauses sooner over a cable. The USB buffer keeps the value saved before, until it's changed. Contributed by @maxim4ik163 ([#746](https://github.com/shihabal3amri/DiPlay/pull/746)).
- **Settings → Audio → Audio routing** has a slider (−20 to 0 dB) that lowers only CarPlay's navigation prompts, for head units whose lowest navigation volume is still too loud ([#719](https://github.com/shihabal3amri/DiPlay/issues/719)). It applies while a prompt plays, without reconnecting. Contributed by @acari-git ([#752](https://github.com/shihabal3amri/DiPlay/pull/752)).
- With **Car phone audio for CarPlay calls** on, DiPlay records calls from the voice-recognition microphone source. The voice-communication source clipped about a fifth of the samples in the car's phone state on a 2023 Han, so the other person heard a loud, distorted voice ([#473](https://github.com/shihabal3amri/DiPlay/issues/473)). Geely and Lynk & Co head units keep their previous source. Contributed by @sa3eedo12 ([#770](https://github.com/shihabal3amri/DiPlay/pull/770)).
- One press of BYD's wheel voice key opens Siri once. The key arrives as two key codes about half a second apart, and each sent a Siri request, so the second ended Siri at once. A new switch with the wheel keys, **Siri on long press only**, ignores the short press. Only BYD head units send those keys, so the switch is offered on BYD only, or wherever it is already on. Contributed by @sa3eedo12 ([#774](https://github.com/shihabal3amri/DiPlay/pull/774)) and @Boring206 ([#786](https://github.com/shihabal3amri/DiPlay/pull/786)).
- Music no longer pauses every minute or so on head units whose audio clock runs fast or slow. A Humax head unit in a Hyundai Elantra played music 0.76 % faster than the iPhone sent it, so the buffer ran dry about every 70 s and music stopped for under a second ([#610](https://github.com/shihabal3amri/DiPlay/issues/610)). DiPlay now adjusts the music's playback rate to keep the buffer level steady, by at most 1.5 %; calls, navigation prompts and Siri are not adjusted. The audio stats show `playbackRate=`. Pending in-car acceptance. [#788](https://github.com/shihabal3amri/DiPlay/pull/788)
- A CarPlay call that Android routes to the head unit's earpiece moves to the loudspeaker. A Podofo head unit built on a phone chip (Qualcomm SM4250, Android 11) played calls on its earpiece, which nobody hears in a car, so calls were silent, and navigation prompts during a call went there too ([#782](https://github.com/shihabal3amri/DiPlay/issues/782)). DiPlay now switches such a call to the loudspeaker, as **Calls on the loudspeaker** does, once per call; head units that already play calls on the loudspeaker are unchanged. The report logs `Audio: call routed to the earpiece; loudspeaker=…`. Pending in-car acceptance. [#797](https://github.com/shihabal3amri/DiPlay/pull/797)

## Diagnostics

- When DiPlay crashes, the next diagnostic report shows where: a new **Last crash recorded by DiPlay** section lists the exception, its causes and the code it was thrown from, redacted like the rest of the report. Android 11+ only recorded `reason=java_crash`, so a crash when the DiYou launcher card opens DiPlay could not be traced ([#463](https://github.com/shihabal3amri/DiPlay/issues/463)). The record stays on the head unit until a report is saved and shared. [#700](https://github.com/shihabal3amri/DiPlay/pull/700)
- The phone page's server (**Get the report on a phone**, settings backup) wakes from waiting for a browser every 0.25 s instead of only after its 10-minute idle timeout, so closing it never waits on a pending accept. On the macOS JVM used for the unit tests, closing it while it waited hung the test run. [#714](https://github.com/shihabal3amri/DiPlay/pull/714)
- On a head unit where BYD's HUD gateway package exists but refuses DiPlay's binding, DiPlay no longer retries it every 300 ms. On a Bliss OS tablet that was about 200 refused binds a minute, each logged by DiPlay and by Android ([#609](https://github.com/shihabal3amri/DiPlay/issues/609)). Retries now back off from 0.3 s to one minute, and the refusal is logged once. [#714](https://github.com/shihabal3amri/DiPlay/pull/714)
- **Pause car Bluetooth during CarPlay** writes each step to the report: when the pause is due, whether Android Bluetooth turned off or why not (CarPlay ended first, Bluetooth already off, no ADB access, Bluetooth stayed on), and when it is back on. These steps went only to logcat, so a report could not show why calls still rang on the car's own call screen ([#18](https://github.com/shihabal3amri/DiPlay/issues/18)). [#740](https://github.com/shihabal3amri/DiPlay/pull/740)
- The report shows what an app call's audio setup says about its voice codec (`vocoderInfo=…`), not only that the key was there. A WeChat call on a Han EV (DiLink 3.0) carried it, and the other person heard nothing while phone calls worked ([#718](https://github.com/shihabal3amri/DiPlay/issues/718)). [#740](https://github.com/shihabal3amri/DiPlay/pull/740)
- The diagnostic report lists the keys the wheel key service received since DiPlay started, up to 40 lines: key code, scan code, and whether DiPlay kept the key or left it to the head unit. A volume key that navigation volume left alone says why. Keys that type text are counted, never listed. `presses=0` with the service bound means the head unit handles its wheel keys before Android sees them ([#662](https://github.com/shihabal3amri/DiPlay/issues/662)). Contributed by @Boring206 ([#702](https://github.com/shihabal3amri/DiPlay/pull/702)).
- The same section lists the media keys that reach DiPlay's media session (`media key next -> CarPlay 1 sent=true`) and its audio focus changes. They went only to logcat, so a report could not show whether a steering-wheel media key reached DiPlay at all ([#610](https://github.com/shihabal3amri/DiPlay/issues/610)). [#788](https://github.com/shihabal3amri/DiPlay/pull/788)
- **Check ADB access** also shows its result as a message, for example that ADB over network is off. Only the line above the button changed, so on a head unit without network ADB the button seemed to do nothing ([#724](https://github.com/shihabal3amri/DiPlay/issues/724)). [#768](https://github.com/shihabal3amri/DiPlay/pull/768)
- The report notes up to five music rebuffer pauses, recoveries and queue-full events per audio stream, with how much music was kept at each pause. The 5-second audio stats keep the totals. Contributed by @faizannazir ([#759](https://github.com/shihabal3amri/DiPlay/pull/759)).
- While DiPlay waits for a CH341 authentication adapter, the report lists the USB devices Android sees (`mfi CH341 not listed by Android; USB devices=[…]`), and names the adapter's device node when it is found. `MFi coprocessor not present` only meant that no adapter was listed, so a report could not tell whether it had left the USB bus or come back under another identity after a session ([#792](https://github.com/shihabal3amri/DiPlay/issues/792)). [#793](https://github.com/shihabal3amri/DiPlay/pull/793)

## Updating and reporting problems

Install the official APK over the previous public release to preserve settings and pairing records. The package remains `com.shihab.diplay`; release packaging verifies the existing signing certificate. Source builds omit runtime authentication assets by default; see [building from source](BUILD.md).

Reproduce remaining problems on **0.2.20**, then open **Settings → Diagnostics → Save diagnostic report**. Android 10+ normally saves to **Downloads/DiPlay**; on Android 7.1–9, DiPlay asks for storage access and saves there too. If it is unavailable, follow the save confirmation and use **View report** or **Share**. Review the `.txt` and attach it to a matching [existing issue](https://github.com/shihabal3amri/DiPlay/issues) or [new issue](https://github.com/shihabal3amri/DiPlay/issues/new/choose). Connection reports require the diagnostic log. Reports are not uploaded automatically.

Include car/head unit, Android/DiLink and full firmware, iPhone/iOS, USB or wireless mode, relevant settings, reproduction steps and failure time.

See [validation](VALIDATION.md) for automated checks. No new maintainer vehicle test of the complete release is claimed. The entries marked "Pending in-car acceptance", the music playback-rate adjustment, the call loudspeaker fallback, the wired and car hotspot changes, the dashboard map changes and the experimental options above need current in-car feedback; test optional features while parked.

Thanks to the contributors linked in the 34 pull requests above, and to the users supplying diagnostic reports and vehicle feedback.