Để phù hợp với mô hình phát triển ổn định của nhánh chính và đảm bảo tính ổn định của nền tảng cho hệ sinh thái, chúng tôi sẽ xuất bản mã nguồn lên AOSP vào quý 2 và quý 4 năm 2026. Để tạo và đóng góp cho AOSP, hãy sử dụng android-latest-release. Nhánh tệp kê khai android-latest-release sẽ luôn tham chiếu đến bản phát hành gần đây nhất được chuyển đến AOSP. Để biết thêm thông tin, hãy xem bài viết Các thay đổi đối với AOSP.

Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

Hướng dẫn dành cho nhà sản xuất về bảo mật Android lâu dài

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 tra tính tương thích (CTS) với Android đánh giá. Đây là phiên bản 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).

Lời cảm ơn và tuyên bố 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ướng dẫn mô tả các phương pháp được đề xuất.

Phản hồi

Hướng dẫn này chưa phải là hướng dẫn toàn diện và chúng tôi dự định sẽ sửa đổi thêm. Gửi ý kiến phản hồi đến manufacturers-guide-android@googlegroups.com.

Bảng thuật ngữ

Thuật ngữ	Định nghĩa
ACC	Cam kết về khả năng tương thích của Android. Trước đây được gọi là Thoả thuận chống phân mảnh 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 tra tính tương thích
FOTA	chương trình cơ sở không dây
GPS	hệ thống định vị toàn cầu
MISRA	Hiệp hội Độ tin cậy phần mềm ngành ô tô
NIST	Viện Tiêu chuẩn và Công nghệ Quốc gia
OBD	hệ thống chẩn đoán trên xe (OBD-II là một bản cải tiến so với OBD-I về cả 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 hoàn chỉnh dựa trên Linux và có mã nguồn mở, được thiết kế cho nhiều loại thiết bị và kiểu dáng. Kể từ lầ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). Tính đến tháng 3 năm 2017, khoảng 67% thiết bị trong số đó sử dụng Android 5.0 (Lollipop) trở lên (các số liệu gần đây hơn có trên Trang tổng quan về 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 trên đồng hồ thông minh, TV và thiết bị thông tin giải trí trong xe (IVI) của ô tô.

Số lượng ứng dụng Android có trong Cửa hàng Google Play đã đạt hơn 2,2 triệu (2016). Hoạt động phát triển ứng dụng Android được hỗ trợ bởi Chương trình tương thích của 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). Chương trình tương thích của Android đảm bảo rằng 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 và hỗ trợ các tính năng cần thiết 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. Các nhà sản xuất nên xem Bản tin bảo mật của Android để biết mức độ áp dụng của những bản cập nhật này đối với các sản phẩm được hỗ trợ trên 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 bản dựng của Android, hãy xem các phần sau:

Giới thiệu về xe được 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 từ khi đài AM ra đời vào những năm 1920. Từ đó, số lượng kết nối vật lý và không dây 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ử để đơn giản hoá việc 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 về mức tiêu thụ nhiên liệu. Làn sóng kết nối tiếp theo đã giới thiệu các tính năng tiện lợi cho người lái xe, chẳng hạn như hệ thống điều khiển từ xa không cần chìa khoá, hệ thống đo từ xa và các tính năng giải trí nâng cao như Bluetooth, Wi-Fi và tính năng chiếu nội dung 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 bán tự động và an toàn.

Khi số lượng kết nối xe tăng lên, diện tích bề mặt có thể bị tấn công của xe cũng tăng theo. Các kết nối mang theo một loạt các mối lo ngại tương tự về an ninh mạng như đối với thiết bị điện tử tiêu dùng. Tuy nhiên, trong khi 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à điều bình thường đối với đồ điện tử tiêu dùng, thì những điều này lại 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ư xe.

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 quá trình sử dụng. Nói tóm lại, nhà sản xuất phải biết 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 ninh lâu dài

Xe được kết nối thường có một hoặc nhiều bộ đ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. Các nhà sản xuất nên theo dõi những thành phần như vậy và xác định các lỗ hổng đã biết được 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 Các 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ề các 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 suốt 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 cơ sở 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) lần đầu.
②	Lần phát hành đầu tiên	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 xuất xưởng trong sản phẩm, các bản cập nhật bảo mật sẽ được lấy từ Bản tin bảo mật của Android (ASB) và có thể là các nguồn khác mà nhà sản xuất cho là có giá trị. y2 = Bản tin bảo mật thứ hai cho phiên bản X của Android, được nhà sản xuất áp dụng (truy cập ngược) cho Android X. Bản cập nhật này được phát hành trong sản phẩm và đồng hồ sản xuất bắt đầu đếm ngượ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át hành bản phát hành hằng năm Android X+1 gần đây hơn. Lý do để phát hành phiên bản mới nhất bao gồm việc thêm các 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 vận chuyển bằng bản phát hành gần đây nhất là do không có đủ thời gian cần thiết cho quy trình phát triển và ra mắt xe để 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ủ mọi yêu cầu về quy định và chứng nhận.
③	Bản cập nhật hệ điều hành đầy đủ	Sau khi SOP kết thúc, nhà sản xuất phát hành bản cập nhật hệ điều hành Android X+2, tức là 2 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 phát hành), vì vậy bản cập nhật sẽ được phát hành dưới dạng X+2.y0 sau khoảng 1,25 năm kể từ ngày bắt đầu bán. 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 được 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 tuỳ thuộc vào 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 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ở của 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 ở hệ điều hành (X+2.y3) + Cấp bản vá bảo mật của Android. Mặc dù các nhà sản xuất có thể chọn từng bản vá bảo mật trong 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 (SPL) của Android liên kết với bản tin (ví dụ: 2017-02-05). Nhà sản xuất có trách nhiệm thực hiện việc chuyển ngược và phát hành bản bảo mật cho sản phẩm được hỗ trợ.
⑤	Bản cập nhật hệ điều hành đầy đủ	Lặp lại bước 3 (Cập nhật toàn bộ hệ điều hành), lần cập nhật toàn bộ hệ điều hành thứ hai sẽ đưa sản phẩm lên Android X+4, tức là 3 năm sau khi xe được sản xuất. Giờ đây, nhà sản xuất đang cân bằng các yêu cầu mới hơn về phần cứng của một phiên bản Android gần đây với phần cứng trong sản phẩm và lợi ích mà người dùng nhận được từ một hệ điều hành Android mới. Nhà sản xuất phát hành một 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 ở phiên bản hệ điều hành (X+4.y0) + Cấp bản vá bảo mật của Android. Trong ví dụ này, do hạn chế về phần cứng, X+4 là phiên bản chính mới nhất của Android sẽ được cung cấp cho sản phẩm này, mặc dù tuổi thọ dự kiến của xe là hơn 6 năm vẫn yêu cầu 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 muộn 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 những phiên bản Android không còn được hỗ trợ sẽ không có 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ừ lầ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 hoàn toàn chịu trách nhiệm về việc tuyển chọn và chuyển 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

Để giảm thiểu nguy cơ bảo mật, Google khuyến nghị và áp dụng các phương pháp hay nhất thường được chấp nhận 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

Các phương pháp nên dùng để bảo mật bao gồm:

Sử dụng phiên bản mới nhất của các 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 nhập 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 về đặ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 nên dùng để phát triển phần mềm bảo mật 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 tài sản, mối đe doạ và biện pháp giảm thiểu tiềm ẩ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 lại và lỗi càng sớm càng tốt.
Thiết kế, triển khai và chạy các bài 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ả các trường hợp kiểm thử tiêu cực)
- Kiểm thử hồi quy thường xuyên (để đảm bảo các lỗi đã khắc phục không xuất hiện lại)
- Kiểm thử mờ (trong bộ kiểm thử đơn vị)
Sử dụng các công cụ phân tích mã nguồn tĩnh (scan-build, lint, 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 (đối với 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 các bản vá phần mềm.

Chính sách chuyển ngược bảo mật

Hiện tại, Google cung cấp dịch vụ hỗ trợ tích cực cho các bản điều chỉnh bảo mật đối với những lỗ hổng bảo mật đã phát hiện và được báo cáo trong 3 năm kể từ ngày phát hành công khai cấp độ API. Dịch vụ hỗ trợ đang hoạt động bao gồm những nội dung sau:

Nhận và điều tra báo cáo về 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 3 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ợ chuyển ngược 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 để thực hiện quy trình đánh giá mã bằng cách sử dụ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 các 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ã độc quyền dành riêng cho thiết bị).
Nhà sản xuất nên tham gia nhóm thông báo xem trước Bản tin bảo mật Android dành cho đối tác theo thoả thuận không tiết lộ (NDA) (yêu cầu ký các thoả thuận pháp lý như NDA dành cho nhà phát triển). Bản tin 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 bảo mật (nếu có)

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

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

Các phương pháp hay về sản phẩm

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

Nguyên tắc chung về việc phát hành

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 gần đây 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 tính ổ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 tính ổn định của sản phẩm có đượ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 có ít lỗ hổng bảo mật đã biết hơn và khả năng bảo vệ bảo mật nâng cao.

Các nguyên tắc được đề xuất bao gồm:

Do thời gian phát triển dài vốn có trong quy trình phát triển xe, các nhà sản xuất có thể cần phải ra mắt với phiên bản hệ điều hành n-2 hoặc cũ hơn.
Duy trì sự tuân thủ Khả năng tương thích của Android cho từng phiên bản hệ điều hành Android được phát hành bằng một chiến dịch không dây (OTA).
Triển khai sản phẩm có khả năng Cập nhật phần mềm qua mạng (FOTA) trên Android để cập nhật nhanh chóng và thân thiện với khách hàng. FOTA phải được thực hiện theo các phương pháp hay nhất về bảo mậ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 xác định được một cách độc lập cho Nhóm bảo mật Android.

Lưu ý: Google đã cân nhắc thông báo theo loại thiết bị hoặc ngành cụ thể 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 của một thiết bị cụ thể (xe, TV, thiết bị đeo, điện thoại, v.v.), nên Google không có cách xác định để gắn nhãn cho bất kỳ vấn đề bảo mật nào với một loại thiết bị.

Nguyên tắc về vòng đời sản phẩm

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 hoặc các bản cập nhật bảo mật cho phiên bản đang dùng trong quá trình cải tiến vòng đời sản phẩm. Bạn có thể cập nhật trong quá trình cập nhật sản phẩm định kỳ lặp lại hoặc để khắc phục nhanh nhằm giải quyết các vấn đề về chất lượng và/hoặc các vấn đề khác. Các phương pháp được đề xuất bao gồm:

Lập 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 một phương pháp phù hợp với ngành để cung cấp thông tin cập nhật cho các phương tiện đã 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 đến phiên bản mới nhất xuống từ source.android.com.

Để đáp ứng những yêu cầu này cho 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ý Cam kết về khả năng tương thích của 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 (mô tả bên dưới) cho đến khi kết quả chấp nhận được đối với Tính 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 rằng 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à mã nguồn mở, 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 CTS từ Android 1.6 đến phiên bản mới nhất xuống 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 tại nhà máy và cập nhật tại hiện trường) phải chứng minh Khả năng tương thích của Android thông qua kết quả CTS. Ví dụ: nếu thiết bị chạy Android 7.1, thì phiên bản CDD 7.1 và CTS 7.1 mới nhất tương ứng phải được tham chiếu khi một hình ảnh bản dựng có ý định phát hành được tạo và kiểm thử. Nhà sản xuất nên sử dụng CTS sớm và thường xuyên để xác định cũng như khắc phục các vấn đề.

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

Quy trình CTS

Quy trình 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ả.

Chạy kiểm thử thường xuyên. CTS được thiết kế như một công cụ tự động tích hợp vào hệ thống bản dựng của bạn. Việc chạy CTS thường xuyên có thể giúp bạn nhanh chóng tìm thấy các lỗi khi xảy ra tình trạng giảm hiệu suất 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à bất kỳ ai cũng có thể tải xuống và sử dụng (mã nguồn đã tải xuống có thể được tạo và chạy hoàn toàn). Khi một kiểm thử không đạt trên thiết bị, việc kiểm tra phần có 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 để sửa lỗi, cải thiện và thêm các kiểm thử mới. Thường xuyên kiểm tra CTS Downloads (Nội dung tải xuống CTS) và cập nhật chương trình CTS nếu cần. Nhà sản xuất và Google sẽ thoả thuận về phiên bản CTS cần vượt qua để ra mắt sản phẩm vì sản phẩm phải được cố định tại một thời điểm nào đó trong khi CTS tiếp tục được làm mới.

Vượt qua CTS

Đối với một sản phẩm tương thích với Android, Google đảm bảo CTS của thiết bị và kết quả kiểm tra trong báo cáo CTS Verifier đều 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, một bài kiểm tra không thành công vì những 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 sẽ được Google xem xét. Trong quá trình này:

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

Nếu một kiểm thử CTS đột ngột không thành công sau khi áp dụng một bản vá bảo mật, thì nhà sản xuất phải sửa đổi bản vá đó để không làm mất 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/platform/cts/+/273371).

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

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

Đáp: Nhà sản xuất trực tiếp cung cấp thiết bị 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 đề 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. 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ì nhịp độ thường xuyên trong việc xuất bản các bản tin và đường liên kết đến nội dung cập nhật trên source.android.com; Google cũng xuất bản 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 chuyển ngược bảo mật.

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

Đáp: Để khai báo cấp độ bản vá bảo mật (SPL) của Android, nhà sản xuất phải giải quyết tất cả các vấn đề bắt buộc được công bố trong Bản tin bảo mật của Android (bao gồm cả các bản tin trước đó) và được liên kết với một SPL cụ thể của Android. 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 ngày 1 tháng 3 năm 2017) đã giải quyết tất cả các vấn đề bắt buộc được nêu 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ả 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 ngày 5 tháng 2 năm 2017.

Hỏi: Điều gì xảy ra khi nhà sản xuất không đồng ý với các 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 các bản cập nhật bảo mật theo yêu cầu của ASB?

Đá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 những lỗ hổng được liệt kê không còn xuất hiện trên thiết bị và thiết bị có thể vượt qua các bài kiểm tra bảo mật liên quan. Do đó, vấn đề không phải là việc nhận 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ể sử dụng các bản cập nhật bảo mật được cung cấp hoặc nếu có thay đổi phù hợp hơn với thiết bị của họ, thì họ có thể sử dụng thay đổi đó.

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 thiết bị không cần thành phần này hoặc CDD không bắt buộc (hoặc kiểm thử chứng nhận liên quan), thì nhà sản xuất có thể xoá thành phần này để 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 thiết bị không gặp phải lỗ hổng bảo mật được ghi lại trong bản tin bảo mật. Tuy nhiên, khi đi chệch khỏi bản cập nhật bảo mật được đề xuất, nhà sản xuất sẽ gặp phải rủi ro là giải quyết vấn đề không chính xác, 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 mọi vấn đề trong ASB, nhưng các nhà sản xuất nên ký thoả thuận dịch vụ 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ự tạo bản sửa lỗi cho một vấn đề được ghi lại 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, cách này sẽ dẫn đến các vấn đề về 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 khuyến khích bạn làm việc với SoC trước để tránh trường hợp này.

H: Nếu nhà sản xuất xác định rằng một mục ASB không áp dụng được 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 bạn phải thực hiện các bản vá để khai báo cấp bản vá bảo mật (SPL) của Android; 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ị ảnh hưởng bởi vấn đề này.

Một ví dụ là khi thành phần đượ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 mộ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á lỗi.

Điều này khác biệt cơ bản với trường hợp nhà sản xuất chỉ muốn sửa 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 một bài kiểm thử bảo mật thất bại. Trong trường hợp này, giả định là SPL chưa đượ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.