HAR 플랫폼 추상화 계층

Android에서 표시할 수 없는 차량 정보를 표시하려면 고가용성 렌더러 (HAR)를 사용하세요. 이는 시작, 가용성, 안전 또는 규정과 같은 문제로 인해 발생할 수 있습니다. HAR는 Rust로 작성된 휴대용 기본 제공 앱입니다.

HAR 프레임워크라고도 하는 HAR에는 앱을 빌드하는 데 사용하는 코드가 포함되어 있습니다. HAR로 빌드된 앱은 HAR 기반 앱 입니다. HAR 프레임워크에는 다양한 플랫폼의 코드 섹션이 있습니다. 예를 들어 Linux 시스템에서는 사운드에 tinyalsa와 같은 라이브러리를 사용합니다. QNX에는 고유한 오디오 라이브러리가 있습니다.

플랫폼에는 하드웨어, 운영체제, 시스템 라이브러리 및 기타 요소가 포함됩니다. 플랫폼별 코드에는 하위 시스템이라는 부분이 있습니다. 각 하위 시스템은 오디오, EVS 카메라 또는 차량 데이터와 같은 하나의 플랫폼 기능을 처리합니다. 플랫폼을 지원하려면 HAR 프레임워크에 모든 하위 시스템이 구현되어 있어야 합니다.

플랫폼별 하위 시스템 코드는 HAR 기반 앱과 동일한 프로세스 또는 별도의 프로세스에서 실행될 수 있습니다. 별도의 경우 이 코드는 프로세스 간 통신 (IPC)을 처리하여 플랫폼이 앱을 지원하는지 확인합니다. 복잡한 IPC 메커니즘은 플랫폼별 코드의 일부여야 합니다.

HAR 테스트 모음은 플랫폼에 구현된 모든 하위 시스템에서 테스트를 실행합니다. 이 모음을 사용하여 플랫폼이 HAR 요구사항을 충족하는지 확인하고 새로운 문제를 찾으세요.

용어

이 페이지에는 다음 용어가 있습니다.

HAR 기반 앱

HAR 프레임워크로 빌드된 OEM 또는 기능별 앱입니다. 앱은 앱 상태 및 기타 맞춤설정 가능한 측면에서 다릅니다.

HAR 프레임워크

앱을 빌드하는 데 사용되는 핵심 도구 세트를 제공합니다.

HAR 플랫폼 추상화

모든 타겟 플랫폼에서 구현해야 하는 알려진 API를 제공하는 HAR 프레임워크의 일부입니다.

HAR 테스트 모음

플랫폼 구현에 대한 일련의 알려진 테스트로, 플랫폼 구현이 지정된 플랫폼에서 HAR 프레임워크를 지원하는지 확인하는 데 도움이 됩니다.

지원 범위 외

HAR는 다음을 처리하지 않습니다.

• 모든 플랫폼 타겟의 개별 구현: 타겟 플랫폼의 구현입니다. 대신 이 페이지에서는 플랫폼 구현이 충족해야 하는 인터페이스와 테스트 모음이 충족해야 하는 사항을 설명합니다.

• 테스트 사례: 모든 인터페이스의 특정 테스트 사례입니다. 대신 이 페이지에서는 인수, 반환 값, 예상되는 동작, 예상되는 부작용을 비롯한 인터페이스의 개별 함수를 설명합니다. 이 페이지에서는 테스트 사례를 구현하고 실행할 수 있는 테스트 모음을 설명합니다.

플랫폼 추상화 대략적인 크레이트 구조

Rust 프로젝트는 크레이트로 구성됩니다. 그림 1은 HAR 플랫폼 추상화 계층의 크레이트 구조를 보여줍니다. 플랫폼 추상화 계층은 두 개 이상의 Rust 크레이트에 영향을 미칩니다.

• 추상화 (Rust trait 설명)는 HAR 프레임워크 크레이트에 있습니다.

• 플랫폼의 구현은 별도의 har-platform-x 크레이트에 있습니다. 예를 들어 har-platform-linux 또는 har-platform-android입니다.

지정된 플랫폼 구현이 없으면 HAR 크레이트를 빌드하거나 테스트할 수 없습니다. HAR 프레임워크는 프레임워크이므로 이는 의도된 것입니다.

플랫폼을 지정하는 앱은 작동하고 테스트되려면 이 프레임워크로 빌드해야 합니다. HAR 프레임워크와 플랫폼 간의 연결은 이 다이어그램에 있습니다.

그림 1. HAR 크레이트.

display-safety 내의 일반 구조

이 디자인은 그림 2와 같이 display_safety 저장소에 일련의 새 크레이트를 추가합니다.

그림 2. 추상화 모듈.

테스트 모음은 구조적으로 앱과 유사하지만 지정된 플랫폼 구현 크레이트에만 의존합니다. 테스트 모음은 HAR 프레임워크에 정의된 특성 및 구조를 참조해야 하지만 더 복잡한 구현을 참조해서는 안 됩니다.

플랫폼 추상화 계층 대략적인 설명

이 표에서는 HAR 플랫폼 추상화 계층에서 정의한 플랫폼별 하위 시스템을 설명합니다.

이름 지정 규칙 및 프레임워크 구조

이 표에서는 이러한 이름과 구조를 보여줍니다.

• HAR 프레임워크에서 제공하는 예상 하위 시스템 trait 인스턴스입니다. 각 trait는 구현해야 하는 플랫폼별 하위 시스템을 나타냅니다.

• 플랫폼 크레이트의 플랫폼별 하위 시스템 구현의 예상 이름입니다. HAR 기반 앱은 이러한 특정 이름이 구현될 것으로 예상합니다.

• 일반적으로 플랫폼 관련 구현에서 HAR 프레임워크로 정보를 전달하는 데 사용되는 관련 HAR 프레임워크 enum 및 struct 인스턴스입니다.

오류 및 오류 처리

제안된 API는 Rust Result<> 유형을 사용합니다. Rust에서는 오류가 있는 Result 유형을 확인해야 합니다. 그렇지 않으면 컴파일러에서 경고 또는 오류를 생성합니다. 빌드 시간 검사는 플랫폼별 코드의 오류 검사를 적용합니다.

플랫폼 구현에서 반환된 오류는 harry::error::Error 유형입니다. 플랫폼 오류 유형이 앱 코드로 유출되지 않는지 확인하려면 HAR 프레임워크에서 제공하는 표준 오류 유형을 사용하세요.

harry::error::Error 유형은 모든 하위 시스템의 특정 오류를 포함하도록 확장됩니다.

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

복구할 수 없는 오류는 주로 정의된 인터페이스와 콜백을 통해 반환됩니다.

테스트 모음 세부 설계

이 섹션에서는 추상화의 플랫폼별 구현을 확인하는 테스트 모음의 설계를 설명합니다.

테스트 모음 테스트 빌드

Soong 빌드 (Android.bp 파일로 정의됨)의 경우 테스트는 Android 플랫폼 빌드 시스템의 일부로 컴파일되며 실행은 atest에서 관리합니다.

테스트 모음 실행

개별 플랫폼을 테스트하려면 다음 단계를 따르세요.

관련 테스트 타겟 (예: atest <module_name>)과 함께 atest 명령어를 사용합니다. 이 명령어는 Android 기기 또는 에뮬레이터에 테스트를 배포하고 실행합니다.