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

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

Trước khi yêu cầu tạo lại ảnh, hãy lưu ý các nguyên tắc sau.

Điều kiện sử dụng và vòng đời

  • Thời gian: Bạn chỉ có thể yêu cầu quay lại sau khi bản phát hành công khai ban đầu của bản dựng hằng quý được ra mắt trên các nhánh phát hành. Yêu cầu yêu cầu respin cho các vendor-hook hoặc các tính năng khác chỉ cho một nhánh phát hành nhất định trong tối đa 6 tháng sau lần 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 để tạo lại cho các bản vá bảo mật được đề cập trong Bản tin 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 (được xác định trong Bản tin về bảo mật Android (ASB)) khiến nhánh không tuân thủ, thì nhánh đó sẽ bị ngừng sử dụng. Chúng tôi không chấp nhận yêu cầu tạo lại cho các nhánh không dùng nữa.
    • Ngày ngừng cung cấp cho một nhánh phát hành GKI nhất định có trong ghi chú về bản 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ợ cho các bản phát hành lại cho đến tháng 3 năm 2027. Ngày này phản ánh thời gian hỗ trợ của phiên bản kernel LTS 2.0 là 18 tháng đối với 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 hỗ trợ là 12 tháng).
  • Phạm vi: Chỉ yêu cầu phát hành lại cho các bản sửa lỗi khẩn cấp, nội dung cập nhật danh sách biểu tượng hoặc để áp dụng bản vá nhằm sửa một tính năng hiện có.

Các tiêu chuẩn gửi bản vá

Để đáp ứng Thời gian xử lý dự kiến theo tiêu chuẩn (ESRT) cho yêu cầu quay lại phiên bản trước, 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à lựa chọn có chọn lọc

  • Ư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ý đều phải được hợp nhất vào nhánh phát triển GKI chính. Ví dụ: nếu cần có bản vá cho một bản phát hành lại 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 chọn lọc từ các nhánh phát hành khác (ví dụ: đừng chọn từ 2025-08 đến 2025-09), vì điều này có thể dẫn đến thông tin về tác giả hoặc thông tin 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 ban đầu của cam kết (ví dụ: tác giả, dấu thời gian ban đầu). Sử dụng git cherry-pick -x để giữ lại 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 tuần tự duy nhất gồm các cam kết.
  • Vị trí ABI và KMI: Nếu một bản vá nhiều lần có chứa các bản cập nhật giao diện mô-đun hạt nhân (KMI) và giao diện nhị phân của ứng dụng (ABI) (ví dụ: thay đổi danh sách biểu tượng 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.
  • Đổi cơ sở: Nếu chỉnh sửa một cam kết gốc trong chuỗi, bạn phải đổi cơ sở tất cả các bản vá con dựa 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ó điểm đánh dấ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 tạo thành công.

Thẻ bắt buộc

Tiến trình của yêu cầu respin sẽ 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.
    • Trường hợp 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ì đó phải là bản vá được chọn lọc từ phiên bản LTS và được định dạng dưới dạng bản vá UPSTREAM. Xem phần Làm cách nào để gửi bản vá cho Nhân chung của Android.
  • Bug (hiện có): Bạn không được xoá các thẻ Bug: XYZ hiện có khỏi 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 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 chọn 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 rõ ràng cho nhánh phát hành, bạn không cần thực hiện thêm bất kỳ hành động nào.
    • Nếu CL không áp dụng một cách rõ ràng, 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 đã làm trong quá trình giải quyết xung đột, hãy xem Các yêu cầu đối với việc chuyển ngược 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 tạo lại để giúp nhóm GKI ưu tiên. Mức độ ưu tiên này giúp nhóm GKI hỗ trợ các đối tác hiệu quả hơn và kịp thời hơn.

  • Đối với những yêu cầu quan 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 ở mức P0 và P1, bạn cũng phải giải thích lý do cần thiết phải giải quyết gấ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 quay lại 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 quay lại được đánh dấu là đã khắc phục, hãy gửi yêu cầu quay lại mới. Đừng mở lại yêu cầu để thêm danh sách thay đổi (CL) khác.
  • Nếu yêu cầu tạo lại 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 xuống một cấp, ví dụ: P0 sẽ giảm xuống P1.
  • Nếu bạn không phản hồi trong vòng 2 tuần, lỗi sẽ được đánh dấu là Won't Fix (Không khắc phục) (Lỗi không còn hiệu lực).

Gửi yêu cầu tạo lại

Sơ đồ sau đây minh hoạ quy trình respin. Quy trình này 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 phát hành lại khẩn cấp.

Cách gửi yêu cầu tạo lại:

  1. Điền thông tin vào biểu mẫu yêu cầu tạo lại 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ị các 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 thích hợp.
    • Sửa đổi bản vá được chọn lọc để thêm thẻ Bug: XYZ trích dẫn mã yêu cầu respin.

    Ví dụ: Để chọn 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. Những việc sau sẽ xảy ra sau khi bạn gửi yêu cầu:

    • Quy trình xem xét sau khi bạn gửi yêu cầu:

      • Nhóm GKI của Google sẽ xem xét yêu cầu và phê duyệt hoặc giao lại yêu cầu đó 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ã của thay đổi đó. Bộ tính giờ ESRT sẽ 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, thì bộ hẹn giờ ESRT sẽ đặt lại.
      • Nhóm GKI hợp nhất, tạo, kiểm thử hồi quy và chứng nhận thay đổi.

    • Phát hành: