Tuesday, March 5, 2024

AOSP 빌드와 Fastboot 플래싱: 안드로이드 시스템의 근간을 탐험하다
  /   No comments   

안드로이드(Android)는 오늘날 전 세계 모바일 운영체제의 절대적인 강자로 자리매김했습니다. 하지만 대부분의 사용자는 제조사가 제공하는 정제된 형태의 안드로이드만을 경험합니다. 이 세련된 인터페이스 이면에는 거대한 오픈 소스 프로젝트와 시스템의 가장 깊은 곳을 제어할 수 있는 강력한 도구들이 존재합니다. 그 핵심에 바로 AOSP(Android Open Source Project)와 Fastboot가 있습니다. 이 두 가지는 단순한 기술 용어를 넘어, 안드로이드의 개방성을 상징하며 개발자, 연구원, 그리고 순수한 기술 애호가들에게 무한한 가능성의 문을 열어줍니다.

AOSP는 구글이 주도하는 안드로이드의 원시 소스 코드 그 자체이며, 우리가 사용하는 모든 안드로이드 스마트폰의 유전적 원형입니다. Fastboot는 이 원시 코드를 컴파일하여 만들어진 시스템 이미지를 디바이스의 '뼈대'에 해당하는 플래시 메모리에 직접 새겨 넣는 외과수술용 메스와도 같은 도구입니다. 이 글에서는 AOSP를 직접 빌드하고 Fastboot를 통해 디바이스에 생명을 불어넣는 전 과정을 심도 있게 탐험하며, 안드로이드 시스템의 근본적인 작동 원리를 이해하는 여정을 시작할 것입니다. 이는 단순히 커스텀 펌웨어를 설치하는 방법을 넘어, 소프트웨어가 하드웨어를 어떻게 지배하고 제어하는지에 대한 통찰을 제공할 것입니다.

1. 안드로이드 오픈 소스 프로젝트(AOSP)의 본질

AOSP는 'Android Open Source Project'의 약자로, 그 이름이 말해주듯 안드로이드 운영체제의 기반을 이루는 모든 소스 코드를 담고 있는 거대한 공개 프로젝트입니다. 이는 특정 회사의 소유물이 아닌, 전 세계 개발자들이 접근하고, 수정하며, 기여할 수 있는 인류의 공동 자산과도 같습니다. 우리가 흔히 '순정 안드로이드'라고 부르는 구글 픽셀(Pixel) 폰의 운영체제부터, 삼성의 One UI, 샤오미의 MIUI에 이르기까지 모든 안드로이드 변종은 AOSP라는 단일한 뿌리에서 파생된 가지들입니다.

AOSP와 상용 안드로이드: 무엇이 다른가?

AOSP를 직접 빌드하여 설치했을 때 사용자들이 가장 먼저 마주하는 차이점은 바로 '구글 앱'의 부재입니다. AOSP는 운영체제의 핵심 기능, 즉 리눅스 커널, 하드웨어 추상화 계층(HAL), 안드로이드 런타임(ART), 그리고 시스템 UI, 전화, 연락처와 같은 기본 애플리케이션 프레임워크만을 포함합니다.

반면, 우리가 시중에서 구매하는 스마트폰에 설치된 안드로이드는 AOSP 위에 구글 모바일 서비스(Google Mobile Services, GMS)라는 독점 소프트웨어 패키지가 추가된 형태입니다. GMS에는 구글 플레이 스토어, 구글 맵, Gmail, 유튜브 등 우리가 안드로이드 생태계의 핵심으로 여기는 서비스들이 포함됩니다. 이 GMS는 오픈 소스가 아니며, 구글과의 라이선스 계약을 통해 제조사들에게만 제공됩니다. 따라서 AOSP는 안드로이드의 '뼈대'이며, GMS는 그 위에 부가가치를 더하는 '근육과 신경'이라고 비유할 수 있습니다. AOSP 개발은 이 뼈대를 직접 조립하고 이해하는 과정입니다.

AOSP 소스 코드 구조 탐험

AOSP 소스 코드는 수백만 줄의 코드로 이루어진 방대한 집합체이며, 그 구조를 이해하는 것은 빌드 과정을 이해하는 첫걸음입니다. 주요 디렉터리들은 각각 명확한 역할을 수행합니다.

  • build/: 안드로이드 빌드 시스템의 핵심이 담겨 있습니다. Make 파일, 스크립트, 설정 파일들이 위치하며, 전체 빌드 프로세스를 관장합니다.
  • frameworks/: 안드로이드 애플리케이션 프레임워크의 핵심 소스 코드가 위치합니다. 액티비티 매니저, 윈도우 매니저 등 앱 개발자들이 사용하는 API의 실제 구현부가 여기에 있습니다.
  • bionic/: 안드로이드 시스템을 위한 표준 C 라이브러리입니다. 기존의 GNU C 라이브러리(glibc)와 달리, 임베디드 환경에 최적화되어 가볍고 빠릅니다.
  • art/: 안드로이드 런타임(ART) 관련 소스 코드입니다. 앱의 바이트코드를 기계어로 변환하고 실행하는 역할을 담당합니다.
  • kernel/: 리눅스 커널 소스 코드입니다. 안드로이드는 리눅스 커널 위에서 동작하므로, 하드웨어 드라이버와 기본적인 시스템 프로세스 관리는 이 커널이 담당합니다.
  • device/: 각 제조사와 디바이스별 하드웨어 관련 설정 파일 및 드라이버(BLOB) 정보가 담겨 있습니다. 예를 들어, device/google/crosshatch/는 Pixel 3 XL 기기를 위한 파일들을 포함합니다.
  • vendor/: 제조사별 독점 라이브러리나 애플리케이션이 위치하는 공간입니다. AOSP 자체에는 내용이 거의 없지만, 실제 디바이스용 빌드에서는 중요한 역할을 합니다.
  • packages/: 전화, 연락처, 설정, 런처 등 기본적인 시스템 앱들의 소스 코드가 들어있습니다.

이러한 구조를 이해하면, 특정 기능을 수정하거나 문제를 해결할 때 어느 부분을 살펴보아야 할지 파악하는 데 큰 도움이 됩니다.

2. AOSP 빌드 시스템: 소스 코드에서 실행 가능한 이미지로

AOSP 소스 코드를 실제 디바이스에서 동작하는 운영체제로 만드는 과정을 '빌드(build)'라고 합니다. 이 과정은 수많은 소스 파일을 컴파일하고, 라이브러리를 연결하며, 최종적으로 디바이스에 플래싱할 수 있는 여러 이미지 파일(.img)로 패키징하는 복잡한 작업의 연속입니다.

빌드 환경 준비: 성공의 반

AOSP 빌드는 상당한 컴퓨팅 자원을 요구하며, 특정 환경에서만 원활하게 진행됩니다. 실패를 최소화하기 위해 철저한 준비가 필수적입니다.

  • 운영체제: AOSP 빌드는 공식적으로 우분투(Ubuntu) LTS 버전을 비롯한 특정 리눅스 배포판에서만 지원됩니다. macOS도 가능하지만 일부 제약이 따르며, Windows는 WSL(Windows Subsystem for Linux)을 통해 가능하지만 권장되지 않습니다.
  • 하드웨어 사양: 최소 16GB 이상의 RAM과 300GB 이상의 여유 저장 공간이 필요합니다. 소스 코드 자체의 용량도 크지만, 빌드 과정에서 생성되는 중간 파일과 최종 결과물의 용량이 상당하기 때문입니다. CPU 코어 수가 많을수록 빌드 속도가 비약적으로 향상됩니다.
  • 필수 패키지 설치: 빌드에 필요한 다양한 도구들을 미리 설치해야 합니다. Git, Python, Java Development Kit(JDK), C/C++ 컴파일러(GCC/Clang) 및 각종 라이브러리가 포함됩니다. 구글의 AOSP 공식 문서에는 필요한 패키지를 한 번에 설치할 수 있는 명령어가 친절하게 안내되어 있습니다.
$ sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5-dev lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

소스 코드 다운로드: 'Repo' 도구 활용

AOSP는 수백 개의 Git 저장소(repository)로 구성되어 있어, 이를 하나씩 클론하는 것은 거의 불가능합니다. 구글은 이 문제를 해결하기 위해 'Repo'라는 도구를 제공합니다. Repo는 여러 Git 저장소를 한 번에 관리하고 동기화할 수 있게 해주는 래퍼 스크립트입니다.

  1. Repo 설치: 먼저 Repo 도구를 다운로드하고 실행 권한을 부여합니다. 
    $ mkdir -p ~/.bin
$ PATH=~/.bin:$PATH
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo
$ chmod a+x ~/.bin/repo
  2. 저장소 초기화 (repo init): 소스 코드를 다운로드할 디렉터리를 만들고, 어떤 버전(브랜치)의 AOSP를 받을지 지정합니다. -u 옵션으로 매니페스트(manifest) 저장소의 URL을, -b 옵션으로 브랜치 이름을 지정합니다. 예를 들어, 안드로이드 12 소스를 받으려면 다음과 같이 실행합니다. 
    $ mkdir aosp
$ cd aosp
$ repo init -u https://android.googlesource.com/platform/manifest -b android-12.0.0_r1
  3. 소스 코드 동기화 (repo sync): 초기화가 완료되면, 실제 소스 코드 다운로드를 시작합니다. 이 과정은 네트워크 속도와 서버 상태에 따라 수 시간이 소요될 수 있습니다. -j 옵션으로 병렬 다운로드 스레드 수를 지정하여 속도를 높일 수 있습니다. 
    $ repo sync -j8

빌드 프로세스 3단계

소스 코드 다운로드가 완료되면, 본격적인 빌드 과정에 돌입합니다. 이 과정은 크게 세 단계의 명령어로 이루어집니다.

1. 환경 설정 스크립트 실행 (source build/envsetup.sh)

가장 먼저 실행해야 하는 이 명령어는 현재 셸(shell) 세션에 AOSP 빌드에 필요한 환경 변수와 여러 유용한 헬퍼 함수들을 로드합니다. source 명령어는 스크립트의 내용을 현재 셸의 컨텍스트에서 실행하라는 의미입니다. 이 명령을 실행하면 lunch, m, croot 등 빌드를 위한 전용 명령어들을 사용할 수 있게 됩니다. 

$ source build/envsetup.sh
including device/google/cuttlefish/vendorsetup.sh
... (이하 생략)

2. 빌드 타겟 선택 (lunch)

lunch 명령어는 '어떤 기기'를 위해 '어떤 종류'의 빌드를 할 것인지 선택하는 과정입니다. 아무 인자 없이 lunch를 실행하면 선택 가능한 모든 타겟 목록이 나타나며, 여기서 원하는 타겟의 번호를 입력하거나 전체 이름을 직접 입력할 수 있습니다. 

$ lunch

Lunch menu... pick a combo:
     1. aosp_arm-eng
     2. aosp_arm64-eng
     ...
     35. aosp_crosshatch-userdebug
     ...

Which would you like? [aosp_arm-eng] 35

타겟의 이름은 PRODUCT-VARIANT 형식으로 구성됩니다.

  • PRODUCT: 빌드의 대상이 되는 제품 또는 기기를 의미합니다. (예: aosp_crosshatch는 Pixel 3 XL)
  • VARIANT: 빌드의 종류를 의미하며, 주로 세 가지가 사용됩니다.
    • eng (Engineering): 엔지니어링 빌드. 루트(root) 접근이 기본적으로 활성화되어 있고, 디버깅을 위한 추가 도구들이 포함됩니다. 개발 단계에서 가장 많이 사용됩니다.
    • userdebug: 사용자 디버그 빌드. eng 빌드와 유사하지만, 일반 사용자 환경에 더 가깝게 설정되어 있습니다. 루트 접근이 가능하며 성능 테스트 등에 사용됩니다.
    • user: 최종 사용자 빌드. 우리가 시중에서 구매하는 스마트폰에 설치되는 버전입니다. 루트 접근이 비활성화되어 있고, 보안과 성능이 최적화되어 있습니다.

3. 컴파일 실행 (make)

모든 준비가 끝나면, make 명령어를 통해 실제 컴파일을 시작합니다. 이 과정에서 C/C++ 코드는 기계어로, 자바 코드는 DEX 바이트코드로 변환되고, 모든 리소스가 패키징되어 최종 이미지 파일이 생성됩니다. 

$ make -j16

-jN 옵션은 빌드 작업을 병렬로 수행할 스레드의 수를 지정합니다. 일반적으로 CPU 코어 수의 1~2배 사이의 값을 사용하는 것이 효율적입니다. 이 과정은 시스템 사양에 따라 수십 분에서 수 시간까지 걸릴 수 있습니다.

빌드 결과물 확인

빌드가 성공적으로 완료되면, 모든 결과물은 out/target/product/<PRODUCT_NAME>/ 디렉터리에 생성됩니다. 여기서 <PRODUCT_NAME>은 lunch에서 선택한 제품 이름입니다 (예: crosshatch). 이 디렉터리에서 Fastboot로 플래싱할 핵심 이미지 파일들을 찾을 수 있습니다.

  • boot.img: 리눅스 커널과 램디스크(ramdisk)를 포함하는 이미지. 부팅 과정의 가장 초기 단계를 담당합니다.
  • system.img: 안드로이드 프레임워크와 시스템 앱 등 운영체제의 핵심부가 담긴 파티션 이미지입니다.
  • vendor.img: 하드웨어와 관련된 독점 드라이버 및 라이브러리가 포함된 이미지입니다.
  • userdata.img: 사용자 데이터 파티션의 초기 이미지입니다. 이 이미지를 플래싱하면 기기의 모든 사용자 데이터가 초기화됩니다.
  • vbmeta.img: 안드로이드 검증 부팅(Verified Boot)을 위한 메타데이터를 담고 있습니다.
  • dtbo.img: 디바이스 트리 오버레이(Device Tree Overlay) 이미지로, 하드웨어 구성을 동적으로 로드하는 데 사용됩니다.

이제 이 이미지 파일들을 디바이스에 설치할 준비가 모두 끝났습니다. 이 '설치' 과정을 담당하는 도구가 바로 Fastboot입니다.

3. Fastboot 프로토콜과 작동 원리

Fastboot는 안드로이드 디바이스의 부트로더(Bootloader)와 직접 통신하여 플래시 메모리의 파티션을 읽고, 쓰고, 지울 수 있게 해주는 프로토콜이자 커맨드 라인 도구입니다. 안드로이드 운영체제가 부팅되기 이전의 가장 낮은 레벨에서 작동하기 때문에, 시스템이 완전히 손상되어 부팅되지 않는 '벽돌' 상태의 디바이스를 복구하는 데에도 사용될 수 있는 매우 강력한 유틸리티입니다.

Fastboot의 작동 방식: 클라이언트와 호스트

Fastboot는 간단한 클라이언트-호스트 모델로 작동합니다.

  • 클라이언트: 개발자의 컴퓨터에서 실행되는 fastboot 커맨드 라인 프로그램입니다. 사용자가 입력한 명령어를 USB를 통해 디바이스로 전송하는 역할을 합니다.
  • 호스트 (또는 서버): 안드로이드 디바이스의 부트로더에 구현된 Fastboot 프로토콜 수신부입니다. 컴퓨터로부터 명령을 받아 플래시 메모리에 실제 작업을 수행합니다.
이 통신이 이루어지기 위해서는 디바이스가 일반적인 안드로이드 모드가 아닌, 'Fastboot 모드' 또는 '부트로더 모드'로 부팅되어야 합니다.

Fastboot 사용의 필수 전제 조건

Fastboot를 사용하기 전에 반드시 몇 가지 준비 과정을 거쳐야 합니다.

1. Android SDK Platform-Tools 설치

fastboot 명령어와 그 단짝인 adb(Android Debug Bridge) 명령어는 구글에서 제공하는 'SDK Platform-Tools' 패키지에 포함되어 있습니다. 구글 공식 웹사이트에서 다운로드하여 시스템 경로에 추가해야 터미널 어디에서든 명령어를 실행할 수 있습니다.

2. 디바이스 USB 드라이버 설치

컴퓨터가 Fastboot 모드의 디바이스를 올바르게 인식하려면 해당 디바이스 제조사에서 제공하는 USB 드라이버가 필요합니다. 특히 Windows 사용자의 경우, 이 드라이버가 제대로 설치되지 않으면 'device not found' 오류의 주된 원인이 됩니다.

3. 부트로더 언락 (Bootloader Unlocking)

이것은 Fastboot 사용에서 가장 중요하고 위험한 단계입니다. 대부분의 상용 안드로이드 디바이스는 보안상의 이유로 부트로더가 잠겨(locked) 있습니다. 부트로더가 잠겨 있으면, 제조사가 서명한 공식 펌웨어만 플래싱할 수 있으며, fastboot flash와 같은 민감한 명령어는 거부됩니다. AOSP 빌드와 같은 비공식 이미지를 설치하려면 반드시 부트로더를 언락(unlock)해야 합니다.

부트로더 언락 과정은 다음과 같습니다:

  1. 개발자 옵션 활성화: 디바이스의 '설정 > 휴대전화 정보 > 빌드 번호' 항목을 7번 연속으로 탭하여 개발자 옵션을 활성화합니다.
  2. OEM 잠금 해제 활성화: '설정 > 시스템 > 개발자 옵션'으로 이동하여 'OEM 잠금 해제' 옵션을 켭니다. 이 옵션은 부트로더 언락을 허용하는 스위치 역할을 합니다.
  3. Fastboot 모드로 재부팅: 디바이스를 컴퓨터에 연결하고, 터미널에서 adb reboot bootloader 명령을 실행하거나, 전원이 꺼진 상태에서 특정 키 조합(보통 볼륨 다운 + 전원 버튼)을 눌러 Fastboot 모드로 진입합니다.
  4. 언락 명령어 실행: 터미널에서 다음 명령어를 실행합니다. (구형 기기는 fastboot oem unlock) 
    $ fastboot flashing unlock
  5. 디바이스에서 확인: 명령어 실행 후, 디바이스 화면에 부트로더를 언락할 것인지 묻는 확인 메시지가 나타납니다. 이때 언락을 진행하면 디바이스의 모든 사용자 데이터(사진, 앱, 연락처 등)가 즉시 삭제된다는 경고가 표시됩니다. 이는 보안 조치로, 도난된 디바이스의 데이터에 접근하는 것을 방지하기 위함입니다. 볼륨 키로 'Yes'를 선택하고 전원 키로 확인하면 언락이 완료되고 디바이스가 재부팅됩니다.

부트로더가 언락된 디바이스는 부팅 시 경고 메시지를 표시하며, 일부 보안에 민감한 앱(예: 금융 앱)이 작동하지 않을 수 있습니다. 하지만 이는 AOSP 개발과 커스터마이징을 위한 필수적인 통과 의례입니다.

4. Fastboot 명령어 심층 분석

Fastboot는 단순한 플래싱 도구를 넘어, 디바이스의 상태를 확인하고 파티션을 관리하며 부팅 프로세스를 제어하는 다양한 명령어를 제공합니다.

기본 및 정보 확인 명령어

  • fastboot devices: 현재 컴퓨터에 연결되어 Fastboot 모드로 인식된 디바이스의 시리얼 번호를 출력합니다. 아무것도 출력되지 않는다면 드라이버 문제나 케이블 연결 불량을 의심해야 합니다.
  • fastboot reboot: 디바이스를 정상적으로 안드로이드 시스템으로 재부팅합니다.
  • fastboot reboot bootloader: 현재 Fastboot 모드에서 다시 Fastboot 모드로 재부팅합니다. 드라이버 문제 해결 후 다시 연결을 시도할 때 유용합니다.
  • fastboot getvar [VARIABLE]: 부트로더가 가지고 있는 다양한 변수 값을 조회합니다. 예를 들어, fastboot getvar product는 제품 이름을, fastboot getvar all은 모든 변수 정보를 한 번에 보여줍니다. 이를 통해 현재 부트로더 상태, 파티션 정보, 시리얼 번호 등을 상세히 확인할 수 있습니다.

플래싱 및 파티션 관리 명령어

  • fastboot flash [PARTITION] [FILENAME.img]: Fastboot의 핵심 기능입니다. 지정된 파티션에 로컬 이미지 파일을 플래싱(쓰기)합니다. 
    # 부트 파티션에 boot.img 파일 플래싱
$ fastboot flash boot boot.img

# 시스템 파티션에 system.img 파일 플래싱
$ fastboot flash system system.img
  • fastboot flashall: 현재 디렉터리에 있는 boot.img, system.img 등 표준 이미지 세트를 자동으로 순서에 맞게 플래싱해주는 편리한 스크립트입니다. -w 옵션을 함께 사용하면 userdata 파티션까지 초기화하여 클린 설치를 진행합니다. 구글 팩토리 이미지를 설치할 때 주로 사용됩니다.
  • fastboot erase [PARTITION]: 특정 파티션의 데이터를 완전히 삭제합니다. fastboot flash 전에 파티션을 깨끗하게 정리할 때 사용될 수 있습니다.
  • fastboot format [PARTITION]: 특정 파티션을 지정된 파일 시스템(예: ext4, f2fs)으로 포맷합니다. erase보다 더 낮은 레벨의 초기화 작업입니다.

고급 개념과 관련 명령어

A/B (Seamless) 업데이트

최신 안드로이드 디바이스들은 시스템 안정성과 원활한 백그라운드 업데이트를 위해 A/B 파티션 구조를 사용합니다. 이는 boot, system 등 주요 파티션이 A 슬롯과 B 슬롯, 두 벌씩 존재하는 방식입니다. 사용자가 A 슬롯으로 부팅하여 시스템을 사용하는 동안, OTA 업데이트는 비활성 상태인 B 슬롯에 설치됩니다. 설치가 완료되고 다음 재부팅 시, 부트로더는 부팅 슬롯을 B로 전환하여 업데이트된 시스템으로 매끄럽게 부팅합니다.

이러한 구조에서 Fastboot 명령어는 슬롯을 명시적으로 지정해야 합니다.

  • fastboot --set-active=a 또는 fastboot --set-active=b: 다음 부팅 시 활성화할 슬롯을 지정합니다.
  • fastboot flash boot_a boot.img: A 슬롯의 부트 파티션에 플래싱합니다.
  • fastboot getvar current-slot: 현재 활성화된 슬롯이 어느 쪽인지 확인합니다.

동적 파티션 (Dynamic Partitions)

안드로이드 10부터 도입된 동적 파티션은 OTA 업데이트의 유연성을 높이기 위한 기술입니다. 과거에는 system, vendor, product 파티션의 크기가 고정되어 있어, 한 파티션의 공간이 부족해도 다른 파티션의 남는 공간을 활용할 수 없었습니다. 동적 파티션은 이들을 하나의 거대한 물리적 파티션인 super.img 안에 논리적인 파티션으로 통합 관리합니다. 따라서 각 논리 파티션의 크기를 OTA 업데이트 시 유연하게 조절할 수 있습니다.

이 구조에서는 개별 이미지를 플래싱하는 대신, 모든 논리 파티션을 포함하는 super.img를 통째로 플래싱해야 합니다. 

$ fastboot flash super super.img

임시 부팅 (Temporary Boot)

  • fastboot boot [IMAGE.img]: 이 명령어는 이미지를 플래시 메모리에 영구적으로 쓰지 않고, RAM에 로드하여 일회성으로 부팅시킵니다. 주로 TWRP와 같은 커스텀 리커버리 이미지를 설치 전에 테스트하는 용도로 매우 유용하게 사용됩니다. 
    # twrp.img 파일을 플래싱하지 않고 임시로 부팅
$ fastboot boot twrp.img

5. 실전: AOSP 빌드부터 플래싱까지의 전 과정

이제 이론적 지식을 바탕으로, AOSP 소스 코드를 다운로드하여 빌드하고, 그 결과물을 실제 디바이스(예: Pixel 3 XL, 코드네임 'crosshatch')에 Fastboot를 이용해 설치하는 전체 과정을 단계별로 수행해 보겠습니다.

1단계: 환경 설정 및 소스 코드 다운로드

앞서 설명한 대로 우분투 환경을 구성하고, 필수 패키지를 설치합니다. 이후 Repo 도구를 이용해 Pixel 3 XL에 맞는 안드로이드 11 브랜치의 소스 코드를 다운로드합니다. 

# 작업 디렉터리 생성 및 이동
$ mkdir aosp_P3XL && cd aosp_P3XL

# Repo 초기화 (Android 11, Pixel 3 XL 타겟)
$ repo init -u https://android.googlesource.com/platform/manifest -b android-11.0.0_r46

# 소스 코드 동기화 (네트워크 및 CPU 상황에 맞게 -j 옵션 조절)
$ repo sync -c -j16

2단계: 독점 바이너리(Proprietary Binaries) 다운로드 및 적용

AOSP 소스 코드에는 Wi-Fi, 블루투스, 그래픽 드라이버 등 하드웨어 구동에 필수적인 독점 바이너리(BLOB)가 포함되어 있지 않습니다. 이는 구글 개발자 사이트에서 별도로 다운로드하여 소스 코드에 추가해야 합니다. 다운로드한 압축 파일들을 AOSP 소스 루트 디렉터리에서 풀면, 이를 적용하는 셸 스크립트가 포함되어 있습니다. 

# 구글 드라이버 페이지에서 'crosshatch'용 바이너리 다운로드 후 압축 해제
$ ./extract-google_devices-crosshatch.sh
$ ./extract-qcom-crosshatch.sh

스크립트를 실행하면 라이선스 동의 절차를 거친 후, 바이너리 파일들이 소스 코드 내의 vendor/ 디렉터리에 자동으로 위치하게 됩니다.

3단계: AOSP 빌드

이제 모든 준비가 끝났습니다. 빌드 환경을 설정하고, 타겟을 선택한 후, 컴파일을 시작합니다.

# 빌드 환경 설정
$ source build/envsetup.sh

# 빌드 타겟 선택 (aosp_crosshatch-userdebug)
$ lunch aosp_crosshatch-userdebug

# 빌드 시작 (CPU 코어 수에 맞게 조절)
$ make -j16

4단계: 디바이스 준비 및 Fastboot 플래싱

빌드가 수 시간에 걸쳐 완료되면 out/target/product/crosshatch/ 경로에 이미지 파일들이 생성됩니다. 이제 디바이스를 Fastboot 모드로 전환하고 플래싱을 시작합니다. 

# 디바이스를 Fastboot 모드로 전환 (ADB 사용 시)
$ adb reboot bootloader

# Fastboot 연결 확인
$ fastboot devices

# 부트로더, 라디오 등 펌웨어 이미지 플래싱
$ fastboot flash bootloader bootloader-crosshatch-[version].img
$ fastboot flash radio radio-crosshatch-[version].img
$ fastboot reboot-bootloader

# 시스템 이미지 플래싱
$ fastboot flash boot boot.img
$ fastboot flash dtbo dtbo.img
$ fastboot flash vbmeta vbmeta.img

# A/B 슬롯을 사용하는 기기이므로, system, vendor 등을 포함하는 zip 파일을 업데이트
# (AOSP 빌드는 update.zip도 생성해줌)
$ fastboot update image-aosp_crosshatch-ota-eng.[username].zip

# 사용자 데이터 초기화 (선택 사항, 클린 설치 시 권장)
$ fastboot -w

# 시스템 재부팅
$ fastboot reboot

5단계: 설치 결과 확인

모든 과정이 성공적으로 끝났다면, 디바이스는 잠시 후 AOSP 로고를 보여주며 부팅을 시작할 것입니다. 초기 부팅은 시간이 다소 걸릴 수 있습니다. 부팅이 완료되면, GMS가 없는 순수한 AOSP의 모습을 확인할 수 있습니다. 이제 당신은 자신만의 안드로이드 운영체제를 빌드하고 설치하는 데 성공한 것입니다.

6. 문제 해결 및 고급 팁

AOSP 빌드와 플래싱 과정은 복잡한 만큼 다양한 문제에 직면할 수 있습니다. 일반적인 문제와 해결책을 알아두는 것은 필수입니다.

흔히 발생하는 빌드 오류

  • Out of Memory (메모리 부족): 빌드 중 시스템이 멈추거나 'Jack server' 관련 오류가 발생한다면, RAM이나 스왑(swap) 공간이 부족할 가능성이 높습니다. -j 옵션 값을 낮추거나, RAM을 증설하거나, 스왑 파일을 생성하여 해결할 수 있습니다.
  • Missing Dependencies (의존성 패키지 누락): 빌드 초기 단계에서 특정 도구나 라이브러리를 찾을 수 없다는 오류가 발생하면, 빌드 환경 준비가 미흡한 것입니다. 오류 메시지를 잘 읽어보고 필요한 패키지를 apt-get 등으로 설치해야 합니다.
  • JDK 버전 불일치: 구형 안드로이드 버전은 구형 JDK를, 최신 버전은 최신 JDK를 요구합니다. AOSP 공식 문서에서 빌드하려는 버전에 맞는 JDK 버전을 확인하고 설치해야 합니다.

플래싱 실패 시 대처법

  • < waiting for device > 또는 device not found: Fastboot가 디바이스를 인식하지 못하는 상태입니다. USB 드라이버 설치 여부, USB 케이블의 데이터 전송 지원 여부, USB 포트 상태를 순서대로 확인해야 합니다.
  • FAILED (remote: 'partition does not exist'): 존재하지 않는 파티션에 플래싱을 시도할 때 발생합니다. 파티션 이름을 정확히 입력했는지, 해당 디바이스의 파티션 레이아웃이 맞는지 확인해야 합니다.
  • FAILED (remote: 'flashing is not allowed in locked state'): 부트로더가 잠겨 있는 상태에서 플래싱을 시도할 때 발생하는 명백한 오류입니다. 부트로더 언락을 먼저 진행해야 합니다.

부팅 실패(부트루프) 시 디버깅

플래싱 후 디바이스가 부팅 로고 화면에서 넘어가지 않는 '부트루프(bootloop)'에 빠지는 것은 가장 흔한 문제입니다.

  1. 데이터 초기화: 가장 먼저 시도해볼 방법은 Fastboot를 통해 userdata와 cache 파티션을 초기화하는 것입니다 (fastboot -w). 이전 시스템의 데이터와 충돌하여 발생하는 문제를 해결할 수 있습니다.
  2. 로그 확인 (adb logcat): 만약 디바이스가 부팅 과정 중 어느 정도 진행되어 ADB 연결이 가능하다면, adb logcat 명령을 통해 시스템 로그를 실시간으로 확인할 수 있습니다. 로그에서 'Fatal' 또는 'Error' 메시지를 찾아 문제의 원인이 되는 프로세스나 서비스를 파악할 수 있습니다.
  3. 순정 펌웨어로 복구: 모든 방법이 실패했을 때, 최후의 수단은 제조사에서 제공하는 순정 펌웨어(팩토리 이미지)를 Fastboot로 다시 플래싱하여 디바이스를 초기 상태로 되돌리는 것입니다. 이를 통해 최소한 디바이스를 다시 사용할 수 있는 상태로 만들고, 문제의 원인을 다시 분석할 수 있습니다.

AOSP 빌드와 Fastboot 플래싱은 안드로이드의 심장부로 들어가는 문입니다. 이 과정은 때로는 좌절감을 안겨줄 만큼 어렵고 복잡하지만, 성공적으로 마쳤을 때 얻는 성취감과 안드로이드 시스템에 대한 깊은 이해는 그 어떤 것과도 비교할 수 없습니다. 단순히 주어진 것을 사용하는 소비자를 넘어, 운영체제를 직접 만들고 제어하는 생산자의 관점을 경험하게 될 것입니다. 이 글이 여러분의 여정에 훌륭한 나침반이 되기를 바랍니다.


0 개의 댓글:

Post a Comment