ANDROID AUTOMOTIVE · VHAL

앱이 읽는 차량 속성의 경계

공조 값을 읽는 앱이 ECU 레지스터를 직접 읽는 것은 아닙니다. 속성 구성, 접근 권한, 값의 상태와 실제 전송을 나눕니다.

비동기 VHAL과 앱 API의 호출 성격을 구분합니다

앱은 CarPropertyManager로 속성을 읽거나 이벤트를 구독하고 Car Service를 통해 VHAL과 연결됩니다. AIDL VHAL의 getValues·setValues는 결과를 콜백으로 전달합니다. 함수가 반환됐다고 실제 읽기·설정이 끝난 것은 아닙니다. 반면 앱의 동기 getProperty는 오래 걸릴 수 있어 메인 스레드에서 호출하지 않도록 안내됩니다.

앱 CarPropertyManager, Car Service, Vehicle HAL, 제조사 전송과 ECU를 구분한 책임 경계. VHAL 결과와 이벤트는 콜백으로 돌아옴.
한 스레드의 동기 호출 스택이 아닌 책임 경계입니다.

Android 13부터의 AIDL VHAL과 기존 HIDL 구현을 구분해 실제 제품의 Android·HAL 버전을 기록합니다. 최신 API가 권장하는 subscribePropertyEvents와 구형 registerCallback 예시도 대상 API 버전에 맞춰 읽습니다.

참조 구현의 DefaultVehicleHal은 IVehicleHardware와 분리됩니다. FakeVehicleHardware는 메모리 맵에 값을 저장하는 시험용 구현으로, 실제 차량 버스를 사용하지 않습니다. 이를 모든 차량의 캐시나 ECU 데이터 경로로 일반화하지 않습니다.

속성 ID만으로 권한과 유효성을 알 수 없습니다

VehiclePropConfig에는 타입, 영역, 접근·변경 모드 등이 있습니다. STATIC, ON_CHANGE, CONTINUOUS를 구분하고 CONTINUOUS의 구독 주기와 variable update rate 지원도 해당 버전에서 확인합니다. 모든 신호가 값이 바뀔 때만 보고되는 것은 아닙니다.

VehiclePropValue의 prop, areaId, timestamp, status를 값과 함께 봅니다. 읽기 상태가 AVAILABLE이 아니면 값 필드를 사용하지 않습니다. 읽기 상태가 AVAILABLE이어도 쓸 수 있다는 보장은 없으므로 설정 결과·오류를 따로 확인합니다.

공조 예시에서는 제품이 지원하는 HVAC 속성과 영역 ID, 읽기·쓰기 권한을 확인합니다. setFanSpeed(50)이나 /dev/hvac0을 보편적인 표준 AAOS API처럼 소개하지 않습니다. 제조사 전용 속성도 구성과 접근 제어를 따로 확인해야 합니다.

Android 시스템 property의 ro.*·persist.*와 getprop는 다른 체계입니다. 이름에 property가 들어간다고 해서 CarPropertyManager와 같은 저장소·API인 것은 아닙니다.

SOME/IP·CAN·직접 장치 접근은 제조사 구현을 봅니다

AOSP의 SDV SOME/IP 통합 안내는 파트너 스택과 COVESA vsomeip 구현을 모두 허용합니다. 특정 차량 속성이 원격 서비스·인스턴스·이벤트에 어떻게 대응하는지는 제조사 코드와 설정에서 찾아야 합니다. 이 SDV 경로가 모든 기존 VHAL의 필수 구성은 아닙니다.

COVESA의 기본 라우팅 설명에서는 별도 설정이 없으면 처음 실행된 vsomeip 앱이 routing manager를 시작합니다. libvsomeip3.so와 별도 routingmanagerd 프로세스를 모든 AAOS 제품의 필수 단계로 그리지 않습니다.

CAN 전송이나 SocketCAN, 특정 poll/select·ioctl 조합 역시 실제 backend에서 확인할 후보이지 VHAL 계약 자체가 아닙니다. 원격 ECU 레지스터가 앱의 Java 객체와 하나의 커널 페이지 테이블로 곧바로 연결되는 것도 아닙니다. 특정 드라이버의 mmap이나 카메라 DMA-BUF 설명을 공조 속성의 보편 경로에 끼워 넣지 않습니다.

지원 목록에서 실제 결과까지 따라갑니다

  1. Android 버전과 AIDL/HIDL backend, 지원하는 속성·영역·타입을 확인합니다.
  2. 접근 권한 오류와 가용 상태, 읽기 결과와 쓰기 결과를 구분합니다.
  3. 구독 설정, VHAL 콜백과 오류가 어느 요청에 대응하는지 확인합니다.
  4. 차량 속성이 제조사 전송 계층의 어느 신호나 서비스에 대응하는지 추적합니다.
  5. 발생 시각과 수신 시각의 시계 기준을 맞춰 비교합니다. 앱 콜백만으로 ECU 제어 성공이나 전체 지연을 단정하지 않습니다.

출발점은 Sairamkrishna Mammahe의 SOME/IP, VHAL–kernel, class–hardware 게시물입니다. 도식은 자체 작성했으며 실제 차량 제어·버스 송신·HAL 실행은 하지 않았습니다. 영상은 별도 EVS·Camera2 경로에서 다룹니다.

English summary. Vehicle properties have typed configuration, areas, access rules and availability. AIDL VHAL results are asynchronous; app APIs may have different blocking behavior. Android system properties and OEM CAN/SOME/IP transport are distinct layers, not one universal register-access chain.