How to Test Android Auto Apps on Windows With Desktop Head Unit and ADB Tunneling

What the Desktop Head Unit actually is​

Google says the DHU lets your development machine emulate an Android Auto head unit so that you can run and test Android Auto apps. It runs on Windows, macOS, and Linux systems. Google first released it in August 2015. Its launch post said it lets you test pre-released versions of your app in a production-like environment, without having to work from your car.

This is not a phone emulator, and the distinction matters. The split works like this:

• Your PC runs the DHU and shows the dashboard interface.
• Your physical Android phone runs Android Auto and the app being tested.
• A USB cable connects the two.

Google's original announcement put it plainly: the DHU runs on your workstation, and your phone runs the Android Auto companion app. Carrasqueira makes the same point: the heavy lifting stays on the phone, so a modest PC is enough.

What you need before you start​

Google's current documentation lists these prerequisites:

1. Developer mode enabled on a mobile device running Android 9 (API level 28) or higher.
2. The app you want to test installed on that phone.
3. Android Auto installed on the phone, and the latest version if it is already there.
4. In Android Studio, the SDK Manager's SDK Tools tab, where you download the Android Auto Desktop Head Unit Emulator package.

The DHU is installed in the SDK_LOCATION/extras/google/auto/ directory. Android Studio shows the SDK location at the top of the SDK Tools screen, and Carrasqueira suggests copying it from there.

You do not need to be a developer. Android Studio is free, and the DHU is one of its optional SDK packages. You can't test an arbitrary app, though. Android Auto only shows apps in categories it supports, such as media, messaging, navigation and similar types. Google's guidance, as summarised in the research notes, is that apps outside those categories are unlikely to open on the head unit. "Test all my apps" really means "test the apps that already support Android Auto."

Two ways to connect: Accessory Mode or ADB tunneling​

Google documents two USB connection methods. Accessory Mode is the recommended one for DHU 2.x. The command is desktop-head-unit --usb. Google warns that on Windows this method may need a WinUSB driver for the phone, and that driver can interfere with ADB. If the DHU can't find or connect to the device, Google suggests running adb kill-server first or switching to ADB tunneling.

Carrasqueira could not get Accessory Mode working on his Windows PC and used ADB tunneling instead. That is one person's experience, and Google does not say Accessory Mode fails on Windows in general. It does flag a driver complication, which is probably why he hit trouble.

ADB tunneling, step by step​

These steps follow the XDA walkthrough, checked against Google's documentation:

1. Enable developer mode in Android Auto. Open Android Auto's settings on the phone and tap the version number repeatedly (XDA says 10 times) until the developer prompt appears. Accept it.
2. Start the head unit server. Open the overflow (three-dot) menu in Android Auto's developer settings and choose Start head unit server. A notification confirms it is running. Google's original announcement says to start the server before launching the DHU on the PC.
3. Connect the phone by USB. Unlock it and approve the USB debugging prompt if it appears.
4. Forward the port. From the SDK's platform-tools folder, or with ADB on your PATH, run adb forward tcp:5277 tcp:5277.
5. Launch the DHU. Run desktop-head-unit.exe from the extras\google\auto folder on Windows. XDA's examples use Unix-style paths such as ./extras/google/auto/desktop-head-unit. Those work in macOS or Linux shells, but Windows users should expect the .exe name and backslash paths in Command Prompt. PowerShell needs .\ in front of local commands.

The phone should then behave as if it were connected to a real head unit.

Linux and macOS notes​

On Linux or macOS you must run chmod +x ./desktop-head-unit to make the binary executable. Linux users on DHU 2.x also need GLIBC 2.32 or later, plus the libc++1 and libc++abi1 libraries. These Linux requirements do not apply on Windows.

If you get a blank screen​

Google's troubleshooting advice for a blank screen on first connection, per the research notes, is to close the DHU, stop and restart the head unit server on the phone, and start the DHU again. Grant any extra permissions the phone asks for, then restart the DHU if needed. Check Android Auto's settings for "Previously connected cars" and make sure "Add new cars to Android Auto" is on. I haven't tested these steps myself. They come from Google's guide as relayed in the research notes, because the live documentation page wasn't fully retrievable here.

What you can test at your desk​

According to XDA and Google's documentation, the DHU supports more than looking at the screen:

• Touch input. Mouse clicks stand in for taps, and a touchscreen PC can be used directly.
• Rotary and hybrid input. The command-line options are touch, rotary and hybrid. In rotary mode, mouse clicks are ignored and you use keyboard shortcuts or DHU commands. This is a good check for cars that have a knob and no touchscreen.
• Voice input. You can speak into the PC's microphone or play the sample recordings that ship with the DHU.
• Simulated vehicle data. The DHU can fake location, speed, gear and similar values, as well as day/night mode. The sensors must be enabled in the DHU configuration file first, or the commands are ignored.
• Display settings. You can vary the resolution and DPI to see how an interface scales.

What DHU testing can't tell you​

The DHU is a convenience, not a guarantee. The "before it goes near my car" framing has limits:

• It emulates a generic head unit. It can't reproduce your car's own screen size, steering-wheel controls, Bluetooth quirks or Wi-Fi behavior.
• The sample voice recordings cover basic commands. They don't reproduce road noise or a real in-car microphone.
• For developers, Google says to test against its Auto app quality criteria before submitting to Google Play. The DHU helps with that, but it doesn't replace testing in real vehicles.

A sensible workflow is to use the DHU as a fast pre-flight check, and only then try the app in the car. It will catch obvious problems like missing screens or broken navigation before you are in traffic.

One more caution​

Carrasqueira jokes that you could use the PC as a dashboard in your actual car, and then says you probably shouldn't. I agree. The DHU is a development tool. It is not a road-legal infotainment system, and a laptop on the passenger seat is a distraction hazard.

Bottom line​

If you use Android Studio on Windows, the DHU is a free, official way to check how an Android Auto app behaves without leaving your desk. Try Accessory Mode first, since Google recommends it. If it fails, fall back to ADB tunneling, as XDA's author did. Treat the results as a rehearsal, not final proof that the app works in your car.