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.

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.

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.

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.

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.

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.

• 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.

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.

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.)

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):

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)

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.