# DiPlay Legacy Android: CarPlay projection for pre-Android 7 car hardware > This is a fork of the DiPlay CarPlay projection app, refactored so it still runs on Android 4.4 through 6.0 and on the 32-bit automotive hardware that shipped in cars years before the modern head units. It is the interesting case of a fork that exists because of hardware rather than features, and its own release notes are a running list of Bluetooth pairing timeouts and Allwinner T3 re-enumeration deadlocks. **programmerguohuajing/DiPlay-Legacy-Android** — 基于 shihabal3amri/DiPlay 修改，面向低版本 Android 系统与老款 Android 车机兼容 - Repository: https://github.com/programmerguohuajing/DiPlay-Legacy-Android - Website: https://programmerguohuajing.github.io/DiPlay-Legacy-Android/ - Stars: 760 · Forks: 103 - Language: Kotlin - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/programmerguohuajing-diplay-legacy-android ## Why the fork exists: an API level floor, not a feature disagreement DiPlay Legacy Android is a modification of shihabal3amri/DiPlay with deep compatibility refactoring, and the reason is stated as a scope difference rather than a philosophy. Upstream DiPlay supports Android 7.0 and above, API 24, in its latest releases, primarily targeting modern 64-bit platforms. This project focuses on Android 4.4 KitKat, API 19, through Android 6.0, as well as legacy 32-bit automotive hardware architectures including armeabi-v7a, x86, Allwinner T3, MediaTek and AC8227L, low-level Linux usbfs driver hardening, and proprietary Bluetooth stacks such as the Hangsheng HSAE used in Dongfeng Nissan. That is a very specific list and it is the right way to read the project. The fork is not competing with upstream on features. It is keeping an application running on hardware that upstream has moved past, and the constraints that creates are concrete. The code reflects that. A modern Android app assumes AndroidX, assumes a modern Bluetooth stack with a documented API, and assumes a Java toolchain level that suits current libraries. None of those hold on a car head unit that shipped with Android 4.4 and has never been updated by its manufacturer, because there is no update path for a car. The head unit is a sealed appliance with a fixed SoC and a fixed vendor image. So the work in this fork is the unglamorous kind: making an application build and run against an API level that modern tooling no longer supports, on chipsets that vendor kernels expose in non-standard ways, with Bluetooth stacks that do not implement the standard profiles cleanly. The result is described as CarPlay for compatible BYD and legacy Android head units, wired and wireless, with the familiar DiAuto interface, as an independent app under the package name com.shihab.diplay. ## The release notes read like a field service log The most informative thing in this repository is the list of recent release tags, because they describe the work without any framing. Version 0.2.80, published on 2026-10-20, fixed an external Bluetooth pairing authentication timeout and a self-check status, and eliminated a hang when reconnecting a wired mode after unplugging. Version 0.2.79, from 2026-10-19, fixed iPhone search invisibility for external Bluetooth on the CM390, eliminated black borders on right-angle video, and added compatibility for the Allwinner T3. Version 0.2.78, earlier the same day, restored wireless CarPlay audio output, eliminated an Allwinner T3 re-enumeration deadlock, and enhanced the wired TCP handshake. Read as a set, that is a hardware and stack compatibility log rather than a feature log. A pairing authentication timeout on one Bluetooth module, an iPhone that cannot be discovered on another, a deadlock when the Allwinner T3 re-enumerates its USB devices, a hang when a wired connection is yanked out mid-session. These are the failure modes you only find by owning the hardware and using it every day. The re-enumeration deadlock and the wired-mode reconnect hang are the kind of bugs that are close to unfixable without a device, because they involve the interaction between an app's socket handling and a kernel's device lifecycle, and the reproduction is a physical act of unplugging something. The pace matches that. Three releases in a single day, 2026-10-19 and 2026-10-20, each with a specific fix attached, is what a maintainer fixing reported problems on real hardware looks like. The last push to the repository was on 2026-10-20, and the repository is not archived. ## The Apple identity problem, stated plainly by the project itself One paragraph in the README deserves to be read carefully and quoted rather than paraphrased, because it is the project's own account of its main limitation. This is not an Apple-certified product. The APK bundles an experimental accessory identity recovered from public Carlinkit firmware, not a newly provisioned MFi identity for DiPlay. A bundled private key is extractable. Acceptance after future iOS updates, reliability across head units and suitability of that identity for general distribution are unresolved. This release invites community testing, and it is not a guarantee of universal compatibility. That is an unusually clear statement, and every clause in it has a consequence. The identity is recovered rather than provisioned, so it is a constant that Apple can change, and the release notes confirm that behaviour is version-dependent, with an Android 9 Wi-Fi Direct path using generated group credentials and unverified requested frequency while Android 10 and above verifies its negotiated group frequency. The key being extractable and shared across every install is the other half. It means the identity is not a secret, it is a known value, and the risk of one user extracting it is not materially different from every user having it. The project says plainly that suitability for general distribution is unresolved, which is a legal question as much as a technical one. The practical advice for a user is to install on the car rather than the phone, since no jailbreak, dongle, Mac, account or authentication server is required, and to expect that a future iOS update may stop the projection working until the identity is updated. That is a different kind of dependency from an ordinary app, and it is inherent to the approach rather than a bug in this fork. The compatibility notes also state that the earlier releases were tested on a development DiLink 5.1 car, that earlier wheel-speed and video contributions were tested on a BYD Tang with DiLink 5.0 and an iPhone 15 Pro on iOS 27, and that wheel-speed dead reckoning in tunnels remains unverified, with broader head-unit and iOS compatibility not guaranteed. ## What the app actually does, and the split between what needs ADB and what does not The feature set is described in terms that assume you know the domain, so it is worth unpacking. It is CarPlay for BYD cars, wired and wireless, with local authentication. The BYD HUD navigation shows arrows, distance and street names on verified firmware, which depends on the car firmware rather than the app. There is car hotspot support, improved audio buffering and saved receive diagnostics. Automatic address discovery, fixed-channel Wi-Fi fallbacks and successful-configuration memory are all about making a wireless connection survive a restart. Icon and text size, resolution and frame rate are configurable, and applying a display change reconnects CarPlay. Local diagnostic export is available, and reports are sent only if you choose to share them. It installs alongside DiAuto, with the instruction to run one projection app at a time. The install model is the part with a real constraint. You install on the car, not the iPhone, and your head unit must permit APK installation. Core CarPlay does not require ADB, but the optional dashboard, battery, wheel-speed and parked-video features do. The APK supports Android 9 and above, API 28, for the upstream release this README documents, and wireless supports Wi-Fi Direct, the car's existing hotspot or existing Wi-Fi on the same LAN. That gap between the install target and the minimum API is the fork's whole point in one line. The upstream preview documented here requires Android 9, and this fork's entire purpose is to go back to Android 4.4. The documentation set is thorough and the paths tell you what to expect: an install and connect guide, a compatibility and troubleshooting page, a smooth wireless CarPlay guide, a privacy page covering diagnostic reports, a build page, a validation page, release notes, and third party notices. There is also a specific document for the Android 9 Wi-Fi Direct path and another for BYD navigation, the latter covering the HUD firmware scope and cleanup limits. The app ships in English, Arabic, Russian, Ukrainian, Spanish, Simplified Chinese and Traditional Chinese for Taiwan, with separate Traditional Chinese wording, and the app also recognises Hong Kong and Macao selections. ## The repository layout, and a build split that explains the sample directories The top level of the repository is a Gradle project with a structure that reveals how the fork is organised. There is a mobile/ directory, a shared/ directory and a common/ directory, which is the standard split between the application, the code shared between the app and the build tooling, and the common module. There is a samples/ directory with two entries, home/ and maphost/, and the build documentation names them, telling you to select mobile for the main DiPlay app and that maphost is a map sample. There is a site/ directory for the release website, a docs/ directory, and a scripts/ directory. The build files are the Kotlin DSL versions, build.gradle.kts and settings.gradle.kts, with the gradlew and gradlew.bat wrappers, a gradle.properties and a gradle/ directory. There is a checksums/ directory at the root, which for an APK distribution project is the mechanism for verifying the artefact you downloaded. The testing artefacts are interesting because they show how this project is validated. There is a T3-WIRED-TEST-PLAN.md at the root, named after the Allwinner T3 chipset that appears in two of the three most recent release notes, and there is a docs/VALIDATION.md page referenced as the place for contribution links and remaining physical tests. The README also notes that general stutter, call and Siri, decoder and model-specific reports still need current-device evidence, and that the 0.2.13 notes remain available as historical guidance. So the validation story is explicit about what remains unfinished. A validation document, a chipset-specific test plan, a diagnostics feature that produces a text report, and a documented expectation that some categories of report need a physical device to reproduce. The agent-facing files are also present, with AGENTS.md and CLAUDE.md at the root, alongside SECURITY.md, CONTRIBUTING.md, CHANGELOG.md and THIRD_PARTY_NOTICES.md, and the third party notices file is the one to read if you are assessing the licence position of a build that bundles vendor blobs, which a project bundling a recovered accessory identity and car firmware hooks is likely to. ## Conclusion Adopt DiPlay Legacy Android if you have an older BYD head unit running Android 4.4 to 6.0 and the upstream app no longer installs, because that is the exact gap this fork exists to fill and the per-hardware work in its release notes shows the effort involved. Do not adopt it on a modern head unit, where upstream DiPlay supports Android 7.0 and above and is the better-maintained path. Before you install, read the scope notes carefully, because support is for BYD cars specifically, and note that the bundled accessory identity is recovered rather than provisioned, so acceptance after future iOS updates is unresolved. ## FAQ ### What is the difference between DiPlay Legacy Android and upstream DiPlay? Upstream DiPlay supports Android 7.0 and above, API 24, in its latest releases, targeting modern 64-bit platforms. This fork focuses on Android 4.4 KitKat, API 19, through Android 6.0, legacy 32-bit automotive architectures such as armeabi-v7a, x86, Allwinner T3, MediaTek and AC8227L, low-level Linux usbfs driver hardening, and proprietary Bluetooth stacks. ### Is DiPlay Legacy Android an Apple-certified product? No. The README states that the APK bundles an experimental accessory identity recovered from public Carlinkit firmware rather than a newly provisioned MFi identity, that the bundled private key is extractable, and that acceptance after future iOS updates, reliability across head units and suitability for general distribution are unresolved. ### Which car brands are supported? The projects focus on BYD cars. They may work on other brands, but other brands are unsupported and there are no plans to add support or fix brand-specific incompatibilities. ### How do I report a problem with DiPlay Legacy Android? Reproduce it on the current release, then use Settings, Diagnostics and Save diagnostic report, which on Android 10 and above normally saves to Downloads/DiPlay and on Android 9 uses the document picker. Review the text file and add it to a matching issue, including the vehicle and head unit model, firmware and Android or DiLink version, phone and iOS version, connection backend, settings, steps and failure time, and never post your hotspot password. ## Sources - [License: GPL-3.0](https://github.com/programmerguohuajing/DiPlay-Legacy-Android/blob/main/LICENSE) - [programmerguohuajing/DiPlay-Legacy-Android on GitHub](https://github.com/programmerguohuajing/DiPlay-Legacy-Android) - [Project website](https://programmerguohuajing.github.io/DiPlay-Legacy-Android/) - [README](https://github.com/programmerguohuajing/DiPlay-Legacy-Android/blob/main/README.md) - [Releases](https://github.com/programmerguohuajing/DiPlay-Legacy-Android/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/programmerguohuajing-diplay-legacy-android