Documentation

Vehicle Property & Hardware Signal Catalog

Exhaustive engineering reference of verified Vehicle Hardware Abstraction Layer (VHAL) properties, Geely adaptation function IDs, and OBD2 diagnostic signals on the Geely IHU629G head unit platform.

1. Probing Methodology & Verification Framework

To systematically verify signals without false positives or synthetic defaults, property investigation follows a disciplined eight-step methodology:

1. Origin Identification: Classifies the candidate source:
   • Symbol match: Exported constants in android.car.jar (proves symbol existence only).
   • Directed diff: Comparing pre/post Discovery.snapshot state captures across isolated hardware operations.
   • OEM decompile: Extracting exact functionId, areaType, and resolution logic from disassembled OEM applications.
   • Direct OBD2: Querying ECU registers directly via UDS commands over CAN.
2. Registration Verification (CONFIGCHECK): Queries CarPropertyManager.getPropertyList() and range declarations. A degenerate range (min=max=0) indicates unpopulated hardware. Note that certain valid properties (e.g. SEAT_OCCUPANCY, DOOR_POS) bypass getPropertyList() enumeration but answer validly via typed accessors (getFloatProperty, getIntProperty).
3. Property Scope (Area-Indexed vs. Scalar):
   • Area-Indexed: Requires querying explicit bitmasks (doors: 1, 4, 16, 64; windows: 16, 64, 256, 1024; seats: 1, 4, 16, 32, 64).
   • Scalar: Global powertrain and trip metrics operate on Area 0. Querying additional areas on scalar properties yields redundant results.
4. Resolution via Wrapper (WRAPREAD): Geely adaptation layer functionIds must be resolved via CarAccess.wrapFuncId(funcId, areaType) prior to invoking CarPropertyManager. Direct reads using raw function IDs query incorrect registers.
5. Predefined Semantics & Units: Physical units, quantization steps, and scaling formulas must be established before reading to differentiate genuine telemetry from uninitialized memory buffers.
6. Cross-Validation with OEM UI: Comparing readouts against live OEM dashboard indicators (com.flyme.auto.energy, com.flyme.auto.hvac, cluster displays) confirms calibration alignment.
7. Physical Actuation for Writable (RW) Properties: Software write verification requires:
   • Baseline read.
   • Property write dispatch.
   • Settling delay for mechanical or electrical transition.
   • Independent follow-up read and direct physical confirmation (actuator movement, relay click, dash icon).
8. Dynamic State Logging: Properties such as power flow, energy consumption, and cruise states report 0.0 or null while stationary. Validation requires continuous logging during active driving or fast charging.

Diagnostic Command Interface

# Full property sweep snapshot
adb shell am broadcast -n com.geely.drivemem/.BootReceiver -a com.geely.drivemem.DISCOVER

# Direct property write
adb shell am broadcast -n com.geely.drivemem/.BootReceiver -a com.geely.drivemem.WRITEPROP --ei prop <id> --ei area <area> --ei val <int_val>
adb shell am broadcast -n com.geely.drivemem/.BootReceiver -a com.geely.drivemem.WRITEPROP --ei prop <id> --ei area <area> --ef fval <float_val>

# Read-only query
adb shell am broadcast -n com.geely.drivemem/.BootReceiver -a com.geely.drivemem.READPROP --es props "<id1,id2>" --es areas "<a1,a2>"

Status Key:

• ✅ Confirmed: Verified live on vehicle hardware with observable effect or validated telemetry.
• 🟢 Validated Read: Confirmed state reporting, write actuation pending further verification.
• 🟡 Candidate: Theoretical or decompile lead, unverified on hardware.
• 🔴 Dead / Unwired: Declared in software tables but unpopulated or rejected by physical vehicle hardware.
• ⚪ NOOP / Inert: Accepts commands without error but produces no physical actuation.

2. Powertrain & Driving Telemetry

3. Climate Control (HVAC)

4. High-Voltage Battery & Charging

Fast Charging (DCFC) Detection Logic

To distinguish DC fast charging from AC charging reliably across power tapering curves:

• Mains AC Charging: Current $\le 32 ext{ A}$, voltage $pprox 220 ext{–}245 ext{ V}$.
• DC Fast Charging: Pack voltage $\ge 250 ext{ V}$ (consistently $380 ext{–}415 ext{ V}$), current up to $50 ext{ A}$. Pack voltage threshold cleanly separates modes even when DCFC current tapers at high SoC.

5. Drive Modes & Dynamics

6. Cruise Control & ADAS

6a. AVAS (Acoustic Vehicle Alerting System)

Not to be confused with ADAS above — AVAS is the low-speed pedestrian warning sound, a completely different system with a different control path. The OEM Settings “Som” screen only exposes which tune plays (Clássico / Tom Galático / Caminhada Espacial, a plain int CarPropertyManager property) — it never shows a mute/off control at all, for any tune.

Muting is a separate call, not a property write: android.car.media.CarAudioManager (a hidden framework class, reached by reflection — getCarManager("audio"), confirmed real by decompiling the reference app, see CarAccess.audioCall() in drivemem) exposes getAVASMode() / setAVASMode(int), where 0 = muted and >=1 = the active mode. This is the mechanism the reference app (backup-centralex/jadx-out, KEY_AVAS_MUTED) uses for its own AVAS mute toggle — not a Settings-app UI patch.

Confirmed 2026-09-12, live from modehelper: isAVASModeSupported() → true; baseline getAVASMode() → 1; setAVASMode(0) muted it (readback confirmed 0); setAVASMode(1) restored it (readback confirmed 1). No SecurityException — unlike the identical call attempted from Drive Assist itself, which fails with requires permission android.car.permission.CAR_CONTROL_AUDIO_VOLUME. Same pattern as the AEB property write: the platform-signed helper can do it, the normal app can’t.

7. Lighting & Body Electronics

Exterior & Interior Lighting

Convenience & Peripheral Features

8. Doors, Windows & Latches

Door State & Locking

Power Windows

Writing to WINDOW_POS directly drives the mechanical window regulator:

Window Position Encoding:
0 = Fully Closed
100 = Fully Open

9. Seat Occupancy & Belts

Architectural Note: The physical rear seat occupancy and seatbelt switches are routed directly from the Body Control Module (BCM) to the instrument cluster over dedicated harness wiring; signals do not cross into the Android head unit.

10. Direct OBD2 UDS Parameter Identifiers (BMS ECU 0x7E2)

Diagnostics querying the high-voltage Battery Management System directly over CAN via a paired Bluetooth ELM327 adapter:

Bus Initialization Sequence

ATE0         # Echo off
ATSP6        # Protocol 6: ISO 15765-4 CAN (11-bit ID, 500 kbit/s)
ATM0         # Memory off
ATS0         # Spaces off
ATAL         # Allow long frames
ATAT1        # Adaptive timing on
ATH1         # Headers on
ATST64       # Response timeout (64 * 4 ms = 256 ms)
ATSH7E2      # Set target ECU address to 0x7E2 (BMS ECU)

Parameter Identifiers (Service 0x22 - ReadDataByIdentifier)

Battery temperature is 4B48, A - 40. The temperature DIDs came from a Car Scanner (“Geely Geometry C” profile) communication log on 2026-09-28, 07:33, 20 °C outside: 4B48, 4B23, 4B25 and 4BC2 all answered 0x3D (21 °C) and 4BDA 0x3C (20 °C). Car Scanner labels them “Average”, “Max. cell”, “Min. cell”, “Inlet” and “Charging socket”, but it shows max/min/inlet as -9.5 °C (it scales them A * 0.5 - 40, wrongly). Which of 4B48/4BC2 is the average was settled from 892 polling rounds in the same log: 4B48 lies between min (4B25) and max (4B23) in 97% of them, 4BC2 is below the minimum in 28% – the pattern of a coolant inlet. 4B1C, 4B85 and 4B8A answer 7F 22 31 (not supported).

4B3C is not a temperature, under any offset. It was used first as A - 40 (gave -11 °C on a 22 °C day, 2026-09-24), then as A (looked right at 29–32 °C, then climbed 27 -> 80 over three days, fell only 62 -> 56 over a parked night, and read 67 on the 20 °C morning above). Every battery_temp_c stored 2026-09-13..28 was that byte; CarDb v23 clears them, first copying their “OBD2 was connected” meaning into energy_measured.

The reader writes a logcat warning (tag DriveMem) outside -30..70 °C; that exposes a bad response or scaling change without concealing diagnostic evidence.