Open Headunit turns an Android tablet into an Android Auto display

The problem: Android Auto needs a screen the car does not have

Android Auto normally runs on a car's built-in infotainment screen. Plenty of vehicles do not have one, or have one that is old, locked down or tied to a manufacturer's own software. Open Headunit takes the opposite route: it runs on the Android device you already own and acts as the receiver, so the projection lands on a tablet or phone instead of on the dashboard. The README describes it plainly as an app that lets you turn your Android tablet or phone into an Android Auto receiver.

The audience is narrow and specific. This is for someone with a spare Android tablet, a phone that runs Android Auto, and the willingness to wire the two together or fight through a wireless handshake. It is not for someone who wants a finished consumer product with a support line. The project is a revived version of the original headunit project by Michael Reid, and the repository still ships a COPYRIGHT_MICHAEL_REID_GPLv3AFFERO.txt file alongside its own LICENSE, which tells you the lineage is taken seriously.

How projection actually gets from phone to tablet

The app is the receiving end. Your phone runs Android Auto and produces the video stream; Open Headunit decodes and displays it, and sends touch input back. The transport is the part that varies, and the README splits it into a wired path and four wireless paths.

On the wired path, you connect the phone to the tablet over USB, set the phone to host mode if needed, press the USB button in Open Headunit, pick the phone from the list and allow the connection. On the wireless paths, the negotiation differs. A hardware USB dongle plugged into the headunit handles the whole wireless negotiation on its own. Native Mode talks to Android Auto's native wireless protocol directly over Wi-Fi Direct (P2P) or the Headunit Hotspot transport, configured under Settings, Android Auto Mode, Native Mode. Headunit Server starts Android Auto's own developer server on the phone and is described as the only remaining solution for Self-Mode on AA 17.4 and newer. Wireless Helper is a separate companion app that triggers the connection in the background, and it is limited to Android Auto v17.3 and below.

There is also an intent-based trigger for automation. The URI scheme is headunit://connect?ip=<PHONE_IP>, which means Tasker, MacroDroid or ADB can start a connection attempt without touching the UI.

Installing Open Headunit and making a first wired connection

The README does not give a build-from-source walkthrough; it points at the Google Play listing and the Amazon Appstore listing for the packaged app, and at the wiki for setup guides. The repository does contain README_OPENSOURCE_BUILDING.txt and a Gradle wrapper, so a source build is possible, but the README itself treats the store builds as the normal route. Install from one of the two store badges, then open the app on the tablet.

Before anything else, install Android Auto on the phone. Then connect the phone to the tablet with a USB cable. The README notes that you may need to set the phone to host mode and select Android Auto there.

# On the tablet, in Open Headunit: tap the USB button,
# select your phone in the list, then confirm the connection.

After you allow the connection, Android Auto should start projecting onto the tablet. If you want to trigger a wireless attempt from a script instead, the README gives this ADB example, where the IP is the phone's address on the network:

adb shell am start -a android.intent.action.VIEW -d "headunit://connect?ip=192.168.1.25"

The wiki is where the project puts detailed documentation and troubleshooting, and the README repeats that pointer rather than inlining the steps.

Android Auto 17.4 broke the automatic wireless launch, and the README says so

This is the most important limitation and the project states it in bold at the top. Android Auto 17.4 and newer breaks almost all third-party wireless triggers, including Self-Mode and the automated launch through Wireless Helper. Google made internal changes that stop projection from starting automatically without the native developer server or hardware dongles. The practical consequence: if your phone is on Android Auto 17.4 or later and you were counting on the connection appearing by itself, it will not.

The workarounds are the four listed options. A USB wireless dongle is called the most reliable and is the recommended one. Native Mode is the direct Wi-Fi Direct or Headunit Hotspot handshake. Headunit Server is the only remaining route to Self-Mode on those versions. Wireless Helper keeps working, but only up to 17.3. Notice what that means for anyone who wants a fully automatic, app-free experience on current Android Auto: the README effectively points them at hardware.

There is a second version cliff. Self-mode on Android 10 (Q) and below is affected because Google disabled automatic wireless projection startup for those versions in Android Auto 16.4 and higher. The documented workaround is to start the built-in Android Auto Headunit Server and connect over Wi-Fi in loopback mode.

Known issues worth reading before you install

The README keeps a Known Issues list, and it is more useful than most. Google Maps in portrait mode can lose touch interaction on some devices; the suggested fix is dropping the pixel density (DPI) setting below 200, for example 190. Wireless connections that drop frequently are often the phone's own Wi-Fi assistant or a switch-between-networks setting killing the link because it sees no internet, so the README suggests disabling those and checking battery saving options.

A harder failure is being stuck on Android is starting, with projection never beginning. The README attributes this to a broken h265 decoder on some devices and says to set the video codec in the settings to h264. That is a real constraint on hardware choice: a device with a faulty h265 decoder will not work until you change the codec.

One entry is honest in a way that is rare in project documentation. On Wi-Fi Direct taking a long time to connect, a user found it related to Google Assistant rather than Gemini for Android Auto, and on newer Android Auto versions with Gemini it runs smoothly again. The README then says, in effect, that it has no idea why. Treat that as an open question rather than a solved one.

Where Open Headunit is the wrong tool, and what to use instead

Open Headunit is the wrong tool when the goal is a wireless Android Auto connection that starts on its own with no hardware and no manual step. On Android Auto 17.4 and above the README says that path is gone. If that is your requirement, the honest answer is a USB wireless Android Auto dongle, which the README itself recommends as the most reliable option and which handles the negotiation in hardware. That is a different approach: the dongle speaks the wireless protocol for you, so the phone never has to be coaxed into projection.

The other realistic alternative is a commercial head unit. A factory or aftermarket unit with Android Auto built in gives you the projection without a second Android device, without codec settings, and without a companion helper app that stops working past a specific Android Auto version. The trade is cost and flexibility: you get a closed device you do not control, and you lose the ability to run Open Headunit on a tablet you already own or to trigger connections through an intent from Tasker. Headunit Reloaded is another name that comes up in this space, and the difference in approach is that Open Headunit is the open source, AGPL-3.0 revived fork with its own wireless helper and Self-Mode handling, rather than a closed paid app.

One more boundary: the README does not document rollback. If a beta release misbehaves, there is no published procedure for returning to the previous version, so treat the beta channel accordingly.

Licence, maintenance and the real cost of keeping it running

Open Headunit is licensed AGPL-3.0, and the repository also carries COPYRIGHT_MICHAEL_REID_GPLv3AFFERO.txt for the original project it revives. AGPL-3.0 is a strong copyleft licence with a network clause, which matters if you intend to modify the app and expose it to users over a network. That is a description of the licence text, not legal advice; if you plan to distribute a modified build or run it as a service, get your own reading of the terms.

The last push to the default branch was on 2026-09-25, and the most recent release is v.3.5.0-beta1 from the same day, preceded by v.3.5.0-alpha on 2026-09-22 and v.3.4.0 on 2026-09-18. Those are beta and alpha tags, which is the maintenance cost in practice: you are tracking a project that ships pre-releases, and the 3.5.0-beta1 notes include a Native AA fix for reconnecting to a network that is still there instead of rebuilding it every time. Upgrading means re-testing your connection path, because the wireless behaviour is exactly what changes between releases.

The upgrade cost is not only the app. Google's Android Auto releases move the ground underneath it, as 16.4 and 17.4 both did. A setup that works today can require a dongle or a manual server start after a phone-side update you did not choose. Budget for that, not just for the install.

Editorial conclusion

Adopt Open Headunit if you have a spare Android tablet, a phone running Android Auto, and either a USB cable or one of the four wireless paths the README lists. Do not adopt it if you expect a wireless connection to start by itself on Android Auto 17.4 or newer, or if you are on Android 10 or below and want Self-Mode without the Headunit Server workaround. Before installing, confirm your Android Auto version, check whether your device decodes h265, and read the wiki troubleshooting page for the exact failure you are hitting.

Frequently asked questions

Official sources

1. andreknieriem/open-headunit on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases