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

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

SDV의 서비스 품질 일정

SDV 서비스 품질 (QoS) 일정 관리 프레임워크는 수명 주기 관리자 (LM)가 관리하는 서비스 번들에 결정적인 CPU 리소스 할당을 제공합니다. 하위 수준 Linux 일정 관리 속성 (정책, 우선순위, Nice)을 논리적 사전 설정으로 추상화하여 플랫폼은 서비스 개발과 차량 전체 시스템 조정 간의 명확한 분리를 지원합니다. 이를 통해 시스템이 불안정성을 방지하기 위해 백그라운드 작업을 제한하는 동안 안전에 중요한 시간 민감성 워크로드에 필요한 컴퓨팅 대역폭을 제공할 수 있습니다.

역할 및 책임

SDV 일정 모델은 위임된 책임 패턴을 따라 서비스가 휴대 가능하도록 유지하면서 OEM이 시스템을 조정할 수 있도록 지원합니다.

역할	책임	주요 결과물
SDV 플랫폼 (Google)	`sdv_service_bundles_scheduling.proto` 스키마를 정의하고, LM 시행 로직을 구현하고, `sdv_service_bundles_scheduling` 클라이언트 라이브러리를 제공합니다.	Protobuf 정의 및 플랫폼 라이브러리
OEM (시스템 통합업체)	특정 하드웨어에서 `ELEVATED`가 무엇을 의미하는지와 같은 각 사전 설정의 구체적인 값을 정의하고 시스템 전체 구성을 제어합니다.	`/product/etc/lifecycle_config.textproto`
서비스 개발자	적절한 논리적 사전 설정 이름을 선택하고 서비스 번들 매니페스트에 `scheduling_config.textproto` 경로를 등록합니다.	`scheduling_config.textproto` 및 `sdv_service_bundles_manifest.textproto`

기술 워크플로

플랫폼 통합: OEM은 차량별 lifecycle_config.textproto를 정의합니다. 이 파일은 시스템 전체 일정 프로필 (사전 설정)을 설정하고 타겟 하드웨어에 따라 구체적인 Linux 일정 속성에 매핑합니다.
서비스 번들 개발: 개발자는 APEX 패키지 내에 scheduling_config.textproto을 번들로 묶고 논리적 사전 설정 (예: ELEVATED)을 추천하며 내부 스레드 이름을 정의합니다.
서비스 번들 통합: 차량 통합 단계에서 OEM은 개발자가 추천하는 사전 설정을 검토합니다. OEM은 권장 프로필을 유지하거나 ELEVATED 서비스를 NORMAL로 다운그레이드하는 등 프로필을 재정의하여 APEX에 서명하기 전에 전반적인 시스템 안정성을 개선할 수 있습니다.
런타임 속성 확인: 서비스가 시작되면 LM은 서비스의 매니페스트에서 승인된 사전 설정을 식별하고 OEM의 시스템 구성에서 해당 Linux 속성을 가져옵니다.
시작 동기화 및 적용: LM은 신호 및 계속 프로토콜을 사용하여 실행을 계속하도록 신호를 보내기 전에 해결된 속성을 서비스 프로세스에 적용합니다.

핵심 개념

다음 개념은 SDV 일정 프레임워크의 핵심입니다.

예약 사전 설정

일정 예약 사전 설정은 SDV에서 QoS를 관리하는 기본 메커니즘입니다. 개발자는 원시 Linux 예약 매개변수를 정의하는 대신 이름으로 사전 정의된 사전 설정을 참조합니다. 런타임에 LM은 이러한 논리적 이름을 구체적인 Linux 일정 속성에 매핑합니다.

다음은 lifecycle_config.textproto에서 예시로 구성된 사전 설정입니다.

미리 설정된 이름	일정 정책	일반적인 nice 값	일반적인 사용 사례
`NORMAL`	`SCHED_OTHER`	`0`	표준 서비스 (HVAC, 미디어, 설정)
`ELEVATED`	`SCHED_OTHER`	`-10`	핵심 시스템 구성요소 및 인프라
`IDLE`	`SCHED_IDLE`	`19`	백그라운드 분석 및 중요하지 않은 로깅
`CUSTOM`	사용자 정의	`-20` (초기)	실시간 정책 또는 선호도가 필요한 서비스

사전 설정을 적용할 때 LM은 setpriority 시스템 호출을 사용하여 프로세스 전체 nice 값을 설정합니다. 이는 기본 Linux 완전 공정 스케줄러 (CFS)에서 경합 중에 프로세스가 수신하는 상대 CPU 공유에 영향을 미칩니다.

권한 및 보안

무단 우선순위 에스컬레이션을 방지하기 위해 SDV 플랫폼은 SELinux 도메인과 Linux 기능을 기반으로 하는 계층화된 보안 모델을 사용합니다.

보안 도메인

untrusted_service_bundle: 표준 사전 설정 (NORMAL, ELEVATED, IDLE)의 기본 도메인입니다. 커널은 이 도메인의 프로세스를 제한하여 자체 일정 매개변수를 변경하지 못하도록 합니다.
priority_service_bundle: 시스템 전체 lifecycle_config.textproto에서 is_privileged: true이 설정된 사전 설정을 사용하는 서비스 번들에 부여됩니다. 이 도메인으로 전환하면 프로세스에 CAP_SYS_NICE 기능이 부여되어 자체 리소스 할당을 관리할 수 있습니다.

CAP_SYS_NICE 기능

플랫폼은 priority_service_bundle 도메인의 프로세스에 CAP_SYS_NICE 기능을 부여합니다. 이 권한을 통해 프로세스는 다음을 할 수 있습니다.

초기 할당을 넘어 자체 nice 값을 높입니다.
SCHED_FIFO 또는 SCHED_RR과 같은 실시간 클래스로 예약 정책을 변경합니다.
sched_setaffinity를 사용하여 CPU 어피니티를 설정합니다.
SCHED_DEADLINE의 전문 기한 매개변수를 구성합니다.

이 기능을 전용 도메인으로 제한하면 명시적으로 승인된 서비스에 대한 중단을 제한하여 시스템 전체의 일정 균형을 보호할 수 있습니다.

구성 가이드

이 섹션에서는 OEM과 서비스 개발자 모두를 위한 구성 안내를 제공합니다.

OEM 가이드: 시스템 전체 사전 설정

OEM은 /product/etc/lifecycle_config.textproto에서 일정 프로필을 정의합니다. 플랫폼은 OEM이 차량 하드웨어에 따라 조정해야 하는 lifecycle_management/config/lifecycle_config.textproto의 예를 제공합니다.

예: 실시간 사전 설정 정의

OEM은 표준 애플리케이션에 의해 선점되어서는 안 되는 안전 관련 서비스에 대해 CRITICAL 사전 설정을 정의할 수 있습니다.

# lifecycle_config.textproto
scheduling_presets {
  name: "CRITICAL"
  is_privileged: true
  thread_scheduling_configuration {
    policy: 1      # SCHED_FIFO
    priority: 80   # High real-time priority
  }
}

개발자 가이드: 서비스 번들 구성

서비스 개발자는 사전 설정을 권장하고 선택적으로 scheduling_config.textproto 파일에 논리 스레드 이름을 정의합니다. 플랫폼에서 검색하려면 이 파일의 경로가 sdv_service_bundles_manifest.textproto에 등록되어야 합니다.

예: 매니페스트 등록

# sdv_service_bundles_manifest.textproto
service_bundle_entries {
  name: "SensorService"
  scheduling_config_path: "configs/scheduling_config.textproto"
}

예: 표준 사전 설정 사용

대부분의 서비스의 경우 scheduling_config.textproto에서 미리 설정 이름을 참조하면 됩니다.

# configs/scheduling_config.textproto
scheduling_preset_name: "ELEVATED"

예: 서비스 생성 작업자 스레드 예약

서비스 개발자는 지연 시간이 짧은 센서 데이터 루프와 같은 특수 작업을 처리하기 위해 코드에 추가 작업자 스레드를 만들 수 있습니다. 개발자는 구성 파일에서 이러한 내부 스레드의 명명된 예약 속성을 정의할 수 있습니다.

이 메타데이터를 사용하여 내부 작업자 스레드의 속성을 설정하는 권한이 있는 서비스에서만 수동 적용을 사용하세요.

# configs/scheduling_config.textproto
scheduling_preset_name: "CUSTOM"

# Map of logical thread names to their attributes (propagated as metadata)
thread_scheduling_configuration {
  key: "sensor-processing-thread"
  value {
    policy: 1        # SCHED_FIFO
    priority: 50
    cpu_affinity_ids: [2, 3]  # Pin to specific cores
  }
}

시스템 동작 및 시행

SDV 플랫폼은 서비스별 코드를 실행하기 전에 일정 구성 활성화를 위해 엄격한 시행 모델을 사용합니다.

시작 동기화

서비스가 잘못된 우선순위로 실행되지 않도록 (초기화 단계에서도) LM과 서비스 번들 러너 (SBR)는 신호 및 계속 동기화 프로토콜을 사용합니다.

프로세스 생성: LM이 SBR 프로세스를 포크합니다. 이 시점에서 SBR 하위 프로세스는 실행되지만 즉시 차단된 상태로 들어가 stdin에서 신호를 기다립니다.
속성 적용: 하위 요소가 차단된 동안 LM은 setpriority 시스템 호출을 사용하여 요청된 nice 값을 적용하고 일정 관리 정책 (예: SCHED_IDLE)을 구성합니다.
보안 전환: LM이 SELinux 도메인 전환을 실행하여 하위 요소를 untrusted_service_bundle 또는 priority_service_bundle 도메인으로 이동합니다.
신호: 모든 매개변수가 성공적으로 적용된 후에만 LM이 단일 바이트 신호를 자녀의 stdin에 전송합니다.
실행: SBR이 신호를 수신하고 서비스 라이브러리 로드를 시작하고 수명 주기 메서드를 호출합니다.

기본 스레드 및 수명 주기에 미치는 영향

서비스 라이브러리를 로드하기 전에 동기화하면 플랫폼은 모든 수명 주기 콜백에서 기본 실행 스레드의 요청된 우선순위를 유지합니다.

onCreate: 모든 종속 항목 삽입과 초기 리소스 할당이 올바른 우선순위로 발생합니다.
onStart: 사전 설정은 활성 상태로의 전환과 초기 작업 루프를 관리합니다.
onStop 및 onDestroy: 플랫폼은 종료 중에 중요한 시스템 활동이 부족해지는 것을 방지하기 위해 동일한 우선순위로 정리 작업을 실행합니다.

바인더 스레드 풀 및 우선순위 상속

플랫폼 관리 바인더 스레드 풀의 스레드는 풀을 생성한 스레드의 우선순위로 작업을 실행하지 않습니다. 대신 동기 트랜잭션의 경우 서버 스레드가 호출자의 우선순위를 상속합니다. 바인더 커널 드라이버가 이 우선순위 상속 메커니즘을 제어합니다.

스레드 수준 미세 조정

세부적인 제어가 필요한 서비스 번들 (예: 실시간 처리 루프)은 작업자 스레드에 구성을 수동으로 적용해야 합니다. 다음 단계에 따라 스레드 수준 구성을 적용합니다.

권한이 있는 사전 설정 (is_privileged: true이 설정된 경우)을 요청합니다.
sdv_service_bundles_scheduling 라이브러리의 get_scheduling_configuration 함수를 사용하여 thread_scheduling_configuration를 읽습니다.
sched_setattr를 사용하여 작업자 스레드에 속성을 적용합니다.

SELinux 및 기능 시행

플랫폼은 SELinux와 CAP_SYS_NICE Linux 기능을 사용하여 스케줄링 사전 설정을 적용합니다.

NORMAL 또는 IDLE과 같은 사전 설정을 사용하는 서비스의 경우 시작 중에 LM에 의해 일정이 구성됩니다. 이러한 서비스에는 CAP_SYS_NICE 기능이 없으며 우선순위나 정책을 변경할 수 없습니다.
권한이 있는 사전 설정을 사용하는 서비스 (is_privileged: true)에는 CAP_SYS_NICE 기능이 부여됩니다. 이를 통해 실시간 작업에 필요한 대로 내부 스레드의 일정을 수동으로 제어할 수 있습니다.

확인 및 샘플

일정 동작을 확인하려면 로그 분석과 시스템 수준 성능 측정을 조합해야 합니다. SDV 플랫폼은 이러한 기법을 보여주는 전용 샘플을 제공합니다.

QoS 예약 샘플

samples/qos_scheduling에 있는 이 샘플에는 병렬로 실행되고 진행 상황을 보고하도록 설계된 여러 성능 테스트 서비스가 포함되어 있습니다.

PerformanceTesterNormal: NORMAL 사전 설정으로 실행됩니다.
PerformanceTesterElevated: ELEVATED 사전 설정으로 실행됩니다.
PerformanceTesterRealtime: CUSTOM 사전 설정을 사용하여 내부 작업자 스레드에 SCHED_FIFO를 적용합니다.
PolicyOffender: NORMAL 사전 설정을 사용하는 동안 실시간 우선순위를 설정하려고 시도하는 진단 서비스입니다. 이는 플랫폼이 승인되지 않은 에스컬레이션을 성공적으로 차단하는지 확인하는 데 사용됩니다.

인증 도구 모음 실행

QoS 관련 오케스트레이션 구성을 사용 설정합니다.

adb shell setprop persist.sdv.orchestrator_config_path /etc/orch/vm_qos_scheduling_orch_config.textproto
기기를 재부팅하여 각 예약 도메인에서 서비스를 시작합니다.

adb reboot
로그를 필터링하여 비교 실적 결과를 확인합니다.

adb logcat | grep sdv_sample_qos_common

PerformanceTesterElevated 서비스는 PerformanceTesterNormal에 비해 완료된 작업 단위가 훨씬 더 많다고 보고합니다. EPERM 또는 SELinux 거부 오류가 PolicyOffender 서비스의 로그에 포함됩니다.

이전 버전과의 호환성

하위 호환성을 위해 매니페스트에 scheduling_config_path를 지정하지만 구성 파일에 scheduling_preset_name를 지정하지 않는 기존 서비스 번들은 자동으로 권한이 있는 서비스로 취급됩니다. 이렇게 하면 수동 스레드 조정에 의존하는 이전 서비스에 필요한 기능 (예: CAP_SYS_NICE)이 유지됩니다.
루트 구성 메시지 DeadlineSchedulingConfiguration는 향후 출시에서 이름이 변경될 예정입니다. 현재 이름은 과거의 이름이며, 메시지가 기한 일정뿐만 아니라 모든 일정 유형을 처리한다는 점을 더 이상 정확하게 반영하지 않습니다.