안드로이드 8.0의 혁신 HIDL 이란? .hal 소스코드로 배우는 Binderized HAL 완벽 가이드

안드로이드 스마트폰 제조사(OEM)에서 시스템 소프트웨어를 개발하다 보면, "OS 버전 하나 올리기가 왜 이렇게 힘들까?"라는 탄식이 절로 나오곤 했습니다. 과거에는 새 안드로이드 순정 소스(AOSP)가 나오면 제조사가 만들어 둔 하드웨어 드라이버와 HAL(Hardware Abstraction Layer) 코드를 프레임워크 내부에 일일이 다시 묶어서 컴파일해야 했기 때문입니다. 구글은 이 해묵은 파편화 문제를 해결하기 위해 안드로이드 8.0(Oreo)에서 프로젝트 트레블(Project Treble)이라는 거대한 아키텍처 공사를 단행했습니다.

그 핵심 무기가 바로 오늘 다룰 HIDL(HAL Interface Definition Language)입니다. OS 프레임워크와 하드웨어 드라이버 사이의 통신 규격을 인터페이스 언어로 명확히 정의하여 둘을 완전히 독립된 프로세스로 떼어내 버린 것인데요. 이번 포스팅에서는 HIDL이 왜 도입되었는지 그 배경을 알아보고, 실제 .hal 소스코드와 컴파일러가 만들어내는 코드 구조를 매핑해 가며 현대적인 안드로이드 HAL의 뼈대를 완벽하게 이해해 보겠습니다.

 

📌 핵심 요약 3줄

1. HIDL은 안드로이드 OS 프레임워크와 하드웨어 서브시스템(HAL) 간의 경계를 바인더(Binder) IPC 기반의 프로세스 독립 구조로 분리하기 위해 도입된 인터페이스 정의 언어입니다.
2. .hal 파일에 메서드를 선언한 뒤 구글 표준 툴인 hidl-gen을 가동하면, IPC 통신에 필요한 C++ 뼈대 코드(Stub/Proxy)가 자동으로 빌드 파이프라인에서 생성됩니다.
3. HIDL 도입 덕분에 벤더 제조사는 상위 안드로이드 버전이 업그레이드되더라도 하위의 하드웨어 제어 레이어 코드를 수정 없이 그대로 재사용할 수 있는 유연성을 얻었습니다.

---

1. 프로젝트 트레블과 HIDL의 필요성

기존의 전통적인 레거시 HAL 구조에서는 프레임워크 프로세스(system_server)가 벤더의 공유 라이브러리(.so)를 메모리에 직접 올려 썼습니다. 이러다 보니 구글이 프레임워크를 업데이트하면 벤더 사의 HAL 라이브러리도 링크 에러가 나거나 오동작하여 통째로 다시 빌드해야 했습니다.

HIDL은 이 강한 결합을 끊어내고 프레임워크와 HAL을 각각 별도의 방(독립된 프로세스)에 가두어 둔 뒤, 문틈으로 바인더(Binder) 메시지만 주고받도록 체질을 개선했습니다.

---

2. HIDL 아키텍처 및 빌드 컴파일 메커니즘

개발자가 인터페이스 정의서 파일인 .hal을 작성하면, AOSP 빌드 시스템은 내부적으로 hidl-gen이라는 전용 도구를 실행합니다. 이 컴파일러가 유저가 작성한 명세서를 해석하여 바인더 통신용 C++ 소스코드를 양방향으로 뚝딱 만들어 주는데요. 그 생성 관계를 표로 정리했습니다.

생성되는 파일 클래스 성격	가동되는 위치 및 역할 범위	개발자가 해야 할 작업 내용
IExample.h (인터페이스)	클라이언트와 서버 공통 활용 규격 헤더	hidl-gen 툴체인이 규격서를 기반으로 자동 생성 (수정 금지)
BpExample.h (Proxy 단)	프레임워크(Client) 스페이스 공간에 상주	상위 자바/네이티브 서비스가 보낸 요청을 바인더 패킷으로 포장
BnExample.h (Stub 단)	벤더 HAL(Server) 프로세스 공간에 상주	바인더 통로에서 전달된 패킷을 뜯어 실제 하드웨어 함수로 연결
Example.cpp (구현체)	벤더 HAL 서버 내부 실제 로직 공간	★ 개발자가 직접 코딩하는 영역으로 하드웨어 드라이버 제어 코드를 채움

---

3. AOSP 코드 예제로 보는 HIDL 파이프라인

그럼 실제 코드 구성을 보며 클라이언트와 서버가 어떻게 맞물려 돌아가는지 단계별로 살펴보겠습니다.

3.1 인터페이스 규격 선언 (IExample.hal)

먼저 하드웨어 벤더 영역에서 상위 프레임워크에게 "우리 장치는 이러한 원격 함수를 지원합니다"라고 명세서를 배포합니다.

코드 스니펫

 

// hardware/interfaces/example/1.0/IExample.hal
package android.hardware.example@1.0;

interface IExample {
    // 프레임워크가 호출하면 문자열을 바인더 채널로 던져주는 원격 메서드
    helloWorld() generates (string response);
};

3.2 벤더 단의 실체 구현 클래스 (Example.cpp)

자동 생성된 베이스 인터페이스 클래스를 구현(Override)하여 실제 비즈니스 로직을 서술합니다.

C++

 

#include <android/hardware/example/1.0/IExample.h>

using android::hardware::example::V1_0::IExample;
using android::hardware::Return;

// hidl-gen이 만들어준 추상 클래스를 상속받습니다.
struct Example : public IExample {
    // 가상 함수를 재정의하여 실제 수행할 물리 기능을 코딩합니다.
    Return<std::string> helloWorld() override {
        // 실제 임베디드 장치라면 여기서 드라이버 데이터를 포맷팅합니다.
        return std::string("Hello from HIDL Binderized Service!");
    }
};

3.3 백그라운드 서버 가동 및 데몬 등록 (service.cpp)

독립된 프로세스로 구동되기 위해 main 함수를 만들고, 안드로이드 바인더 서비스 관리자(hwservicemanager)에 자신을 정식 서비스로 등록합니다.

C++

 

#include <hidl/HidlTransportSupport.h>
#include <android/hardware/example/1.0/IExample.h>
#include "Example.h"

using android::hardware::configureRpcThreadpool;
using android::hardware::joinRpcThreadpool;

int main() {
    // 1. 하드웨어 제어 인스턴스 동적 메모리 할당 (강성 포인터 `sp` 활용)
    android::sp<IExample> service = new Example();
    
    // 2. 바인더 통신을 처리할 전용 스레드 풀 개수 설정 (여기서는 1개)
    configureRpcThreadpool(1, true);
    
    // 3. hwservicemanager에 이 서비스를 시스템 공식 등록
    if (service->registerAsService() != android::OK) {
        return 1; // 등록 실패 시 에러 리턴
    }
    
    // 4. 메인 스레드가 대기 상태로 진입하며 들어오는 바인더 IPC 요청을 무한 루프로 대기
    joinRpcThreadpool();
    return 0;
}

3.4 상위 프레임워크 단에서의 호출 (Client 단)

이제 준비가 끝났습니다. 프레임워크 영역의 C++ 네이티브 데몬이나 시스템 서비스에서는 다음과 같이 싱글톤 스타일로 원격지의 HAL 프로세스를 찾아와 함수를 그냥 로컬 함수 쓰듯 호출합니다.

C++

 

#include <android/hardware/example/1.0/IExample.h>
#include <iostream>

using android::hardware::example::V1_0::IExample;

void callHidlService() {
    // 바인더 네임 서버(hwservicemanager)를 호출해 켜져 있는 HAL 주소를 획득합니다.
    android::sp<IExample> service = IExample::getService();
    
    if (service == nullptr) {
        std::cerr << "HIDL 서비스를 찾을 수 없습니다!" << std::endl;
        return;
    }
    
    // 프로세스 경계를 넘어 저 멀리 백그라운드에 떠 있는 HAL 함수가 실행되고 결과가 돌아옵니다.
    std::string response = service->helloWorld();
    std::cout << "HAL 프로세스로부터 수신한 페이로드 데이터: " << response << std::endl;
}

---

4. HIDL과 AIDL HAL의 차이점 점검

최신 안드로이드 버전으로 가면서 구글은 플랫폼 내부 인터페이스 정의 언어의 파편화를 한 번 더 다듬었습니다. 앱 영역에서 쓰던 AIDL을 하드웨어 영역까지 이식한 것인데요. 두 기술의 결을 명확히 대조해 드립니다.

기술 비교 키워드	HIDL (Hardware Interface Definition Language)	AIDL 기반 HAL (최신 안드로이드 아키텍처)
최초 도입 시점	안드로이드 8.0 (Project Treble 핵심 아키텍처)	안드로이드 11부터 전면 도입 및 권장 기술 지정
네임 서버 관리자	hwservicemanager가 독립 운영됨	통합 servicemanager가 일반 서비스와 HAL을 일괄 관리
빌드 스크립트 도구	Android.bp 내부에 hidl_interface 정의 사용	cc_aidl_library 및 aidl_interface 빌드 모듈 구조 사용
데이터 타입 유연성	vec<T>, string 등 C++ 레이아웃 지향적 타입 구성	자바 및 C++ 언어 양단을 완전히 커버하는 공통 추상 타입
구글 가이드 동향	빌드 인프라가 레거시로 분류되어 동결 추세	향후 신규 추가되는 모든 표준 HAL은 AIDL 작성이 대원칙

---

💡 HIDL 시스템 개발을 위한 실전 팁

1. VINTF 매니페스트(manifest.xml) 파일의 엄격한 선언: HIDL 서비스를 코딩하고 registerAsService()를 정상 실행했더라도, 장치의 vendor/etc/vintf/manifest.xml 설정 파일에 내가 추가한 인터페이스 패키지명과 버전, 인스턴스 네임(default)을 정확하게 서술해 주지 않으면 안드로이드 프레임워크가 안전 보장 확인(VINTF 검증) 단계에서 이 HAL의 접근 권한을 완전히 차단해 버립니다. 새 모듈을 올릴 때는 반드시 매니페스트 XML 명세서 수정 단계를 세트로 묶어서 기억하셔야 합니다.
2. 동기식 연산과 비동기식 콜백 인터페이스의 명확한 설계: 하드웨어 연산 중 시간이 수백 밀리초 이상 걸리는 무거운 작업(예: 센서 데이터 캘리브레이션, 모터 정밀 보정 등)을 HIDL 일반 메서드로 선언하면, 상위 프레임워크 스레드가 응답이 올 때까지 바인더 블로킹 상태에 빠져 시스템 전체가 버벅대거나 ANR(App Not Responding) 에러를 뿜을 수 있습니다. 시간이 걸리는 기능은 처리가 시작되면 즉시 성공 플래그만 먼저 리턴하고, 연산이 끝났을 때 벤더 프로세스가 프레임워크가 전달해 준 콜백 인터페이스(IExampleCallback)를 역으로 호출(Fire)하여 데이터를 밀어 올려주도록 비동기 파이프라인을 설계해야 안전합니다.

⚠️ 흔히 하는 실수

1. 바인더 스레드 풀(joinRpcThreadpool) 배치 오류로 인한 프로세스 좀비화: HIDL 서비스의 main() 함수에서 configureRpcThreadpool(1, true);만 덜렁 선언해 두고 하단에 joinRpcThreadpool(); 컨텍스트 블로킹 호출을 누락하여 프로세스가 곧바로 종료되어 버리는 코딩 실수가 종종 발생합니다. 메인 스레드가 바인더의 신호를 수신할 수 있도록 통로를 열어두고 대기선에 묶어두는 작업을 빼먹으면 서비스 데몬이 켜지자마자 죽어버려 프레임워크 단에서 널 포인터 크래시를 마주하게 됩니다.
2. 패키지 경로 및 디렉토리 구조 불일치로 인한 컴파일 컴파일러 터짐: HIDL 컴파일러(hidl-gen)는 소스 파일이 위치한 디렉토리의 실제 물리 경로와 파일 내부 상단에 적힌 package android.hardware.example@1.0; 선언문 명칭의 일치 여부를 대단히 엄격하게 검증합니다. 폴더 구조의 이름이 패키지 뎁스 구조와 단 한 글자라도 매칭되지 않거나 오타가 나면 빌드 타임에 추적하기 까다로운 스크립트 파싱 에러를 내뱉으므로, 디렉토리 트리 구조를 설계할 때 항상 패키지 명명 규칙 표준 가이드라인을 칼같이 지켜야 시간 낭비를 막을 수 있습니다.

---

5. 결론

HIDL은 안드로이드 역사상 가장 복잡하고 거대했던 아키텍처 개편인 '프로젝트 트레블'을 이끈 핵심 공신입니다. 비록 현재는 시스템 인터페이스 단일화를 위해 한 단계 더 진화한 AIDL HAL 구조로 헤게모니가 점차 넘어가고 있는 과기주의 단계이지만, 현재 양산 중인 대다수의 안드로이드 소스코드 하단 기저에는 수많은 HIDL 모듈들이 여전히 중추 역할을 수행하고 있습니다. 그렇기 때문에 이 통신 메커니즘을 명확히 이해하는 것은 유능한 플랫폼 개발자가 되기 위한 필수 통과 의례와도 같습니다.