Codelab을 통해 역사상 가장 광범위하게 설치되어 있는 운영체제의 개발을 지원할 수 있습니다. 여러분은 여기에서 Android 플랫폼 엔지니어가 되기 위한 여정을 시작하게 됩니다.
쉬운 길은 아니지만 Android팀에서는 새 버전을 출시할 때마다 여러분의 여정을 간소화하기 위해 노력하고 있습니다. 또한 Android팀에서는 Android 오픈소스 프로젝트(AOSP)로 직접 작업하며 매일 개선을 이루어내고 있습니다.
이제 편하게 앉아 터미널을 켜고 역사를 함께 만들어 가세요.
목표
이 Codelab의 목표는 다음의 두 가지입니다.
- 플랫폼(운영체제)에서 작업하는 Android 엔지니어가 어떤 개발자 워크플로를 거치는지 알아봅니다.
- Android의 도구, 문서, 개발자 워크플로에 관한 의견을 제공해 봅니다.
기본 요건
이 Codelab의 요구사항 목록은 일반 플랫폼(AOSP) 개발 요구사항에서 파생됩니다. 이 Codelab을 수강하려면 다음을 설정하세요.
- 모든 공개 요구사항을 충족하는 실제 Linux 워크스테이션
- Android 코드베이스를 수정하는 데 필요한 Repo와 Git 구성
환경
일반적으로 사용자는 워크스테이션에서 직접 빌드하고 개발합니다. 다양한 터미널에서 작업할 수 있고 사용되는 명령어 중 다수가 터미널마다 다르므로 각 터미널 세션에서 명령어를 다시 실행해야 합니다. 구체적으로는 source build/envsetup.sh
및 lunch
명령어가 포함됩니다.
워크스테이션 설정
- 워크스테이션에 필수 패키지를 설치합니다.
- 터미널을 실행 중일 때 Repo를 설치하고 모든 Git 저장소의 사용자 인증 정보를 받습니다.
코드 초기화 및 동기화
홈 디렉터리로 이동합니다.
cd ~
홈 디렉터리 내에 다음과 같이 로컬 작업 하위 디렉터리를 만듭니다.
mkdir aosp
다음과 같이 디렉터리로 이동합니다.
cd aosp
다음과 같이 AOSP 저장소 소스 코드 메인 브랜치를 초기화합니다(기본값).
repo init -u https://android.googlesource.com/platform/manifest
Git 사용자 인증 정보(이름, 이메일 주소)를 입력하거나 수락합니다.
다음과 같이 소스 코드를 동기화합니다.
repo sync -j8
초기 동기화에는 1시간 이상 걸릴 수 있습니다.
각 Repo 체크아웃은 매니페스트 파일에 의해 표현됩니다. 별개의 디렉터리에 존재한다면 한 번에 둘 이상의 Repo 체크아웃이 허용됩니다. 하지만 각 체크아웃과 빌드는 약 300GB에 달하며 계속 늘어나고 있으므로 Repo 체크아웃을 2개로 제한하거나 시스템에 보조 드라이브를 장착해야 합니다.
코드 빌드
Android를 빌드하려면 타겟 기기 유형을 선택하여 lunch
명령어로 빌드해야 합니다. 타겟은 특정 모델이나 폼 팩터와 같은 기기 순열입니다.
기기 타겟 aosp_cf_x86_64_phone-userdebug
를 사용하면 실제 기기 없이 테스트할 수 있는 Cuttlefish 가상 Android 기기를 빌드할 수 있습니다.
실제 기기를 빌드하고 업데이트하려면 다른 타겟을 선택하고 기기 플래싱 관련 안내를 따르세요.
소스 코드 체크아웃의 루트에서 다음 명령어를 실행하여 Android 기기의 빌드 환경을 설정합니다.
source build/envsetup.sh
다음과 같이 빌드 타겟을 lunch 명령어에 전달합니다.
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
다음을 사용하여 체크아웃 내 어디서나 코드를 빌드하세요.
m
첫 빌드는 몇 시간이 걸릴 수 있습니다. 후속 빌드에서는 빌드 시간이 많이 짧아집니다.
Cuttlefish 실행
Cuttlefish는 빌드를 테스트할 때 사용하는 Android 에뮬레이터입니다.
Cuttlefish를 설치한 적이 없다면 필수 Cuttlefish 종속 항목을 반드시 설치해야 합니다. 터미널 창에서 다음 명령어를 실행해 호스트 Debian 패키지를 다운로드, 빌드, 설치하세요.
sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
git clone https://github.com/google/android-cuttlefish
cd android-cuttlefish
for dir in base frontend; do pushd $dir # Install build dependencies sudo mk-build-deps -i dpkg-buildpackage -uc -us popd done
sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot
재부팅하면 추가 커널 모듈 설치가 트리거되고
udev
규칙이 적용됩니다.Cuttlefish를 실행합니다.
launch_cvd --daemon
웹브라우저에서
https://localhost:8443
으로 이동해 Cuttlefish 기기에 연결하세요. 방금 빌드한 Android 기반 기기의 동영상 스트림 안내가 표시됩니다.
변경하기
이 변경 목록 예에 따라 소스 코드를 업데이트합니다.
체크아웃의 루트(
aosp/
디렉터리)에서frameworks/native
Git 프로젝트로 이동합니다.cd frameworks/native
다음 명령어를 사용하여 임시 프로젝트를 시작합니다.
repo start <some-name> .
SurfaceFlinger.cpp
를 수정하여 다음 위치에서 변경 목록의 업데이트를 포함합니다.aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
다음 줄을 찾습니다.
void SurfaceFlinger::updateColorMatrixLocked() {
updateColorMatrixLocked() 시작 부분에 다음 두 줄을 추가합니다.
mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f}, vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});
다음과 같이 코드를 빌드합니다.
m
기기에서 빌드를 업데이트합니다.
adb root
adb remount
adb sync
adb reboot
그림 1과 같이 선택한 기기에서 색상이 변경되는지 확인합니다.
그림 1. 성공적인 색상 변경 후 화면 모습
코드 테스트
Codelab의 이 부분에서는 소스 트리에 있고 실패하게 되는 테스트 예를 활용합니다. Atest를 사용하여 로컬에서 테스트를 실행하고 코드를 테스트합니다.
테스트를 사용하려면 다음 안내를 따르세요.
실행:
atest DevCodelabTest
테스트가 실패합니다. 실패한 테스트의 스택 트레이스를 검사합니다.
STACKTRACE: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:87) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertTrue(Assert.java:53) at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)
그런 다음 여기를 확인합니다.
platform_testing/tests/example/devcodelab
수정할 파일을 가져오려면
android.test.example.devcodelab.DevCodelabTest
에서 테스트 이름을 가져와.
을/
로 바꿔 다음 결과를 가져옵니다.src/android/test/example/devcodelab/DevCodelabTest.java
그런 후 다음을 수정하여
platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
아래 내용을
Assert.assertTrue(false)
아래와 같이 바꿉니다.
Assert.assertTrue(true)
테스트를 다시 실행하여 문제가 해결되었는지 확인합니다.
atest DevCodelabTest
검토를 위해 코드 업로드
Repo는 여러 Git 저장소(또는 프로젝트)에서 동시에 작업할 수 있도록 git clone
과 같은 명령어를 번들로 묶어 Git 사용을 간소화합니다.
소스 컨트롤 도구에서 Android 소스 코드 작업에 관한 전체 문서 링크가 포함된 Git 및 Repo 개요를 참고하세요. 각 프로젝트와 연결된 브랜치의 Git 프로젝트 및 개별 프로젝트(경로)의 전체 목록은 AOSP 저장소를 참고하세요.
Git에서 프로젝트의 코드를 검토하려면 Gerrit 웹 기반 코드 검토 시스템을 사용합니다.
변경사항이
frameworks/native
프로젝트에 적용되었다고 가정하고 다음 명령어를 실행하여 업로드합니다.cd frameworks/native
repo start codelab .
git add .
git commit
커밋 메시지로 다음을 입력합니다.
Android codelab change Test: manual atest
변경사항을 업로드합니다.
repo upload
성공적으로 완료되면 다음과 같은 메시지가 표시됩니다.
Upload project frameworks/native/ to remote branch main:
branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
ff46b36d android codelab change
to https://android-review.googlesource.com/ (y/N)? y
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote: https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android codelab change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
* [new branch] codelab -> refs/for/main
Gerrit에서 변경사항 확인
다음과 같이 터미널에 출력된 링크로 이동합니다.
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
Android 플랫폼 개발을 위한 입문자용 Codelab을 완료했습니다. 패치 제출에서 다음 단계를 확인하고, Android 개발에 관한 자세한 내용은 이 사이트의 나머지 부분을 참고하세요.
변경사항 되돌리기
일반적으로 테스트 후 검토 및 승인 시 Gerrit에 변경사항을 제출하고 저장소에 병합합니다.
하지만 여기서는 이 Codelab의 목적에 맞게 Gerrit에서 Abandon을 클릭하여 변경 목록을 되돌립니다.
그런 다음 frameworks/native
프로젝트 디렉터리(또는 하위 디렉터리)에서 관련된 임시 브랜치를 폐기합니다.
repo abandon codelab .
테스트 파일의 변경사항도 되돌려야 합니다. 변경사항을 repo start
, git commit
, repo upload
하지 않았으므로 파일 자체를 재설정할 수 있습니다. aosp/platform_testing directory
에 있다고 가정하고 다음 명령어를 사용하여 파일을 재설정합니다.
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
이제 작업이 완료되었습니다. 훌륭합니다.
도움말 확인
Codelab을 진행하는 동안 오류가 발생하면 페이지 하단에 있는 Issue Tracker 링크를 사용하여 오류를 신고해 주세요. android-building 그룹에 질문을 보낼 수 있습니다.