일반 커널 이미지(GKI) 릴리스 프로세스

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

GKI 릴리스 케이던스

GKI는 2021년 7월 14일부터 KMI Freeze 이후 월간 주기로 출시됩니다. 다음 그래픽은 출시 일정의 주기를 보여줍니다.

GKI 월간 인증 빌드 체크인 마감일 GKI 사전 로드 준비 날짜 상표 확인?
칠월
(KMI 동결)		 2021년 7월 14일 7월말 안드로이드 12
AOSP 인증 빌드 - 7월		 예
팔월 2021년 8월 16일 8월 말 안드로이드 12
AOSP 인증 빌드 - 8월		 예
구월 2021년 9월 17일 9월말 안드로이드 12
AOSP 인증 빌드 - 9월		 예
십월 2021년 10월 15일 2021년 10월 29일 안드로이드 12
AOSP 인증 빌드 - 10월		 예
십일월 2021년 11월 12일 2021년 11월 30일 안드로이드 12
AOSP 인증 빌드 - 11월		 예
12월 2021년 12월 10일 2021년 12월 22일 안드로이드 12
AOSP 인증 빌드 - 12월		 예
1월 2022년 1월 14일 2022년 1월 31일 안드로이드 12
AOSP 인증 빌드 - 1월		 예
2월 2022년 2월 14일 2022년 2월 28일 안드로이드 12
AOSP 인증 빌드 - 2월		 예
3월 2022년 3월 16일 2022년 3월 31일 안드로이드 12
AOSP 인증 빌드 - 3월		 예
4월 2022년 4월 15일 2022년 4월 29일 안드로이드 12
AOSP 인증 빌드 - 4월		 예
5월 2022년 5월 16일 2022년 5월 31일 안드로이드 12
AOSP 인증 빌드 - 5월		 예
6월 2022년 6월 15일 2022년 6월 30일 안드로이드 12
AOSP 인증 빌드 - 6월		 예
칠월 2022년 7월 15일 2022년 7월 29일 안드로이드 12
AOSP 인증 빌드 - 7월		 예
팔월 2022년 8월 15일 2022년 8월 31일 안드로이드 12
AOSP 인증 빌드 - 8월		 예
구월 2022년 9월 16일 2022년 9월 30일 안드로이드 12
AOSP 인증 빌드 - 9월		 예
십월 2022년 10월 14일 2022년 10월 31일 안드로이드 12
AOSP 인증 빌드 - 10월		 예
십일월 2022년 11월 14일 2022년 11월 30일 안드로이드 12
AOSP 인증 빌드 - 11월		 예
12월 2022년 12월 9일 2022년 12월 21일 안드로이드 12
AOSP 인증 빌드 - 12월		 예

OEM을 위한 GKI 빌드 유효성

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

인증된 빌드 respin 정책

  • GKI 인증 바이너리는 ASB의 LTS 요구 사항을 더 이상 준수하지 않으면 리스핀에 대해 지원되지 않습니다. 예를 들어 android12-5.10-2021-11 분기(5.10.66)는 android12-5.10-2021-11 분기(5.10.66)가 ASB-2022-11.
  • 자세한 내용은 긴급 재회전 프로세스 를 참조하십시오.

주간 개발 릴리스

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

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

월간 인증 릴리스

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

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

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

긴급재회전 프로세스

긴급재회전 프로세스 그림 2. 긴급재회전 절차

OEM은 문제를 차단하는 TA(기술 승인)를 위해 커널을 다시 회전해야 할 수 있습니다. Respin은 월별 인증 릴리스 빌드에서 지원되며 예상 표준 해결 시간(ESRT)은 미국 시간대에서 영업일 기준 2일입니다.

ESRT는 수정 사항이 포함된 인증된 GKI 바이너리를 제공하는 데 걸리는 시간으로 정의됩니다. 단, GKI 팀이 승인하고 영향을 받는 OEM이 검토합니다. ESRT는 추정치일 뿐이며 보증으로 해석되어서는 안 됩니다.

TA 차단 수정을 위해 재스핀이 필요한 OEM은 다음을 수행해야 합니다.

  1. Issue Tracker 에 버그를 신고하고 즉시 Google 담당자에게 연락하세요.
    • 이미 수정 사항이 있는 경우 Google에서 검토할 수 있도록 버그가 AOSP의 패치 제출을 가리켜야 합니다. 패치를 제출할 수 없는 경우 문제 추적기 의 버그에 패치를 텍스트 파일로 첨부합니다.
    • 아직 수정 사항이 없는 경우 버그에 커널 버전 번호 및 로그를 포함하여 최대한 많은 정보가 포함되어야 하므로 Google에서 문제 디버그를 도울 수 있습니다.
  2. 수정 사항에 동의하면 Google GKI 팀 코드에서 변경 사항을 검토(CR+2)하고 회귀를 테스트합니다. 테스트는 ESRT 카운트다운을 시작하고 바이너리가 ci.android.com 에 게시되면 종료됩니다.

GKI 자격

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

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

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

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

    자주 묻는 질문

    이미 출시된 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에는 선택한 월별 인증 커널 위에 있는 패치만 포함됩니다. 이러한 리스핀에는 해당 기본 월별 릴리스를 사용하여 OEM이 지정된 시간까지 보고한 모든 출시 차단 버그 수정이 포함되어 있습니다. 이러한 유형의 시나리오가 어떻게 발생하는지에 대한 다음 예를 참조하십시오.

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

    10월 respin에는 모든 OEM 제출 패치가 있지만 다른 OEM 패치는

    우리 제품으로 특별히 테스트되지 않았기 때문에 우리에게 영향을 미칩니다. 우리 패치만 포함할 수 있습니까?

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

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

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

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