2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
공급업체 인터페이스 객체
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 문서에서는 공급업체 인터페이스 객체(VINTF 객체)의 설계에 관해 설명합니다. 이 객체는 기기에 관한 관련 정보를 집계하고 쿼리 가능한 API를 통해 정보를 제공합니다.
VINTF 객체 설계
VINTF 객체는 필요한 정보를 기기에서 직접 수집합니다. 매니페스트와 같은 다른 측면은 XML에 통계적으로 설명되어 있습니다.
그림 1. 매니페스트, 호환성 매트릭스, 런타임 수집 가능 정보
VINTF 객체 설계는 기기 및 프레임워크 구성요소와 관련하여 다음을 실행합니다.
기기 |
프레임워크 |
- 정적 구성요소(기기 매니페스트 파일)의 체계를 정의합니다.
- 기기의 기기 매니페스트 파일 정의를 위한 빌드 시간 지원을 추가합니다.
- 런타임 시 기기 매니페스트 파일(및 기타 런타임 수집 가능 정보)을 가져와 쿼리 결과로 패키징하는 쿼리 가능한 API를 정의합니다.
|
|
VINTF 객체는 신뢰할 수 있어야 하며 객체 요청 시점과 상관없이 항상 온전한 정보를 제공해야 합니다(주의사항 참조).
매니페스트 및 매트릭스
Android 8.0부터는 런타임 API가 기기의 콘텐츠를 쿼리하고 이 정보를 OTA(Over-the-Air) 업데이트 서버와 관계 당사자(CTS DeviceInfo
등)에게 전송합니다. 일부 정보는 런타임 시에 검색되며 여기서 일부는 정적으로 정의됩니다.
- 기기 매니페스트는 기기가 프레임워크에 제공할 수 있는 콘텐츠의 정적 구성요소를 설명합니다.
- 프레임워크 호환성 매트릭스는 Android 프레임워크가 기기로부터 무엇을 기대하는지 설명합니다. 매트릭스는 Android 프레임워크의 다음 버전이 개발되는 동안 구성이 결정되는 정적 항목입니다.
- 프레임워크 매니페스트는 프레임워크가 기기에 제공할 수 있는 높은 수준의 서비스를 설명합니다.
- 기기 호환성 매트릭스는 공급업체 이미지가 프레임워크에 요구하는 서비스를 설명합니다. 구성은 기기가 개발되는 동안 수동으로 결정됩니다.
이러한 두 쌍의 매니페스트와 매트릭스는 기기가 기기의 기능과 호환되는 프레임워크 업데이트를 받을 수 있도록 OTA 시간에 조정되어야 합니다. 일반적으로 매니페스트는 무엇이 제공되는지를 설명하고 호환성 매트릭스는 무엇이 요구되는지를 설명합니다.
이 섹션에는 다음과 같은 매니페스트 및 매트릭스 관련 세부정보가 포함되어 있습니다.
- 매니페스트는 기기 매니페스트, 프레임워크 매니페스트 및 매니페스트 파일 체계를 정의합니다.
- 호환성 매트릭스는 호환성 매트릭스의 체계를 정의합니다.
- FCM 수명 주기는 HIDL HAL이 어떻게 지원 중단되고 제거되는지, 그리고 FCM 파일이 어떻게 HAL 버전의 상태를 반영하도록 수정되는지를 설명합니다.
- DM 개발은 공급업체가 어떻게 새 기기의 기기 매니페스트에 타겟 FCM 버전을 정의하고 선언할 수 있는지, 그리고 기존 기기의 공급업체 이미지를 업그레이드할 때 타겟 FCM 버전을 어떻게 구현할 수 있는지에 관해 설명합니다.
- 매칭 규칙은 호환성 매트릭스와 매니페스트 간의 성공적인 매칭을 위한 규칙을 정의합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Vendor interface object\n\nThis document describes the design of the *vendor interface object*\n(VINTF object), which aggregates relevant information about a device and makes\nthat information available through a *queryable API*.\n\nVINTF object design\n-------------------\n\nA VINTF object gathers some of the information it needs directly from the\ndevice. Other aspects, such as the manifests, are described statically in\nXML.\n\n**Figure 1.** Manifests, compatibility matrixes, and runtime-collectible information.\n\nVINTF object design provides the following for device and framework\ncomponents:\n\n| For the Device | For the Framework |\n|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| - Defines a schema for the static component (the [device manifest file](/docs/core/architecture/vintf/objects#device-manifest-file)). - Adds build time support for defining the device manifest file for a given device. - Defines the [queryable API](/docs/core/architecture/vintf/objects#queryable-api) at runtime that retrieves the device manifest file (along with the other runtime-collectible information) and packages them into the query result. | - Defines a schema for the static component (the [framework manifest file](/docs/core/architecture/vintf/objects#framework-manifest-file)). - Defines the [queryable API](/docs/core/architecture/vintf/objects#queryable-api) at runtime that retrieves the framework manifest file and packages it into the query result. |\n\nThe VINTF object must be reliable and provide the same complete information\nregardless of when the object is requested (see\n[Caveats](/docs/core/architecture/vintf/resources#caveats)).\n\nManifests and matrixes\n----------------------\n\nAs of Android 8.0, a runtime API queries what is on the device and sends that\ninformation to the [Over-the-Air (OTA)](/docs/core/ota)\nupdate server and other interested parties (such as CTS\n`DeviceInfo`). Some information is retrieved at runtime and some of\nit is statically-defined.\n\n- The **device manifest** describes the static component of what the device can provide to the framework.\n- The **framework compatibility matrix** describes what the Android framework expects from a given device. The matrix is a static entity whose composition is determined manually during development of the next release of the Android framework.\n- The **framework manifest** describes high-level services the framework can provide to the device.\n- The **device compatibility matrix** describes the services the vendor image requires of the framework. Its composition is determined manually during the development of the device.\n\nThese two pairs of manifests and matrixes must be reconciled at OTA time to\nensure a device can get framework updates that are compatible with the device's\ncapabilities. In general, a *manifest* describes what is provided and a\n*compatibility matrix* describes what is required.\n\nThis section includes the following details on manifests and matrixes:\n\n- [Manifests](/docs/core/architecture/vintf/objects) defines the device manifest, framework manifest, and manifest file schema.\n- [Compatibility\n Matrixes](/docs/core/architecture/vintf/comp-matrices) defines the schema for the compatibility matrix.\n- [FCM Lifecycle](/docs/core/architecture/vintf/fcm) details how HIDL HALs are deprecated and removed and how FCM files are modifed to reflect the status of the HAL Version.\n- [DM Development](/docs/core/architecture/vintf/dm) describes how vendors can define and declare the Target FCM Version in the device manifest for new devices or implement new HAL versions and increment the Target FCM Version when upgrading the vendor image for old devices.\n- [Matching Rules](/docs/core/architecture/vintf/match-rules) defines the rules for a successful match between a compatibility matrix and a manifest."]]