HAL은 커널 드라이버 파일의 다른 이름이 아닙니다
- Framework의 요청
정해진 HAL 인터페이스의 메서드를 호출합니다.
Binder를 통한 IPC 또는 해당 구현 방식의 호출
- HAL 서비스
요청을 검사하고 장치별 처리 방법으로 바꿉니다.
open·read·ioctl 등 해당 드라이버의 UAPI 사용
- Linux 드라이버
장치의 레지스터·인터럽트·버퍼를 관리합니다.
하드웨어 프로토콜에 맞춰 접근
- 센서
측정 결과나 상태를 제공합니다.
화살표는 요청이 전달되는 관계입니다. 모든 HAL이 직접 장치 파일을 열거나 모든 서비스가 같은 프로세스에서 실행되는 것은 아닙니다.
구형 hw_module_t 예제, HIDL 예제, AIDL HAL 예제는 서로 다른 인터페이스 세대입니다. 기존 보드에 어느 경로가 남아 있는지 확인한 뒤 읽어야 합니다. AIDL을 쓰는 것만으로 임의의 vendor·system 조합이 자동 호환되는 것은 아닙니다. AIDL HAL
제공하는 인터페이스와 요구하는 인터페이스를 맞춥니다
VINTF의 manifest는 기기나 framework가 제공하는 인터페이스를 기술하고, compatibility matrix는 상대 쪽에 요구하는 조건을 기술합니다. 실제 서비스의 등록 이름·instance·버전과 선언이 맞아야 합니다. 파일 하나에 이름을 적었다고 서비스 프로세스가 자동으로 만들어지는 것은 아닙니다.
| 확인 단계 | 확인하는 사실 |
|---|---|
| 인터페이스 정의 | 메서드·타입·안정성 규칙과 버전을 확인합니다. |
| 빌드 | 구현 바이너리·의존 라이브러리·설정 파일이 제품 이미지에 들어갔는지 확인합니다. |
| init 서비스 | 서비스가 어떤 사용자·그룹·class로 시작되는지 확인합니다. |
| VINTF 선언 | 제공·요구하는 HAL과 실제 instance 이름을 비교합니다. |
| SELinux와 장치 권한 | 서비스가 등록·검색·장치 접근을 할 권한이 있는지 확인합니다. |
property 값은 환경 변수와 다르게 관리됩니다
Android property는 시스템의 property 서비스를 통해 관리하는 이름·값 체계입니다. 프로세스의 shell 환경 변수를 바꾸는 것과 다릅니다. 내부 값은 문자열로 저장하지만 property_contexts에서 타입과 보안 문맥을 지정할 수 있습니다. 어떤 프로세스가 읽거나 쓸 수 있는지는 정책으로 제한합니다. property 이름·타입·접근 규칙
getprop vendor.demo.mode
getprop ro.boot.verifiedbootstate첫 이름은 설명용으로 만든 property이며 실제 제품에 반드시 존재하지 않습니다. 두 번째는 부팅 시 전달된 verified boot 상태를 확인하는 데 쓰입니다. getprop는 값을 읽는 명령입니다. 값이 있다고 해서 이를 읽는 서비스가 존재하거나 그 서비스가 변경을 실시간 반영한다는 보장은 없습니다.
| 접두사 또는 파일 | 역할 |
|---|---|
ro. | 일반적으로 한 번 설정한 뒤 다시 쓰지 않는 property 규칙과 관련됩니다. 보안 비밀을 저장하라는 뜻은 아닙니다. |
persist. | 재부팅 뒤에도 유지할 값인지와 관련됩니다. 이름만 붙이면 모든 부팅 시점에 읽을 수 있는 것은 아닙니다. |
vendor. / persist.vendor. | vendor가 소유하는 property 이름 공간을 나타냅니다. 접근 허가를 자동으로 부여하는 접두사는 아닙니다. |
property_contexts | 이름을 SELinux property type과 값 타입에 대응시킵니다. rc의 서비스 시작 조건과는 다른 정보입니다. |
권한 오류를 먼저 숨기면 원인을 잃습니다
장치를 열지 못한다면 장치 노드가 만들어졌는지, Unix 소유자·그룹·모드가 맞는지, SELinux가 어느 접근을 거부했는지 차례로 확인합니다. 권한을 넓히거나 SELinux를 끄면 특정 현상이 사라질 수 있지만 제품의 올바른 권한 설계를 확인한 결과는 아닙니다.
Property를 바꿨는데 동작이 달라지지 않으면 값을 설정한 주체의 권한, property의 실제 값, 이를 읽는 코드와 읽는 시점을 각각 확인합니다. 서비스가 시작 때 한 번만 읽는 값이라면 property 변경만으로 실행 중인 상태가 바뀌지 않을 수 있습니다. SELinux 구현과 정책 확인
UWB 메시지를 전달해도 측정 가능한 상태라는 뜻은 아닙니다
UWB는 HAL 인터페이스와 서비스 상태를 구별해야 하는 사례입니다. AOSP UWB HAL 설명의 UCI 메시지 전달과 앱에 알리는 사용 가능 상태는 같은 결과가 아닙니다. 아래 코드는 Android android-16.0.0_r1의 고정 소스를 기준으로 합니다. 다른 릴리스나 vendor 구현에 같은 분기 순서를 가정하지 않습니다.
hardware/interfaces 커밋 5688f7eb1e11의 안정 AIDL 인터페이스 IUwbChip.aidl에서 sendUciMessage()는 UCI 바이트열을 전달하고 쓴 바이트 수를 반환합니다. 큐에 넣고 바로 반환하거나 쓰기가 끝날 때까지 기다릴 수 있지만 쓰기 순서는 보장해야 합니다. 반환값을 거리 측정 성공으로 해석하지 않습니다. IUwbClientCallback.aidl의 onUciMessage()는 응답·알림을 전달하며, onHalEvent()는 별도 비동기 이벤트와 상태를 전달합니다.
| 관측한 것 | 소스가 말하는 범위 | 단정하면 안 되는 것 |
|---|---|---|
| UCI 바이트 전송 | HAL을 통해 메시지가 전달되는 계약입니다. | ranging 세션의 시작·성공·거리 정확도 |
장치의 DEVICE_STATE_READY | 기본 변환은 STATE_ENABLED_INACTIVE입니다. 국가 코드 처리 뒤 앱에 알릴 상태를 다시 계산합니다. | 앱에 항상 enabled가 통지된다는 결론 |
SYSTEM_REGULATION | 상태 변경의 이유입니다. 국가 코드 무효 또는 지정된 규제 오류 조건에서 설정됩니다. | 별도의 adapter 상태 값 또는 모든 오류의 공통 원인 |
국가 코드와 공개 상태 사이에는 조건 분기가 있습니다
Uwb 모듈 커밋 adcc2fe7aada의 UwbServiceCore.java에서 computeAdapterState()는 앞의 하드웨어 유휴 특례를 제외한 경로에서 국가 코드가 유효하지 않거나, 전달된 설정 결과가 STATUS_CODE_OK가 아니면 STATE_DISABLED를 반환합니다. 내부 장치 상태가 READY여도 이 결과가 가능합니다. 국가 코드가 유효하다는 사실만으로 꺼진 장치를 켜거나 모든 다른 조건을 만족시키지는 않습니다.
앞선 예외 분기를 빼면 설명이 달라집니다. 이 버전은 내부 상태가 disabled이고 enable 요청은 유지되지만 하드웨어 활성화 요청이 없는 조건을 먼저 검사합니다. 여기에 해당하면 국가 코드 검사보다 앞에서 STATE_ENABLED_HW_IDLE을 반환합니다. 따라서 “국가 코드가 무효이면 모든 경로에서 반드시 disabled”라고 일반화하지 않습니다.
computeAndNotifyAdapterStateChange()는 국가 코드가 무효이거나 설정 결과가 STATUS_CODE_ANDROID_REGULATION_UWB_OFF일 때 이유를 SYSTEM_REGULATION으로 바꿉니다. 다른 non-OK 설정 결과도 일반 경로에서 disabled를 만들 수 있지만 이유까지 모두 규제로 바꾸는 것은 아닙니다. UwbCountryCode.java는 선택할 코드가 없으면 00으로 대체하고 native 설정 결과를 전달합니다. 해당 버전의 isValid()는 null·길이·문자·00 여부를 검사할 뿐, 국가별 전파 사용 허가를 판정하는 법률 목록은 아닙니다.
이 절은 공개 AIDL·서비스 소스의 의미를 비교한 것입니다. FiRa 회원 전용 규격 열람, 국가 코드 강제 변경, 실제 UWB 측정 또는 규제 적합성 인증을 수행한 결과가 아닙니다.
English: transport, adapter state and reason
UCI transport is not proof of successful ranging. In the pinned service, device READY normally maps to enabled-inactive, but the ordinary active-hardware path reports disabled for an invalid country code or a provided non-OK configuration result. An earlier hardware-idle branch remains an explicit exception. SYSTEM_REGULATION is a reason, not an adapter state; other failures need not have that reason. Source checks do not establish device performance or regulatory approval.
APF는 규칙을 만드는 CPU와 실행하는 Wi-Fi 펌웨어를 나눕니다
Android Packet Filter(APF)는 HAL을 통해 장치 쪽 실행 로직을 갱신하는 사례입니다. 메인 CPU의 Network Stack은 네트워크·기기 상태에 맞춰 APF 바이트코드를 생성하고, Wi-Fi HAL은 프로그램 설치와 카운터 읽기를 연결합니다. 수신 패킷마다 바이트코드를 실행하는 인터프리터는 Wi-Fi 칩셋 펌웨어에 있습니다. 호스트 드라이버에서 같은 필터를 실행하면 이미 CPU를 깨워야 하므로 이 오프로딩의 전력 절감 근거가 달라집니다.
AOSP APF 문서는 APFv4를 필터링·카운터 기능으로, APFv6를 여기에 패킷 송신을 더한 버전으로 설명합니다. 지원 펌웨어에서는 ARP·NS 요청에 응답하는 규칙을 만들 수 있습니다. Android 버전만 보고 모든 칩셋에 APFv6가 있다고 가정하지 않으며, Linux eBPF와 같은 명령어 집합·실행 위치라는 뜻도 아닙니다.
| 관측 지점 | 뜻하는 것 | 입증하지 않는 것 |
|---|---|---|
apf_run() == 0 | 받은 패킷을 앱 프로세서로 넘기지 않습니다. 폐기 또는 응답을 생성한 경로일 수 있습니다. | 응답이 실제 무선 링크로 전송되거나 상대에게 수신됐다는 증거 |
apf_run() != 0 | 받은 패킷을 호스트로 전달할 판정입니다. | 모든 검사가 정상 종료됐다는 뜻 |
apf_transmit_buffer() == 0 | 펌웨어가 송신에 성공했거나 성공할 것으로 판단한 결과입니다. 실제 송신은 비동기일 수 있습니다. | 상대 수신·응답 완료 또는 무선 품질 보장 |
고정 커밋 7b2fa9e7773b2d6a56ac6ff63e402d984885610a의 v6 인터페이스와 구현을 대조하면, 정상 통과 값은 1이고 진입 인자의 정렬·길이 등에 문제가 있으면 2를 반환할 수 있습니다. 내부 프로그램 실행 중의 예외는 바깥 실행 래퍼에서 통과 값으로 바꾸는 경로도 있습니다. 따라서 nonzero를 모두 “오류 없는 정상 필터 판정”으로 분류하지 않습니다. 송신 콜백 오류·카운터·입력 조건도 함께 구분해야 합니다.
통합 조건에는 헤더만이 아닌 전체 패킷 전달, APF 전용 메모리 보존, HAL을 통한 프로그램 갱신이 포함됩니다. vendor 필터가 APF보다 먼저 패킷을 버리면 APF는 그 패킷을 관측하지 못합니다. APF 카운터만으로 모든 수신 트래픽을 복원하거나 일정한 절전 비율을 계산하면 안 됩니다. 여기서는 펌웨어·필터를 설치하거나 CTS·실기 전력 측정을 수행하지 않았습니다.
English: filter decision is not transmit completion
The host generates APF rules and installs them through the Wi-Fi HAL; firmware interprets incoming packets. APFv6 adds transmission support. A zero apf_run result suppresses host delivery of the received packet, but does not prove successful response transmission. The transmit callback may be asynchronous. The pinned interpreter can pass packets on errors; counters, integration faults and transmit outcomes remain separate observations. No device settings or firmware were changed.