Eonon Android 5.1 InCar Enetertainment unit - ALPconnect Testing
DON'T BUY
These units will not support ALPconnect at this stage, the manufacturer has zero intentions of fixing it.
This GOES for ALL!! China made android 4.4 and 5.1 units
Joyous (JY)
HuiFei/Kai Ge Le (KGL)
Klyde (KLD)
Unkown (GS)
Kaiyide (KYD)
Hot Audio (HA)
RoadMaster (RM & YZ)
Unkown (BN)
Unkown (MZ)
Joying
NAVISKAUTO
Eonon
Erisin
Pumpkin
Navall
Xtrons
Quote:
It's severely limited, when compared to any other Android device with BT. This is due to the OEM's choice of the BC5/BC6 module, and their poor BT implementation. Instead of routing BT audio traffic through the Android system, like a normal device would, they route it through the MCU. That would be fine on its own, except they route pretty much all BT interactions through the MCU, via serial AT commands, which is very non-standard. Simple things like pairing, or using SPP profile just don't work, or require a bit of finagling.
On top of that, there's code (at least in MTCB; dunno about newer MTCD) in MTCManager that filters which devices can pair via BT for OBD use. It checks the device name and if it starts with OBD, it will allow it to pass to the next step during pairing. I can only imagine they chose to do that so they could sell their companion BT OBD adapters with the headunits?
My XMTC module had accounted for this limitation in name-based filtering (apparently not the only limitation though; if your adapter was at least v1.4 it should work), but it hasn't been updated to work on any 2016 roms. Since I no longer have time to maintain that project, it's been open sourced on my github. The BT pieces could be extracted into their own module, but I thought I had read someone else (maybe MVG70?) had made a BT xposed module for these devices to try and address compatibility issues.
Quote:
The MCU's embedded application program handles all the logics for operating the unit as a single device rather than many separate devices. For example, if we're listening to the I-pod and decide to push the radio button, the MCU and it's program is the one responsible to sense our decision, turn off the I-pod control, switch audio input to the radio, turn the tuner ON and 'tell' Android (or whatever device is responsible for displaying a user interface for example WinCE) to show us the radio interface. It communicates with all the other chips and boards in the system through a serial communication line, more than likely I2C or Asynchronous serial communication.
In the case of pure android units, it's important to understand that while Android is likely what we care about the most and all whe are really exposed to in terms of user interface, from a hardware standpoint, the android board is simply one of the other components of the unit, at the same level as the DVD player or the radio. Its audio and video outputs and inputs are switched as needed by the MCU. The MCU is hierarchically speaking above Android. The MCU is much simpler and smaller than Android, it handles only a set of core logics, and consumes virtually no power compared to the whole system. It remains powered when our ACC wire is disconnected and handles turning the rest of the system off and back on when the ACC is powered again.
