User Tools

Site Tools


dev

This is an old revision of the document!


Developing & building for the head unit

How to set a machine up to build, sign, install and debug apps for the Aiways U5 head unit (Adayo i.MX6, Android 4.4.2). See Hardware & OS for the platform and How to get in for getting in.

Examples

Three small apps you can install on the car — good starting points that show how the pieces fit together. Each runs as system (sharedUserId=“android.uid.system”), is platform-signed, and ships with no settings baked in: you configure everything on the device, so the downloads below contain no Wi-Fi passwords, MQTT credentials or IP addresses. Source will be published to Git later; these are debug builds (see Signing below).

App What it does Download
OpenAiways Connect Keeps Wi-Fi connected (priority list) and ADB-over-Wi-Fi enabled — the app that gets you in. openaiways-connect.apk
OpenAiways Telemetry Reads CAN signals and publishes them to MQTT with Home Assistant auto-discovery. openaiways-telemetry.apk
OpenAiways Terminal A real VT100 terminal with a built-in keyboard; runs as system, or as root via the local adbd. openaiways-terminal.apk

Installing

  1. Sideload the .apk (copy to a USB stick or download it on the unit) — see How to get in for the file-manager route.
  2. Open each app once after installing. Android keeps a freshly-installed app in a “stopped” state where it does not receive the boot broadcast, so this first manual launch is what arms auto-start.
  3. Configure it (below). Connect and Telemetry then auto-start on every reboot; Terminal is launched by hand when you want a shell.

OpenAiways Connect

Add your Wi-Fi networks (SSID + password, as a priority list) and tick ADB. After boot it reconnects Wi-Fi and re-enables adb-over-Wi-Fi. Passwords are masked (toggle “Show passwords”).

OpenAiways Telemetry

Enter your MQTT broker (host, port, user, password) and a base topic. With Home Assistant auto-discovery the car shows up automatically — state of charge, voltage, current, range, charging and more. Nothing is published until a broker is set.

OpenAiways Terminal

A proper terminal (based on jackpal's emulatorview) with its own on-screen US keyboard, so the device's IME is not needed.

  • The su key (top row, right) switches the shell to root and back — when you are root it reads system. Root is a real uid 0 PTY served by the local adbd; the prompt shows root@…#.
  • The × in the top-right corner closes the terminal.
  • One adb client at a time: the unit's adbd serves a single connection, so while the terminal holds the root shell a laptop's adb cannot connect (and vice-versa). Leaving or closing the terminal frees adb again automatically.

OpenAiways Terminal — built-in US keyboard and root/su switch

What you need

  • Android Studio (any recent version) + the Android SDK. The unit is Android 4.4.2 (API 19), so set minSdkVersion 19 (compileSdk / targetSdk can be higher). The ABI is armeabi-v7a — don't ship arm64/x86-only native libraries.
  • A JDK (the one bundled with Android Studio is fine).
  • adb (Android platform-tools) on your PATH.

ADB over Wi-Fi

The unit runs adb over TCP and has ro.adb.secure=0 (no key-auth prompt). On the home Wi-Fi it is at <HEAD-UNIT-IP>:5555.

adb connect <HEAD-UNIT-IP>:5555
adb devices        # -> <HEAD-UNIT-IP>:5555   device

If adb-over-TCP isn't up, enable it from a root shell on the unit: setprop service.adb.tcp.port 5555 then stop adbd; start adbd.

Signing — the one thing to know

Several of our apps declare sharedUserId=“android.uid.system” so they can bind the OEM services and use system permissions. That requires the APK to be signed with the platform key.

On this setup no signing config is needed: the build machine's ~/.android/debug.keystore is the AOSP platform test-key, so a plain debug build is already platform-signed. Build and install:

./gradlew :app:assembleDebug
adb -s <HEAD-UNIT-IP>:5555 install -r app/build/outputs/apk/debug/app-debug.apk

install -r replaces in place, and on a signature mismatch it fails safely (the old app stays), so it's safe to try. (On a machine whose debug key is NOT the platform key, an app with the system sharedUserId won't install — put the platform test-key at ~/.android/debug.keystore, or add an explicit signingConfig.)

Talking to the car from an app

Vehicle data and commands go through two OEM bound services (bind by Intent action + package — they are not in ServiceManager, so a shell service call can't reach them):

Service Bind (action / package) Interface Use
Canbus action.adayo.CANBUSSERVICE / com.adayo.canbus ICanbusService getInt/getFloat/getIntArray(key) to read, sendData(action,val) to command — the signal keys
CarManager action.adayo.CARSERVICE / com.adayo.carmanager ICarService audio / EQ, radio, mcu_writeDataToMcu (raw MCU frames)

Carry the AIDL interface, or call via a raw Binder transact(). Sketch (Canbus):

bindService(new Intent("action.adayo.CANBUSSERVICE").setPackage("com.adayo.canbus"),
            conn, BIND_AUTO_CREATE);
// in onServiceConnected:
ICanbusService s = ICanbusService.Stub.asInterface(binder);
int   soc = s.getInt(3457);     // pack-1 SoC %
float v   = s.getFloat(3455);   // pack-1 voltage V
s.sendData(103, 1);             // A/C ON  (⚠ actuates the car)

No-code CAN probing

To try keys without writing an app, OpenAiways Telemetry has a built-in probe (it already binds ICanbusService) — read or command any key straight from adb. See CAN bus → Probing signals live.

dev.1786218200.txt.gz · Last modified: by 127.0.0.1