Yêu cầu tạo lại

Respin là quy trình hợp nhất lại, xây dựng lại, kiểm thử lại và cấp chứng nhận lại cho tệp nhị phân sau khi phát hành công khai nhân GKI.

Trước khi yêu cầu respin, hãy lưu ý các nguyên tắc sau.

Điều kiện và vòng đời

  • Thời gian: Bạn chỉ có thể yêu cầu respin trên các nhánh phát hành sau khi phát hành công khai bản dựng hằng quý ban đầu. Chỉ yêu cầu respin cho các yêu cầu về vendor-hooks hoặc các tính năng khác cho một nhánh phát hành nhất định trong tối đa 6 tháng sau khi phát hành công khai ban đầu.
  • Bảo mật và LTS: Sau 6 tháng, các nhánh chỉ đủ điều kiện quy trình tái bản cho các bản vá bảo mật được trích dẫn trong Bản tin về bảo mật Android (ASB) hoặc các bản sửa lỗi nghiêm trọng.
  • Ngừng sử dụng: Khi các yêu cầu về LTS do Bản tin bảo mật Android (ASB) xác định khiến nhánh không tuân thủ, nhánh đó sẽ bị ngừng sử dụng. Chúng tôi không chấp nhận các yêu cầu respin cho các nhánh đã ngừng sử dụng.
    • Ngày ngừng sử dụng cho một nhánh phát hành GKI nhất định được đưa vào ghi chú bản dựng phát hành GKI hằng quý trong phần Bản phát hành. Ví dụ: bản phát hành tháng 9 năm 2025 được hỗ trợ respin cho đến tháng 3 năm 2027. Ngày này phản ánh thời gian hoạt động 18 tháng của phiên bản kernel LTS 2.0 cho các bản phát hành bắt đầu từ tháng 9 năm 2025 (các bản phát hành trước tháng 9 năm 2025 có thời gian hoạt động là 12 tháng).
  • Phạm vi: Chỉ yêu cầu respin cho các bản sửa lỗi khẩn cấp, nội dung cập nhật danh sách ký hiệu hoặc để áp dụng bản vá nhằm khắc phục một tính năng hiện có.

Tiêu chuẩn gửi bản vá

Để đáp ứng Thời gian giải quyết tiêu chuẩn dự kiến (ESRT) cho quá trình xử lý yêu cầu respin, tất cả các bản vá được gửi đến một nhánh phát hành phải tuân thủ các quy tắc kỹ thuật sau.

Nguồn đáng tin cậy và cherry-pick

  • Ưu tiên nhánh phát triển: Tất cả các bản vá được đưa vào nhánh phát hành hằng quý phải được hợp nhất vào nhánh phát triển GKI chính. Ví dụ: nếu cần một bản vá cho respin của android15-6.6-2025-08, thì bản vá đó phải được hợp nhất vào android15-6.6.
  • Chọn lọc sạch: Bạn phải chọn lọc các bản vá trực tiếp từ nhánh phát triển. Đừng cherry-pick từ các nhánh phát hành khác (ví dụ: đừng chọn từ 2025-08 sang 2025-09), vì việc này có thể dẫn đến thông tin về tác giả hoặc cam kết không nhất quán với phiên bản trong nhánh phát triển. Chúng tôi sẽ không chấp nhận các bản vá có thông tin không nhất quán.
  • Giữ nguyên siêu dữ liệu: Giữ nguyên siêu dữ liệu cam kết ban đầu (ví dụ: tác giả, dấu thời gian ban đầu). Sử dụng git cherry-pick -x để giữ nguyên siêu dữ liệu.

Chuỗi cam kết

  • Chuỗi tuần tự: Nếu yêu cầu respin liên quan đến nhiều bản vá, hãy tải các bản vá đó lên dưới dạng một chuỗi cam kết tuần tự.
  • Vị trí ABI và KMI: Nếu respin nhiều bản vá bao gồm các bản cập nhật giao diện mô-đun nhân (KMI) và giao diện nhị phân của ứng dụng (ABI) (ví dụ: thay đổi danh sách ký hiệu hoặc cập nhật tệp XML/STG), hãy đặt các cam kết này ở cuối chuỗi cam kết.
  • Rebasing: Nếu bạn chỉnh sửa một cam kết gốc trong chuỗi, bạn phải rebase tất cả các bản vá con trên bản sửa đổi mới nhất của bản vá gốc để tránh lỗi bản dựng.
  • Giải quyết xung đột: Xác minh rằng không có dấu hiệu xung đột nào trong bất kỳ bản vá nào.
  • Xác minh bản dựng: Toàn bộ chuỗi cam kết phải được xây dựng thành công.

Thẻ bắt buộc

Tiến trình của yêu cầu respin bị chặn nếu không có các thẻ sau trong thông báo cam kết:

  • Change-Id: Phải giống với Change-Id của thay đổi nhánh phát triển.
    • Ngoại lệ: Nếu bản vá được hợp nhất vào nhánh phát triển trong quá trình cập nhật LTS, thì bản vá đó phải là bản chọn lọc của phiên bản LTS và được định dạng dưới dạng bản vá UPSTREAM. Xem bài viết Cách gửi bản vá cho Nhân chung Android.
  • Bug (hiện có): Không được xoá các thẻ Bug: XYZ hiện có trong cam kết nhánh phát triển ban đầu.
  • Bug (respin): Bạn phải thêm thẻ Bug: XYZ mới, trong đó XYZ tương ứng với Mã lỗi được liên kết với yêu cầu respin hiện tại.
  • Cập nhật thẻ cam kết UPSTREAM nếu cần: Khi cherry-pick một CL từ nhánh phát triển sang nhánh phát hành và CL được gắn thẻ là UPSTREAM, hãy cân nhắc các trường hợp sau:
    • Nếu CL áp dụng sạch cho nhánh phát hành, bạn không cần thực hiện thêm thao tác nào.
    • Nếu CL không áp dụng sạch, hãy khắc phục các xung đột, cập nhật thẻ thành BACKPORT và ghi lại những việc đã thực hiện trong quá trình giải quyết xung đột, hãy xem Yêu cầu đối với backport từ Linux chính.

Mức độ ưu tiên và ESRT

Chỉ định mức độ ưu tiên (mức độ khẩn cấp) cho yêu cầu respin để giúp nhóm GKI ưu tiên. Mức độ ưu tiên này giúp nhóm GKI hỗ trợ đối tác kịp thời hơn.

  • Đối với các yêu cầu nghiêm trọng hoặc cần được xử lý sớm, hãy đánh dấu mức độ ưu tiên là P0.
  • Đối với các yêu cầu P0P1, bạn cũng phải nêu rõ lý do khẩn cấp.

Bảng sau đây cung cấp thông tin về mức độ ưu tiên của lỗi và thời gian giải quyết (ESRT):

Mức độ ưu tiênESRT
P02 ngày làm việc
P15 ngày làm việc
P210 ngày làm việc
P315 ngày làm việc

Chính sách SLA

  • Gửi yêu cầu respin riêng cho từng nhánh phát hành.
  • Nếu bạn có thay đổi đối với yêu cầu respin được đánh dấu là đã khắc phục, hãy gửi yêu cầu respin mới. Đừng mở lại yêu cầu để thêm danh sách thay đổi (CL) bổ sung.
  • Nếu yêu cầu respin cần bạn phản hồi và bạn không phản hồi trong vòng 3 ngày làm việc, thì mức độ ưu tiên sẽ giảm đi một cấp, ví dụ: P0 sẽ giảm xuống P1.
  • Nếu bạn không phản hồi trong 2 tuần, lỗi sẽ được đánh dấu là Won't Fix (Obsolete) (Sẽ không khắc phục (Không dùng nữa)).

Gửi yêu cầu respin

Biểu đồ sau đây cho thấy quy trình tái bản. Quy trình bắt đầu khi đối tác OEM (bạn) gửi yêu cầu respin.

Quy trình khởi động lại khẩn cấp Hình 1.Quy trình respin khẩn cấp.

Cách gửi yêu cầu respin:

  1. Điền vào biểu mẫu yêu cầu respin GKI và liên hệ ngay với đầu mối liên hệ của bạn tại Google.

    • Biểu mẫu này tạo ra một lỗi yêu cầu respin GKI.
  2. Chuẩn bị bản vá:

    • Xác minh rằng bản vá được hợp nhất vào nhánh phát triển GKI.
    • Áp dụng bản vá cho nhánh phát hành GKI phù hợp.
    • Sửa đổi bản vá được cherry-pick để thêm thẻ Bug: XYZ trích dẫn mã yêu cầu respin.

    Ví dụ: Cách chọn lọc một CL từ android16-6.12 sang android16-6.12-2025-12:

    # 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. Gửi lỗi. Sau khi bạn gửi yêu cầu, những việc sau sẽ xảy ra:

    • Quy trình xem xét sau khi gửi:

      • Nhóm GKI của Google xem xét yêu cầu và phê duyệt yêu cầu đó hoặc chỉ định lại cho bạn nếu cần thêm thông tin.
      • Sau khi thống nhất về bản sửa lỗi, nhóm GKI của Google sẽ xem xét mã thay đổi. Bộ hẹn giờ ESRT đang hoạt động trong quá trình xem xét này. Tuy nhiên, nếu bản vá bị từ chối hoặc cần được làm lại, bộ hẹn giờ ESRT sẽ đặt lại.
      • Nhóm GKI hợp nhất, xây dựng, kiểm thử hồi quy và chứng nhận thay đổi.
    • Bản phát hành:

      • Tệp nhị phân được phát hành lên ci.android.com.
      • Khung thời gian ESRT kết thúc và nhóm GKI của Google đánh dấu yêu cầu là đã khắc phục và tham chiếu đến bản dựng respin.
      • Bản dựng respin cũng được đăng trên trang bản dựng phát hành Hình ảnh nhân chung (GKI).