Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Hướng dẫn dành cho nhà sản xuất về bảo mật Android lâu dài
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Hướng dẫn này mô tả các phương pháp hay nhất mà Google đề xuất để áp dụng các bản vá bảo mật được Bộ kiểm thử tính tương thích với Android (CTS) đánh giá. Chương trình này dành cho các nhà sản xuất thiết bị OEM tương thích với Android (nhà sản xuất) sẽ được hỗ trợ lâu hơn 3 năm, chẳng hạn như xe cộ, TV, hộp giải mã tín hiệu số và thiết bị gia dụng. Hướng dẫn này không dành cho người dùng cuối (ví dụ: chủ sở hữu xe).

Xin chân thành cảm ơn và từ chối trách nhiệm

Hướng dẫn này không ràng buộc Google hoặc các nhà sản xuất khác về mặt pháp lý hoặc hợp đồng và không nhằm mục đích đưa ra một bộ yêu cầu. Thay vào đó, hướng dẫn này là một tài liệu hỗ trợ hướng dẫn mô tả các phương pháp đề xuất.

Phản hồi

Hướng dẫn này không nhằm mục đích cung cấp thông tin đầy đủ; chúng tôi dự định sẽ có thêm các bản sửa đổi. Gửi ý kiến phản hồi tới manufacturers-guide-android@googlegroups.com.

Bảng chú giải thuật ngữ

Thuật ngữ	Định nghĩa
ACC	Cam kết về khả năng tương thích với Android. Trước đây được gọi là Thoả thuận chống phân mảnh của Android (AFA).
AOSP (Dự án nguồn mở Android)	Dự án nguồn mở Android
ASB	Bản tin về bảo mật Android
BSP	Gói hỗ trợ bảng
CDD	Tài liệu định nghĩa về khả năng tương thích
CTS	Bộ kiểm thử khả năng tương thích
FOTA	chương trình cơ sở qua mạng
GPS	hệ thống định vị toàn cầu
MISRA	Hiệp hội độ tin cậy phần mềm trong ngành ô tô
NIST	Viện Tiêu chuẩn và Công nghệ Quốc gia
OBD	chẩn đoán trên bo mạch (OBD-II là một điểm cải tiến so với OBD-I cả về khả năng và tiêu chuẩn hoá)
OEM (Nhà sản xuất thiết bị gốc)	nhà sản xuất thiết bị gốc
Hệ điều hành	hệ điều hành
SEI	Viện Kỹ thuật phần mềm
SoC	hệ thống trên chip
SOP	bắt đầu sản xuất
SPL	Cấp bản vá bảo mật
TPMS	hệ thống giám sát áp suất lốp

Giới thiệu về hệ điều hành Android

Android là một ngăn xếp phần mềm đầy đủ, nguồn mở, dựa trên Linux, được thiết kế cho nhiều thiết bị và kiểu dáng. Kể từ bản phát hành đầu tiên vào năm 2008, Android đã trở thành Hệ điều hành (OS) phổ biến nhất, hỗ trợ hơn 1,4 tỷ thiết bị trên toàn thế giới (2016). Khoảng 67% thiết bị trong số đó sử dụng Android 5.0 (Lollipop) trở lên kể từ tháng 3 năm 2017 (các số liệu mới hơn có trên Trang tổng quan Android). Mặc dù phần lớn thiết bị là điện thoại di động và máy tính bảng, nhưng Android đang phát triển mạnh mẽ trong các đồng hồ thông minh, TV và thiết bị thông tin giải trí trên ô tô (IVI).

Số lượng ứng dụng Android có trong Cửa hàng Google Play đã đạt ngưỡng hơn 2,2 triệu (năm 2016). Chương trình Khả năng tương thích của Android hỗ trợ việc phát triển ứng dụng Android. Chương trình này xác định một bộ yêu cầu thông qua Tài liệu định nghĩa về khả năng tương thích (CDD) và cung cấp các công cụ kiểm thử thông qua Bộ kiểm thử tính tương thích (CTS). Các chương trình tương thích với Android đảm bảo mọi ứng dụng Android đều có thể chạy trên mọi thiết bị tương thích với Android hỗ trợ các tính năng bắt buộc cho ứng dụng.

Google thường xuyên phát hành các phiên bản hệ điều hành mới, bản cập nhật bảo mật hệ điều hành và thông tin về các lỗ hổng đã phát hiện. Nhà sản xuất phải xem xét Bản tin bảo mật Android để biết khả năng áp dụng các bản cập nhật này cho các sản phẩm được hỗ trợ hệ điều hành Android. Để xem xét tính bảo mật, khả năng tương thích và hệ thống xây dựng của Android, hãy xem các nội dung sau:

Giới thiệu về xe kết nối (sản phẩm chính tắc có thời gian tồn tại lâu dài)

Xe bắt đầu được kết nối khi đài AM ra đời vào những năm 1920. Từ đó, số lượng kết nối không dây và kết nối vật lý bên ngoài bắt đầu tăng lên khi các cơ quan quản lý và nhà sản xuất ô tô chuyển sang sử dụng thiết bị điện tử để dễ dàng chẩn đoán và bảo dưỡng (ví dụ: cổng OBD-II), cải thiện độ an toàn (ví dụ: TPMS) và đáp ứng các mục tiêu tiết kiệm nhiên liệu. Làn sóng kết nối tiếp theo đã ra mắt các tính năng tiện lợi cho người lái xe, chẳng hạn như tính năng mở khoá từ xa không cần chìa khoá, hệ thống viễn thông và các tính năng thông tin giải trí nâng cao như Bluetooth, Wi-Fi và tính năng chiếu từ điện thoại thông minh. Ngày nay, các cảm biến và khả năng kết nối tích hợp (ví dụ: GPS) hỗ trợ các hệ thống lái xe an toàn và bán tự động.

Khi số lượng kết nối của xe tăng lên, diện tích bề mặt tiềm ẩn của cuộc tấn công xe cũng tăng theo. Các kết nối này cũng mang đến một loạt mối lo ngại về an ninh mạng tương tự như đối với thiết bị điện tử tiêu dùng. Tuy nhiên, mặc dù việc khởi động lại, cập nhật bản vá hằng ngày và các hành vi không giải thích được là tiêu chuẩn đối với thiết bị điện tử tiêu dùng, nhưng những hành vi này không nhất quán đối với các sản phẩm có hệ thống quan trọng về an toàn như ô tô.

Nhà sản xuất phải chủ động đảm bảo tính bảo mật và an toàn liên tục của sản phẩm trong thực tế. Tóm lại, nhà sản xuất phải nắm được các lỗ hổng bảo mật đã biết trong sản phẩm và áp dụng phương pháp dựa trên rủi ro để giải quyết các lỗ hổng đó.

Đảm bảo an toàn lâu dài

Xe ô tô kết nối thường có một hoặc nhiều đơn vị điều khiển điện tử (ECU) bao gồm nhiều thành phần phần mềm như hệ điều hành, thư viện, tiện ích, v.v. Nhà sản xuất nên theo dõi các thành phần đó và xác định các lỗ hổng đã công bố bằng cách phân tích chủ động, bao gồm:

Thường xuyên đánh giá sản phẩm dựa trên cơ sở dữ liệu về Lỗ hổng và vấn đề rò rỉ phổ biến (CVE).
Thu thập thông tin về các lỗ hổng bảo mật liên quan đến sản phẩm.
Kiểm thử bảo mật.
Tích cực phân tích Bản tin bảo mật Android.

Ví dụ về bản cập nhật hệ điều hành và bản vá bảo mật (IVI chạy Android):

Hình 1. Ví dụ về việc triển khai bản cập nhật bảo mật và hệ điều hành chính trong vòng đời của xe.

#	Bước	Hoạt động
①	Nhánh phát triển	Nhà sản xuất chọn một phiên bản Android (Android X). Trong ví dụ này, "Android X" trở thành nền tảng của những gì sẽ được vận chuyển trong xe hai năm trước khi bắt đầu sản xuất (SOP).
②	Ra mắt lần đầu	Vài tháng trước khi Android X trở thành phiên bản hệ điều hành đầu tiên được vận chuyển trong sản phẩm, các bản cập nhật bảo mật được lấy từ Bản tin bảo mật Android (ASB) và có thể là các nguồn khác mà nhà sản xuất coi là có giá trị. y2 = Bản tin bảo mật thứ hai cho phiên bản X của Android, do nhà sản xuất áp dụng (đưa về phiên bản cũ) cho Android X. Bản cập nhật này được đưa vào sản phẩm và đồng hồ phát hành bắt đầu tích tắc từ Năm 0 với Android X.y2. Trong ví dụ này, nhà sản xuất đã quyết định không phân phối bản phát hành hằng năm Android X+1 mới đây hơn. Các lý do để phát hành bản phát hành mới nhất bao gồm việc thêm tính năng mới, giải quyết các lỗ hổng bảo mật mới và/hoặc phát hành các dịch vụ của Google hoặc bên thứ ba yêu cầu phiên bản Android mới hơn. Lý do không nên phát hành bản phát hành gần đây nhất là do thiếu thời gian vốn có trong quá trình phát triển và ra mắt xe cần thiết để tích hợp, kiểm thử và xác thực các thay đổi, bao gồm cả việc tuân thủ tất cả các yêu cầu về chứng nhận và quy định.
③	Cập nhật toàn bộ hệ điều hành	Sau SOP, nhà sản xuất sẽ phát hành bản cập nhật hệ điều hành Android X+2, tức là hai bản phát hành Android sau phiên bản dùng cho sản phẩm ban đầu (Android X0). Các bản cập nhật bảo mật ASB có sẵn cho cấp độ API (kể từ ngày xuất xưởng), vì vậy, bản cập nhật sẽ được phát hành dưới dạng X+2.y0 khoảng 1,25 năm sau SOP. Bản cập nhật hệ điều hành này có thể tương thích hoặc không tương thích với các sản phẩm đã triển khai. Nếu có, bạn có thể tạo một kế hoạch để cập nhật các xe đã triển khai. Trừ phi có các thoả thuận kinh doanh khác, quyết định cập nhật toàn bộ hệ điều hành là hoàn toàn thuộc về nhà sản xuất.
④	Bản cập nhật bảo mật	Sau 2 năm sản xuất xe, nhà sản xuất sẽ vá hệ điều hành Android X+2. Quyết định này được đưa ra dựa trên kết quả đánh giá rủi ro của nhà sản xuất. Nhà sản xuất chọn bản cập nhật bảo mật ASB thứ ba cho bản phát hành X+2 làm cơ sở cho bản cập nhật. Các sản phẩm nhận được bản cập nhật bảo mật hiện đang ở (X+2.y3) OS + Cấp bản vá bảo mật của Android. Mặc dù nhà sản xuất có thể chọn từng bản vá bảo mật từ bất kỳ ASB nào, nhưng họ phải khắc phục tất cả các vấn đề bắt buộc trong bản tin để sử dụng cấp độ bản vá bảo mật Android (SPL) liên kết với bản tin (ví dụ: 2017-02-05). Nhà sản xuất chịu trách nhiệm triển khai bản phát hành bảo mật và điều chỉnh cho phiên bản cũ cho sản phẩm được hỗ trợ.
⑤	Cập nhật toàn bộ hệ điều hành	Lặp lại bước 3 (Cập nhật toàn bộ hệ điều hành), bản cập nhật toàn bộ hệ điều hành thứ hai sẽ nâng sản phẩm lên Android X+4, sau 3 năm kể từ khi bắt đầu sản xuất xe. Nhà sản xuất hiện đang cân bằng các yêu cầu phần cứng mới hơn của phiên bản Android gần đây với phần cứng trong sản phẩm và lợi ích của người dùng từ hệ điều hành Android đã cập nhật. Nhà sản xuất phát hành bản cập nhật không có bản cập nhật bảo mật, vì vậy, sản phẩm hiện đang ở cấp bản vá bảo mật Android + Hệ điều hành (X+4.y0). Trong ví dụ này, do các giới hạn về phần cứng, X+4 là phiên bản Android chính mới nhất sẽ được cung cấp cho sản phẩm này, mặc dù thời gian sử dụng dự kiến của xe là hơn 6 năm vẫn cần có hỗ trợ bảo mật.
⑥	Bản cập nhật bảo mật	Lặp lại bước 4 (Bản cập nhật bảo mật). Nhà sản xuất có nhiệm vụ lấy các bản cập nhật bảo mật ASB từ một phiên bản Android mới hơn nhiều (X+6) và chuyển một số hoặc tất cả các bản cập nhật đó trở lại Android X+4. Nhà sản xuất có trách nhiệm hợp nhất, tích hợp và thực hiện các bản cập nhật (hoặc ký hợp đồng với bên thứ ba). Ngoài ra, nhà sản xuất cần lưu ý rằng các vấn đề bảo mật trong các phiên bản Android không còn được hỗ trợ sẽ không được đề cập trong ASB.
⑦	Bản cập nhật bảo mật	Sau 8 năm trong vòng đời sản xuất của xe, 4 bản phát hành Android kể từ bản cập nhật hệ điều hành gần đây nhất ở Bước 5 (Cập nhật toàn bộ hệ điều hành) và 10 năm kể từ khi Android X được chỉ định, nhà sản xuất phải chịu toàn bộ trách nhiệm tuyển chọn và điều chỉnh ngược các bản vá bảo mật cho những phiên bản cũ hơn 3 năm kể từ bản phát hành công khai cấp độ API.

Các phương pháp bảo mật hay nhất

Để khiến việc xâm phạm bảo mật trở nên khó khăn hơn, Google đề xuất và sử dụng các phương pháp hay nhất được chấp nhận rộng rãi về bảo mật và kỹ thuật phần mềm, như mô tả trong phần Triển khai bảo mật.

Nguyên tắc bảo mật

Sau đây là một số phương pháp bảo mật được đề xuất:

Sử dụng các phiên bản mới nhất của thư viện bên ngoài và thành phần nguồn mở.
Không đưa chức năng gỡ lỗi xâm phạm vào các phiên bản phát hành của hệ điều hành.
Xoá chức năng không dùng đến (để giảm bề mặt tấn công không cần thiết).
Sử dụng nguyên tắc đặc quyền tối thiểu và các phương pháp hay nhất khác để phát triển ứng dụng Android.

Nguyên tắc phát triển phần mềm

Các phương pháp đề xuất để phát triển phần mềm an toàn cho vòng đời của hệ thống bao gồm:

Thực hiện mô hình hoá mối đe doạ để xếp hạng và xác định các thành phần, mối đe doạ và biện pháp giảm thiểu tiềm năng.
Thực hiện đánh giá kiến trúc/thiết kế để đảm bảo thiết kế an toàn và hợp lý.
Thường xuyên xem xét mã để xác định các mẫu chống và lỗi sớm nhất có thể.
Thiết kế, triển khai và chạy các chương trình kiểm thử đơn vị có mức độ sử dụng mã cao, bao gồm:
- Kiểm thử chức năng (bao gồm cả trường hợp kiểm thử âm tính)
- Kiểm thử hồi quy thường xuyên (để đảm bảo lỗi đã khắc phục không tái diễn)
- Kiểm thử mờ (là một phần của bộ kiểm thử đơn vị)
Sử dụng các công cụ phân tích mã nguồn tĩnh (quét bản dựng, tìm lỗi mã nguồn, v.v.) để xác định các vấn đề tiềm ẩn.
Sử dụng các công cụ phân tích mã nguồn động, chẳng hạn như AddressSanitizer, UndefinedBehaviorSanitizer và FORTIFY_SOURCE (dành cho các thành phần gốc) để xác định và giảm thiểu các vấn đề tiềm ẩn trong quá trình phát triển hệ thống.
Có chiến lược quản lý mã nguồn phần mềm và cấu hình/phiên bản phát hành.
Có chiến lược quản lý bản vá để tạo và triển khai bản vá phần mềm.

Chính sách điều chỉnh phiên bản cũ về bảo mật

Google hiện đang tích cực hỗ trợ việc điều chỉnh bảo mật cho các lỗ hổng bảo mật đã phát hiện và báo cáo trong vòng ba (3) năm kể từ bản phát hành công khai cấp độ API. Dịch vụ hỗ trợ chủ động bao gồm:

Nhận và điều tra báo cáo lỗ hổng.
Tạo, kiểm thử và phát hành bản cập nhật bảo mật.
Cung cấp các bản phát hành định kỳ về bản cập nhật bảo mật và thông tin chi tiết về bản tin bảo mật.
Đánh giá mức độ nghiêm trọng theo các nguyên tắc đã thiết lập.

Sau ba năm kể từ ngày phát hành công khai cấp độ API, Google đề xuất các nguyên tắc sau:

Sử dụng bên thứ ba (chẳng hạn như nhà cung cấp SoC hoặc nhà cung cấp Kernel) để hỗ trợ điều chỉnh cho các bản cập nhật bảo mật hệ điều hành cũ hơn 3 năm kể từ khi phát hành API.
Sử dụng bên thứ ba để đánh giá mã bằng các ASB được cung cấp công khai. Mặc dù ASB xác định các lỗ hổng cho phiên bản hiện được hỗ trợ, nhưng nhà sản xuất có thể sử dụng thông tin được cung cấp để so sánh các bản cập nhật mới phát hành với các phiên bản trước đó. Bạn có thể sử dụng dữ liệu này để phân tích tác động và có thể tạo các bản vá tương tự cho các phiên bản hệ điều hành cũ hơn 3 năm kể từ khi phát hành API.
Khi thích hợp, hãy tải bản cập nhật bảo mật lên Dự án nguồn mở Android (AOSP).
Nhà sản xuất phải điều phối việc xử lý các bản cập nhật bảo mật cho mã dành riêng cho nhà cung cấp (ví dụ: mã dành riêng cho thiết bị độc quyền).
Nhà sản xuất nên tham gia nhóm thông báo Bản xem trước thông báo của Đối tác về bản tin bảo mật Android theo thoả thuận không tiết lộ thông tin (yêu cầu ký các thoả thuận pháp lý như Thoả thuận không tiết lộ thông tin của nhà phát triển). Thông báo phải bao gồm:
- Thông báo
- Tóm tắt các vấn đề theo cấp độ bản vá, bao gồm cả CVE và mức độ nghiêm trọng
- Thông tin chi tiết về lỗ hổng (nếu có)

Tài liệu tham khảo khác

Để biết hướng dẫn về cách lập trình an toàn và các phương pháp phát triển phần mềm, hãy tham khảo những nội dung sau:

Các phương pháp được đề xuất về sản phẩm

Google khuyến khích bạn sử dụng các phương pháp được đề xuất sau đây.

Nguyên tắc chung về việc ra mắt

Nhìn chung, bạn nên ra mắt mọi sản phẩm có kết nối bằng phiên bản hệ điều hành mới nhất và nhà sản xuất nên cố gắng sử dụng phiên bản hệ điều hành mới nhất trước khi ra mắt sản phẩm. Mặc dù việc khoá phiên bản là cần thiết để tăng độ ổn định trước khi kiểm thử và xác thực, nhưng nhà sản xuất phải cân bằng độ ổn định của sản phẩm thu được từ các phiên bản hệ điều hành cũ với các phiên bản hệ điều hành mới hơn có ít lỗ hổng bảo mật đã biết hơn và tăng cường biện pháp bảo vệ bảo mật.

Sau đây là một số nguyên tắc được đề xuất:

Do thời gian phát triển dài vốn có trong quy trình phát triển xe, nhà sản xuất có thể cần phải ra mắt bằng phiên bản hệ điều hành n-2 trở xuống.
Duy trì việc tuân thủ Khả năng tương thích với Android cho mỗi phiên bản hệ điều hành Android đã phát hành bằng một chiến dịch không dây (OTA).
Triển khai tính năng Cập nhật qua mạng (FOTA) cho phần mềm của sản phẩm Android để cập nhật nhanh và thân thiện với khách hàng. Bạn nên thực hiện FOTA bằng các phương pháp bảo mật hay nhất, chẳng hạn như ký mã và kết nối TLS giữa sản phẩm và văn phòng hỗ trợ CNTT.
Gửi các lỗ hổng bảo mật trên Android mà bạn phát hiện được một cách độc lập cho Nhóm bảo mật Android.

Lưu ý: Google đã cân nhắc loại thiết bị hoặc thông báo theo ngành trong Bản tin bảo mật Android. Tuy nhiên, vì Google không biết nhân, trình điều khiển hoặc chipset cho một thiết bị cụ thể (ô tô, TV, thiết bị đeo, điện thoại, v.v.), Google không có cách nào xác định để gắn nhãn bất kỳ vấn đề bảo mật nào cho một loại thiết bị.

Nguyên tắc về chu kỳ sản phẩm

Nhà sản xuất phải cố gắng sử dụng phiên bản hệ điều hành mới nhất hoặc bản cập nhật bảo mật cho phiên bản đang sử dụng trong quá trình cải tiến chu kỳ sản phẩm. Bạn có thể cập nhật trong các bản cập nhật sản phẩm định kỳ hoặc bản sửa lỗi khẩn cấp để giải quyết vấn đề về chất lượng và/hoặc các vấn đề khác. Sau đây là một số phương pháp được đề xuất:

Tạo kế hoạch để giải quyết các bản cập nhật trình điều khiển, nhân và giao thức.
Sử dụng phương thức phù hợp với ngành để cung cấp nội dung cập nhật cho các xe đã triển khai.

Tài liệu định nghĩa về khả năng tương thích (CDD)

Tài liệu định nghĩa về khả năng tương thích (CDD) mô tả các yêu cầu để một thiết bị được coi là tương thích với Android. CDD là tài liệu công khai và dành cho tất cả mọi người; bạn có thể tải các phiên bản CDD từ Android 1.6 xuống phiên bản mới nhất từ source.android.com.

Để đáp ứng các yêu cầu này đối với một sản phẩm, bạn cần thực hiện các bước cơ bản sau:

Đối tác ký Thoả thuận cam kết về khả năng tương thích với Android (ACC) với Google. Sau đó, một Chuyên gia tư vấn giải pháp kỹ thuật (TSC) sẽ được chỉ định làm người hướng dẫn.
Đối tác hoàn tất quy trình xem xét CDD cho phiên bản hệ điều hành Android của sản phẩm.
Đối tác chạy và gửi kết quả CTS (như mô tả bên dưới) cho đến khi kết quả đạt yêu cầu về Khả năng tương thích với Android.

Bộ kiểm tra tính tương thích (CTS)

Công cụ kiểm thử Bộ kiểm tra tính tương thích (CTS) xác minh việc triển khai sản phẩm có tương thích với Android hay không và có bao gồm các bản vá bảo mật mới nhất hay không. CTS là công khai, nguồn mở và dành cho tất cả mọi người; bạn có thể tải các phiên bản CTS từ Android 1.6 xuống phiên bản mới nhất từ source.android.com.

Mỗi bản dựng phần mềm Android được phát hành công khai (hình ảnh cài đặt ban đầu và hình ảnh cập nhật tại hiện trường) phải chứng minh Khả năng tương thích với Android thông qua kết quả CTS. Ví dụ: nếu thiết bị chạy Android 7.1, bạn nên tham chiếu đến phiên bản tương ứng mới nhất của CDD 7.1 và CTS 7.1 khi tạo và kiểm thử hình ảnh bản dựng có ý định phát hành. Các nhà sản xuất nên sử dụng CTS sớm và thường xuyên để xác định và khắc phục các vấn đề.

LƯU Ý: Những đối tác ký các thoả thuận khác, chẳng hạn như Dịch vụ của Google dành cho thiết bị di động (GMS), có thể cần phải đáp ứng các yêu cầu khác.

Quy trình làm việc của CTS

Quy trình làm việc của CTS bao gồm việc thiết lập môi trường kiểm thử, chạy kiểm thử, diễn giải kết quả và tìm hiểu mã nguồn CTS. Các nguyên tắc sau đây nhằm giúp người dùng CTS (ví dụ: nhà phát triển, nhà sản xuất) sử dụng CTS một cách hiệu quả.

Thường xuyên chạy kiểm thử. CTS được thiết kế là một công cụ tự động tích hợp vào hệ thống xây dựng của bạn. Việc thường xuyên chạy CTS có thể giúp bạn nhanh chóng và sớm phát hiện các lỗi khi xảy ra sự cố suy thoái hoặc hồi quy phần mềm.
Tải và kiểm tra mã nguồn CTS. Mã nguồn CTS đầy đủ là phần mềm nguồn mở mà mọi người đều có thể tải xuống và sử dụng (mã nguồn đã tải xuống có thể tạo và chạy được đầy đủ). Khi một kiểm thử không đạt trên thiết bị, việc kiểm tra phần liên quan của mã nguồn có thể giúp bạn xác định lý do.
Tải CTS mới nhất. Các bản phát hành Android mới có thể cập nhật CTS bằng các bản sửa lỗi, cải tiến và kiểm thử mới. Thường xuyên kiểm tra Tải CTS xuống và cập nhật chương trình CTS nếu cần. Nhà sản xuất và Google phải đồng ý về phiên bản CTS để phát hành sản phẩm vì sản phẩm phải được đóng băng tại một thời điểm nào đó trong khi CTS tiếp tục được làm mới.

Đạt được CTS

Đối với sản phẩm Tương thích với Android, Google đảm bảo rằng kết quả kiểm thử của CTS và Trình xác minh CTS của thiết bị là chấp nhận được. Về nguyên tắc, tất cả các bài kiểm thử đều phải đạt. Tuy nhiên, Google sẽ xem xét một bài kiểm thử không đạt do các lý do khác ngoài việc thiết bị không tuân thủ các yêu cầu về Khả năng tương thích với Android. Trong quá trình này:

Nhà sản xuất cung cấp cho Google các bản vá CTS, quy trình xác thực bản vá và lý do để chứng minh đối số.
Google sẽ kiểm tra tài liệu bạn gửi và nếu chấp nhận, sẽ cập nhật các bài kiểm thử CTS có liên quan để thiết bị vượt qua bản sửa đổi tiếp theo của CTS.

Nếu một kiểm thử CTS đột nhiên không thành công sau khi áp dụng bản vá bảo mật, nhà sản xuất phải sửa đổi bản vá để không làm hỏng khả năng tương thích HOẶC cho thấy kiểm thử đó không chính xác và cung cấp bản sửa lỗi cho kiểm thử (như mô tả ở trên).

CTS vẫn mở để xem xét các bản sửa lỗi kiểm thử. Ví dụ: Android 4.4 vẫn tiếp tục chấp nhận các bản sửa lỗi (xem https://android-review.googlesource.com/#/c/273371/).

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

Hỏi: Ai chịu trách nhiệm áp dụng bản cập nhật bảo mật cho một cách triển khai cụ thể của Android?

Đáp: Nhà sản xuất trực tiếp cung cấp thiết bị sẽ chịu trách nhiệm. Thực thể này không phải là Google. Google phát hành các bản cập nhật bảo mật trong AOSP chứ không phải cho một thiết bị cụ thể (chẳng hạn như xe).

Hỏi: Google xử lý các vấn đề về bảo mật trong Android như thế nào?

Đáp: Google liên tục điều tra các vấn đề và phát triển các bản sửa lỗi tiềm năng. Google cung cấp các bản sửa lỗi này cho tất cả các cấp độ API được hỗ trợ trong quy trình cập nhật bảo mật thường xuyên. Kể từ tháng 8 năm 2015, Google đã duy trì tần suất phát hành thông báo và đường liên kết đến các bản cập nhật cho source.android.com; Google cũng phát hành các bản cập nhật bảo mật trong các bản phát hành hệ điều hành chính. Ngoài ra, hãy xem Chính sách điều chỉnh cho phiên bản cũ về bảo mật.

Hỏi: Nếu nhà sản xuất tích hợp tất cả các bản vá AOSP từ một ASB nhưng không tích hợp các bản vá từ nhà cung cấp BSP được đề cập trong cùng một bản tin, thì nhà sản xuất có thể vẫn nâng cấp mức độ bảo mật (ví dụ: áp dụng bản vá tương ứng cho nền tảng/bản dựng) không?

Đáp: Để khai báo cấp bản vá bảo mật Android (SPL), nhà sản xuất phải giải quyết tất cả các vấn đề bắt buộc được phát hành trong Bản tin bảo mật Android (bao gồm cả các bản tin trước đó) và liên kết với một SPL Android cụ thể. Ví dụ: một nhà sản xuất sử dụng Bản tin bảo mật tháng 3 năm 2017 (SPL 2017-03-01) đã giải quyết tất cả các vấn đề bắt buộc được ghi nhận trong bản tin tháng 3 năm 2017 cho SPL đó và tất cả các bản cập nhật trước đó, bao gồm cả bản cập nhật dành riêng cho thiết bị cho tất cả các Bản tin bảo mật Android trước đó, bao gồm cả bản cập nhật dành riêng cho thiết bị liên kết với SPL 2017-02-05.

Hỏi: Điều gì sẽ xảy ra khi nhà sản xuất không đồng ý với bản cập nhật bảo mật do nhà cung cấp BSP cung cấp HOẶC khi nhà cung cấp không cung cấp bản cập nhật bảo mật do ASB yêu cầu?

Đáp: ASB mô tả các lỗ hổng bảo mật (được liệt kê theo danh sách CVE) và thường cung cấp các kiểm thử bảo mật phù hợp. Mục tiêu là đảm bảo không thể tái tạo các lỗ hổng được liệt kê trên một thiết bị và thiết bị đó có thể vượt qua các bài kiểm thử bảo mật liên quan. Do đó, vấn đề không phải là việc tải bản cập nhật bảo mật do Google hoặc nhà cung cấp bên thứ ba cung cấp, mà là việc nhà sản xuất chứng thực rằng thiết bị không dễ bị tấn công theo danh sách CVE trong ASB. Nhà sản xuất có thể tự do sử dụng các bản cập nhật bảo mật được cung cấp hoặc sử dụng thay đổi phù hợp hơn với thiết bị của họ nếu có.

Ví dụ: hãy xem xét trường hợp Google giải quyết một lỗ hổng bảo mật AOSP bằng cách thay đổi mã cho phép thành phần vẫn hoạt động đầy đủ và tuân thủ CDD. Nếu nhà sản xuất xác định rằng thành phần không cần thiết trên thiết bị hoặc không bắt buộc theo CDD (hoặc quy trình kiểm thử chứng nhận có liên quan), thì nhà sản xuất có thể xoá thành phần đó để giảm nhu cầu bảo dưỡng trong tương lai và giảm bề mặt tấn công. Mặc dù nhà sản xuất không sử dụng bản cập nhật bảo mật được cung cấp, nhưng họ đã đảm bảo rằng thiết bị không bị lỗ hổng CVE được ghi nhận trong bản tin bảo mật. Tuy nhiên, khi không tuân theo bản cập nhật bảo mật được đề xuất, nhà sản xuất có nguy cơ xử lý không chính xác vấn đề, tạo ra các lỗ hổng bảo mật mới hoặc làm giảm chức năng của bản dựng cuối cùng.

Mặc dù chúng tôi hợp tác với tất cả các đối tác SoC để đảm bảo có bản sửa lỗi cho tất cả các vấn đề trong ASB, nhưng nhà sản xuất nên ký thoả thuận bảo dưỡng với nhà cung cấp SoC trong suốt vòng đời của thiết bị. SoC có thể ngừng cung cấp dịch vụ cho một chipset sớm hơn dự kiến, vì vậy, việc thiết lập thoả thuận trước khi chọn chipset cho thiết bị là một phần quan trọng trong quy trình ra mắt thiết bị.

Cuối cùng, trong trường hợp không thể trực tiếp mua hoặc tạo một bản sửa lỗi độc lập cho vấn đề được ghi nhận trong ASB, nhà sản xuất có thể duy trì SPL Android trước đó và vẫn thêm các bản sửa lỗi mới có sẵn vào bản dựng. Tuy nhiên, việc này cuối cùng sẽ dẫn đến các vấn đề về việc chứng nhận bản dựng (vì Android đảm bảo rằng cấp bản vá bảo mật mới nhất có trên các thiết bị được chứng nhận). Google đề xuất bạn nên làm việc trước với SoC để tránh thực hiện việc này.

Hỏi: Nếu nhà sản xuất xác định một mục ASB không áp dụng cho sản phẩm của họ, thì mục đó có cần được áp dụng hoặc vá để đáp ứng các yêu cầu khác của Google hoặc để vượt qua CTS không?

Đáp: Chúng tôi không yêu cầu phải áp dụng bản vá để khai báo cấp bản vá bảo mật của Android (SPL); chúng tôi yêu cầu nhà sản xuất chứng thực rằng bản dựng của họ không dễ bị lỗi này.

Ví dụ: một thành phần đang được vá không tồn tại trong hệ thống của nhà sản xuất hoặc một thành phần bị xoá khỏi hệ thống của nhà sản xuất để giải quyết vấn đề. Trong trường hợp đó, hệ thống có thể tuân thủ mà không yêu cầu nhà sản xuất phải vá.

Điều này về cơ bản khác với việc nhà sản xuất chỉ muốn khắc phục các bản vá quan trọng, trong khi không áp dụng các bản vá khác có thể khiến quy trình kiểm thử bảo mật không thành công. Trong trường hợp này, SPL được giả định là không được đáp ứng.

Hướng dẫn dành cho nhà sản xuất về bảo mật Android lâu dài Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.