{"id":29726780,"url":"https://github.com/aa-proxy/aa-proxy-rs","last_synced_at":"2026-05-28T12:01:14.922Z","repository":{"id":260865818,"uuid":"880802913","full_name":"aa-proxy/aa-proxy-rs","owner":"aa-proxy","description":"AndroidAuto wired/wireless proxy","archived":false,"fork":false,"pushed_at":"2025-07-16T09:36:38.000Z","size":1845,"stargazers_count":108,"open_issues_count":13,"forks_count":12,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-07-17T13:54:09.888Z","etag":null,"topics":["android-auto","android-automotive","diy","headunit","io-uring","proxy","raspberry-pi","rust","wireless-android-auto"],"latest_commit_sha":null,"homepage":"","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/aa-proxy.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2024-10-30T11:45:07.000Z","updated_at":"2025-07-16T16:18:19.000Z","dependencies_parsed_at":null,"dependency_job_id":"6e9bbf1c-6ead-4c47-b83a-ae18cc9da1f8","html_url":"https://github.com/aa-proxy/aa-proxy-rs","commit_stats":{"total_commits":29,"total_committers":1,"mean_commits":29.0,"dds":0.0,"last_synced_commit":"718124c357a59aa602a996811536adbe75208724"},"previous_names":["manio/aa-proxy-rs","aa-proxy/aa-proxy-rs"],"tags_count":7,"template":false,"template_full_name":null,"purl":"pkg:github/aa-proxy/aa-proxy-rs","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aa-proxy%2Faa-proxy-rs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aa-proxy%2Faa-proxy-rs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aa-proxy%2Faa-proxy-rs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aa-proxy%2Faa-proxy-rs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/aa-proxy","download_url":"https://codeload.github.com/aa-proxy/aa-proxy-rs/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aa-proxy%2Faa-proxy-rs/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":266928478,"owners_count":24007908,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-07-24T02:00:09.469Z","response_time":99,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["android-auto","android-automotive","diy","headunit","io-uring","proxy","raspberry-pi","rust","wireless-android-auto"],"created_at":"2025-07-25T00:04:08.399Z","updated_at":"2026-05-28T12:01:14.912Z","avatar_url":"https://github.com/aa-proxy.png","language":"Rust","funding_links":[],"categories":["Rust","raspberry-pi"],"sub_categories":[],"readme":"# 🛸 aa-proxy-rs\n\n[![Discord](https://img.shields.io/discord/1358047273434615968?style=for-the-badge\u0026logo=discord\u0026logoColor=white\u0026label=Discord\u0026labelColor=%235865F2\u0026color=%231825A2)](https://discord.gg/c7JKdwHyZu)\n\n## About\nThis project is a DIY proxy tool that bridges a wireless Android phone with a USB-connected car head unit to enable the use of Android Auto.\nOriginally derived from the [WirelessAndroidAutoDongle](https://github.com/nisargjhaveri/WirelessAndroidAutoDongle) project (specifically as\na replacement for its `aawgd` component), it has since evolved into an independent and self-contained solution with its own development direction.\n\nThe project initially focused on supporting the Raspberry Pi, but has since grown to include other platforms as well.\n\n![Hardware overview](images/aa-proxy-rs.webp)\n*Sample Connection Diagram – Raspberry Pi Zero 2 W*\n\n## Features\n- **Reliable and safe** – written in [Rust](https://www.rust-lang.org/), minimizing memory-related bugs and crashes\n- **High performance** – uses modern [io_uring](https://kernel.dk/io_uring.pdf) kernel API for efficient I/O handling\n- [Companion app](https://aa-proxy.github.io/docs/companion-app)\n- **Dual I/O backend** – modern `tokio` backend alongside optional `io_uring` support for compatibility with older Linux kernels\n- **Automatic reconnection** – attempts to recover Android Auto connection in all failure scenarios\n- **Transfer monitoring** – displays bandwidth usage and real-time transfer statistics\n- **[Embedded web interface](#embedded-web-interface)** – lightweight UI for status and control\n- **Stall detection** – detects and handles stalled data transfers\n- **[MITM (Man-in-the-Middle) mode](#mitm-mode)** – supports advanced tweaks and modifications:\n  - DPI change\n  - **[Google Maps EV Routing](#google-maps-ev-routing)** – allows EV-specific navigation features\n  - Remove tap restriction\n  - Disable media sink\n  - Disable TTS sink\n  - Video in motion\n  - Enable developer mode\n  - Detects user-initiated `Disconnect` on phone and prevents auto-reconnect\n  - `Waze` workaround for LHT (Left-Hand Traffic) countries\n  - **Per-vehicle SDR UI override profiles** – patch AA UI margins and content insets for specific head units and phone combinations\n  - **Media stream inspection** – tap decrypted AA video/audio stream via TCP (`media_dump_base_port`) for use in VLC, mpv, etc.\n  - **Injected display support** – define auxiliary/cluster displays with custom FPS, DPI, touchscreen support, and startup actions\n  - **Media tap registry \u0026 reverse bridge** – dynamically expose media streams to [companion app](https://aa-proxy.github.io/docs/companion-app) via reverse TCP bridge\n  - **Album art injection** – override album artwork from static images, uploads, or live injected display frames\n  - **Event injection** – key event injection via `/inject_event` and rotary controller support via `/inject_rotary`\n  - **WASM scripting** – write hooks that modify AA packets on the fly via `wasmtime`\n    - Persistent script state and lifecycle hooks\n    - Configurable resource limits and hooks directory\n    - Web UI integration for per-script configuration\n    - Scripts can call the local REST API and push events over WebSocket\n    - Disabled on ARMv6 / RPi Zero W\n  - **BT SCO/eSCO call audio bridge** – routes phone call audio through Android Auto media/microphone channels with echo control and resampling\n  - **Vendor Extension Channel (VEC)** – packet-level extension channel integrated with REST, WebSocket, and WASM hooks\n  - **Speed \u0026 odometry** – speed data collection (`/speed` endpoint), odometer injection (`/odometer`), and tire pressure injection (`/tire-pressure`) via REST API\n  - **Media button interception** – short press re-injects a clean click; long press triggers a configurable script (`hu_button_handler`)\n  - **Packet debug mode** – fine-grained packet inspection with protobuf decoding, filtering, and payload truncation\n- **Wired USB phone mode** – works without the Bluetooth handshake or Wi-Fi pairing\n- **[Support for Google's Desktop Head Unit (DHU)](#connecting-to-desktop-head-unit-dhu)** – ideal for debugging and development\n- **OTA updates** – SWUpdate over-the-air update support for all Raspberry Pi and AAWireless boards, including TCP reverse bridge for companion app updates\n\n## Current project status\nAfter extensive stress testing and continuous development, the project has reached a level of stability that meets its original goals.\nI now use it almost daily in my own car and continue to fix any issues that come up to ensure a smooth and reliable experience.\u003cbr\u003e\nThere's also a great and supportive community on Discord built around this project. If you'd like to join, ask questions, or get help,\nfeel free to connect with us on the [aa-proxy Discord](https://discord.gg/c7JKdwHyZu) server.\n\n## Supported Hardware\nThis project is currently tested and built for the following boards that support USB OTG:\n- Raspberry Pi Zero W\n- Raspberry Pi Zero 2 W\n- Raspberry Pi 3 A+\n- Raspberry Pi 4\n- Raspberry Pi 5\n- [AAWireless TWO](https://www.aawireless.io/en/products/aawireless-two)\n- AAWireless 3\n- [Radxa Zero 3W](https://radxa.com/products/zeros/zero3w/)\n- [MilkV DuoS](https://milkv.io/duo-s)\n\nMore details: https://aa-proxy.github.io/docs/supported-hardware\n\n\u003e [!NOTE]\n\u003e **Raspberry Pi 3 B+ is _not_ supported** due to the lack of USB OTG support.\n\n\u003e [!WARNING]\n\u003e - **2.4GHz Wi-Fi is being deprecated by Google** and is no longer a reliable long-term solution.  \n\u003e   Newer head units with higher resolutions (e.g. Full HD displays in some Kia/Hyundai models) require **5GHz Wi-Fi**\n\u003e   to function **with full resolution support**.  \n\u003e   Only boards with 5GHz-capable Wi-Fi chips will be able to utilize the full display resolution.  \n\u003e   Simply changing the DPI will not solve this limitation.\n\u003e\n\u003e - Additionally, **2.4GHz Wi-Fi can interfere with Bluetooth**, since both operate on the same frequency band.  \n\u003e   This can occasionally cause connection issues — especially during the initial pairing phase when both Wi-Fi and Bluetooth are active.\n\u003e   The problem is particularly noticeable on devices like the **Raspberry Pi Zero 2 W**.\n\nIn theory, support can be extended to other hardware platforms in the future, as long as the following basic requirements are met:\n- USB OTG or USB Gadget mode support\n- Wi-Fi and Bluetooth (either built-in or via external adapters)\n\nSome work is already underway to bring support to more hardware platforms. For the latest updates or specific questions, feel free to ask on Discord.\n\nThe latest stable SD card images are available on the [Releases page](https://github.com/manio/aa-proxy-rs/releases).\n\n## First-time Connection\n1. Connect your phone to the car head unit using a USB cable and verify that Android Auto starts successfully. Then disconnect the phone.\n2. Connect the board to the car using a data-capable USB cable and ensure you use the USB OTG-enabled port on the board:\n   - **Raspberry Pi Zero W** and **Raspberry Pi Zero 2 W**: Use the second micro-USB port labeled \"USB\" (not the one labeled \"PWR\").\n   - **Raspberry Pi 3 A+**: Use the only USB-A port with a USB-A to USB-A cable.\n   - **Raspberry Pi 4**: Use the USB-C port normally used to power the board.\n3. Open Bluetooth settings on your phone and pair with the new device named `aa-proxy-*`.\n4. After pairing, your phone should automatically connect via Wi-Fi, and the dongle will connect to the head unit via USB, starting Android Auto on the car screen.\n\nFrom the next time onward, the system should automatically connect to your phone and start Android Auto without additional steps.\n\n\u003e [!WARNING]\n\u003e For convenience during the initial setup, SSH access is enabled by default and the device uses a predefined Wi-Fi password.\n\u003e **It is strongly recommended to change these defaults and/or disable SSH access for security reasons.**\n\n\u003e [!NOTE]\n\u003e 📶 **Default Wi-Fi credentials:**  \n\u003e SSID: `aa-proxy`  \n\u003e WPA password: `aa-proxy`  \n\u003e\n\u003e 🔐 **Default SSH credentials:**  \n\u003e User: `root`  \n\u003e Password: `password`  \n\u003e\n\u003e See below for instructions on how to connect to the device's Wi-Fi network.\n\n## Embedded Web Interface\nWhen you connect to the device's WiFi network, you can access the web interface, which is available by default at: [http://10.0.0.1](http://10.0.0.1).\n\n\u003e [!WARNING]\n\u003e If you want to connect to the device (e.g. via the web interface or SSH) **while Android Auto is running**, it won't be accessible from your phone. In that case, you have two options:\n\u003e - Use a different device, such as a laptop or another phone, to connect to the device’s Wi-Fi network.\n\u003e - Or stop Android Auto temporarily, for example by:\n\u003e   - Enabling airplane mode, then enabling Wi-Fi only and connecting manually, **or**\n\u003e   - Disabling both Wi-Fi and Bluetooth, waiting a moment, then re-enabling Wi-Fi and connecting manually.\n\u003e\n\u003e If you're still having trouble connecting, try disabling MAC address randomization.\n\u003e [This guide](https://help.kings.edu/hc/en-us/articles/4406119218455-How-to-Disable-Randomized-MAC-Addresses-on-Android) provides clear instructions on how to do it on Android.\n\nUsing the web interface, you can configure all settings that are also available in `/etc/aa-proxy-rs/config.toml`:\n\n![Webserver preview](images/webserver.png)\n\nYou can also download logs with a single click.\n\n## MITM mode\nMan-in-the-middle mode support has been added recently. This is the mode which allows to change the data passed between the HU and the phone.\nSeparate encrypted connections are made to each device to be able to see or modify the data passed between HU and MD.\u003cbr\u003e\nThis is opening new possibilities like, e.g., forcing HU to specific DPI, adding EV capabilities to HU/cars which doesn't support this Google Maps feature.\u003cbr\u003e\nAll the above is not currently supported but should be possible and easier with this mode now implemented.\u003cbr\u003e\nTo have this mode working you need enable `mitm` option in configuration and provide certificate and private key for communication for both ends/devices.\nDefault directory where the keys are search for is: `/etc/aa-proxy-rs/`, and the following file set needs to be there:\u003cbr\u003e\n- hu_key.pem\n- hu_cert.pem\n- md_key.pem\n- md_cert.pem\n- galroot_cert.pem\n\nI will not add these files into this repository to avoid potential problems. You can find it in other places, or even other git repos, like:\u003cbr\u003e\n- https://github.com/tomasz-grobelny/AACS/tree/master/AAServer/ssl\n- https://github.com/tomasz-grobelny/AACS/tree/master/AAClient/ssl\n- https://github.com/lucalewin/vehiculum/tree/main/src/server/cert\n- https://github.com/lucalewin/vehiculum/tree/main/src/client/cert\n- https://github.com/borconi/headunit/blob/master/jni/hu_ssl.h#L29\n\nSpecial thanks to [@gamelaster](https://github.com/gamelaster/) for the help, support and his [OpenGAL Proxy](https://github.com/gamelaster/opengal_proxy) project.\n\n### DPI settings\nThanks to above MITM mode a DPI setting of the car HU can be forced/replaced. This way we can change the hardcoded value to our own. This is allowing to view more data (at cost of readability/font size).\u003cbr\u003e\nExample with Google Maps, where a `Report` button is available after changing this value:\n\n|160 DPI (default)|130 DPI|\n|---|---|\n|![](images/160dpi.png)|![](images/130dpi.png)\n\n## Google Maps EV routing\nGoogle introduced EV routing features at [CES24](https://blog.google/products/android/android-auto-new-features-ces24/).\nThe first cars to support this via Android Auto are the Ford Mustang Mach-E and F-150 Lightning.\n\nThis clip shows how it works in the car:\u003cbr\u003e\n[![This is a clip how it works in the car](https://img.youtube.com/vi/M1qf9Psu6g8/hqdefault.jpg)](https://www.youtube.com/embed/M1qf9Psu6g8)\n\nThe idea of using this feature with other cars started here: https://github.com/manio/aa-proxy-rs/issues/19 in February 2025.\nAfter a long journey searching for someone with the knowledge and hardware that could help us obtain the logs, we finally, at the end of June 2025,\nthanks to [@SquidBytes](https://github.com/SquidBytes), got the sample data to analyze.\n\nThanks to many hours of work by [@Deadknight](https://github.com/Deadknight) and [@gamelaster](https://github.com/gamelaster), we were finally\nable to make some use of that data.\nUnfortunately, the work is still in progress, but I am currently at a stage where, by customizing some parameters, I can provide real-time battery\nlevel data to `aa-proxy-rs`, and overall it makes correct estimates for my car.\n\n`aa-proxy-rs` has an embedded REST server for obtaining battery data from any source (I am using a slightly modified version of the\n[canze-rs](https://github.com/manio/canze-rs) app for this purpose).\nIt reads the data on the same Raspberry Pi (connecting wirelessly to the Bluetooth OBD dongle).\n\n`aa-proxy-rs` can be configured to execute a specific data collection script when Android Auto starts and needs the battery level data, and also when it stops.\nThe script can be configured in `config.toml` and is executed with the arguments `start` and `stop` accordingly.\n\nThanks to the power of open source, even older EVs can now enjoy modern features and a much better navigation experience!\n\n## Troubleshooting\nSometimes deleting the system Bluetooth cache at /var/lib/bluetooth and restarting bluetoothd fixes persistent issues with device connectivity.\nConsider also using \"Forget\" of bluetooth device in the Android phone.\n\nBy default, the application logs to the file:\n`/var/log/aa-proxy-rs.log`\n\nThis log can be useful for troubleshooting and diagnosing issues.\n\nYou can easily download the log file via the [embedded web interface](#embedded-web-interface).\n\n## Connecting to Desktop Head Unit (DHU)\n\nYou can test and use **aa-proxy-rs** with Google's **Desktop Head Unit (DHU)** in two ways:\n\n#### 1. Using a physical Raspberry Pi\n\nThis method allows you to test with actual hardware and `aa-proxy-rs` running directly on the device. The flow then looks like this:\n\n**[📱 Android Phone] ⇄ [📶 BT+WiFi] ⇄ [📟 RPi with aa-proxy-rs] ⇄ [🔌 USB] ⇄ [🖥️ PC with DHU]**\n\nSteps:\n\n- Connect the Raspberry Pi to your PC or laptop running Linux or macOS (depending on where DHU is installed)\n- Pair your Android phone with the Raspberry Pi over Bluetooth\n- After pairing and connection, you should see a USB device appear on your host system. Use `dmesg` to confirm:\n```\n[Mon Aug 25 15:24:43 2025] usb 3-1: new high-speed USB device number 84 using xhci_hcd\n[Mon Aug 25 15:24:43 2025] usb 3-1: New USB device found, idVendor=18d1, idProduct=2d00, bcdDevice= 6.12\n[Mon Aug 25 15:24:43 2025] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3\n[Mon Aug 25 15:24:43 2025] usb 3-1: Product: aa-proxy-rs (Raspberry Pi Zero 2 W Rev 1.0)\n[Mon Aug 25 15:24:43 2025] usb 3-1: Manufacturer: aa-proxy\n[Mon Aug 25 15:24:43 2025] usb 3-1: SerialNumber: 00000000a3f7d2c9\n```\n\n- Then launch DHU with:  \n`desktop-head-unit --usb=00000000a3f7d2c9`\n- If you have problems, try to disable `legacy` mode\n\n#### 2. Without Raspberry Pi (host-only testing)\n\nIf you want to run the `aa-proxy-rs` application itself for development or functional testing — without using a physical Raspberry Pi — you can build and run it **natively** on the same platform where DHU is running (Linux/macOS).\n\nIn this setup, we recommend using the `wired` option in the config, which enables a USB-based connection between your phone and host machine. The flow then looks like this:\n\n**[📱 Android Phone] ⇄ [🔌 USB] ⇄ [💻 PC with aa-proxy-rs] ⇄ [🖥️ DHU]**\n\nTo make this work, follow these steps:\n\n1. In the `aa-proxy-rs` configuration:\n   - Enable the `dhu` option\n   - Enable the `wired` option and provide your phone's **VID:PID** (vendor ID and product ID)\n2. Compile and launch `aa-proxy-rs` on your host\n3. Connect your Android phone via USB  \n   *(Note: you may need to unlock the screen after connecting)*\n4. `aa-proxy-rs` should detect and connect to the phone, then wait for DHU to connect\n5. Launch DHU **without any arguments**: `desktop-head-unit`\n\n## History and Motivation\nThere are many commercial solutions available for wireless Android Auto, such as AAWireless or Motorola MA1. I even bought a\nclone from AliExpress — but unfortunately, it didn’t work in my car (I ended up giving it to a friend who had a compatible vehicle).\n\nThanks to [Nicnl](https://www.reddit.com/user/Nicnl/) on Reddit, who commented under [this post](https://www.reddit.com/r/RenaultZoe/comments/1c5eg2g/working_wireless_aa_for_rlink1_based_zoe/),\nI discovered a great open-source project based on Raspberry Pi hardware:\n[**WirelessAndroidAutoDongle**](https://github.com/nisargjhaveri/WirelessAndroidAutoDongle) by [Nisarg Jhaveri](https://github.com/nisargjhaveri).\n\nThe author did some excellent research and created a working DIY solution — and most importantly, he shared it openly with the community.\nThat’s something I truly admire and appreciate!\n\nBecause the project is open source, I was even able to run additional LoRa hardware on the same Raspberry Pi for a completely different purpose.\n\nThe original project uses a daemon called `aawgd`, which handles proxying data between the phone and the USB-connected head unit.\nUnfortunately (or fortunately!), the original implementation wasn’t always reliable in my case — I experienced crashes, failed reconnections,\nand the need to restart the service manually.\n\nAfter submitting [this pull request](https://github.com/nisargjhaveri/WirelessAndroidAutoDongle/pull/196), I decided to create a Rust-based\nalternative to `aawgd`. That’s how this project started — by reimplementing the C++ code into a new, standalone application written in Rust.\n\n## Coding\nFrom the beginning, I aimed to simplify parts of the original code wherever possible.\nThis project also became a great opportunity (and a lot of fun!) to dive deeper into how the system was designed and how everything works under the hood.\n\nOne of the biggest challenges I faced was implementing reliable bidirectional I/O forwarding.\nSince the entire application is asynchronous and uses [Tokio](https://tokio.rs/), my first instinct was to use [`copy_bidirectional`](https://docs.rs/tokio/latest/tokio/io/fn.copy_bidirectional.html).\nHowever, this approach didn’t work as expected — likely due to how the USB socket for the `usb-gadget` kernel module interacts with polling/epoll mechanisms.\n\nI also experimented with running separate read/write operations inside Tokio tasks, but ultimately found a better solution:\nusing the modern [io_uring](https://kernel.dk/io_uring.pdf) interface via the [`tokio_uring`](https://github.com/tokio-rs/tokio-uring) library.\n\nThis approach turned out to be both highly efficient and completely stable — solving the problem in a clean and performant way.\n\n## Limitations\n- The project depends on the kernel-level [io_uring](https://kernel.dk/io_uring.pdf) API for its core data transfer functionality.\n  As a result, **Linux kernel version 5.10 or newer is required**.\n\n- Please note: I work on this project in my free time as a hobby.\n  While I do my best to respond and fix issues, I can't always guarantee quick replies or provide ETAs for requested features.\n\n## How it works (technical)\nThe connection process is quite complex and involves several carefully timed steps to establish a stable link between the phone and the car head unit. Below is an overview of what the app does from start to finish:\n\n- **USB:** Disable all existing USB gadgets.\n- **USB:** Register for uevents to monitor USB state changes.\n- Start a local TCP server.\n- **Bluetooth:** Power up the Bluetooth adapter and make it discoverable and pairable.\n- **Bluetooth:** Register two profiles:\n  - One for Android Auto,\n  - One for a fake headset (to trick the phone into recognizing a wireless Android Auto head unit).\n- When a phone connects to the Android Auto profile, the app sends two frames with specific Google protocol data:\n  - `WifiStartRequest`: includes the IP address and port of the TCP server the phone should connect to.\n  - `WifiInfoResponse`: contains the Access Point information for the Wi-Fi connection.\n- After receiving a successful response, the tool disables Bluetooth.\n- The phone connects to the car’s Bluetooth (e.g., for phone calls).\n- Simultaneously, the phone connects via Wi-Fi to our TCP server on the specified port.\n- **USB:** Switch USB gadgets to “default” followed by “accessory” mode to enable proper USB data transmission to the car head unit (fooling the car into thinking the phone is connected via USB).\n- **Final stage:** Bidirectional forwarding of data between the TCP client (phone) and USB port (car).\n\nThe USB side is the active initiator of data transmission, starting with sending a 10-byte first frame. Because of this, timing is critical:\n- If the USB dongle connection starts too early (before the phone is connected), the transmission begins but the TCP socket isn’t ready yet.\n- Conversely, if the phone starts too early and the USB connection is not ready, data cannot be sent to the phone, causing Android Auto to close or timeout the connection.\n\nProper synchronization between these steps ensures a stable and reliable connection.\n\n## Demo\n[![asciicast](https://asciinema.org/a/686949.svg)](https://asciinema.org/a/686949)\n\n## Manual configuration\nDefault startup config file is `/etc/aa-proxy-rs/config.toml`.\n\nConfiguration options are documented in comments, but these needs some more attention:\u003cbr\u003e\n- `legacy`\u003cbr\u003e\nOriginal `aawgd` is using two USB gadgets: **default** and **accessory**. When connecting to car headunit, it switches first to **default** then to **accessory**.\nDuring my development I found out that my car headunit doesn't need this switching. It is working fine connecting directly to **accessory** gadget.\nMoreover with this approach it is much faster and doesn't need to wait for USB events in dedicated _UEvent_ thread. As the result I decided to leave the old (legacy)\ncode under this switch for compatibility with some headunits.\u003cbr\u003e\nIn short: if you have problems with USB connection try to enable the legacy mode.\n\n- `connect`\u003cbr\u003e\nBy default without this option the aa-proxy-rs is starting but it is only visible as a bluetooth dongle, to which you have to connect manually from your phone to\ninitiate AndroidAuto connection. If I am correct this was called `dongle mode` in `aawgd`.\u003cbr\u003e\nIf you provide `connect` option with default `00:00:00:00:00:00` wildcard address, then the daemon is trying to connect to known (paired?) bluetooth devices (phones) in a loop\n(the **bluetoothd** have a cached list of recently connected devices in /var/lib/bluetooth).\u003cbr\u003e\nIf you set this option to specific `MAC_ADDRESS` where MAC_ADDRESS is the MAC of your phone (bluetooth), then the aa-proxy-rs will try to connect only to this specified device\nin a loop (ignoring all **bluetoothd** cached devices).\n\n## Building\n\nIf you'd like to build the SD card images yourself, head over to our Buildroot repository:\u003cbr\u003e\n**https://github.com/aa-proxy/buildroot**\n\nThere you’ll find all the necessary tools and instructions to generate custom images tailored to your hardware or specific needs.\n\n## Stand-alone Usage\n\nWhile the aa-proxy-rs binary is typically used as part of the prebuilt system image, it can also be run manually:\n\n```\nUsage: aa-proxy-rs [OPTIONS]\n\nOptions:\n  -c, --config \u003cCONFIG\u003e         Config file path [default: /etc/aa-proxy-rs/config.toml]\n  -g, --generate-system-config  Generate system config and exit\n  -h, --help                    Print help\n  -V, --version                 Print version\n```\n\n\u003e [!WARNING]\n\u003e Kernel Requirements for Stand-alone Usage\n\u003e\n\u003e If you plan to run **aa-proxy-rs** on your own system (outside of the provided system images), be aware that additional **custom kernel modules** are required for full functionality. These modules are not upstreamed and must be built separately.\n\nYou can find the necessary patches here:  \n👉 **[https://github.com/aa-proxy/buildroot/tree/main/external/patches/linux](https://github.com/aa-proxy/buildroot/tree/main/external/patches/linux)**\n\nPlease keep this in mind when creating your own custom solution with `aa-proxy-rs`.\n\nTo achieve full functionality similar to the official Buildroot-based images, make sure the following kernel options are enabled as well:\n- CONFIG_USB_CONFIGFS_UEVENT\n- CONFIG_USB_CONFIGFS_F_ACC\n- CONFIG_BT_RFCOMM\n- CONFIG_BT_RFCOMM_TTY\n\n## Similar/other open source AndroidAuto-related projects\n- https://github.com/nisargjhaveri/WirelessAndroidAutoDongle\n- https://github.com/nisargjhaveri/AAWirelessGateway\n- https://github.com/openDsh/openauto\n- https://github.com/qhuyduong/AAGateway\n- https://github.com/Demon000/web-auto\n- https://github.com/f1xpl/openauto\n- https://github.com/gamelaster/opengal_proxy\n- https://github.com/tomasz-grobelny/AACS\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faa-proxy%2Faa-proxy-rs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Faa-proxy%2Faa-proxy-rs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faa-proxy%2Faa-proxy-rs/lists"}