Quy trình phát hành Hình ảnh hạt nhân chung (GKI)

Trang này mô tả cách phát hành GKI, bao gồm cả các bản phát hành khẩn cấp hằng tuần, hằng tháng và ngoài phạm vi phát hành. Mục tiêu của tài liệu này là cung cấp cho OEM hướng dẫn về nơi lấy GKI cũng như quy trình khắc phục khẩn cấp ngoài phạm vi hỗ trợ. Nhà sản xuất thiết bị gốc (OEM) cũng có thể sử dụng tính năng phát triển GKI để tìm hiểu thêm về cách họ có thể làm việc với nhóm Hạt nhân Android nhằm tối ưu hoá hạt nhân GKI cho các sản phẩm của mình.

Tốc độ phát hành GKI

GKI được phát hành theo tần suất hằng tháng sau khi KMI ngừng hoạt động.

Bản phát hành GKI cho Android 13, 14 và 15

Bảng sau đây chỉ áp dụng cho android13-5.10, android13-5.15 và android14-5.15.

Bảng sau đây chỉ áp dụng cho android14-6.1 và android15-6.6.

Bản phát hành GKI cho Android 12

Sau tháng 5 năm 2024, các bản phát hành android12-5.10 GKI sẽ theo tần suất hằng quý và được phát hành vào giữa tháng. Bảng sau đây chỉ áp dụng cho android12-5.10.

Tính hợp lệ của bản dựng GKI cho OEM

Nhà sản xuất thiết bị gốc có thể sử dụng GKI Android mới phát hành. Nhà sản xuất thiết bị gốc (OEM) có thể ra mắt bằng các bản dựng được chứng nhận GKI, miễn là các bản dựng đó tuân thủ các yêu cầu về LTS trong Bản tin bảo mật Android (ASB).

Bản phát hành phát triển hằng tuần

Bạn có thể tự phục vụ các tệp nhị phân GKI từ Android CI khi các thay đổi được hợp nhất. Các bản dựng hằng tuần sẽ không được chứng nhận, mặc dù có thể được dùng làm cơ sở để phát triển và kiểm thử. Không thể sử dụng bản dựng hằng tuần cho bản dựng thiết bị phát hành chính thức dành cho người dùng cuối.

Bản phát hành được chứng nhận hằng tháng

Bản phát hành hằng tháng của GKI chứa một boot.img đã kiểm thử, trong đó có một chứng chỉ do Google chèn để chứng thực rằng các tệp nhị phân được tạo từ một đường cơ sở mã nguồn đã biết.

Mỗi tháng, một bản phát hành đề xuất hằng tháng của GKI (chưa được chứng nhận) sẽ được chọn sau ngày cắt bớt lượt kiểm tra, thường là bản dựng hằng tuần thứ hai của tháng đó. Sau khi chọn bản phát hành hằng tháng, các thay đổi mới sẽ không được chấp nhận vào bản phát hành của tháng đó. Trong khoảng thời gian đóng cửa sổ, bạn chỉ có thể giải quyết các bản sửa lỗi cho lỗi gây ra lỗi kiểm thử. Bản phát hành đề xuất trải qua quy trình đảm bảo chất lượng (như mô tả trong phần về việc đánh giá GKI) để đảm bảo các kiểm thử tuân thủ đạt được trên bản dựng GSI+GKI với thiết bị tham chiếu cũng như cuttlefish.

Hình 1. Tiến trình phát hành GKI

Quy trình thử lại khẩn cấp

Respin (tái tạo) là quá trình hợp nhất lại, tạo lại, kiểm thử lại và chứng nhận lại tệp nhị phân sau khi bản phát hành công khai của hạt nhân GKI. Bạn có thể yêu cầu gửi lại tệp nhị phân đã chứng nhận trong bất kỳ trường hợp nào sau đây:

• Cách cập nhật danh sách ký hiệu.
• Để áp dụng bản sửa lỗi cho một lỗi, bao gồm cả lỗi phát hiện được trong quá trình phê duyệt của phòng thí nghiệm của nhà mạng.
• Để thêm lệnh gọi của nhà cung cấp.
• Để áp dụng bản vá cho một tính năng hiện có.
• Để áp dụng bản vá bảo mật (sau 6 tháng).

Các bản vá bảo mật sẽ tự động được hợp nhất vào một nhánh phát hành trong tối đa 6 tháng sau khi phát hành nhánh. Sau thời hạn 6 tháng, bạn phải yêu cầu gửi lại để áp dụng các bản vá bảo mật cho một nhánh.

Nguyên tắc về yêu cầu đảo ngược

Trước khi yêu cầu chạy lại, hãy lưu ý các nguyên tắc sau:

• Bạn chỉ được phép thực hiện thao tác quay lại trên các nhánh phát hành sau khi bản phát hành công khai đầu tiên của một bản dựng hằng tháng được ra mắt.

• Chúng tôi chỉ chấp nhận yêu cầu phát hành lại cho một nhánh phát hành nhất định trong tối đa 6 tháng sau bản phát hành công khai đầu tiên. Sau 6 tháng, các nhánh chỉ đủ điều kiện để gửi lại bản sửa lỗi bảo mật được trích dẫn trong Bản tin bảo mật Android.

• 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ủ, thì nhánh đó sẽ không được dùng nữa. Yêu cầu trả về cho các nhánh không dùng nữa không được chấp nhận. Ngày ngừng sử dụng một nhánh phát hành GKI nhất định có trong ghi chú bản phát hành GKI hằng tháng trong phần Bản phát hành. Để lập kế hoạch trong tương lai, các yêu cầu LTS được cập nhật vào tháng 5 và tháng 11 hằng năm. Ví dụ: nhánh android12-5.10-2023-07 (5.10.177) không được hỗ trợ cho các bản phát hành lại sau ngày 1 tháng 5 năm 2024, vì nhánh android12-5.10-2023-07 (5.10.177) không tuân thủ các yêu cầu về LTS của ASB-2024-05.

• Bạn chỉ có thể sử dụng tính năng quay lại khi cần sửa lỗi khẩn cấp, cập nhật danh sách biểu tượng hoặc áp dụng bản vá để khắc phục một tính năng hiện có.

• Tất cả các bản vá đi vào nhánh phát hành hằng tháng 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á để tạo lại android12-5.10-2022-09, thì bản vá đó phải được hợp nhất vào android12-5.10.

• Bạn phải chọn các bản vá từ nhánh phát triển GKI chính và tải bản vá lên nhánh phát hành hằng tháng.

• Trong yêu cầu gửi lại, bạn phải chỉ định mức độ ưu tiên (tính cấp thiết) cho yêu cầu. Ưu tiên này giúp nhóm GKI hỗ trợ đối tác kịp thời hơn, hiệu quả hơn. Đối với các 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 P0 và P1, bạn cũng phải giải thích lý do cấp thiết. Bảng sau đây cung cấp thông tin liên kết giữa mức độ ưu tiên của lỗi và thời gian khắc phục (ESRT):

  Mức độ ưu tiên	ESRT
  P0	2 ngày làm việc
  P1	5 ngày làm việc
  P2	10 ngày làm việc
  P3	15 ngày làm việc

• Bạn phải gửi một yêu cầu gửi lại riêng cho mỗi nhánh phát hành. Ví dụ: nếu cần thực hiện một lần thử lại cho cả android12-5.10-2022-08 và android12-5.10-2022-09, bạn phải tạo hai yêu cầu thử lại.

• Sau khi cung cấp bản dựng và yêu cầu trả lại được đánh dấu là đã khắc phục, bạn không nên mở lại yêu cầu trả lại để thêm CL bổ sung. Bạn phải gửi yêu cầu khôi phục mới nếu cần hợp nhất các bản vá khác.

• Đối với mỗi CL đang được xem xét, hãy thêm các thẻ sau.

  • Bug: phải thêm mã lỗi vào thông báo cam kết cho mỗi CL.
  • Change-Id: phải giống với Change-Id của thay đổi nhánh cơ sở.

• Nếu yêu cầu gửi lại yêu cầu 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ẽ bị hạ một cấp (ví dụ: P0 sẽ bị hạ xuống P1). Nếu bạn không phản hồi trong vòng hai tuần, lỗi sẽ được đánh dấu là Sẽ không khắc phục (Không dùng nữa).

Gửi yêu cầu trả lại

Sơ đồ sau đây cho thấy quy trình thử lại. Quy trình này bắt đầu khi Đối tác OEM (bạn) gửi yêu cầu gửi lại.

Hình 2. Quy trình thử lại

Cách thực hiện quy trình thử lại:

1. Điền vào biểu mẫu yêu cầu gửi lại GKI và liên hệ ngay với Nhà quản lý tài khoản hỗ trợ kỹ thuật của Google. Biểu mẫu này tạo lỗi yêu cầu trả về GKI. Bạn (người yêu cầu), nhóm GKI và những cá nhân cụ thể mà bạn thêm vào danh sách CC của lỗi sẽ thấy các lỗi yêu cầu trả về.
   • Nếu bạn đã có bản sửa lỗi, yêu cầu này sẽ trỏ đến nội dung gửi bản vá trong AOSP để Google có thể xem xét. Nếu không thể gửi bản vá, bạn phải đính kèm bản vá dưới dạng tệp văn bản vào yêu cầu.
   • Nếu bạn không có bản sửa lỗi, yêu cầu phải chứa nhiều thông tin nhất có thể, bao gồm cả số phiên bản hạt nhân và nhật ký để Google có thể giúp gỡ lỗi vấn đề.
2. 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.
3. Sau khi bạn đồng ý với một bản sửa lỗi, nhóm GKI của Google sẽ xem xét mã (CR+2) đối với thay đổi đó. Quy trình xem xét sẽ bắt đầu khung thời gian ESRT. Nhóm GKI hợp nhất, tạo bản dựng, kiểm thử hồi quy và chứng nhận thay đổi.
4. Tệp nhị phân được phát hành cho 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 bản dựng respin. Bản dựng respin cũng được đăng trên trang bản phát hành Hình ảnh hạt nhân chung (GKI).

Điều kiện của GKI

Nơi lấy cấu phần phần mềm bản dựng

Bạn có thể lấy cấu phần phần mềm của tất cả các bản phát hành từ ci.android.com.

Bạn có thể tìm thêm thông tin về CI, bao gồm cả kết quả kiểm thử trên trang tổng quan Tích hợp liên tục Android.

Câu hỏi thường gặp

Dưới đây là một số câu hỏi thường gặp liên quan đến quy trình phát hành GKI.

Có thể tạo tệp nhị phân GKI mới dựa trên GKI đã phát hành không?

Có, đây được gọi là lượt thử lại. Quy trình gửi lại được hỗ trợ miễn là bản dựng GKI đã phát hành (mà bạn yêu cầu gửi lại) tuân thủ các yêu cầu về LTS trong Bản tin bảo mật Android (ASB).

Có thể tái tạo các tệp nhị phân GKI không?

Có, sau đây là ví dụ:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Để tạo lại ví dụ này, hãy tải manifest_$id.xml xuống và thực thi lệnh sau:

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

Bạn có thể truy xuất bản sao cấu phần phần mềm GKI từ out/.../dist.

Tệp nhị phân GKI (bao gồm cả bản vá xoay khẩn cấp) đã được tạo trên cơ sở mã mới nhất chưa?

Không. Các bản phát hành lại chỉ chứa các bản vá nằm trên các hạt nhân được chứng nhận hằng tháng đã được chọn. Các bản phát hành lại này chứa tất cả bản sửa lỗi lỗi chặn khởi chạy do OEM báo cáo cho đến thời điểm bất kỳ bằng cách sử dụng bản phát hành cơ sở tương ứng hằng tháng. Hãy xem ví dụ sau đây về quy trình của loại tình huống này.

• OEM1 và OEM2 quyết định sử dụng bản phát hành tệp nhị phân GKI kể từ tháng 11 năm 2021.
• OEM1 và OEM2 tìm thấy các vấn đề cần bản vá để hỗ trợ. Các bản vá này có thể khác nhau hoặc giống nhau.
• Các bản phát hành lại trên tệp nhị phân tháng 11 năm 2021 có các bản sửa lỗi chặn khởi chạy do cả OEM1 và OEM2 báo cáo trong khoảng thời gian phát hành lại, nhưng không có gì khác.
• Các vấn đề được đề cập trong dấu đầu dòng thứ hai cũng có trong các bản phát hành GKI hằng tháng tiếp theo.

Bản phát hành lại tháng 10 có tất cả các bản vá do OEM gửi, nhưng các bản vá khác của OEM ảnh hưởng đến chúng tôi vì chúng chưa được kiểm thử cụ thể với các sản phẩm của chúng tôi. Có thể chỉ đưa bản vá của chúng tôi vào không?

Điều này là không thể. Đường dẫn gửi lại "cho mỗi OEM" không thể mở rộng quy mô. Thay vào đó, nhóm GKI sẽ kiểm tra kỹ lưỡng từng thay đổi trong bản dựng và kiểm thử các thay đổi đó với tất cả phần cứng hiện có trước khi tạo bản dựng mới. Nếu nhóm GKI nhận thấy vấn đề chỉ xảy ra với một OEM, thiết bị hoặc mẫu, thì nhóm GKI có thể đảm bảo rằng mã được thêm bằng thay đổi chỉ thực thi trên thiết bị, mẫu hoặc SKU bị ảnh hưởng.

Lợi ích chính của các bản phát hành lại hợp nhất là mọi thiết bị sử dụng cùng một cơ sở phát hành đều được hưởng lợi từ nhau, đặc biệt là nếu lỗi mà chúng phát hiện là lỗi chung và áp dụng cho tất cả người dùng. Lỗi hạt nhân cốt lõi được tìm thấy trong quá trình kiểm thử nhà mạng là một ví dụ cụ thể về khái niệm này.

Có trường hợp nào Google cung cấp thông tin cụ thể về các bản vá và tình huống sự cố của nhà sản xuất thiết bị gốc (OEM) để OEM có thể đánh giá tác động và rủi ro khi triển khai các bản vá cho sản phẩm của họ không?

Google sẽ không bao giờ thêm thay đổi nào vào bản dựng trả về cho đến khi hiểu được vấn đề và thu thập tất cả thông tin chi tiết. Bạn có thể xem nội dung này trong nhật ký thay đổi (thông báo cam kết). Google không tiết lộ thiết bị cụ thể nào bị ảnh hưởng, nhưng OEM luôn có thể tìm thấy nội dung mô tả và giải pháp cho vấn đề trong nhật ký thay đổi.