Android 11은 개발자 옵션 내에 DSU 로더와 함께 제공되어 호환되는 GSI를 자동으로 다운로드하고 설치할 수 있습니다! 자세한 내용은 계속 읽어보세요!
좋은 앱 생태계는 운영 체제 성공의 가장 중요한 기둥 중 하나입니다. Google과 Apple 모두 플랫폼에서 좋은 애플리케이션을 보유하는 것의 가치를 인식하고 있으므로 두 회사 모두 사용자와 앱 개발자의 요구 사항 사이에서 균형을 맞추려고 노력합니다. 사용자는 OS의 변경을 계속 추진하고 있으며 대부분의 사람들은 일반적으로 새로운 기능을 높이 평가하지만 이러한 많은 핵심 기능과 행동. 앱의 관련성을 유지하기 위해 지속적으로 노력하는 개발자의 경우 이러한 변경 사항을 처리하는 작업이 늘어나는 작업 목록에 추가됩니다. 이러한 변경 사항이 애플리케이션에 직접적인 영향을 미치지 않더라도 개발자는 여전히 앱이 새 OS 업데이트에서 작동하는지 확인해야 합니다. Google은 Android 앱 개발자가 이 프로세스를 더 쉽게 수행할 수 있도록 수년에 걸쳐 많은 변경 작업을 수행했으며 이제 새로운 DSU 로더라고 하는 Android 11의 기능을 사용하면 앱 개발자가 새로운 Android에서 앱을 훨씬 더 쉽게 테스트할 수 있습니다. 버전.
프로젝트 트레블부터 시작합니다
Android 8.0에서 도입된 Project Treble은 주요 Android OS의 재설계. Project Treble의 목표는 Android OS를 프레임워크와 공급업체 구현이라는 두 개의 큰 덩어리로 나누는 것이었습니다. (여기서 "공급업체"는 장치 내에서 발견되는 독점 하드웨어 구성 요소의 제조업체를 말하며 일반적으로 규소). Android OS 프레임워크는 모든 시스템 앱, UI 및 해당 구성요소, Android 기기 간에 공유되는 API를 포함하는 운영 체제 자체입니다. 공급업체 구현에는 공급업체 HAL(하드웨어 추상화 계층)과 Linux 커널 및 Linux 커널 모듈이 포함됩니다.
OEM은 다양한 공급업체의 다양한 하드웨어 구성 요소가 포함된 스마트폰을 배송하기 때문에 단일 Android OS 릴리스에서 하드웨어를 가동하고 실행하기 위해 많은 작업을 수행해야 합니다. 그런 다음 새로운 Android OS 업데이트가 있을 때마다 하드웨어가 새 버전에서 작동하는지 확인하기 위해 더 많은 작업을 수행해야 합니다. 그러나 Android OS 프레임워크와 특정 Android 버전용 HAL 사이의 ABI(Application Binary Interface)를 표준화하는 Project Treble을 통해 Android OEM은 실리콘 제조업체 및 기타 구성 요소 제조업체가 측면을 업데이트할 때까지 기다릴 필요 없이 기기 업데이트 테스트를 시작할 수 있습니다. 코드. 이 변화는 눈에 띄게 빨라졌습니다.
이것이 Android 업데이트를 위해 Project Treble이 수행한 작업의 요지이지만 앱에서 더 중요한 것은 여기서 개발자는 Treble이 호환성을 위해 일반 시스템 이미지(GSI)를 사용할 수 있게 했다는 것입니다. 테스트.
GSI의 출현
OEM이 Project Treble을 제대로 구현했는지 테스트하기 위해 Google은 OEM이 기기의 AOSP에서 Android의 클린 빌드를 부팅할 수 있어야 한다고 규정합니다. 이 깨끗한 Android 빌드를 일반 시스템 이미지 또는 GSI라고 합니다. GSI가 부팅되고 대부분의 기본 하드웨어가 제대로 작동하면 OEM은 장치가 Project Treble의 요구 사항을 충족한다는 것을 알게 됩니다. 따라서 GSI의 초기 목적은 Treble 호환성을 테스트하는 것이었지만 여기 XDA-Developers의 개발 커뮤니티에서 본 것처럼 다른 목적으로도 사용할 수 있습니다. 우리는 GSI가 어떻게 기본적으로 Android UX가 많은 장치가 새 릴리스가 출시된 후 며칠 내에 작동 기능이 있는 최신 버전의 Android를 즐길 수 있습니다. 그러나 Google은 GSI의 또 다른 목적을 구상하고 있습니다. 즉, 앱 개발자가 이미 소유하고 있는 물리적 기기에서 새로운 Android 버전으로 앱을 테스트할 수 있는 기능을 제공하는 것입니다.
Android 10에서 Google은 개발자를 위한 자체 GSI 빌드를 출시했습니다. Google은 앱 개발자가 GSI를 사용하여 자신의 하드웨어에서 Android의 클린 빌드를 부팅해야 한다는 생각을 굳혔고, 기본 Android에 대해 애플리케이션의 동작을 더 쉽게 테스트할 수 있습니다. 따라서 이 방법은 OEM 동작 변경 없이 기본 Android에서 앱 호환성을 테스트하는 기존 옵션에 추가되었습니다. Pixel 스마트폰을 사용하거나, Android Studio 내의 공식 Android Emulator를 사용하거나, 앱 빌드를 클라우드의 기기 인스턴스에 배포합니다.
GSI가 제공하는 모든 편리함에도 불구하고 GSI 설치는 여전히 번거로운 과정이었습니다. 앱 개발자는 Android 기기에서 시스템 이미지를 수동으로 플래싱하는 것이 불편할 수 있습니다. 이는 일반적으로 취미 생활자나 Android OS 개발자에게만 친숙하기 때문입니다. GSI를 설치하려면 빠른 부팅을 통해 시스템 이미지를 플래싱해야 했습니다. 이를 위해서는 Android Verified Boot를 비활성화하고 부트로더를 잠금 해제해야 합니다. 부트로더 잠금 해제에는 완전한 사용자 데이터 삭제가 필요합니다. 그리고 우리 모두 알다시피 모든 Android 기기의 부트로더 잠금을 해제하기 위한 단일 프로세스나 가이드가 없기 때문에 일관성을 찾을 수 없습니다. 예를 들어, 삼성 기기에는 빠른 부팅 기능이 없지만 Xiaomi 기기에서는 부트로더 잠금을 해제하기 위해 몇 개의 후프를 통과해야 합니다. 더 단순한 것으로 풀릴 가능성이 있는 편리한 엉망입니다.
동적 시스템 업데이트가 들어오는 곳입니다.
GSI를 간단히 설치하는 동적 시스템 업데이트
Google은 GSI를 설치하는 현재 방법이 완벽한 솔루션이 아님을 깨닫고 더 나은 솔루션을 찾기 시작했습니다. 안드로이드 10에서는 Google은 동적 시스템 업데이트 테스트를 시작했습니다., 또는 DSU. DSU는 빠른 부팅 명령을 사용하여 시스템 이미지를 플래시하여 원래 설치를 덮어쓰지 않고 GSI를 임시로 설치하는 새로운 방법입니다. DSU를 사용하면 GSI로 부팅하고 앱을 테스트한 다음 변경되지 않은 원래 설치로 편리하게 재부팅할 수 있습니다.
DSU가 원래 설치를 건드리지 않고 GSI를 설치할 수 있는 이유는 임시로 저장된 새 시스템 및 데이터 파티션 이미지를 생성하기 때문입니다. /data/gsi. 그런 다음 이러한 이미지는 원래 시스템 및 데이터 파티션이 아닌 부팅 중에 마운트됩니다. 전화기에는 이러한 새로운 임시 이미지를 위한 추가 저장 공간이 필요하기 때문에 전화기에는 동적으로 크기를 조정할 수 있는 파티션인 "논리적 파티션"이 보드에 있어야 합니다. 논리 파티션은 Android용 새로운 사용자 공간 분할 시스템으로, Android 10으로 출시되는 기기에 필수입니다. 기기가 Android 10으로 실행된 경우 DSU를 통한 GSI 설치를 지원해야 합니다.
Android 10에서 수행해야 할 모든 작업 DSU를 통해 GSI 설치 시스템 속성을 변경한 다음 DynamicSystemUpdatesInstallationService 인텐트 추가로 GSI에 대한 경로가 포함된 인텐트를 전송합니다.
이 프로세스가 생소해 보일 수 있지만 사용하는 것과 비교할 때 훨씬 쉽고 덜 방해가 됩니다. fastboot 명령을 사용하고 원래 설치를 포함하여 모든 번거로움을 처리하고 닦았다. ADB에 대한 약간의 지식과 DSU를 사용하려는 의도가 필요하지만 대부분의 앱 개발자에게는 문제가 되지 않습니다. 그래도 프로세스를 더 간단하게 만들 수 없는 이유는 없습니다. 또한 DSU를 통해 GSI를 설치하려면 여전히 부트로더를 잠금 해제해야 하며 그 과정에서 모든 사용자 데이터를 삭제해야 합니다. 이를 위해 Google은 GSI 설치의 두 가지 측면을 개선하기 위한 변경 사항을 구현했습니다. Android 11에서는 GSI를 설치하기 위해 명령줄을 사용할 필요가 전혀 없습니다. 이와는 별도로 부트로더를 잠금 해제하지 않고도 GSI를 설치할 수 있도록 했습니다.
Android 11의 DSU 로더
DSU 로더는 Android 11의 개발자 옵션에 있는 새로운 도구로 다음을 수행할 수 있습니다. 다운로드 그리고 설치하다 fastboot 또는 ADB 명령을 입력할 필요 없이 Google의 최신 GSI. 설정에서 DSU 로더 옵션을 탭하기만 하면 Google에서 바로 지원되는 GSI 목록이 포함된 대화 상자가 나타납니다. 이러한 지원되는 GSI는 현재 OS 및 아키텍처를 기반으로 하므로 OS 버전보다 최신이고 SoC 아키텍처와 일치하는 GSI만 설치할 수 있습니다. 설치하려는 GSI를 선택하기만 하면 Google 서버에서 다운로드되어 자동으로 백그라운드에 설치됩니다.
DSU 로더를 사용하면 개발자는 GSI를 설치하기 위해 명령줄을 건드릴 필요가 없습니다. 아직 해결해야 할 문제가 하나 남아 있기 때문에 적어도 그것은 꿈입니다.
앞으로의 길
현재 DSU 로더를 통해 GSI를 설치하려면 잠금 해제된 부트로더가 필요합니다. 이것이 전체 시련의 목적을 무너뜨릴 수 있지만, 이런 식으로 되어서는 안 되며, 우리는 그것이 고쳐질 것이라고 들었습니다. Google은 사용자가 부트로더를 잠금 해제하지 않고도 DSU를 통해 Google 서명 GSI를 부팅할 수 있도록 계획했습니다. 실제로 Google은 다음을 요구합니다. 모든 Android 10 실행 기기에는 Android Verified Boot 공개 키가 포함되어 있습니다. Google이 서명한 Android 10, Android 11 및 Android 12 GSI의 장치의 램디스크에 AVB 공개 키를 포함하면 AVB가 부팅하려는 GSI를 거부하지 않도록 합니다. 이것이 현재 방법에 부트로더 잠금 해제가 포함되는 이유입니다. 빈 vbmeta 이미지를 vbmeta 파티션에 플래시하여 플래시하려는 GSI를 거부하지 않도록 AVB를 비활성화합니다. 그러나 AVB를 비활성화하는 것은 주요 보안 위험입니다. system/boot/product/vendor 파티션은 기기에 로드할 수 있습니다. 그 요구 사항에서 멀리.
그렇다면 부트로더를 잠금 해제하거나 명령줄 도구를 사용하지 않고도 DSU를 통해 GSI를 부팅할 수 있는 시점은 언제일까요? Google이 이 모든 것이 제대로 작동하기 전에 초기 Android 11 개발자 프리뷰에서 해결해야 할 몇 가지 문제가 있다고 언급했듯이 곧 바랍니다. 앞으로는 부트로더를 잠금 해제하지 않고도 DSU를 통해 향후 Developer Preview GSI를 설치할 수 있습니다. 아마도 Android 12 개발자 미리보기가 제공되면 Android 11의 개발자 옵션에서 DSU 로더를 사용하여 완전히 부팅할 수도 있습니다. 앱 개발자에게 이는 새로운 Android 버전을 실행하는 물리적 하드웨어에서 애플리케이션을 테스트할 수 있는 또 다른 방법이 있음을 의미합니다.