리스핀 요청

리스핀은 GKI 커널의 공개 버전이 출시된 후 바이너리를 재병합, 재빌드, 재테스트 및 재인증하는 프로세스입니다.

리스핀을 요청하기 전에 다음 가이드라인을 참고하세요.

자격 요건 및 수명 주기

  • 시기: 리스핀은 분기별 빌드의 최초 공개 출시가 시작된 후에만 출시 브랜치에서 요청할 수 있습니다. 최초 공개 출시 후 최대 6개월 동안만 특정 출시 브랜치의 공급업체 후크 또는 기타 기능에 대한 리스핀 요청을 요청합니다.
  • 보안 및 LTS: 6개월 후에는 Android 보안 게시판 (ASB)에 인용된 보안 패치 또는 심각한 버그 수정에 한해서만 브랜치를 리스핀할 수 있습니다.
  • 지원 중단: Android 보안 게시판 (ASB)에 정의된 LTS 요구사항으로 인해 브랜치가 규정을 준수하지 않으면 브랜치가 지원 중단됩니다. 지원 중단된 브랜치에 대한 리스핀 요청은 수락되지 않습니다.
    • 특정 GKI 출시 브랜치의 지원 중단 날짜는 출시 아래의 분기별 GKI 출시 빌드 노트에 포함됩니다. 예를 들어 2025년 9월 출시는 2027년 3월까지 리스핀이 지원됩니다. 이 날짜는 2025년 9월부터 출시되는 버전의 LTS 2.0 커널 버전 수명인 18개월을 반영합니다 (2025년 9월 이전 출시 버전의 수명은 12개월임).
  • 범위: 긴급 버그 수정, 기호 목록 업데이트, 기존 기능 수정을 위한 패치 적용을 위해서만 리스핀을 요청하세요.

패치 제출 표준

리스핀 요청 처리의 예상 표준 해결 시간 (ESRT)을 충족하려면 출시 브랜치에 제출된 모든 패치가 다음 기술 규칙을 준수해야 합니다.

정보 소스 및 선택

  • 개발 브랜치 우선: 분기별 출시 브랜치에 적용할 모든 패치는 이미 주 GKI 개발 브랜치에 병합되어 있어야 합니다. 예를 들어 android15-6.6-2025-08의 리스핀을 위해 패치가 필요한 경우 이 패치는 이미 android15-6.6에 병합되어 있어야 합니다.
  • 클린 선택: 개발 브랜치에서 직접 패치를 선택해야 합니다. 다른 출시 브랜치에서 선별하지 마세요 (예: 2025-08에서 2025-09로 선택하지 마세요). 개발 브랜치의 버전과 일치하지 않는 작성자 또는 커밋 정보가 발생할 수 있습니다. 정보가 일치하지 않는 패치는 허용되지 않습니다.
  • 메타데이터 보존: 원본 커밋 메타데이터 (예: 작성자, 원본 타임스탬프)를 보존합니다. git cherry-pick -x를 사용하여 메타데이터를 보존합니다.

커밋 체인

  • 순차적 체인: 다시 스핀 요청에 여러 패치가 포함된 경우 커밋의 단일 순차적 체인으로 업로드합니다.
  • ABI 및 KMI 배치: 다중 패치 리스핀에 커널 모듈 인터페이스 (KMI) 및 애플리케이션 바이너리 인터페이스 (ABI) 업데이트 (예: 기호 목록 변경 또는 XML/STG 파일 업데이트)가 포함된 경우 이러한 커밋을 커밋 체인의 맨 끝에 배치합니다.
  • 리베이스: 체인에서 상위 커밋을 수정하는 경우 빌드 실패를 방지하기 위해 상위 패치의 최신 버전 위에 모든 하위 패치를 리베이스해야 합니다.
  • 충돌 해결: 패치에 충돌 마커가 없는지 확인합니다.
  • 빌드 확인: 전체 커밋 체인이 성공적으로 빌드되어야 합니다.

필수 태그

커밋 메시지에 다음 태그가 없으면 리스핀 요청이 진행되지 않습니다.

  • Change-Id: 개발 브랜치 변경사항의 Change-Id와 동일해야 합니다.
  • Bug (기존): 원래 개발 브랜치 커밋의 기존 Bug: XYZ 태그를 삭제하면 안 됩니다.
  • Bug (다시 스핀): XYZ가 현재 다시 스핀 요청과 연결된 버그 ID에 해당하는 새 Bug: XYZ 태그를 추가해야 합니다.
  • 필요한 경우 UPSTREAM 커밋 태그를 업데이트합니다. 개발 브랜치에서 출시 브랜치로 CL을 선택하고 CL에 UPSTREAM 태그가 지정된 경우 다음 시나리오를 고려하세요.
    • CL이 출시 브랜치에 깔끔하게 적용되면 추가 조치를 취하지 않아도 됩니다.
    • CL이 깔끔하게 적용되지 않으면 충돌을 수정하고 태그를 BACKPORT로 업데이트하고 충돌 해결의 일환으로 수행한 작업을 문서화합니다(기본 Linux에서 백포트 요구사항 참고).

우선순위 및 ESRT

GKI팀이 우선순위를 정할 수 있도록 리스핀 요청에 우선순위 (긴급도)를 할당합니다. GKI팀은 이 우선순위를 참고하여 파트너를 적시에 지원할 수 있습니다.

  • 중요한 요청이나 시급한 요청인 경우 우선순위를 P0으로 지정하세요.
  • P0 및 P1 요청에는 긴급도를 설명하는 내용도 기재해야 합니다.

다음 표에는 버그 우선순위와 해결 소요 시간(ESRT)이 매핑되어 있습니다.

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

SLA 정책

  • 출시 브랜치마다 별도의 리스핀 요청을 제출합니다.
  • 수정됨으로 표시된 다시 스핀 요청을 변경해야 하는 경우 새 다시 스핀 요청을 제출하세요. 추가 변경 목록 (CL)을 추가하기 위해 요청을 다시 열지 마세요.
  • 리스핀 요청을 처리하려면 개발자의 응답이 필요한데 개발자가 영업일 기준 3일 이내에 응답하지 않으면 우선순위가 한 등급 내려갑니다(예: P0이 P1로 내려감).
  • 2주간 응답하지 않을 경우 버그가 해결되지 않음(더 이상 사용되지 않음)으로 표시됩니다.

리스핀 요청 제출

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

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

리스핀 요청을 제출하려면 다음 단계를 따르세요.

  1. GKI 리스핀 요청 양식을 작성한 후 즉시 Google 담당자에게 연락합니다.

    • 이 양식을 작성하면 GKI 리스핀 요청 버그가 생성됩니다.

  2. 패치 준비:

    • 패치가 GKI 개발 브랜치에 병합되었는지 확인합니다.
    • 적절한 GKI 출시 브랜치에 패치를 적용합니다.
    • 리턴 요청 ID를 인용하는 Bug: XYZ 태그를 포함하도록 선별된 패치를 수정합니다.

    예: android16-6.12에서 android16-6.12-2025-12로 CL을 선택하려면 다음을 실행합니다.

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. 버그를 제출합니다. 요청을 제출하면 다음과 같은 일이 발생합니다.

    • 제출 후 검토 절차:

      • Google GKI팀이 요청을 검토하고 승인하거나, 추가 정보가 필요한 경우 다시 개발자에게 할당합니다.
      • 수정사항이 합의되면 Google GKI팀이 변경사항의 코드를 검토합니다. 이 검토 중에 ESRT 타이머가 활성화됩니다. 하지만 패치가 거부되거나 수정이 필요한 경우 ESRT 타이머가 재설정됩니다.
      • GKI팀이 변경사항을 병합하고, 빌드하고, 회귀를 테스트하고, 인증합니다.

    • 출시: