Android dialer role app for FYT-series head units with UIS7870/UIS7862S SoC (like DUDU Auto)
Redirects the standard Android-invoked dial requests to the Bluetooth module (in fact, there are two Bluetooth modules in these devices; we're referring here to the non-Android one that handles HFP headsets) and the system-installed com.syu.bt app, which initiates the call using your connected smartphone using the C_DIAL cmd with strs=[$phoneNumber] payload.
Note: Both the phone and the head unit must have synchronized the contact list. Both Gemini and the Bluetooth must be able see details of the specified contact.
Below is an example of making a voice call using Google Gemini:
Demo-video.mp4
My goal was to separate the library layer from the app layer so that the client wouldn’t see the “hard” low-level binder logic, and I managed to achieve that (“facade architecture”):
val fytModule = BluetoothModule.get(context)
fytModule.dialNumber("+48123456789") { success ->
Log.d("MyApp","Dial request status: $success")
fytModule.close()
}However, the library part is certainly far from optimal, and I’d like to rewrite it in the future. Beware: Kotlin isn't my first-choice language (or even my second), and I've never used low-level Binders either so the code may be far from perfect.
Android <-> Binders (cmd/update/get/...) <-> FYT modules (BT/Radio/Canbus/...)
Update codes (prefix U like U_PHONE_NAME) - reading value from this type of code must be implemented as an observer even if you want to retrieve the value only once,
Get codes (prefix G) - no known examples for the Bluetooth module,
Command codes (prefix C like C_DIAL) - commands changing module state, doing some action.
Codes reference: Decompiled APKs (mainly com.syu.bt and com.syu.ms).
DUDU firmware uses Tencent Legu encryption in its APKs, so statically analyzing it is almost impossible; it's better to reverse firmware files from other FYT-based manufacturers; IPC communication is the same.