Android Q의 APEX: 프로젝트 트레블 이후 가장 큰 것은?

APEX 구현은 아마도 Project Treble 도입 이후 Google이 직면한 가장 큰 골칫거리일 것입니다. APEX란 무엇이며, APEX 도입으로 Android가 어떻게 바뀌나요?

APEX 이면의 아이디어 자체는 일상적인 GNU/Linux 배포판에서 흔히 볼 수 있습니다. 즉, Linux 라이브러리 세트의 특정 섹션을 대상으로 하는 패키지 업데이트입니다. 하지만 Android가 모든 시스템 라이브러리와 프레임워크는 대부분의 Linux 배포판에서 사용되는 일반적인 RW(읽기-쓰기) 파티션에 비해 저장되어 표준 업그레이드 프로세스를 렌더링합니다. 부적합하다.

라이브러리는 다른 프로그램에서 사용할 수 있는 미리 컴파일된 코드입니다. 일반적으로 사용되는 메소드를 Android 앱이 호출할 라이브러리로 만들 수 있으며, 동일한 코드를 여러 앱에서 다시 구현할 필요가 없으므로 APK 크기를 줄일 수 있습니다. /system/lib 및 /system/lib64 디렉터리에서 사전 설치된 여러 시스템 라이브러리를 찾을 수 있습니다. Android 시스템 라이브러리는 일반적으로 개별적으로 업데이트되지 않고 OTA 업데이트를 통해 Android 플랫폼 업그레이드의 일부로 업데이트됩니다. 반면 Linux 배포판의 라이브러리는 개별적으로 업데이트될 수 있습니다. APEX의 도입으로 Android의 시스템 라이브러리는 Android 앱처럼 개별적으로 업데이트될 수 있습니다. 이것의 주요 이점은 앱 개발자가 OEM이 전체 시스템 업그레이드를 출시할 때까지 기다리지 않고 업데이트된 라이브러리를 활용할 수 있다는 것입니다. APEX 작동 방식에 대해 좀 더 기술적으로 자세히 살펴보겠습니다.

APEX는 라이브러리 업데이트 방식을 어떻게 바꾸나요?

APEX는 Android가 /system과 다른 비표준 파티션에서 모든 라이브러리와 파일을 로드하는 방식을 Google이 다시 고려하도록 강제하는(또는 오히려 강제하는) 생태계입니다.

우선, 공유 라이브러리와 정적 라이브러리의 차이점을 지정해야 합니다. 공유 라이브러리는 자체적으로 실행하는 데 필요한 모든 코드를 포함하지는 않지만 실제로 다른 라이브러리에 "링크"되어 있는 라이브러리(일반적으로 libkind.so라는 파일)입니다. 코드를 제공하는 반면 정적 라이브러리는 짐작할 수 있듯이 다른 라이브러리에 의존하지 않고 모든 것이 정적으로 포함된 라이브러리입니다. 파일.

Android는 역사적으로 라이브러리 경로(Linux 세계에서는 LD_LIBRARY_PATH라고 함)를 단일 파일로 구성했습니다. 바이너리 또는 다른 라이브러리에 필요한 공유 라이브러리에 대해 허용된 검색 경로를 구성하기 위해 ld.config.txt [0]을 호출했습니다. 도서관. 이러한 경로는 구성에 하드코딩되어 있으며 확장할 수 없습니다. 읽기 전용 시스템 파티션을 포함한 이 레이아웃은 사용자가 OTA Android 업데이트를 설치하지 않는 한 업데이트할 수 없는 라이브러리로 이어집니다. Google은 단일 APEX 패키지가 패키지에 포함된 추가(업데이트된) 라이브러리 경로가 포함된 자체 ld.config.txt를 제공하도록 하여 검색 경로를 확장할 수 있도록 이 문제를 해결했습니다.

이러한 조치로 주요 문제 중 하나가 해결되었지만 여전히 극복해야 할 몇 가지 심각한 문제가 있었습니다. 우선, ABI(애플리케이션 바이너리 인터페이스) 안정성입니다. 라이브러리는 업그레이드된 라이브러리를 사용하더라도 다른 앱과 라이브러리가 동일한 프로토콜로 계속 작동할 수 있도록 항상 안정적인 인터페이스 세트를 내보내야 합니다. Google은 APEX 라이브러리 간에 안정적인 C 인터페이스를 만들기 위해 적극적으로 노력하고 있습니다.

그러나 APEX는 라이브러리와 바이너리에만 국한되지 않습니다. 실제로 여기에는 구성 파일, 시간대 업데이트 및 일부 Java 프레임워크(작성 당시에는 암호화되어 있음)가 포함될 수 있습니다.

다음은 AOSP에서 제공하는 현재 APEX 패키지의 몇 가지 예입니다.

• com.android.runtime: ART 및 생체공학 런타임(바이너리 및 라이브러리)
• com.android.tzdata: TimeZone 및 ICU 데이터(라이브러리 및 구성 데이터)
• com.android.resolv: 네트워크 관련 요청을 해결하기 위해 Android에서 사용하는 라이브러리(라이브러리)
• com.android.conscrypt: Java 보안 제공자(Java 프레임워크)

APEX 패키지는 어떻게 설치되고 구성됩니까?

APEX 패키지는 편리한 ADB(현재 개발 시점)로 설치할 수 있는 간단한 zip 아카이브(예: APK)입니다. 그리고 나중에는 사용자가 패키지 관리자(예: Google Play 또는 Android 패키지를 통해 수동으로)를 통해 직접 수행합니다. 설치 프로그램).

ZIP 레이아웃은 다음과 같습니다.

그것에 대해 자세히 살펴 보겠습니다.

apex_manifest.json은 패키지 이름과 버전을 지정합니다.

apex_payload.img는 마이크로 파일 시스템 이미지(EXT4 형식)입니다.

다른 파일은 패키지를 설치하는 데 사용되는 확인 프로세스의 일부입니다. 한번 살펴보자.

존재 AndroidManifest.xml, 비록 애플리케이션에서 주로 사용되더라도 표준 APK 설치에 사용되는 구현의 대부분이 이러한 패키지에서도 재사용된다는 것을 이해하는 데 도움이 됩니다. 실제로는 확장명만 확인하여 구분할 수 있습니다.

그만큼 메타-INF/ 디렉터리에는 패키지 인증서가 있으며 일반 APK와 동일한 메커니즘을 사용합니다. 그래서 이 패키지들은 사용자가 업데이트를 설치하기 전에 런타임 시 개인/공개 키 쌍으로 확인됩니다. 하지만 Google에는 그것만으로는 충분하지 않았기 때문에 보안 계층을 2개 더 추가했습니다. 그들은 dm-verity를 ​​사용하여 이미지의 무결성을 확인하고 AVB(Android 자체 검사 부팅) 검증을 통해 이미지가 신뢰할 수 있는 소스에서 나온 것인지 확인합니다. 최악의 경우 APEX 패키지가 거부됩니다.

모든 확인 단계가 성공하면 이미지가 유효한 것으로 표시되고 다음 재부팅 시 시스템 변형이 대체됩니다.

부팅 시 이미지는 어떻게 설치되나요?

현재 내 기기(에뮬레이터)에 설치된 APEX를 살펴보는 것부터 시작하겠습니다.

보시다시피 사전 설치된 패키지는 /system/apex/에 저장되어 있으며 현재 모두 버전 번호 1입니다. 하지만 APEX가 활성화되면 어떻게 될까요? 다시 com.android.tzdata를 예로 사용하겠습니다.

기기를 재부팅하고 logcat을 분석해 보겠습니다.

처음 2줄은 패키지의 출처와 배송 위치를 이해하는 데 충분한 정보를 제공합니다. 설치됨: /apex/, 활성화된 파일을 저장하는 데 사용되는 Android Q에 도입된 새 디렉터리입니다. 패키지.

패키지가 AVB로 성공적으로 확인되고 공개 키가 일치하면 APEX가 루프 장치를 사용하여 /dev/block/loop0에 마운트되어 EXT4 파일 시스템이 시스템에 액세스할 수 있게 됩니다. 루프 장치는 파일을 블록 장치로 액세스할 수 있게 만들어 해당 파일의 내용을 마운트 지점으로 액세스할 수 있게 만드는 의사 장치입니다.

이 시점에서는 @1 접미사(패키지 버전을 나타냄)로 인해 APEX가 아직 사용되지 않습니다. 마지막으로 패키지가 성공적으로 활성화되었음을 시스템에 알리기 위해 Android가 tzdata가 활성화되기를 적극적으로 기대하는 /apex/com.android.tzdata에 패키지가 바인드 마운트됩니다. 바인드 마운트는 다른 지점 아래의 기존 디렉터리나 파일을 오버레이합니다. [1]

APEX 구현은 AOSP의 단일 저장소에 완전히 포함되어 있습니다. [2] apexd(APEX 데몬) 디렉터리에는 Android에서 실행되는 코드가 있습니다. apexer 디렉터리에는 빌드 시스템에서 APEX 패키지를 생성하는 데 사용되는 코드가 있습니다.

목적은 무엇입니까?

이 시점에서 내가 할 수 있는 일은 추측뿐이다. 내 추측으로는 Google이 업데이트할 수 있는 핵심 APEX 패키지 세트를 만들려고 노력하고 있다는 것입니다. 공급업체 간에 공유되는 Android의 통합 기본 코어로 '시스템' 업데이트만 가능하지만 단일 패키지 사용 업데이트.

모든 기기가 APEX를 지원하나요?

아니요. 예를 들어 apexd에서는 모든 Android 모듈을 업데이트하기 위해 부팅 직후 /data/apex를 사용할 수 있어야 합니다. FDE(전체 디스크 암호화)를 사용하면 사용자가 장치를 잠금 해제할 때까지 /data/apex가 암호화됩니다. 부팅 시 시스템 APEX 변형만 로드되므로 APEX는 기본적으로 쓸모 없게 됩니다. 그 외에 모든 장치는 APEX를 지원해야 하지만 몇 가지 커널 패치가 필요합니다(이 중 대부분은 루프 장치를 사용하는 동안 Google에서 찾은 수정 사항입니다). [3] [4]

---

출처 [0], [1], [2], [3], [4]