이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Switch to English

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 체크아웃을 가질 수 있습니다. 그러나 각 체크아웃 및 빌드는 약 300GB 사용량(및 증가)이므로 2개의 repo 체크아웃으로 제한하거나 보조 드라이브로 시스템을 보강하십시오.

팁: 여유 공간을 늘리려면 브랜치 디렉토리를 삭제하고 다음과 같이 디렉토리 생성부터 새로 시작하십시오. rm -rf aosp2.

코드 빌드

Android를 빌드하려면 lunch 명령으로 빌드할 대상 장치 유형을 선택해야 합니다. 대상은 특정 모델 또는 폼 팩터와 같은 장치 순열입니다.

아래에 포함된 기기 대상 aosp_cf_x86_64_phone-userdebug 사용하면 물리적 기기 없이 테스트용 Cuttlefish 가상 Android 기기를 빌드할 수 있습니다.

대신 물리적 장치를 구축하고 업데이트하려면 다른 대상을 선택하고 장치 플래싱 에 대한 지침을 따르십시오.

소스 코드 체크아웃의 루트에서 다음 명령을 실행하여 Android 디바이스 빌드를 위한 환경을 설정하십시오.
```
source build/envsetup.sh
```
다음과 같이 빌드 대상을 lunch 명령에 전달합니다.
```
lunch aosp_cf_x86_64_phone-userdebug
```
다음을 사용하여 체크아웃의 모든 위치에서 코드를 빌드하십시오 .
```
m
```

첫 번째 빌드에는 몇 시간이 걸릴 것으로 예상합니다. 후속 빌드는 훨씬 적은 시간이 소요됩니다.

Acloud 인스턴스 생성

Acloud 는 사용자가 가상 Android 기기(이 경우 Cuttlefish)를 만드는 데 도움을 주는 AOSP의 명령줄 도구입니다.

코드를 빌드하는 데 사용된 동일한 터미널 세션에 있는 경우 계속 진행하십시오. 그렇지 않으면 envsetup.sh 스크립트와 여기에서 처음 사용한 것과 동일한 lunch 명령을 다시 실행하십시오. 그 다음에

다음을 사용하여 Acloud 로컬 인스턴스를 생성합니다.
```
acloud create --local-image --local-instance
```
필수 패키지에 대한 업데이트를 수락합니다.
메시지가 표시되면 모든 변경 사항을 적용하려면 워크스테이션을 다시 시작합니다.
오징어 장치를 선택합니다.

Android 장치가 포함된 VNC 세션이 표시되어야 합니다!

마우스와 키보드를 사용하여 워크스테이션의 가상 장치와 상호 작용할 수 있습니다. Android 디버그 브리지(adb) logcat 명령을 사용하여 기기를 사용하는 동안 로그 내의 활동을 추적할 수도 있습니다.

adb logcat

변경

이 예제 변경 목록 에 따라 소스 코드를 업데이트하십시오.

체크아웃 루트( aosp/ 디렉터리)에서 frameworks/native Git 프로젝트로 이동합니다.
```
cd frameworks/native
```
다음 명령으로 임시 프로젝트를 시작합니다.
```
repo start <some-name> .
```
다음 위치에 있는 변경 목록의 업데이트를 포함하도록 SurfaceFlinger.cpp 편집합니다.
```
aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
```
이 줄을 찾으십시오.
```
postComposition();
```

이 두 줄을 다음으로 바꿉니다.

postComposition();
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});
updateColorMatrixLocked();

코드를 빌드합니다.
```
m
```

기기에서 빌드를 업데이트합니다.

adb root
adb remount
adb sync
adb reboot
acloud reconnect

기기를 선택하라는 메시지가 표시되면 경과 시간이 가장 짧은 기기를 선택합니다. (아마도 목록에서 마지막 항목일 것입니다.) 모든 가상 장치 인스턴스를 보려면 acloud list 및 acloud list -v 명령을 사용하십시오.

선택한 장치에서 그림 1과 유사한 색상 변화가 나타나는지 확인합니다.

Example of a successful color change

그림 1. 성공적인 색상 변경 후 화면 모습

코드 테스트

Codelab의 이 부분은 소스 트리에 있고 실패한 예시 테스트를 활용합니다. 이것은 로컬에서 테스트를 실행하고 코드를 테스트하기 위해 Atest를 사용합니다.

테스트를 사용하려면 다음 지침을 따르십시오.

달리다:
```
atest DevCodelabTest
```
테스트가 실패합니다. 이를 수정하려면 실패한 테스트의 소스 코드를 찾으십시오.
```
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
```

그럼 여기를 봐

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 master:
  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/master

Gerrit에서 변경사항 보기

다음과 유사한 터미널에 인쇄된 링크로 이동합니다.

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

이로써 Android 플랫폼 개발을 위한 시작 코드랩이 완료되었습니다. 다음 단계에 대한 패치 제출을 참조하고 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 그룹에 질문을 보내주세요.