Google의 일반 커널 이미지는 Android의 조각화 문제를 해결하기 위한 다음 단계입니다.

Google은 수년 동안 Android의 단편화를 줄이기 위해 노력해 왔습니다. 하지만 그 원인 중 하나는 Android의 고유한 특성과 선택과 자유라는 양날의 검 때문입니다. 이 분야에는 셀 수 없이 많은 OEM이 활동하고 있으며 모두 자신의 장치에 맞게 수정하고 싶어합니다. 문제는 Android OS 업데이트가 전반적으로 느리게 출시되는 것처럼 보이지만 실제로 OEM이 기기를 업데이트하도록 Google이 할 수 있는 일이 많지 않다는 것입니다. 따라서 Google이 할 수 있는 차선책은 업데이트 프로세스를 최대한 쉽고 원활하게 만드는 것입니다.

Android 업데이트 문제 완화

개발 부담을 줄이기 위한 Google의 장기 프로젝트 중 첫 번째 주요 이니셔티브는 프로젝트 트레블. 2017년 Android 8.0 Oreo와 함께 발표된 Project Treble은 공급업체 구현(HAL 및 기기별 Linux 커널 포크)에서 OS 프레임워크를 분리하여 Android를 모듈화했습니다. 이를 통해 Android OEM이 최신 AOSP 프레임워크를 기반으로 OS를 리베이스하는 것이 더 쉬워졌습니다. 공급업체의 코드를 업데이트하지 않고도 최신 버전을 부팅할 수 있기 때문입니다. 결과적으로 OEM은 이전보다 더 빠르게 맞춤형 Android 포크를 준비할 수 있었고 더 나아가 주요 OS 업데이트를 더 빠르게 출시할 수 있었습니다.

Google 계획의 다음 단계는 주요 Android 구성 요소에 대한 업데이트 제공을 간소화하는 것이었습니다. Google에서는 이 이니셔티브를 프로젝트 메인라인 2019년에 Android 10과 함께 출시되었을 때였습니다. Google은 본질적으로 주요 OS 구성 요소를 제어하고 OEM이 이를 수정하는 것을 금지했습니다. 그런 다음 OEM이 패치를 직접 적용할 때까지 기다리지 않고도 이러한 주요 구성 요소에 대한 업데이트를 원격으로 출시할 수 있도록 Google Play를 통해 제공 메커니즘을 설정했습니다. Mainline은 기기가 중요한 OS 구성요소의 업데이트된 버전을 수신하는 속도를 크게 개선하여 Android 생태계 전체의 보안을 향상시켰습니다.

하지만 Treble의 경우 현실적으로 Linux 커널을 비공개 소스 공급업체 코드와 함께 묶어서는 안 됩니다. 토드 죠스(Todd Kjos) 올해의 Linux 배관공 컨퍼런스 과거에는 Android의 조각화와 관련하여 직면한 어려움에 대해 설명했으며 현재는 OEM이 장치와 함께 제공하는 Linux 커널을 중심으로 많은 문제가 발생하고 있습니다. 맥락에 따라 Google은 각 메인라인 Linux 커널을 'Android 공통 커널” (ACK) 분기는 메인라인 릴리스를 면밀히 추적하지만 몇 가지 Android 관련 패치를 추가합니다. Qualcomm, MediaTek 및 Samsung과 같은 SoC 공급업체는 포크를 수행합니다. 저것 그들이 만드는 각 SoC에 대한 커널. 그런 다음 OEM은 해당 SoC 관련 커널을 가져와 추가 패치를 추가하여 출시하려는 특정 하드웨어에 대한 지원을 구현합니다.

위 다이어그램은 장치의 커널이 Linux LTS 커널에서 추상화하는 여러 계층의 변경을 어떻게 거치는지 보여줍니다. 단순화하기 위해 Linux 커널로 시작하고 몇 가지 변경 사항을 거쳐 Android 일반 커널로 병합됩니다. 여기에서 Android 일반 커널은 자체 수정 및 변경 사항을 통해 공급업체 커널(Qualcomm, MediaTek 등)에 병합됩니다. 마지막으로 공급업체 커널은 OEM의 장치별 커널로 병합됩니다. 이 단계에서는 모든 장치의 커널이 처음에 사용된 Linux LTS 커널에서 멀리 제거됩니다.

이러한 모든 포크로 인해 Android 기기에서 실행되는 코드의 최대 50%가 트리 외부 코드입니다. 즉, 업스트림 Linux 또는 AOSP 일반 커널에서 나온 것이 아닙니다. 이로 인해 업스트림 변경 사항을 병합하는 것이 엄청나게 어렵습니다(시간과 비용은 말할 것도 없고). OEM의 경우 그렇게 할 인센티브는 없지만 이러한 관행은 장치 보안에 해로울 수 있습니다. 이는 또한 많은 Android 장치가 이전 LTS 커널 릴리스에 남아 있는 이유이기도 하며, 이로 인해 장치가 새로운 Linux 커널 기능에 액세스할 수 없게 되는 부작용이 있습니다.

Android는 조각화되어 있으며 Google은 이를 알고 있습니다.

구글은 이것이 문제라는 것을 잘 알고 있으며, 심지어 "단편화 비용" Android 개발자 문서에 있습니다. 구글이 그러는데 "대부분의 주력 장치에는 이미 18개월 이상 된 커널 버전이 함께 제공됩니다.". 더 나쁜 것은 Google도 다음과 같이 말합니다. "Android 10은 3.18, 4.4, 4.9, 4.14, 4.19 커널을 지원하며, 경우에 따라 2017년 Android 8 이후 새로운 기능으로 향상되지 않았습니다." 이로 인해 새로운 Linux 커널 버전이 필요한 기능을 추가하기가 어렵습니다. Linux 커널 3.18은 Android 5.0 Lollipop이 Android의 최신 버전이었던 2014년 12월에 출시되었습니다. 그것은 분명히 문제이며 플랫폼을 방해할 수 있습니다.

예를 들어, 코드 오로라 포럼(Code Aurora Forum, 줄여서 CAF)은 다양한 Qualcomm Snapdragon SoC의 소스 코드를 호스팅합니다. SoC로서의 Qualcomm 공급업체가 Linux 커널의 포크된 버전을 OEM/ODM에 배포하면 해당 회사는 배송 시 장치별 변경 사항을 추가합니다. 장치. 이것이 여러 계층의 조각화를 추가하는 것입니다. 또한 Qualcomm은 회사의 각 Snapdragon 모바일 플랫폼에 맞게 Android를 최적화하기 위해 AOSP 프레임워크를 변경했습니다. Qualcomm은 수정된 Linux 커널, AOSP 프레임워크 및 기타 소프트웨어 도구를 보드 지원 패키지(BSP)의 일부로 파트너에게 비공개로 배포합니다. CAF는 Qualcomm이 이러한 Linux 커널 변경 사항과 AOSP 프레임워크 변경 사항을 공개적으로 게시하는 곳입니다.

이 CAF 릴리스는 순수 AOSP가 아닌 시작점으로 사용하려는 맞춤 ROM 개발자에게 유용할 수 있습니다. 포럼의 "CAF 기반" ROM. 수년 동안 수많은 중급형 스마트폰을 지원했던 Snapdragon 625를 기억하시나요? 이는 Linux Kernel 3.18과 함께 출시되었으며, 2018년 말(칩셋 출시 후 2년)이 되어서야 Qualcomm은 커널 소스를 업데이트하고 이를 게시했습니다. CAF msm8953(Snapdragon 625의 칩셋 이름)의 경우 Linux 커널 4.9를 지원합니다. 문제는 대부분의 OEM이 휴대폰을 이 새로운 Linux 커널 버전으로 업데이트하지 않습니다. 특히 칩이 출시된 지 2년이 지난 중급 휴대폰은 업데이트하지 않습니다. 출시된. 물론, 그러한 주요 커널 업데이트가 처음부터 발생하는 경우는 매우 드뭅니다. 가지다 일어난 일이므로 불가능한 시나리오는 아닙니다.

전체적으로 현재 Android의 단편화는 가볍게 말하면 엉망입니다. 이러한 조각화를 수정하려는 Google의 최근 시도는 일반 커널 이미지(GKI)의 형태로 이루어졌습니다.

일반 커널 이미지 소개

이러한 단편화를 해결하기 위해 Google은 Android GKI(일반 커널 이미지) 작업을 수행했습니다. 이는 본질적으로 ACK 분기에서 직접 컴파일된 커널입니다. GKI는 SoC 공급업체 및 OEM 맞춤설정을 플러그인 모듈로 분리하여 트리 외부 코드를 제거하고 Google이 커널 업데이트를 최종 사용자에게 직접 푸시할 수 있도록 합니다. Google은 1년 넘게 Play 스토어를 통해 GKI 업데이트를 제공하는 방법을 연구해 왔습니다. 메인라인 모듈을 사용하여.

따라서 Linux 커널 5.10.43 이상을 실행하는 Android 12로 출시되는 기기는 다음 중 하나를 수행해야 합니다. 미샤알 라만(Mishaal Rahman)에 따르면.

• Google 서명 부팅 이미지 배포

또는

• GKI에서 내보낸 KMI의 하위 집합인 KMI(커널 모듈 인터페이스)를 내보내는 커널이 포함된 부팅 이미지를 배포합니다. GKI에서 노출된 UAPI의 상위 집합인 사용자 공간 API를 내보내고 해당 GKI의 모든 기능을 지원합니다. 버전

공급업체는 GKI에 연결되는 모듈을 만들 수 있지만 GKI의 아이디어는 Google이 커널 변경 사항을 처리하는 책임을 진다는 것입니다. 커널 모듈 인터페이스(또는 KMI, 이에 대한 자세한 내용은 기사 뒷부분에서 설명)는 트리 외부 코드가 예상되는 위치입니다.

Google Pixel 6 시리즈는 Android 12와 함께 출시되어 Linux 커널 5.10과 함께 제공되며 GKI와 함께 제공되는 최초의 휴대폰입니다. Google은 잠재적으로 Play 스토어를 통해 커널을 업데이트할 수 있기 때문에 커널 업데이트가 자주 표시될 수도 있습니다. LTS 커널 업데이트는 일반적으로 매주 출시되므로. 어느 쪽이든 현재 OTA를 통해 업데이트하는 번거로운 방법보다 훨씬 더 나은 시스템이지만 이는 본질적으로 GMS 프레임워크에 연결되어 있음을 의미합니다.

Google은 간단히 GKI를 다음과 같이 정의합니다.

• ACK 소스를 기반으로 구축되었습니다.
• 이는 단일 커널 바이너리와 아키텍처별, LTS 릴리스별 관련 로드 가능 모듈입니다(현재는 arm64만 해당). android11-5.4 그리고 android12-5.4).
• 관련 ACK에 대해 지원되는 모든 Android 플랫폼 릴리스로 테스트되었습니다. GKI 커널 버전의 전체 기간 동안 지원 중단되는 기능은 없습니다.
• 지정된 LTS 내의 드라이버에게 안정적인 KMI를 노출합니다.
• SoC 또는 보드별 코드는 포함되어 있지 않습니다.

Google은 2023년까지 "업스트림 우선" 개발 모델을 채택할 수 있는 위치에 있기를 원합니다. 이를 통해 Google은 새로운 코드가 메인라인 Linux 커널에 먼저 들어가도록 하여 Android 기기에서 트리 외부 코드가 발생하는 '기술적 부채'를 줄이는 데 도움이 될 것입니다.

커널 모듈 인터페이스(KMI)

커널 모듈 인터페이스(KMI)는 Android에서 진행 중인 조각화에 대한 Google 솔루션의 일부입니다. 본질적으로 SoC 및 보드 지원은 더 이상 코어 커널에 위치하지 않으며 대신 로드 가능한 모듈로 이동됩니다. 모듈이 업데이트됨에 따라 커널과 모듈 모두 독립적으로 업데이트될 수 있습니다. /lib/modules. GKI 자체는 가능한 한 깔끔하고 일반적이어야 하며, 이는 현재 트리 외부 코드를 별도의 모듈로 오프로드함으로써 가능해집니다.

테드 죠스 역 에서 설명 올해 Linux 배관공 컨퍼런스에서는 "다년간의 가장 큰 목표는 모든 하드웨어 관련 코드를 일반 커널에서 공급업체 모듈로 가져오는 것입니다. 공급업체 모듈과 일반 커널이 비동기적으로 출시될 수 있도록 안정적인 인터페이스가 있어야 합니다." GKI 1.0은 본질적으로 '규정 준수 테스트'입니다.

실제로 GKI 호환성은 기기가 일반 시스템 이미지(GSI)를 사용하여 VTS 및 CTS-on-GSI+GKI 테스트를 통과했음을 의미합니다. GKI 부팅 이미지를 부팅 파티션 및 시스템의 GSI 시스템 이미지에 플래시하여 설치된 GKI 커널 분할. 공급업체 테스트 스위트(VTS)는 모든 장치가 Project Treble과 호환되는 것으로 간주되기 위해 통과해야 하는 자동화된 테스트입니다. Google의 애플리케이션 제품군에 액세스하려면 호환성 테스트 제품군(CTS)이 필요합니다.

기기는 다른 제품 커널과 함께 제공될 수 있으며 GKI에서 제공하지 않는 로드 가능한 모듈을 사용할 수 있습니다. 그러나 제품 커널과 GKI 커널은 모두 동일한 Vendor_boot 및 공급업체 파티션에서 모듈을 로드해야 합니다. 따라서 모든 제품 커널에는 동일한 바이너리 커널 모듈 인터페이스(KMI)가 있어야 합니다.

위 다이어그램은 Google이 원한다 이를 달성하기 위한 방법을 설명합니다. 일반 커널 및 GKI 모듈은 AOSP의 일부가 되며 GKI는 공급업체가 구현할 수 있는 Android 프레임워크 및 HAL(하드웨어 추상화 계층)과 통신할 수 있습니다. 공급업체가 커널에서 원하는 특정 독점 코드(예: 카메라 드라이버)는 대신 KMI를 통해 GKI의 확장이 되는 공급업체 모듈에 푸시됩니다.

GKI가 Android의 조각화 문제를 해결하는 데 어떻게 도움이 됩니까?

Google은 스마트폰 개발 프로세스를 간소화하기 위해 많은 노력을 기울여 왔습니다. 모든 OEM은 고유한 브랜드 아이덴티티를 원하며 모든 OEM은 해당 장치에 대한 소유권을 갖기를 원합니다. Android One 프로그램과 달리 Android 스마트폰은 Google이 GMS 라이선스를 받기 위해 설정한 일련의 규칙을 준수하는 한 원하는 대로 무엇이든 될 수 있습니다. 그러나 과거에는 Google이 Android 기기 개발에서 많은 역할을 하지 못했습니다. Project Treble, Mainline과 같은 변경 사항과 이제 GKI가 Android에서 훨씬 더 최근에 출시되었습니다. 역사.

하지만 도움이 될까요? 그래야 하지만 나중에 눈에 띄는 결실을 맺는 다년간의 일이 될 가능성이 높습니다. 이는 Android 12로 출시되는 기기에만 적용됩니다. 즉, 앞으로 몇 년 동안 GKI가 없는 기기를 보게 될 것입니다. 이는 발표 당시 Project Treble에 대한 비판이기도 했지만, 분명히 요즘 출시되는 모든 장치는 이를 지원합니다. 이러한 작업에는 시간이 걸리며 Google이 천천히 Android를 장악함에 따라 모든 OEM의 개발 프로세스가 쉬워졌습니다. Android 생태계(그 중 일부가 Android에서 사용되는 Linux 커널에 대한 완전한 제어권을 갖고 싶어하더라도) 스마트폰.