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

일반 커널 이미지 (GKI) 출시 프로세스

이 페이지에서는 주간, 월간 및 정해진 주기 외 긴급 출시를 포함하여 GKI가 출시되는 방법을 설명합니다. 이 문서의 목표는 GKI를 수령할 위치 및 주기 외 긴급 수정 프로세스에 관한 가이드라인을 OEM에 제공하는 것입니다. OEM은 또한 GKI 개발을 통해 Android 커널팀과 협업하여 제품에 맞게 GKI 커널을 최적화할 수 있는 방법을 자세히 알아볼 수 있습니다.

GKI 출시 주기

GKI는 KMI Freeze 이후 월간 주기로 출시됩니다.

Android 13, 14, 15 GKI 출시

다음 표는 android13-5.10, android13-5.15, android14-5.15에만 적용됩니다.

GKI 월간 인증 빌드	체크인 마감 날짜	GKI 미리 로드 준비 날짜	확인 여부
11월	2024년 11월 11일	2024년 11월 27일	예
1월	2025년 1월 14일	2025년 1월 31일	예
3월	2025년 3월 14일	2025년 3월 31일	예

다음 표는 android14-6.1 및 android15-6.6에만 적용됩니다.

GKI 월간 인증 빌드	체크인 마감 날짜	GKI 미리 로드 준비 날짜	확인 여부
10월	2024년 10월 1일	2024년 10월 14일	예
11월	2024년 11월 1일	2024년 11월 15일	예
12월	2024년 12월 2일	2024년 12월 16일	예
1월	2025년 1월 6일	2025년 1월 22일	예

Android 12 GKI 출시

2024년 5월 이후에는 android12-5.10 GKI 출시가 분기별 주기로 매월 중순에 게시됩니다. 다음 표는 android12-5.10에만 적용됩니다.

GKI 월간 인증 빌드	체크인 마감 날짜	GKI 미리 로드 준비 날짜	확인 여부
11월	2024년 11월 1일	2024년 11월 15일	예
2월	2025년 2월 3일	2025년 2월 17일	예

OEM용 GKI 빌드 유효성

OEM은 최근 출시된 Android GKI를 사용할 수 있습니다. OEM은 Android 보안 게시판(ASB)의 LTS 요구사항을 준수하는 한 GKI 인증 빌드로 출시할 수 있습니다.

주간 개발 출시

출시는 Cuttlefish로 테스트되어 최소 품질 기준을 통과하는지 확인합니다.

GKI 바이너리는 Android CI의 셀프서비스에 사용할 수 있습니다. 변경사항이 병합되기 때문입니다. 주간 빌드는 인증되지는 않지만 개발 및 테스트의 기준으로 사용할 수 있습니다. 최종 사용자를 위한 프로덕션 기기 빌드에는 주간 빌드를 사용할 수 없습니다.

월간 인증 출시

GKI 월간 출시에는 알려진 소스 코드 기준에서 바이너리가 빌드되었음을 증명하기 위해 Google에서 삽입한 인증서가 포함된 테스트된 boot.img가 포함되어 있습니다.

매월 GKI 월간 출시 후보(인증되지 않음)는 체크인 마감 날짜 후에 선택되며 이는 일반적으로 해당 월의 두 번째 주간 빌드입니다. 월간 출시 후보가 선택된 후에는 새로운 변경사항이 해당 월의 출시에 허용되지 않습니다. 종료된 기간에는 테스트 실패를 일으키는 버그에 관한 수정사항만 처리될 수 있습니다. 출시 후보는 GKI 검증 섹션에 설명된 것처럼 품질 보증을 거쳐 cuttlefish뿐 아니라 참조 기기의 GSI+GKI 빌드에서 규정 준수 테스트를 통과하는지 확인합니다.

GKI 출시 주기 일정 그림 1. GKI 출시 일정

긴급 리스핀 프로세스

리스핀은 GKI 커널의 공개 버전이 출시된 후에 바이너리를 재병합, 재빌드, 재테스트 및 재인증하는 프로세스를 의미합니다. 다음과 같은 경우에 인증된 바이너리의 리스핀을 요청할 수 있습니다.

기호 목록을 업데이트하려는 경우
버그(이동통신사 랩 승인 중에 발견된 버그 포함) 수정을 적용하려는 경우
공급업체 후크를 추가하려는 경우
기존 기능에 패치를 적용하려는 경우
(6개월 후에) 보안 패치를 적용하려는 경우

보안 패치는 브랜치가 출시된 후 최대 6개월간 출시 브랜치에 자동으로 병합됩니다. 6개월 기한이 지난 후에 브랜치에 보안 패치를 적용하려면 리스핀을 요청해야 합니다.

리스핀 요청 가이드라인

리스핀을 요청하려면 먼저 다음 가이드라인을 참고하세요.

리스핀은 월간 빌드의 최초 공개 출시가 시작된 후에만 출시 브랜치에서 허용됩니다.
리스핀 요청은 출시 브랜치의 최초 공개 출시 후 최대 6개월 동안만 허용됩니다. 6개월 후에는 Android 보안 게시판에 명시된 보안 패치에 대해서만 브랜치 리스핀이 허용됩니다.
Android 보안 게시판 (ASB)에 정의된 LTS 요구사항으로 인해 브랜치가 규정을 준수하지 않으면 브랜치가 지원 중단됩니다. 지원 중단된 브랜치에 대한 리스핀 요청은 수락되지 않습니다. 특정 GKI 출시 브랜치의 지원 중단 날짜는 출시의 월간 GKI 출시 빌드 메모에 포함되어 있습니다. 향후 계획을 위해 LTS 요구사항은 매년 5월과 11월에 업데이트됩니다. 예를 들어 android12-5.10-2023-07 브랜치 (5.10.177)는 2024년 5월 1일 이후에는 리스핀에 지원되지 않습니다. android12-5.10-2023-07 브랜치 (5.10.177)가 ASB-2024-05의 LTS 요구사항을 준수하지 않기 때문입니다.
리스핀은 긴급 버그 수정, 기호 목록 업데이트, 기존 기능 수정을 위한 패치 적용을 위해서만 허용됩니다.
월간 출시 브랜치에 적용할 모든 패치는 이미 주 GKI 개발 브랜치에 병합되어 있어야 합니다. 예를 들어, android12-5.10-2022-09의 리스핀을 위해 패치가 필요한 경우 이 패치는 이미 android12-5.10에 병합되어 있어야 합니다.
주 GKI 개발 브랜치에서 패치를 선택한 다음 월간 출시 브랜치에 업로드해야 합니다.
리스핀 요청에서는 요청에 우선순위(긴급도)를 지정해야 합니다. GKI팀은 이 우선순위를 참고하여 파트너를 적시에 지원할 수 있습니다. 중요한 요청이나 시급한 요청인 경우 우선순위를 P0으로 지정하세요. P0 및 P1 요청에는 긴급도를 설명하는 내용도 기재해야 합니다. 다음 표에는 버그 우선순위와 ESRT(해결 소요 시간)가 매핑되어 있습니다.

우선순위 ESRT

P0 영업일 기준 2일

P1 영업일 기준 5일

P2 영업일 기준 10일

P3 영업일 기준 15일

우선순위	ESRT
P0	영업일 기준 2일
P1	영업일 기준 5일
P2	영업일 기준 10일
P3	영업일 기준 15일

출시 브랜치마다 별도의 리스핀 요청을 제출해야 합니다. 예를 들어, android12-5.10-2022-08 브랜치와 android12-5.10-2022-09 브랜치에 리스핀이 필요한 경우 2건의 리스핀 요청을 생성해야 합니다.
빌드가 제공되고 리스핀 요청이 수정됨으로 표시된 후에는 CL을 추가하기 위해 리스핀 요청을 다시 열어서는 안 됩니다. 병합해야 하는 추가 패치가 있는 경우 새 리스핀 요청을 제출해야 합니다.
고려 중인 각 CL에 다음과 같은 태그를 추가하세요.
- Bug: 각 CL의 커밋 메시지에 버그 ID를 추가해야 합니다.
- Change-Id: 기본 브랜치 변경사항의 Change-Id와 동일해야 합니다.
참고: 이러한 태그가 없으면 리스핀 요청이 진행되지 않습니다.
리스핀 요청을 처리하려면 개발자의 응답이 필요한데 개발자가 영업일 기준 3일 이내에 응답하지 않을 경우, 우선순위가 한 등급 강등됩니다(예: P0은 P1로 강등됨). 2주간 응답하지 않을 경우, 버그가 해결되지 않음(더 이상 사용되지 않음)으로 표시됩니다.

리스핀 요청 제출

다음 다이어그램은 리스핀 프로세스를 보여줍니다. 이 프로세스는 OEM 파트너(개발자)가 리스핀 요청을 제출하면 시작됩니다.

긴급 리스핀 프로세스 그림 2. 리스핀 프로세스

리스핀 프로세스를 시작하려면 다음을 실행하세요.

GKI 리스핀 요청 양식을 작성한 후 즉시 Google 기술계정 관리자에게 연락합니다. 이 양식을 작성하면 GKI 리스핀 요청 버그가 생성됩니다. 리스핀 요청 버그는 개발자(요청자), GKI팀, 그리고 버그의 CC 목록에 추가된 특정 사용자가 볼 수 있습니다.
- 이미 수정사항이 있는 경우 Google에서 검토할 수 있도록 요청이 AOSP의 패치 제출을 가리켜야 합니다. 패치를 제출할 수 없다면 패치를 요청에 텍스트 파일로 첨부해야 합니다.
- 수정사항이 없는 경우 Google에서 문제를 디버그하는 데 도움을 줄 수 있도록 요청에 커널 버전 번호와 로그 등 최대한 많은 정보를 포함해야 합니다.
Google GKI팀이 요청을 검토하고 승인하거나, 추가 정보가 필요한 경우 다시 개발자에게 할당합니다.
수정사항이 합의되면 Google GKI팀이 변경사항의 코드를 검토(CR+2)합니다. 검토로 ESRT 기간이 시작됩니다. GKI팀이 변경사항의 병합, 빌드, 회귀 테스트, 인증을 진행합니다.
바이너리가 ci.android.com으로 출시됩니다. ESRT 기간이 종료되고 Google GKI팀이 요청을 수정됨으로 표시한 후 리스핀 빌드를 참조합니다. 일반 커널 이미지(GKI) 출시 빌드 페이지에도 리스핀 빌드가 게시됩니다.

GKI 검증

GKI 빌드 유형	품질 정책 시행	참고
주간	Cuttlefish 테스트 부팅 VTS의 하위 집합 CTS의 하위 집합	인증받지 않음. 테스트 및 기기 불러오기 전용입니다. 기기 실행에 사용할 수 없음
월간(인증됨)	Cuttlefish 테스트 부팅 VTS CTS 참조 하드웨어 테스트 부팅 VTS CTS
리스핀(인증됨)	Cuttlefish 테스트 부팅 VTS CTS의 하위 집합 참조 기기 테스트 부팅 VTS	GKI 인증 빌드를 기반으로 빌드됨 빌드는 검증 후 인증됨

GKI 빌드 유형

품질 정책 시행

참고

주간

Cuttlefish 테스트

부팅
VTS의 하위 집합
CTS의 하위 집합

인증받지 않음. 테스트 및 기기
불러오기 전용입니다.
기기 실행에 사용할 수 없음

월간(인증됨)

Cuttlefish 테스트

부팅
VTS
CTS

참조 하드웨어 테스트

부팅
VTS
CTS

리스핀(인증됨)

Cuttlefish 테스트

부팅
VTS
CTS의 하위 집합

참조 기기 테스트

부팅
VTS

GKI 인증 빌드를 기반으로 빌드됨
빌드는 검증 후 인증됨

빌드 아티팩트를 가져올 위치

모든 출시의 아티팩트는 ci.android.com에서 가져올 수 있습니다.

Android 지속적 통합 대시보드에서 테스트 결과를 비롯하여 CI에 관한 자세한 내용을 확인할 수 있습니다.

FAQ

다음은 GKI 출시 프로세스와 관련하여 자주 묻는 질문입니다.

이미 출시된 GKI를 기반으로 새 GKI 바이너리를 빌드할 수 있나요?

예, 이를 리스핀이라고 합니다. 리스핀 프로세스는 출시된 GKI 빌드(리스핀이 요청됨)에서 Android 보안 게시판(ASB)의 LTS 요구사항을 준수하는 한 지원됩니다.

GKI 바이너리를 재현할 수 있나요?

예. 다음 예를 참고하세요.

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

예를 재현하려면 manifest_$id.xml을 다운로드하고 다음 명령어를 실행합니다.

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

out/.../dist에서 GKI 아티팩트 사본을 가져올 수 있습니다.

GKI 바이너리(긴급 스핀 패치 포함)는 최신 코드베이스에 기반하여 빌드되었나요?

아니요. 리스핀에는 선택한 월간 인증 커널 위에 있는 패치만 포함됩니다. 이러한 리스핀에는 OEM이 상응하는 기본 월간 출시를 통해 특정 시간까지 보고한 모든 출시 차단 버그 수정이 포함되어 있습니다. 이러한 유형의 시나리오가 발생하는 방식은 다음 예를 참고하세요.

OEM1과 OEM2는 2021년 11월부터 GKI 바이너리 출시를 사용하기로 합니다.
OEM1과 OEM2는 지원을 위해 패치가 필요한 문제를 찾습니다. 이러한 패치는 다를 수도 있고 같을 수도 있습니다.
2021년 11월 바이너리 위에 있는 리스핀에는 리스핀 기간에 OEM1과 OEM2에서 보고한 출시 차단 수정사항이 있지만 그뿐입니다.
두 번째 글머리기호에 언급된 문제는 후속 GKI 월간 출시에도 포함됩니다.

10월 리스핀에는 모든 OEM 제출 패치가 있지만 다른 OEM 패치가 영향을 미칩니다. 당사 제품과 함께 테스트하지 않았기 때문입니다. 당사 패치만 포함할 수 있나요?

불가능합니다. 'OEM별' 리스핀 경로는 확장할 수 없습니다. 대신 GKI팀에서는 리스핀 빌드에 적용되는 모든 변경사항을 철저하게 검토하고 새 빌드를 만들기 전에 사용 가능한 모든 하드웨어로 변경사항을 테스트합니다. GKI팀에서 문제가 OEM, 기기 또는 모델에 특정된 것으로 발견하면 GKI팀은 변경사항으로 추가된 코드가 영향을 받는 기기, 모델 또는 SKU에서만 실행되도록 할 수 있습니다.

통합 리스핀의 주요 이점은 동일한 출시 기반을 사용하는 모든 기기가 서로에게 유익하다는 것입니다. 특히, 발견된 버그가 일반적이고 모든 사용자에게 적용되는 경우 그렇습니다. 이동통신사 테스트에서 발견된 핵심 커널 버그는 이 개념의 구체적인 예입니다.

OEM이 제품에 패치를 구현할 때의 영향과 위험을 평가할 수 있도록 OEM 패치 및 문제 시나리오에 관한 구체적인 정보를 Google에서 제공하는 상황이 있나요?

Google에서는 문제가 파악되고 모든 세부정보가 수집될 때까지 리스핀 빌드에 변경사항을 추가하지 않습니다. 이는 변경 로그(커밋 메시지)에서 확인할 수 있습니다. Google에서는 영향을 받는 특정 기기를 공개하지 않지만 OEM은 언제든지 변경 로그에서 문제 설명과 솔루션을 확인할 수 있습니다.