2026년부터 트렁크 안정 개발 모델과 일치하고 생태계의 플랫폼 안정성을 보장하기 위해 2분기와 4분기에 AOSP에 소스 코드를 게시합니다. AOSP를 빌드하고 기여하려면 android-latest-release를 사용하세요. android-latest-release 매니페스트 브랜치는 항상 AOSP에 푸시된 최신 버전을 참조합니다. 자세한 내용은 AOSP 변경사항을 참고하세요.

Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

구성 개요

AOSP는 기기에 구성 정보를 저장하는 다음과 같은 옵션을 제공합니다.

시스템 속성
초기 부팅 기기 구성
하드웨어 추상화 계층(HAL) 속성
시스템 구성 XML 파일
리소스 오버레이(정적 및 런타임)

시스템 속성

시스템 속성은 build.prop 전역 사전에 저장된 문자열 키-값 쌍입니다. 시스템 속성은 사용하기 쉽고 성능 오버헤드가 낮은 시스템 전체 리소스입니다. 시스템 속성을 사용하면 시스템 속성이 여러 프로세스에서 공유되는 경우에도 프로세스 간 통신(IPC)을 사용할 필요가 없습니다. 그러나 시스템 속성은 전역 변수와 유사하며 잘못 사용하면 위험할 수 있습니다. 시스템 속성을 잘못 사용하면 보안이 취약해지거나 사용자가 앱에 액세스할 수 없게 되는 등의 문제가 발생할 수 있습니다. 시스템 속성을 사용하여 구성 정보를 저장하기 전에 다른 구성 옵션을 고려하세요.

시스템 속성에 관한 자세한 내용은 시스템 속성 추가를 참고하세요.

초기 부팅 기기 구성

Android 17 이상에서 init_dev_config 서비스는 기기 구성 및 시스템 속성 초기화를 지원합니다. 이 동적 아키텍처 메커니즘은 초기 부팅 시 자동으로 실행됩니다.

단일 시스템 또는 공급업체 이미지가 여러 하드웨어 변형을 지원해야 하는 경우 구성 값을 빌드 시 항상 하드코딩할 수는 없습니다. init_dev_config 서비스는 apexd-bootstrap 바로 전 early-init 단계에서 실행되므로 공급업체는 하드웨어 상태 (예: 부트로더 인수, 일찍 마운트된 파티션 또는 하드웨어 구성 테이블)를 검사하고 종속 서비스와 라이브러리가 초기화되기 전에 시스템 속성을 동적으로 초기화할 수 있습니다.

서비스 통합 및 수명 주기

init_dev_config 서비스는 시스템 init.rc에 기본적으로 정의되며 apexd-bootstrap 전에 early-init 중에 동기적으로 실행됩니다. 통합자는 새 init 서비스를 선언할 필요가 없습니다.

대신 기존 서비스는 실행 파일 경로에서 속성 확장을 사용하여 시스템 서비스 선언을 공급업체 바이너리에서 분리합니다. 통합자는 ro.vendor.init_dev_config.path 속성을 사용하여 공급업체 바이너리 경로를 지정하고 필수 SELinux 라벨과 권한으로 구성합니다.

공급업체 구현 요구사항

init_dev_config와 통합하려면 다음 단계를 따르세요.

PRODUCT_VENDOR_PROPERTIES를 사용하여 빌드 시간에 공급업체 바이너리 경로를 구성합니다. 제공된 바이너리 경로는 시스템에 설치된 바이너리의 유효한 경로여야 합니다.
```
PRODUCT_VENDOR_PROPERTIES += \
    ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
```
이 속성이 설정되지 않으면 init은 서비스 실행을 건너뛰고 부팅이 정상적으로 계속됩니다.
서비스는 apexd-bootstrap 전에 실행되므로 APEX에서 제공하는 전체 bionic 라이브러리는 아직 사용할 수 없습니다. Android.bp에서 bootstrap: true를 설정합니다.
```
rust_binary {
    name: "init_dev_config",
    vendor: true,
    srcs: ["src/main.rs"],
    rustlibs: [
        "librustutils",
    ],
    bootstrap: true,
}
```

하드웨어 변형을 감지하고 적절한 시스템 속성을 설정하는 서비스 로직을 작성합니다.

use rustutils::system_properties;

fn main() {
    let hw_sku = read_hardware_sku();

    // Dynamically initialize vendor-specific properties:
    let display_type = match hw_sku {
        1 => "oled",
        _ => "lcd",
    };
    system_properties::write("vendor.display.panel_type", display_type)
        .expect("Failed to set vendor display property");
}

init_dev_config_exec로 공급업체 바이너리에 라벨을 지정합니다.
```
 /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0
```
필수 속성 유형을 설정할 수 있도록 init_dev_config 도메인 권한을 부여합니다.
```
 set_prop(init_dev_config, vendor_my_sku_prop)
```

APEX 활성화 및 사용 중지에 init_dev_config를 사용하는 방법에 관한 자세한 내용은 부팅 시 공급업체 APEX 선택을 참고하세요.

HAL 속성

구성의 정보 소스가 기기의 하드웨어 구성요소에서 비롯된 경우 하드웨어의 HAL은 해당 구성요소의 정보를 제공해야 합니다. 구성에 액세스하기 위해 기존 HAL에서 새 HAL 메서드를 정의합니다. HAL 개발에 관한 자세한 내용은 HAL용 AIDL을 참고하세요.

시스템 구성 XML 파일

구성 데이터가 정적이지만 복잡한 경우(구조화된 경우) 구성 데이터에 XML이나 기타 유사한 형식을 사용하는 것이 좋습니다. 파일 스키마가 안정적으로 유지되는지 확인합니다. XML 파일의 경우 xsd_config를 사용하여 스키마를 안정적으로 유지하고 자동 생성된 XML 파서를 활용할 수 있습니다.

리소스 오버레이

리소스 오버레이를 사용하여 제품을 맞춤설정할 수 있습니다. 리소스 오버레이에는 두 가지 유형이 있습니다.

표준 리소스 오버레이: 빌드 시간에 제품을 맞춤설정하는 데 사용됩니다. 표준 리소스 오버레이에 관한 자세한 내용은 리소스 오버레이로 빌드 맞춤설정을 참고하세요.
런타임 리소스 오버레이(RRO): 런타임에 타겟 패키지의 리소스 값을 변경하는 데 사용됩니다. 예를 들어 시스템 이미지에 설치된 앱은 리소스 값에 따라 동작을 변경할 수 있습니다. 빌드 시간에 리소스 값을 하드코딩하는 대신 다른 파티션에 설치된 RRO가 런타임에 앱의 리소스 값을 변경할 수 있습니다. RRO에 관한 자세한 내용은 런타임에 앱 리소스의 값 변경을 참고하세요.