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

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

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

GKI 출시 주기

GKI는 KMI 동결 후 월별 케이던스로 출시됩니다.

Android 13 및 14 GKI 릴리스

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

GKI 월간 인증 빌드	체크인 마감 날짜	GKI 사전 로드 준비 날짜	확인?
십월	2022년 10월 14일	2022년 10월 31일	예
십일월	2022년 11월 14일	2022년 11월 30일	예
12월	2022년 12월 9일	2022년 12월 21일	예
1월	2023년 1월 17일	2023년 1월 31일	예
2월	2023년 2월 15일	2023년 2월 28일	예
3월	2023년 3월 15일	2023년 3월 31일	예
4월	2023년 4월 13일	2023년 4월 28일	예
5월	2023년 5월 17일	2023년 5월 31일	예
6월	2023년 6월 15일	2023년 6월 30일	예
칠월	2023년 7월 18일	2023년 7월 31일	예
팔월	2023년 8월 16일	2023년 8월 31일	예
구월	2023년 9월 14일	2023년 9월 29일	예
십월	2023년 10월 18일	2023년 10월 31일	예
십일월	2023년 11월 10일	2023년 11월 30일	예
12월	2023년 12월 12일	2023년 12월 22일	예

Android 12 GKI 출시

2023년 5월 이후 android12-5.10 GKI 릴리스는 2개월 주기로 진행되며 월 중순에 게시됩니다. 다음 표는 android12-5.10 에만 적용됩니다.

GKI 월간 인증 빌드	체크인 마감 날짜	GKI 사전 로드 준비 날짜	확인?
칠월	2023년 7월 3일	2023년 7월 14일	예
구월	2023년 9월 1일	2023년 9월 15일	예
십일월	2022년 11월 3일	2022년 11월 17일	예
1월	2024년 1월 5일	2024년 1월 19일	예

OEM용 GKI 빌드 유효성

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

주간 개발 릴리스

릴리스는 최소 품질 기준을 통과하는지 확인하기 위해 갑오징어 로 테스트됩니다.

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

월간 인증 릴리스

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

매월 GKI 월별 릴리스 후보(인증되지 않음)는 일반적으로 해당 월의 두 번째 주간 빌드인 체크인 마감 날짜 이후에 선택됩니다. 월별 릴리스 후보를 선택한 후에 는 해당 월의 릴리스에 새 변경 사항이 적용되지 않습니다. 닫힌 기간 동안에는 테스트 실패를 유발하는 버그에 대한 수정만 수행할 수 있습니다. 릴리스 후보는 GKI 인증 섹션 에 설명된 대로 품질 보증을 거쳐 참조 장치와 오징어를 사용하여 GSI+GKI 빌드에서 규정 준수 테스트를 통과하도록 합니다.

GKI 출시 주기 타임라인 그림 1. GKI 출시 일정

긴급 재스핀 프로세스

respin은 GKI 커널의 공개 릴리스 후 바이너리를 다시 병합, 재구축, 재테스트 및 재인증하는 프로세스를 의미합니다. 다음 상황에 대해 인증된 바이너리의 재스핀을 요청할 수 있습니다.

기호 목록을 업데이트합니다.
캐리어 랩 승인 중에 발견된 버그를 포함하여 버그에 대한 수정 사항을 적용합니다.
공급업체 후크를 추가하려면 .
기존 기능에 패치를 적용합니다.
보안 패치 적용(6개월 후)

보안 패치는 분기 릴리스 후 최대 6개월 동안 릴리스 분기에 자동으로 병합됩니다. 6개월 컷오프 이후에는 분기에 보안 패치를 적용하기 위해 respin을 요청해야 합니다.

재스핀을 요청하기 전에 다음 지침을 참고하십시오.

Respin은 월별 빌드의 초기 공개 릴리스가 시작된 후 릴리스 분기에서만 허용됩니다.
Respin 요청은 최초 공개 릴리스 후 최대 6개월 동안 지정된 릴리스 분기에 대해서만 허용됩니다. 6개월 후 지점은 Android 보안 게시판 에 인용된 보안 패치에 대해서만 재스핀할 수 있습니다.
LTS 요구 사항 으로 인해 분기가 비준수 상태가 되면 해당 분기는 더 이상 사용되지 않습니다. 더 이상 사용되지 않는 분기에 대한 Respin 요청은 허용되지 않습니다. 예를 들어 android12-5.10-2021-11 분기(5.10.66)는 2022년 11월 이후 응답에 대해 지원되지 않습니다. android12-5.10-2021-11 분기(5.10.66)가 LTS 요구 사항을 준수하지 않기 때문입니다. ASB-2022-11.
Respin은 긴급한 버그 수정, 기호 목록 업데이트 또는 기존 기능을 수정하기 위한 패치 적용에만 적용됩니다.
월간 출시 분기로 들어가는 모든 패치는 기본 GKI 개발 분기에 이미 병합되어 있어야 합니다. 예를 들어 android12-5.10-2022-09 의 respin에 패치가 필요한 경우 이미 android12-5.10 에 병합되어 있어야 합니다.
기본 GKI 개발 브랜치에서 패치를 선별하여 패치를 월별 릴리스 브랜치에 업로드해야 합니다.
respin 요청에서 요청에 우선 순위(긴급)를 지정해야 합니다. 이 우선순위는 GKI팀이 적시에 파트너를 더 잘 지원하는 데 도움이 됩니다. 중요하거나 시간에 민감한 요청의 경우 우선순위를 P0 으로 표시하십시오. P0 및 P1 요청의 경우 긴급성을 정당화해야 합니다. 다음 표는 버그 우선순위와 해결 시간(ESRT)의 매핑을 제공합니다.
우선 사항 ESRT
P0 영업일 기준 2일
P1 영업일 기준 5일
P2 영업일 기준 10일
P3 영업일 기준 15일

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

릴리스 분기별로 별도의 respin 요청을 제출해야 합니다. 예를 들어 android12-5.10-2022-08 및 android12-5.10-2022-09 모두에 respin이 필요한 경우 두 개의 respin 요청을 만들어야 합니다.
빌드가 제공되고 respin 요청이 수정됨으로 표시되면 추가 CL을 추가하기 위해 respin 요청을 다시 열어서는 안 됩니다. 병합해야 하는 추가 패치가 있는 경우 새 respin 요청을 제출해야 합니다.
고려 중인 각 CL에 대해 다음 태그를 추가합니다. 이 정보가 없으면 respin 요청에 대한 진행이 차단됩니다.
- Bug : 각 CL의 커밋 메시지에 버그 ID를 추가해야 합니다.
- Change-Id : 기본 분기 변경의 Change-Id와 동일해야 합니다.
respin 요청에 응답이 필요하고 영업일 기준 3일 이내에 응답하지 않으면 우선순위가 한 단계 낮아집니다(예: P0이 P1 로 다운그레이드됨). 2주 동안 응답하지 않으면 버그가 Wo n't Fix (Obsolete) 로 표시됩니다.

재스핀 요청 제출

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

긴급 재스핀 프로세스 그림 2. respin 프로세스

respin 프로세스를 시작하려면 다음을 수행하십시오.

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

GKI 자격

GKI 빌드 유형	품질 집행	노트
주간	오징어 테스트 신병 VTS의 하위 집합 CTS의 하위 집합	인증되지 않았습니다. 테스트 및 장치를 가져옵니다. 장치를 시작하는 데 사용할 수 없습니다.
월간(인증)	오징어 테스트 신병 VTS CTS 참조 하드웨어 테스트 신병 VTS CTS
Respins(인증)	오징어 테스트 신병 VTS CTS의 하위 집합 참조 장치 테스트 신병 VTS	GKI 인증 빌드 위에 구축되었습니다. 빌드는 자격을 갖춘 후에 인증됩니다.

GKI 빌드 유형

품질 집행

노트

주간

오징어 테스트

신병
VTS의 하위 집합
CTS의 하위 집합

인증되지 않았습니다. 테스트 및
장치를 가져옵니다.
장치를 시작하는 데 사용할 수 없습니다.

월간(인증)

오징어 테스트

신병
VTS
CTS

참조 하드웨어 테스트

신병
VTS
CTS

Respins(인증)

오징어 테스트

신병
VTS
CTS의 하위 집합

참조 장치 테스트

신병
VTS

GKI 인증 빌드 위에 구축되었습니다.
빌드는 자격을 갖춘 후에 인증됩니다.

빌드 아티팩트를 얻을 수 있는 위치

모든 릴리스의 아티팩트는 ci.android.com 에서 얻을 수 있습니다.

Android 지속적 통합 대시보드에서 테스트 결과를 포함하여 CI에 대한 자세한 정보를 찾을 수 있습니다.

FAQ

이미 출시된 GKI를 기반으로 새로운 GKI 바이너리를 빌드할 수 있습니까?

예, 이것은 respin으로 알려져 있습니다. respin 프로세스는 릴리스된 GKI 빌드(respin이 요청된 빌드)가 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 바이너리(긴급 스핀 패치 포함)가 최신 코드베이스에 구축되었습니까?

아니요. Respin에는 선택한 월간 인증 커널 위에 있는 패치만 포함됩니다. 이러한 respin에는 해당 기본 월간 릴리스를 사용하는 OEM이 지정된 시간까지 보고한 모든 출시 차단 버그 수정이 포함됩니다. 이러한 유형의 시나리오가 어떻게 발생하는지에 대한 다음 예를 참조하십시오.

OEM1과 OEM2는 2021년 11월부터 GKI 바이너리 릴리스를 사용하기로 결정합니다.
OEM1 및 OEM2는 지원을 위해 패치가 필요한 문제를 찾습니다. 이러한 패치는 다를 수도 있고 같을 수도 있습니다.
2021년 11월 바이너리 상단의 재스핀에는 재스핀 기간 동안 OEM1과 OEM2 모두에서 보고된 출시 차단 수정 사항이 있지만 그 이상은 없습니다.
두 번째 중요 항목에 언급된 문제는 후속 GKI 월별 릴리스에도 포함됩니다.

10월 respin에는 모든 OEM 제출 패치가 있지만 다른 OEM 패치는 우리 제품에 대해 구체적으로 테스트되지 않았기 때문에 우리에게 영향을 미칩니다. 우리의 패치만 포함할 수 있습니까?

이건 불가능 해. "OEM당" respin 경로는 현재 확장할 수 없습니다. 대신 GKI 팀은 respin 빌드에 들어가는 모든 변경 사항을 면밀히 조사하고 새 빌드를 만들기 전에 사용 가능한 모든 하드웨어로 변경 사항을 테스트합니다. GKI 팀에서 문제가 OEM/기기/모델과 관련된 것으로 확인되면 GKI 팀은 변경으로 추가된 코드가 영향을 받는 기기/모델/SKU에서만 실행되도록 할 수 있습니다.

통합 respin의 주요 이점은 동일한 릴리스 기반을 사용하는 모든 장치가 서로 이점을 얻는다는 것입니다. 특히 발견한 버그가 일반적이고 모든 사용자에게 적용 가능한 경우에 그렇습니다. 캐리어 테스트에서 발견된 핵심 커널 버그는 이 개념의 구체적인 예입니다.

Google에서 OEM 패치 및 문제 시나리오에 대한 특정 정보를 제공하여 OEM이 제품에 패치를 구현하는 데 따른 영향과 위험을 평가할 수 있는 상황이 있나요?

Google은 문제가 이해되고 모든 세부 정보가 수집될 때까지 respin 빌드에 변경 사항을 추가하지 않습니다. 이것은 변경 로그(커밋 메시지)에서 볼 수 있습니다. Google은 영향을 받는 특정 기기를 공개하지 않지만 OEM은 항상 변경 로그에서 문제 설명과 해결책을 찾을 수 있습니다.