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

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

GKI 출시 흐름

GKI는 KMI 동결 이후 월별 주기로 출시됩니다.

Android 13 및 14 GKI 출시

다음 표는 android13-5.10 , android13-5.15android14-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월 7일 2023년 12월 22일
1월 2024년 1월 16일 2024년 1월 31일
2월 2024년 2월 13일 2024년 2월 29일
3월 2024년 3월 13일 2024년 3월 29일
4월 2024년 4월 16일 2024년 4월 30일
5월 2024년 5월 14일 2024년 5월 31일
6월 2024년 6월 12일 2024년 6월 28일
칠월 2024년 7월 16일 2024년 7월 31일
팔월 2024년 8월 15일 2024년 8월 30일
구월 2024년 9월 17일 2024년 9월 30일
십월 2024년 10월 15일 2024년 10월 31일
십일월 2024년 11월 11일 2024년 11월 27일
12월 2024년 12월 6일 2024년 12월 23일

2024년 1월부터 아래 표에 설명된 지정된 월별 주기에 따라 android14-5.15 의 월간 릴리스를 재개합니다.

GKI 월간 인증 빌드 체크인 마감일 GKI 사전 로드 준비 날짜 확인됐나요?
1월 2024년 1월 16일 2024년 1월 31일
2월 2024년 2월 13일 2024년 2월 29일
3월 2024년 3월 4일 2024년 3월 15일
4월 2024년 4월 1일 2024년 4월 17일
5월 2024년 5월 1일 2024년 5월 17일
6월 2024년 6월 3일 2024년 6월 17일
칠월 2024년 7월 1일 2024년 7월 15일
팔월 2024년 8월 1일 2024년 8월 16일
구월 2024년 9월 2일 2024년 9월 16일
십월 2024년 10월 1일 2024년 10월 14일
십일월 2024년 11월 1일 2024년 11월 15일
12월 2024년 12월 2일 2024년 12월 16일

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일
십일월 2023년 11월 3일 2023년 11월 17일
1월 2024년 1월 5일 2024년 1월 19일
3월 2024년 3월 4일 2024년 3월 15일
5월 2024년 5월 1일 2024년 5월 17일

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 출시 타임라인

긴급 리스핀 프로세스

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

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

보안 패치는 브랜치가 릴리스된 후 최대 6개월 동안 릴리스 브랜치에 자동으로 병합됩니다. 6개월 기한이 지나면 지사에 보안 패치를 적용하려면 재실행을 요청해야 합니다.

리스핀을 요청하기 전에 다음 지침을 참고하세요.

  • Respin은 월별 빌드의 최초 공개 릴리스가 시작된 후 릴리스 분기에서만 허용됩니다.

  • Respin 요청은 최초 공개 릴리스 후 최대 6개월 동안 특정 릴리스 분기에 대해서만 허용됩니다. 6개월 후에는 Android 보안 게시판 에 언급된 보안 패치에 대해서만 지사를 다시 스핀할 수 있습니다.

  • ASB(Android 보안 게시판) 에 정의된 LTS 요구 사항으로 인해 분기가 규정을 준수하지 않게 되면 해당 분기는 더 이상 사용되지 않습니다. 더 이상 사용되지 않는 분기에 대한 Respin 요청은 허용되지 않습니다. 특정 GKI 출시 분기의 지원 중단 날짜는 Releases 아래의 월간 GKI 출시 빌드 노트에 포함되어 있습니다. 향후 계획을 위해 LTS 요구 사항은 매년 5월과 11월에 업데이트됩니다. 예를 들어, android12-5.10-2023-07 분기(5.10.177)는 2024년 5월 1일 이후의 respin에서 지원되지 않습니다. android12-5.10-2023-07 분기(5.10.177)가 다음을 준수하지 않기 때문입니다. ASB-2024-05의 LTS 요구 사항.

  • Respin은 긴급 버그 수정, 기호 목록 업데이트 또는 기존 기능 수정을 위한 패치 적용에만 적용됩니다.

  • 월간 릴리스 분기에 포함되는 모든 패치는 이미 기본 GKI 개발 분기에 병합되어 있어야 합니다. 예를 들어 android12-5.10-2022-09 의 respin에 패치가 필요한 경우 이미 android12-5.10 에 병합되어 있어야 합니다.

  • 기본 GKI 개발 분기에서 패치를 선별하여 월별 릴리스 분기에 업로드해야 합니다.

  • 리스핀 요청에서는 요청에 우선순위(긴급성)를 할당해야 합니다. 이 우선순위는 GKI팀이 적시에 파트너를 더 효과적으로 지원하는 데 도움이 됩니다. 중요하거나 시간에 민감한 요청의 경우 우선순위를 P0 으로 표시하세요. P0 및 P1 요청의 경우 긴급성을 정당화해야 합니다. 다음 표는 버그 우선순위와 ESRT(해결 시간)의 매핑을 제공합니다.

    우선 사항 ESRT
    P0 영업일 기준 2일
    P1 영업일 기준 5일
    P2 영업일 기준 10일
    P3 영업일 기준 15일
  • 릴리스 브랜치별로 별도의 리스핀 요청을 제출해야 합니다. 예를 들어 android12-5.10-2022-08android12-5.10-2022-09 모두에 대해 respin이 필요한 경우 두 개의 respin 요청을 생성해야 합니다.

  • 빌드가 제공되고 respin 요청이 수정된 것으로 표시된 후에는 추가 CL을 추가하기 위해 respin 요청을 다시 열어서는 안 됩니다. 병합해야 할 추가 패치가 있는 경우 새 리스핀 요청을 제출해야 합니다.

  • 고려 중인 각 CL에 대해 다음 태그를 추가합니다. 이 정보가 없으면 respin 요청의 진행이 차단됩니다.

    • Bug : 각 CL의 커밋 메시지에 버그 ID를 추가해야 합니다.
    • Change-Id : 기본 브랜치 변경의 Change-Id와 동일해야 합니다.
  • 리스핀 요청에 응답이 필요한데 영업일 기준 3일 이내에 응답하지 않으면 우선순위가 한 단계 다운그레이드됩니다(예: P0이 P1 로 다운그레이드됨). 2주 동안 응답하지 않으면 해당 버그는 Won't Fix (Obsolete) 로 표시됩니다.

리스핀 요청 제출

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

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

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

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

GKI 자격

GKI 빌드 유형 품질 집행 노트
주간 오징어 테스트
  • 신병
  • VTS의 하위 집합
  • CTS의 하위 집합
  • 인증되지 않았습니다. 테스트용으로만
    장치가 올라옵니다.
  • 장치를 실행하는 데 사용할 수 없습니다.
월간(인증) 오징어 테스트
  • 신병
  • VTS
  • CTS
참조 하드웨어 테스트
  • 신병
  • VTS
  • CTS
    레스핀(인증) 오징어 테스트
    • 신병
    • VTS
    • CTS의 하위 집합
    참조 장치 테스트
    • 신병
    • VTS
    • GKI 인증 빌드를 기반으로 구축되었습니다.
    • 빌드는 검증 후 인증됩니다.

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

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

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

    자주 묻는 질문

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

    예, 이것을 리스핀이라고 합니다. Respin 프로세스는 출시된 GKI 빌드(respin이 요청된 빌드)가 Android Security Bulletin(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에는 선택한 월간 인증 커널 위에 있는 패치만 포함되어 있습니다. 이러한 리스핀에는 해당 기본 월간 릴리스를 사용하는 OEM이 특정 시간까지 보고한 모든 출시 차단 버그 수정이 포함되어 있습니다. 이러한 유형의 시나리오가 어떻게 발생하는지에 대한 다음 예를 참조하세요.

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

    10월 respin에는 모든 OEM 제출 패치가 있지만 다른 OEM 패치는 우리 제품에 대해 특별히 테스트되지 않았기 때문에 우리에게 영향을 미칩니다. 우리 패치만 포함하는 것이 가능한가요?

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

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

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

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