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 quý và ngoài băng tần. Mục tiêu của tài liệu này là cung cấp cho các OEM hướng dẫn về nơi lấy GKI cũng như quy trình sửa lỗi khẩn cấp ngoài băng tần. Các OEM cũng có thể sử dụng hoạt động phát triển GKI để tìm hiểu thêm về cách họ có thể hợp tác với nhóm Nhân Android để tối ưu hoá nhân GKI cho sản phẩm của mình.

Lịch trình phát hành GKI

GKI được phát hành theo quý sau khi KMI ngừng hoạt động.

Tính hợp lệ của bản dựng GKI đối với OEM

Các OEM có thể sử dụng GKI Android mới phát hành. Các nhà sản xuất thiết bị gốc (OEM) có thể ra mắt 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 LTS trong Bản tin bảo mật Android (ASB).

Bản phát hành hằng tuần cho hoạt động phát triển

Các tệp nhị phân GKI có sẵn để tự phục vụ 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ở cho quá trình phát triển và kiểm thử. Không thể dùng bản dựng hằng tuần cho bản dựng thiết bị sản xuất cho người dùng cuối.

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

Các bản phát hành hằng quý của GKI chứa một boot.img đã được kiểm thử, bao gồm một chứng chỉ do Google chèn vào để 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 quý, một bản phát hành ứng cử viên hằng quý của GKI (chưa được chứng nhận) sẽ được chọn sau ngày hết hạn đăng ký, thường là bản dựng hằng tuần thứ hai của tháng đó. Sau khi bạn chọn bản phát hành thử nghiệm hằng quý, 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 thời gian đóng cửa, chỉ những bản sửa lỗi gây ra lỗi kiểm thử mới được giải quyết. Bản phát hành thử nghiệm trải qua quy trình đảm bảo chất lượng (như mô tả trong phần kiểm định GKI) để đảm bảo các bài kiểm thử tuân thủ vượt qua quy trình kiểm thử trên bản dựng GSI+GKI bằng thiết bị tham chiếu cũng như cuttlefish.

Hình 1. Lịch phát hành GKI

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

Respin (phát hành lại) 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 một bản phát hành công khai của nhân GKI. Bạn có thể yêu cầu tạo lại một tệp nhị phân đã được 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, kể cả những lỗi được phát hiện trong quá trình phê duyệt phòng thí nghiệm của hãng vận chuyển.
• Cách thêm một vendor hook.
• Để á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 hợp nhất vào một nhánh phát hành trong tối đa 6 tháng sau khi nhánh đó được phát hành. Sau thời hạn 6 tháng, bạn phải yêu cầu một bản cập nhật lại để áp dụng các bản vá bảo mật cho một nhánh.

Nguyên tắc yêu cầu tạo lại

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

• Bạn chỉ được phép phát hành lại trên các nhánh phát hành sau khi phát hành công khai lần đầu một bản dựng hằng quý.

• 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 lần phát hành công khai ban đầu. Sau 6 tháng, các nhánh chỉ đủ điều kiện để tạo lại bản dựng cho các bản vá bảo mật được đề cập trong Bản tin bảo mật của Android.

• Khi các yêu cầu 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. Chúng tôi không chấp nhận yêu cầu tạo lại ảnh 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ú bản dựng phát hành GKI hằng quý trong phần Phát hành. Để lập kế hoạch cho tương lai, các yêu cầu về LTS sẽ đượ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.

• Chỉ áp dụng việc phát hành lại cho các bản sửa lỗi khẩn cấp, bản 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ó.

• 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 lần phát hành 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 lọc 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 quý.

• Trong yêu cầu tạo lại, bạn phải chỉ định mức độ ưu tiên (mức độ khẩn cấp) cho yêu cầu. 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 P0 và P1, bạn cũng phải giải thích lý do cần thiết. 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ê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 quay lại riêng cho mỗi nhánh phát hành. Ví dụ: nếu cần xác minh lại cho cả android12-5.10-2022-08 và android12-5.10-2022-09, bạn phải tạo 2 yêu cầu xác minh lại.

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

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

  • Bug: bạn 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 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 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 còn được dùng)).

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.

Hình 2. Quy trình quay lại

Cách bắt đầu quy trình quay lại:

1. Điền vào biểu mẫu yêu cầu GKI Respin và liên hệ ngay với Giám đốc Quản lý Khách hàng về Kỹ thuật của Google. Biểu mẫu này tạo ra một lỗi yêu cầu quay lại GKI. Bạn (người yêu cầu), nhóm GKI và một số cá nhân cụ thể mà bạn thêm vào danh sách người nhận CC của lỗi sẽ thấy được các lỗi yêu cầu respin.
   • Nếu bạn đã có bản sửa lỗi, thì yêu cầu phải trỏ đến bản vá được gửi trong AOSP để Google có thể xem xét. Nếu không thể gửi bản vá, thì 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 chưa 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 và nhật ký của nhân, để Google có thể giúp bạn gỡ lỗi.
2. Nhóm GKI của Google sẽ xem xét yêu cầu và phê duyệt hoặc chỉ định lại yêu cầu đó cho bạn nếu cần thêm thông tin.
3. Sau khi thống nhất về 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 bắt đầu trong khung thời gian ESRT. Nhóm GKI hợp nhất, tạo, 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à đã được khắc phục và tham chiếu bản dựng respin. Bản dựng respin cũng sẽ được đăng trên trang bản dựng phát hành Generic Kernel Image (GKI).

Điều kiện đối với GKI

Nơi lấy các cấu phần phần mềm

Bạn có thể lấy các cấu phần phần mềm cho 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 trên Android.

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

Sau đâ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 một tệp nhị phân GKI mới dựa trên một GKI đã phát hành hay không?

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

Có thể sao chép các tệp nhị phân GKI không?

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

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

Để tái tạo 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ủa 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á khẩn cấp) có được tạo trên cơ sở mã mới nhất không?

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

• OEM1 và OEM2 quyết định sử dụng bản phát hành nhị phân GKI từ tháng 11 năm 2021.
• OEM1 và OEM2 phát hiện thấy các vấn đề cần có bản vá để được hỗ trợ. Các bản vá này có thể khác nhau hoặc có thể giống nhau.
• Các bản phát hành lại trên bản 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 cửa sổ 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 quý 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. Chúng tôi có thể chỉ đưa bản vá của mình vào không?

Bạn không thể làm việc này. Đường dẫn "theo từng OEM" không thể mở rộng. Thay vào đó, nhóm GKI xem xét kỹ lưỡng từng thay đổi trong các bản dựng respin 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 một bản dựng mới. Nếu nhóm GKI nhận thấy vấn đề này chỉ xảy ra trên một OEM, thiết bị hoặc mẫu cụ thể, thì nhóm GKI có thể đảm bảo rằng mã do thay đổi này thêm vào chỉ thực thi trên thiết bị, mẫu hoặc SKU chịu ảnh hưởng.

Lợi ích chính của việc 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ó lợi cho nhau, đặc biệt nếu các 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 phát hiện trong quá trình kiểm thử của 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á của OEM và các tình huống có vấn đề để OEM có thể đánh giá tác động và rủi ro khi triển khai các bản vá với sản phẩm của họ không?

Google sẽ không bao giờ thêm thay đổi vào bản dựng respin cho đến khi hiểu rõ vấn đề và thu thập được tất cả thông tin chi tiết. Điều này được thể hiện trong nhật ký thay đổi (thông báo cam kết). Google không tiết lộ thiết bị cụ thể mà vấn đề này ảnh hưởng, nhưng các 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.