Android의 Project Mainline에 대해 알아야 할 모든 것

최근 몇 년간 Android의 가장 큰 변화 중 하나는 상대적으로 그 중요성에 반하여 레이더 아래로 날아간 것입니다. 프로젝트 본선 안드로이드 10에서. Google은 Android 출시 전반에 걸쳐 특정 Mainline 모듈을 포함하도록 요구합니다. 안드로이드 11 와 함께 들어오는 필수 총 25개의 메인라인 모듈 결합. 다음은 Android의 모든 Project Mainline 모듈 목록과 함께 Project Mainline이 무엇이고 해결하려는 목표에 대한 설명입니다.

프로젝트 메인라인이란 무엇입니까?

Project Mainline을 제대로 이해하려면 약간 되감아야 합니다. 몇 년 전으로 돌아가면 Android 업데이트에 대한 많은 대화가 조각화 문제를 중심으로 이루어졌습니다. 조각화는 아이스크림 샌드위치 - 롤리팝 시대에 Android에서 Google이 해결해야 할 가장 큰 과제 중 하나였습니다. 플랫폼으로서의 Android는 대체로 예측 가능한 패턴으로 정기적인 업데이트를 받았지만 이러한 업데이트가 최종 소비자의 손에 도달하는 데는 매우 오랜 시간이 걸렸습니다. 따라서 Google이 플랫폼 수준에서 중요한 버그와 보안 문제를 수정하는 동안 이러한 변경 사항의 실제 출시에는 많은 것이 필요했습니다. 많은 중개자(SoC 공급업체, OEM, 통신사 등)와 업데이트 제공과 관련된 많은 이동 부품이 있었습니다. 귀하의 휴대 전화와 조각화 문제는 강한 타격을 요구하지 않고 저절로 해결되는 것처럼 보이지 않았습니다. 개입.

이 문제를 해결하기 위한 주요 노력 중 하나는 프로젝트 트레블 Android 8.0 Oreo와 함께 Android의 주요 재설계가 포함되어 Android OS 프레임워크 구성 요소를 공급업체 HAL 및 Linux 커널에서 분리했습니다. 본질적으로 Project Treble은 OS 프레임워크를 장치별 하위 수준 소프트웨어에서 분리하여 Android를 모듈화했습니다. 이러한 방식으로 기기 제조업체(OEM)는 실리콘 제조업체(SoC 공급업체)가 공급업체 구현 코드를 업데이트할 때까지 기다릴 필요가 없으며 OEM은 Android OS 프레임워크를 독립적으로 업데이트할 수 있습니다. 최종 결과는 더 이상 필요하지 않기 때문에 OEM의 최신 Android 릴리스를 더 빠르게 채택하는 것입니다. 중개자(SoC 벤더)가 작업을 시작하기 전에 먼저 작업을 마칠 때까지 기다립니다. 그들의 것.

Android 업데이트 상황은 Project Treble로 즉시 극적으로 개선되지 않았지만 광범위한 OEM을 가능하게 했습니다. Android 10 및 Android 11 베타에 참여할 뿐만 아니라 OEM이 더 많은 기기를 더 빠르게 더 쉽게 업데이트할 수 있습니다. 타임라인. 또한 GSI(Generic System Image)의 전체 개념은 당사 포럼의 애프터마켓 개발에 큰 영향을 미쳤습니다.

개발자는 Project Treble GSI를 사용하여 22개의 구형 기기에서 Android 11을 부팅합니다.

Project Mainline은 Project Treble의 노력을 확장합니다. Treble은 모든 단일 OS 업데이트에 대해 OEM이 SoC 공급업체에 의존하는 정도를 줄인 반면, Mainline은 주요 OS 구성 요소에 대한 보안 업데이트를 제공하기 위해 Google이 OEM에 의존하는 정도를 줄였습니다. Project Mainline은 Treble 철학을 Android 프레임워크의 더 중요한 부분으로 확장하여 OEM을 이 등식에서 종속 중개인으로 제거합니다. Project Mainline의 목적은 Google이 프레임워크 구성요소 및 시스템 애플리케이션의 제어권을 보안에 매우 중요하며 OEM과는 다른 개발 일관성을 유지합니다. Project Mainline은 정당하게 다음과 같이 불립니다. 그만큼 Project Treble 이후 Android의 가장 큰 변화.

Project Mainline의 경우 Google은 Google Play 서비스 프레임워크 및 Google Play 스토어를 통해 제공되는 Mainline 모듈을 사용합니다. 각 메인라인 모듈은 APK 파일, APEX 파일 또는 APK-in-APEX로 제공됩니다. 메인라인 모듈이 업데이트되면 사용자의 기기에 "Google Play 시스템 업데이트"(GPSU) 알림이 표시됩니다. 중요한 구성 요소에 대한 업데이트를 효과적으로 제공하기 위해 Google은 OEM이 업데이트를 출시할 때까지 기다릴 필요 없이 자체적으로 작업을 수행하도록 선택했습니다.

처럼 Google은 Android 웹 사이트에서 다음과 같이 말합니다.:

모듈식 시스템 구성 요소를 사용하면 Google 및 Android 파트너가 비간섭 방식으로 업데이트를 광범위하고 신속하며 원활하게 최종 사용자 장치에 배포할 수 있습니다. 예를 들어, 미디어 코덱 조각화와 치명적인 버그의 조합은 앱 채택 및 사용자 참여를 크게 늦출 수 있습니다. 미디어 관련 모듈을 자주 업데이트하면 코덱 조각화를 줄여 다양한 Android 기기에서 미디어 앱 동작을 보다 일관되게 만들고 중요한 버그를 수정하여 사용자 신뢰를 구축할 수 있습니다.

Android 10 이상은 선택한 시스템 구성요소를 모듈로 변환하며, 그 중 일부는 APEX 컨테이너 형식(Android 10에 도입됨)을 사용하고 일부는 APK 형식을 사용합니다. 모듈식 아키텍처를 통해 중요한 버그 수정 및 기타 사항으로 시스템 구성 요소를 업데이트할 수 있습니다. 하위 수준 공급업체 구현 또는 상위 수준 앱에 영향을 주지 않고 필요에 따라 개선 서비스.

처럼 아르스 테크니카 언급:

Project Mainline, AKA "Google Play System Updates"는 Android의 핵심 시스템 구성 요소를 보다 모듈화하고 업데이트 가능하도록 만들기 위한 주요 노력으로 Android 10에 도입되었습니다. Mainline은 앱 업데이트를 제공하는 것처럼 쉽게 Play 스토어를 통해 핵심 Android 코드를 제공하는 것을 목표로 시스템 구성 요소용으로 특별히 새로운 "APEX" 파일 형식을 도입했습니다. 이전에는 Android에서 제공할 수 있는 유일한 코드 블록은 원래 타사 앱용으로 설계된 파일 유형인 APK였습니다. 여기에는 모든 종류의 보안 제한이 있었고 부팅 프로세스의 후반에만 시작할 수 있었기 때문에 보다 강력한 시스템 구성 요소를 염두에 두고 APEX를 만들었습니다. APEX는 Google 또는 기기 제조업체에서만 만들 수 있으므로 눈에 띄게 더 강력하고 앱 런타임과 같은 중요한 부팅 구성요소를 수용할 수 있습니다.

Mainline은 단순한 기술 솔루션이 아니라 Android의 더 많은 부분을 Google은 기기 제조업체와 협상하여 모두 동일한 블록을 배송하는 데 동의하도록 합니다. 암호. Mainline 모듈은 결국 출하 시 의무 사항이 되므로 Mainline은 실제로 단일 에코시스템 전체 모듈이 모든 사람의 요구를 충족하는지 확인하기 위해 장치 제조업체와 대규모 협업을 수행합니다. 모든 메인라인 모듈이 매우 강력한 APEX 모듈인 것은 아닙니다. 일부는 현재 Google에서 배포하는 Android 코드인 APK일 뿐입니다.

프로젝트 메인라인 — 모듈

Android 10에서 Google은 13개의 특정 메인라인 모듈을 포함하도록 의무화했습니다. Android 11에서는 총 필수 모듈 수가 25개입니다. 다음은 몇 가지 주요 세부 정보와 함께 전체 목록입니다.

위 열에 대한 컨텍스트를 제공하기 위해 'Android 11로 업그레이드 또는 출시된 기기'라는 제목의 열에는 모듈이 있어야 하는지(또는 없어야 하는지)에 대한 세부정보가 포함되어 있습니다. 대체 항목이 포함되어 있기 때문에 표준 시간대 데이터의 경우) Android 11로 업그레이드되었거나 출시되지 않은 Android 11로 출시되는 모든 기기에 있음 상자. 마찬가지로 Android 10으로 출시되는 기기는 몇 가지 모듈을 포함해야 하며 다른 몇 가지를 포함하는 것이 좋습니다. 나머지는 지원되지 않습니다. Android 10으로 업그레이드된 기기의 경우(Android로 출시된 것과는 반대로) 필요한 모듈 목록이 더 짧습니다.

각 Mainline 모듈은 무엇을 합니까?

다음은 각 Mainline 모듈에 대한 간략한 설명입니다.

ADBD

adbd 모듈은 명령줄 adb 및 IDE 디버깅 세션을 관리합니다. adbd를 모듈화하면 Google에서 성능 개선 및 버그 수정을 더 빠르게 제공할 수 있습니다. 과거의 일부 버그는 배터리 소모와 관련이 있었고 전화기가 죽을 때까지 장치가 100% CPU를 계속 사용하도록 만들 수 있었기 때문에 이는 매우 중요합니다. 따라서 이러한 수정 사항을 적용하는 것은 Google에 매우 중요합니다. adb는 앱 개발자와 OEM에서 테스트용으로 널리 사용되기 때문입니다.

Android 신경망 API 런타임

이것은 앱과 백엔드 드라이버 사이에 있는 라이브러리입니다. API는 모바일 장치에서 계산 집약적인 기계 학습 작업을 실행하고 하드웨어 가속 추론 작업을 활성화하기 위한 Android C API입니다.

셀 브로드 캐스트

셀 브로드캐스트는 긴급 및 비긴급 경보(예: AMBER 경보)를 나타냅니다. 이 모듈은 이러한 경고와 관련된 작업과 SMS 디코딩 및 무선 긴급 경고를 위한 지오펜싱과 같은 기타 보조 기능과 관련이 있습니다.

콘크립트

Conscrypt 모듈은 Android의 TLS 구현 및 키 생성기, 암호 및 메시지 다이제스트와 같은 기타 암호화 기능을 처리합니다. 이를 모듈로 배송하면 Google에서 OTA 업데이트에 의존하지 않고도 보안 개선을 가속화할 수 있습니다.

DNS 리졸버

이름에서 알 수 있듯이 DNS 확인자는 DNS를 확인합니다. 즉, 사람이 읽을 수 있는 URL을 IP 주소로 변환합니다. 이 모듈에는 DNS 스텁 리졸버를 구현하는 코드가 포함되어 있으며 이를 모듈로 배송하면 Google에서 DNS 가로채기 및 구성 업데이트 공격에 대해 더 나은 사용자 보호를 제공할 수 있습니다.

문서 UI

문서 UI는 문서 권한을 처리하는 구성 요소의 특정 파일에 대한 액세스 제어를 담당하는 모듈입니다. Google이 명시한 것처럼 스토리지 액세스 및 권한을 모듈로 만들면 최종 사용자의 개인정보 보호 및 보안이 강화되는 반면 RRO(런타임 리소스 오버레이) 기능을 통해 OEM은 필요한 경우 환경(파일 앱 참조)을 테마로 지정할 수 있습니다. 에게. 모듈로서 모든 Google-Android 기기는 동일한 문서 UI 환경과 함께 배송됩니다.

ExtServices

이 모듈에는 알림 순위, 자동 채우기 텍스트 일치 전략, 스토리지 캐시, 패키지 감시 장치 및 기타 서비스와 같은 핵심 OS 기능을 위한 프레임워크 구성 요소가 포함되어 있습니다.

IPsec/IKEv2 라이브러리

이 라이브러리 모듈은 Interworking Wireless LAN과 관련된 새로운 기능과 기존 기능에 관심이 있습니다. (IWLAN) 및 VPN(예: 키, 알고리즘 및 터널과 같은 보안 매개변수 협상) 구성. 이러한 기능을 모듈화하는 아이디어는 생태계 일관성을 촉진하고 보안 및 상호 운용성 문제에 대한 빠른 수정을 제공하는 방법을 제공하는 것입니다.

이들은 3개의 분기된 모듈이지만 서로 의존하는 기능을 가지고 있습니다. 이러한 미디어 모듈은 미디어 유형 및 코드를 처리하고, ExoPlayer와 상호 작용하고, 전송 제어 및 재생 정보를 프레임워크에 노출하고, 인덱싱된 메타데이터를 최적화하는 등의 작업을 수행합니다. 기억하다 안드로이드를 바꾼 익스플로잇, Stagefright 그리고 플랫폼에 대한 월별 보안 업데이트라는 개념을 가져왔습니까? 이 익스플로잇은 미디어 재생 라이브러리 내의 취약점에 의존했습니다. 따라서 미디어 구성요소의 모듈화를 통해 Google은 자주 표적이 되는 이 구성요소에서 보안 버그가 발견되는 경우 신속하고 광범위하게 대응할 수 있습니다.

이 모듈의 기능은 목적이 아니지만 이름에서 즉시 명확합니다. 모듈 메타데이터 모듈에는 장치의 모듈 목록에 대한 메타데이터가 포함되어 있습니다. 그게 전부입니다.

네트워크 스택 구성 요소, 네트워크 스택 권한 구성, 종속 포털 로그인

네트워크 스택 구성 요소 모듈은 공통 IP 서비스, 네트워크 연결 모니터링, 캡티브 로그인 포털 감지를 제공합니다. 권한 구성 모듈은 다른 모듈이 네트워크 관련 작업을 수행할 수 있도록 하는 권한을 정의합니다. 종속 포털 로그인 모듈은 종속 포털(종속 포털)을 처리합니다. 사용자가 인터넷을 얻기 위해 세부 정보를 입력하라는 메시지가 표시되는 특정 공용 Wi-Fi 네트워크에 연결됨 입장.

권한 컨트롤러

이 모듈은 권한 부여 및 관리에 관한 업데이트 가능한 개인 정보 보호 정책 및 UI 요소를 제공합니다. 이것이 Package Installer가 수행하는 작업에 익숙하게 들리기 때문입니다. 런타임 권한 부여, 관리 및 사용 추적과 같은 기능은 Android 9까지 Package Installer 앱의 일부였습니다. Android 10에서 Package Installer 앱은 권한 논리를 업데이트할 수 있도록 섹션으로 분할됩니다. 권한 컨트롤러 모듈은 APK 파일로 제공되며, Android 11에서는 모듈이 장기간 사용되지 않은 앱의 런타임 권한을 자동으로 취소할 수 있습니다.

SDK 확장

이 모듈은 이해하기 어렵고 결과적으로 설명하기가 약간 어렵습니다. 모든 Android 릴리스에는 SDK 수준이 할당됩니다(일반적으로 이전 버전에서 +1). 앱이 특정 SDK를 대상으로 하는 경우 개발자가 Android 릴리스와 함께 가져온 플랫폼 동작 및 API 변경 사항을 고려했다고 가정합니다.

SDK 확장 모듈은 장치의 "확장 SDK" 수준을 결정하고 앱이 확장 SDK 수준을 쿼리하도록 API를 노출합니다. 그것이 공식 문서에서 언급하는 모든 것입니다. 아르스테크니카, 그래도 언급 Play 스토어를 통해 배송될 보조 API 레이어일 가능성이 높습니다.

Statsd, Telemetry Train 버전 패키지

Statsd는 디바이스 메트릭 수집을 담당합니다. 반면 Telemetry Train Version Package에는 활성 코드나 자체 기능이 포함되어 있지 않습니다. 여기에는 Google에서 메트릭 관련 모듈 집합이라고 말하는 "Telemetry Train"의 버전 번호가 포함되어 있습니다. 버전 번호에 따라 Google Play는 보안 패치 버전을 최종 사용자에게 표시하고 메트릭 관련 모듈에 대한 업데이트가 있는지 파악합니다.

테더링

테더링 모듈은 Wi-Fi, USB, Bluetooth 또는 이더넷을 통해 연결된 다른 클라이언트 장치와 장치의 인터넷 연결을 공유합니다. 이 모듈에는 테더링 구성 요소와 해당 종속성이 포함됩니다. OEM은 이 테더링 모듈을 사용하여 단일 표준 참조 구현에 의존하고 여러 장치에서 일관된 경험을 제공할 수 있습니다.

시간대 데이터

시간대 데이터 모듈은 Android 기기의 DST(일광 절약 시간제) 및 시간대를 업데이트하여 데이터를 모두 표준화합니다. 종교적, 정치적, 지정학적 이유에 따라 다소 자주 변경됨) 및 생태계 전반의 업데이트 메커니즘. Android 8.1 및 Android 9는 APK 기반 시간대 데이터 업데이트 메커니즘을 사용했으며 Android 10은 이를 APEX 기반 모듈 업데이트 메커니즘으로 대체합니다. Google은 AOSP가 APK 기반 업데이트에 필요한 플랫폼 코드를 계속 포함하고 있다고 말합니다. Android 10으로 업그레이드하는 기기는 다음을 통해 파트너가 제공하는 시간대 데이터 업데이트를 계속 받을 수 있습니다. APK. 그러나 Google은 APK 기반 업데이트가 APEX 기반 업데이트를 대체한다고 경고합니다.

와이파이

Wi-Fi 기능을 위한 모듈입니다. 최종 사용자는 이제 Android 기기에서 일관된 Wi-Fi 경험을 얻을 수 있을 뿐만 아니라 모듈 업데이트, 앱을 통해 상호 운용성 문제를 해결할 수 있습니다. 개발자는 플랫폼 조각화를 줄일 수 있고 OEM은 통신사 요구 사항을 충족하는 동시에 개별 비용을 절감할 수 있습니다. 커스터마이제이션.

---

바라건대, 이 기사는 Project Mainline이 Google의 Android 생태계에 얼마나 중요한지를 강조합니다.