lmagder
commented
7 years ago Got farther in decoding more of the init message into proto code. Turns out the Linux Google desktop head unit binary is not stripped, so if you look at the symbols and know the structure of the code protoc generates you can get info:
syntax = "proto2";
package HU;
message Header
{
enum PacketType
{
INPUT_EVENT = 1;
SENSOR_EVENT = 3;
}
required PacketType type = 1;
}
message ButtonInfo
{
required uint32 scanCode = 1;
required bool isPressed = 2;
required uint32 meta = 3;
required bool longPress = 4;
}
message ButtonInfoWrapper
{
repeated ButtonInfo button = 1;
}
message TouchInfo
{
enum TOUCH_ACTION
{
RELEASE = 0;
PRESS = 1;
DRAG = 2;
}
message Location
{
required uint32 x = 1;
required uint32 y = 2;
required uint32 pointerId = 3;
}
repeated Location location = 1;
required uint32 actionIndex = 2;
required TOUCH_ACTION action = 3;
}
message InputEvent
{
required uint64 timeStamp = 1;
optional int32 dispChannel = 2;
optional TouchInfo touch = 3;
optional ButtonInfoWrapper button = 4;
}
message SensorEvent
{
message NightMode
{
required bool isNight = 1;
}
repeated NightMode nightMode = 10;
}
enum CHANNEL_TYPE
{
AA_CH_CTR = 0;
AA_CH_SEN = 1;
AA_CH_VID = 2;
AA_CH_TOU = 3;
AA_CH_AUD = 4;
AA_CH_AU1 = 5;
AA_CH_AU2 = 6;
AA_CH_MIC = 7;
}
enum SENSOR_TYPE
{
SENSOR_TYPE_DRIVING_STATUS = 11;
SENSOR_TYPE_NIGHT_DATA = 10;
SENSOR_TYPE_RPM = 3;
SENSOR_TYPE_DIAGNOSTICS = 8;
SENSOR_TYPE_GEAR = 7;
SENSOR_TYPE_COMPASS = 1;
SENSOR_TYPE_LOCATION = 9;
}
enum AUDIO_TYPE
{
SPEECH = 1;
SYSTEM = 2;
MEDIA = 3;
}
enum STREAM_TYPE
{
AUDIO = 1;
VIDEO = 3;
}
message AudioCofig
{
required uint32 sampleRate = 1;
required uint32 bitDepth = 2;
required uint32 channelCount = 3;
}
message ChannelDescriptor
{
required uint32 channelId = 1;
message SensorChannel
{
message Sensor
{
required SENSOR_TYPE type = 1;
}
repeated Sensor sensorList = 1;
}
optional SensorChannel sensorChannel = 2;
message OutputStreamChannel
{
required STREAM_TYPE type = 1;
optional AUDIO_TYPE audioType = 2;
repeated AudioCofig audioConfigs = 3;
message VideoConfig
{
enum VIDEO_RESOLUTION
{
VR_800x480 = 1;
VR_1280x720 = 2;
VR_1920x1080 = 3;
}
enum VIDEO_FPS
{
VFPS_30 = 1;
VFPS_60 = 2;
}
required VIDEO_RESOLUTION resolution = 1;
required VIDEO_FPS frameRate = 2;
required uint32 marginWidth = 3;
required uint32 marginHeight = 4;
required uint32 dpi = 5;
optional uint32 additionalDepth = 6;
}
repeated VideoConfig videoConfigs = 4;
optional bool availableWhileInCall = 5;
}
optional OutputStreamChannel outputStreamChannel = 3;
message InputEventChannel
{
message TouchScreenConfig
{
required uint32 width = 1;
required uint32 height = 2;
}
repeated uint32 keycodesSupported = 1;
optional TouchScreenConfig touchScreenConfig = 2;
optional TouchScreenConfig touchPadConfig = 3;
}
optional InputEventChannel inputEventChannel = 4;
message InputStreamChannel
{
required STREAM_TYPE type = 1;
required AudioCofig audioConfig = 2;
optional bool availableWhileInCall = 3;
}
optional InputStreamChannel inputStreamChannel = 5;
//bt service == 6
//radio == 7
//nav==8
//mediaplayback == 9
//phonestatus = 10
//mediabrowser=11
//vendor extension==12
//genericnotification==13
}
message CarInfo
{
repeated ChannelDescriptor channels = 1;
required string HeadUnitName = 2;
required string CarModel = 3;
required string CarYear = 4;
required string CarSerial = 5;
required bool DriverPos = 6;
required string HeadUnitMake = 7;
required string HeadUnitModel = 8;
required string SWBuild = 9;
required string SWVersion = 10;
required bool canPlayNativeMediaDuringVr = 11;
required bool hideClock = 12;
}
izacus
borconi
anod
I did some preliminary investigation into writing proto files instead of manually constructing the wire protocol, but only with some messages sent by the headunit to the phone so far.
For example in the function I added to send a button message
I saved this out with timestamp = 15, button = 32, isPress = true as buttonMessage.bin. Running this through
protoc --decode_raw < buttonMessage.binyieldsso actually you can see there are two messages concatenated here (since there can't be two field #1s). Assuming all the fields are there the first field is pretty simple, something like
so I chopped it off to get
so just making up names assuming what the code does and inferring types from the wire format since unfortunately protoc does not print them, despite knowing them.
seems to work:
I did a few more like the touch event and the day/night sensor notification and you can start to see patterns. The first packet is always a single enum which is the type of second packet and then all the input events are one packet type with optional sub-structs, same with the sensor event. So it seems you can send all or any subset of the sensors at once. I attached the files.
This would definitely clean up code a lot (especially the sd_buf stuff in hu_app.c) and it shouldn't add runtime requirements since all the protoc stuff generates code you compile and link against. The only potential problem is that protoc generates C++ code by default, which is probably nicer and would work since input_filter uses modern C++, but would be a drastic change. There is a unofficial protoc-c project though testFiles.zip