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.

Bản cập nhật và tài nguyên bảo mật

Nhóm bảo mật Android chịu trách nhiệm quản lý các lỗ hổng bảo mật được phát hiện trong nền tảng Android và nhiều ứng dụng Android cốt lõi đi kèm với thiết bị Android.

Nhóm bảo mật của Android phát hiện các lỗ hổng bảo mật thông qua nghiên cứu nội bộ và cũng phản hồi các lỗi do bên thứ ba báo cáo. Nguồn lỗi bên ngoài bao gồm các vấn đề được báo cáo thông qua biểu mẫu lỗ hổng, nghiên cứu học thuật đã xuất bản và chưa xuất bản, trình bảo trì dự án nguồn mở cấp trên, thông báo của các đối tác nhà sản xuất thiết bị và các vấn đề được công bố công khai trên blog hoặc mạng xã hội.

Báo cáo vấn đề bảo mật

Mọi nhà phát triển, người dùng Android hoặc nhà nghiên cứu bảo mật đều có thể thông báo cho nhóm bảo mật Android về các vấn đề bảo mật tiềm ẩn thông qua biểu mẫu báo cáo lỗ hổng.

Các lỗi được đánh dấu là vấn đề bảo mật sẽ không hiển thị bên ngoài, nhưng cuối cùng có thể được hiển thị sau khi vấn đề được đánh giá hoặc giải quyết. Nếu bạn dự định gửi một bản vá hoặc kiểm thử Bộ kiểm thử khả năng tương thích (CTS) để giải quyết vấn đề bảo mật, vui lòng đính kèm bản vá đó vào báo cáo lỗi và đợi phản hồi trước khi tải mã lên AOSP.

Phân loại lỗi

Nhiệm vụ đầu tiên trong việc xử lý lỗ hổng bảo mật là xác định mức độ nghiêm trọng của lỗi và thành phần nào của Android bị ảnh hưởng. Mức độ nghiêm trọng xác định cách ưu tiên vấn đề, còn thành phần xác định người khắc phục lỗi, người được thông báo và cách triển khai bản sửa lỗi cho người dùng.

Loại ngữ cảnh

Bảng này trình bày các định nghĩa về ngữ cảnh bảo mật phần cứng và phần mềm. Ngữ cảnh có thể được xác định theo độ nhạy của dữ liệu mà nó thường xử lý hoặc khu vực mà dữ liệu đó chạy. Không phải ngữ cảnh bảo mật nào cũng áp dụng cho mọi hệ thống. Bảng này được sắp xếp theo thứ tự từ đặc quyền ít nhất đến nhiều nhất.

Loại ngữ cảnh	Định nghĩa loại
Ngữ cảnh bị ràng buộc	Môi trường thực thi bị hạn chế, nơi chỉ cung cấp các quyền tối thiểu. Ví dụ: các ứng dụng đáng tin cậy xử lý dữ liệu không đáng tin cậy trong môi trường hộp cát.
Bối cảnh không đặc quyền	Môi trường thực thi thông thường mà mã không đặc quyền dự kiến. Ví dụ: một ứng dụng Android chạy trong miền SELinux có thuộc tính `untrusted_app_all`.
Ngữ cảnh đặc quyền	Môi trường thực thi đặc quyền có thể có quyền truy cập vào các quyền nâng cao, xử lý nhiều PII của người dùng và/hoặc duy trì tính toàn vẹn của hệ thống. Ví dụ: một ứng dụng Android có các chức năng bị miền `untrusted_app` của SELinux cấm hoặc có quyền truy cập vào các quyền `privileged\|signature`.
Nhân hệ điều hành	Chức năng: là một phần của nhân chạy trong cùng một ngữ cảnh CPU với hạt nhân (ví dụ: trình điều khiển thiết bị) có quyền truy cập trực tiếp vào bộ nhớ nhân (ví dụ: các thành phần phần cứng trên thiết bị) có khả năng tải tập lệnh vào một thành phần hạt nhân (ví dụ: eBPF) là một trong số ít dịch vụ người dùng được coi là tương đương với hạt nhân (chẳng hạn như `apexd`, `bpfloader`, `init`, `ueventd` và `vold`).
Trusted Hardware Base (THB)	Các thành phần phần cứng riêng biệt, thường là trên SoC, cung cấp chức năng quan trọng đối với các trường hợp sử dụng cốt lõi của thiết bị (chẳng hạn như băng tần cơ sở di động, DSP, GPU và bộ xử lý học máy).
Chuỗi trình tải khởi động	Một thành phần định cấu hình thiết bị khi khởi động, sau đó chuyển quyền kiểm soát sang hệ điều hành Android.
Môi trường thực thi đáng tin cậy (TEE)	Một thành phần được thiết kế để được bảo vệ ngay cả khi có nhân hệ điều hành không thân thiện (ví dụ: TrustZone và trình điều khiển ảo hoá, chẳng hạn như pKVM, bảo vệ Máy ảo khỏi nhân hệ điều hành).
Secure Enclave / Secure Element (SE)	Một thành phần phần cứng không bắt buộc được thiết kế để được bảo vệ khỏi tất cả các thành phần khác trên thiết bị và khỏi các cuộc tấn công vật lý, như được xác định trong phần Giới thiệu về phần tử bảo mật. Bao gồm cả chip Titan-M có trong một số thiết bị Android.

Mức độ nghiêm trọng

Mức độ nghiêm trọng của lỗi thường phản ánh mức độ thiệt hại có thể xảy ra nếu lỗi được khai thác thành công. Hãy sử dụng các tiêu chí sau để xác định mức độ nghiêm trọng.

Rating	Hậu quả của việc khai thác thành công
Quan trọng	Thực thi mã tuỳ ý trong TEE hoặc SE Bỏ qua các cơ chế phần mềm được thiết kế để ngăn các thành phần phần cứng hoặc phần mềm liên quan đến an toàn hoạt động không đúng cách (ví dụ: biện pháp bảo vệ nhiệt) Truy cập từ xa vào thông tin xác thực nhạy cảm dùng để xác thực dịch vụ từ xa (ví dụ: mật khẩu tài khoản hoặc mã thông báo của chủ sở hữu) Thực thi mã tuỳ ý từ xa trong ngữ cảnh băng cơ sở di động mà không có sự tương tác của người dùng (ví dụ: khai thác lỗi trong dịch vụ đài phát thanh di động) Thực thi mã tuỳ ý từ xa trong ngữ cảnh đặc quyền, chuỗi trình tải khởi động, THB hoặc hạt nhân hệ điều hành Bỏ qua từ xa các yêu cầu tương tác của người dùng khi cài đặt gói hoặc hành vi tương đương Bỏ qua từ xa các yêu cầu về tương tác của người dùng đối với chế độ cài đặt bảo mật, nhà phát triển cốt lõi hoặc quyền riêng tư Từ chối dịch vụ liên tục từ xa (vĩnh viễn, yêu cầu cài đặt lại toàn bộ hệ điều hành hoặc đặt lại về trạng thái ban đầu) Bỏ qua tính năng khởi động an toàn từ xa Truy cập trái phép vào dữ liệu do SE bảo vệ, bao gồm cả quyền truy cập do các khoá yếu trong SE cấp.
Cao	Bỏ qua hoàn toàn một tính năng bảo mật cốt lõi (ví dụ: SELinux, FBE hoặc `seccomp`) Một phương thức bỏ qua chung cho công nghệ bảo vệ sâu hoặc giảm thiểu hành vi khai thác trong chuỗi trình tải khởi động, TEE hoặc SE Một phương thức bỏ qua chung cho các biện pháp bảo vệ hệ điều hành tiết lộ bộ nhớ hoặc nội dung tệp trên các ranh giới ứng dụng, người dùng hoặc hồ sơ Các cuộc tấn công vào một SE dẫn đến việc hạ cấp xuống một phương thức triển khai kém an toàn hơn Chuyển từ phần mềm cơ sở bị xâm nhập có thể truy cập từ xa (ví dụ: băng tần cơ sở, trình xử lý giao tiếp (CP)) vào hạt nhân của bộ xử lý ứng dụng (AP) hoặc cơ chế bỏ qua được thiết kế để tách biệt phần mềm cơ sở khỏi hạt nhân AP Bỏ qua chế độ bảo vệ thiết bị, chế độ bảo vệ khi đặt lại về trạng thái ban đầu hoặc các quy định hạn chế của nhà mạng Bỏ qua các yêu cầu tương tác của người dùng do TEE bảo mật Lỗ hổng mã hoá cho phép các cuộc tấn công vào giao thức đầu cuối, bao gồm cả các cuộc tấn công vào bảo mật tầng truyền tải (TLS) và Bluetooth (BT). Quyền truy cập cục bộ vào thông tin xác thực nhạy cảm dùng để xác thực dịch vụ từ xa (ví dụ: mật khẩu tài khoản hoặc mã thông báo của chủ sở hữu) Thực thi mã tuỳ ý cục bộ trong ngữ cảnh đặc quyền, chuỗi trình tải khởi động, THB hoặc hạt nhân hệ điều hành Bỏ qua tính năng khởi động an toàn cục bộ Bỏ qua màn hình khoá Bỏ qua cục bộ các yêu cầu về tương tác của người dùng đối với chế độ cài đặt bảo mật, quyền riêng tư hoặc nhà phát triển cốt lõi Bỏ qua cục bộ các yêu cầu tương tác của người dùng khi cài đặt gói hoặc hành vi tương đương Từ chối dịch vụ liên tục trên thiết bị (vĩnh viễn, yêu cầu cài đặt lại toàn bộ hệ điều hành hoặc đặt lại về trạng thái ban đầu) Truy cập từ xa vào dữ liệu được bảo vệ (tức là dữ liệu chỉ được giới hạn trong một ngữ cảnh đặc quyền) Thực thi mã tuỳ ý từ xa trong ngữ cảnh không đặc quyền Ngăn chặn từ xa quyền truy cập vào dịch vụ di động hoặc Wi-Fi mà không cần người dùng tương tác (ví dụ: làm hỏng dịch vụ đài phát thanh di động bằng một gói bị định dạng không chính xác) Bỏ qua từ xa các yêu cầu tương tác của người dùng (quyền truy cập vào chức năng hoặc dữ liệu cần có sự khởi tạo của người dùng hoặc quyền của người dùng) Ngăn chặn có mục tiêu quyền truy cập vào dịch vụ khẩn cấp Truyền thông tin nhạy cảm qua giao thức mạng không an toàn (ví dụ: HTTP và Bluetooth không mã hoá) khi người yêu cầu mong muốn quá trình truyền diễn ra an toàn. Xin lưu ý rằng điều này không áp dụng cho phương thức mã hoá Wi-Fi (chẳng hạn như WEP) Truy cập trái phép vào dữ liệu do TEE bảo vệ, bao gồm cả quyền truy cập do các khoá yếu trong TEE cấp
Trung bình	Một phương thức bỏ qua chung cho công nghệ bảo vệ sâu hoặc giảm thiểu hành vi khai thác trong một ngữ cảnh đặc quyền, THB hoặc hạt nhân hệ điều hành Một phương thức bỏ qua chung cho các biện pháp bảo vệ hệ điều hành cho thấy trạng thái quy trình hoặc siêu dữ liệu trên các ranh giới ứng dụng, người dùng hoặc hồ sơ Bỏ qua quy trình xác thực hoặc mã hoá Wi-Fi Lỗ hổng bảo mật mật mã trong các nguyên hàm mật mã tiêu chuẩn cho phép rò rỉ văn bản thô (không phải các nguyên hàm được dùng trong TLS) Quyền truy cập cục bộ vào dữ liệu được bảo vệ (tức là dữ liệu chỉ được truy cập trong một ngữ cảnh đặc quyền) Thực thi mã tuỳ ý cục bộ trong ngữ cảnh không đặc quyền Bỏ qua cục bộ các yêu cầu tương tác của người dùng (quyền truy cập vào chức năng hoặc dữ liệu thường yêu cầu người dùng khởi tạo hoặc cấp quyền) Truy cập từ xa vào dữ liệu không được bảo vệ (tức là dữ liệu mà mọi ứng dụng cài đặt trên máy đều có thể truy cập) Thực thi mã tuỳ ý từ xa trong ngữ cảnh bị ràng buộc Từ chối tạm thời dịch vụ trên thiết bị từ xa (treo hoặc khởi động lại từ xa)
Thấp	Một phương thức bỏ qua chung cho công nghệ giảm thiểu khai thác hoặc bảo vệ sâu cấp người dùng trong một ngữ cảnh không đặc quyền Vượt qua quyền mức độ bảo vệ thông thường Lỗ hổng bảo mật mật mã ở lần sử dụng phi chuẩn Bỏ qua chung các tính năng cá nhân hoá trên thiết bị như Voice Match hoặc Face Match Tài liệu không chính xác có thể dẫn đến lỗ hổng bảo mật Thực thi mã tuỳ ý cục bộ trong ngữ cảnh bị ràng buộc Văn bản do hệ thống xác định có nội dung mô tả gây hiểu lầm, tạo ra kỳ vọng bảo mật sai
Mức tác động không đáng kể đến bảo mật (NSI)	Một lỗ hổng đã được giảm thiểu tác động bằng một hoặc nhiều hệ số sửa đổi điểm xếp hạng hoặc các thay đổi về cấu trúc dành riêng cho phiên bản, nhờ đó mức độ nghiêm trọng thực tế thấp hơn mức Thấp, mặc dù vấn đề về mã cơ bản có thể vẫn còn Mọi lỗ hổng yêu cầu hệ thống tệp bị định dạng không đúng, nếu hệ thống tệp đó luôn được chấp nhận/mã hoá trước khi sử dụng. Từ chối tạm thời dịch vụ cục bộ, chẳng hạn như khi có thể giải quyết tình trạng này bằng cách khởi động lại thiết bị hoặc gỡ cài đặt ứng dụng kích hoạt.

Đối tượng sửa đổi giá

Mặc dù thường dễ xác định mức độ nghiêm trọng của lỗ hổng bảo mật, nhưng điểm xếp hạng có thể thay đổi dựa trên hoàn cảnh.

Lý do	Hiệu ứng
Yêu cầu chạy dưới dạng ngữ cảnh đặc quyền để thực thi cuộc tấn công (không áp dụng cho TEE, SE và trình điều khiển ảo hoá như pKVM)	Mức độ nghiêm trọng -1
Thông tin chi tiết về lỗ hổng giúp hạn chế tác động của vấn đề	Mức độ nghiêm trọng -1
Tính năng bỏ qua quy trình xác thực bằng sinh trắc học yêu cầu thông tin sinh trắc học trực tiếp từ chủ sở hữu thiết bị	Mức độ nghiêm trọng -1
Cấu hình trình biên dịch hoặc nền tảng giúp giảm thiểu lỗ hổng trong mã nguồn	Mức độ nghiêm trọng ở mức Trung bình nếu lỗ hổng cơ bản là Trung bình trở lên
Yêu cầu quyền truy cập thực vào phần bên trong thiết bị và vẫn có thể thực hiện nếu thiết bị đang tắt hoặc chưa được mở khoá kể từ khi bật nguồn	Mức độ nghiêm trọng -1
Yêu cầu quyền truy cập thực vào phần bên trong thiết bị khi thiết bị đang bật và đã được mở khoá trước đó	Mức độ nghiêm trọng -2
Một cuộc tấn công cục bộ yêu cầu mở khoá chuỗi trình tải khởi động	Không cao hơn mức Thấp
Một cuộc tấn công cục bộ yêu cầu Chế độ nhà phát triển hoặc bất kỳ chế độ cài đặt chế độ nhà phát triển cố định nào hiện đang được bật trên thiết bị (và không phải là lỗi trong chính Chế độ nhà phát triển).	Không cao hơn mức Thấp
Nếu không có miền SELinux nào có thể thực hiện thao tác theo SEPolicy do Google cung cấp	Tác động không đáng kể đến tính bảo mật

Cục bộ so với gần so với từ xa

Một vectơ tấn công từ xa cho biết rằng lỗi có thể bị khai thác mà không cần cài đặt ứng dụng hoặc không cần quyền truy cập thực vào thiết bị. Điều này bao gồm các lỗi có thể được kích hoạt bằng cách duyệt đến một trang web, đọc email, nhận tin nhắn SMS hoặc kết nối với một mạng không thân thiện.

Các vectơ tấn công gần được coi là từ xa. Những lỗi này bao gồm các lỗi chỉ có thể bị kẻ tấn công khai thác khi ở gần thiết bị mục tiêu, ví dụ: lỗi yêu cầu gửi gói Wi-Fi hoặc Bluetooth bị định dạng không chính xác. Chúng tôi coi các cuộc tấn công dựa trên Băng tần siêu rộng (UWB) và NFC là gần và do đó là từ xa.

Các cuộc tấn công cục bộ yêu cầu kẻ tấn công phải có quyền truy cập trước vào nạn nhân. Trong ví dụ giả định chỉ về phần mềm, điều này có thể xảy ra thông qua một ứng dụng độc hại mà nạn nhân đã cài đặt hoặc một Ứng dụng tức thì mà họ đã đồng ý chạy.

Các thiết bị đã ghép nối thành công (chẳng hạn như thiết bị đồng hành Bluetooth) được coi là cục bộ. Chúng ta phân biệt giữa thiết bị đã ghép nối và thiết bị đang tham gia quy trình ghép nối.

Các lỗi làm giảm khả năng của người dùng trong việc xác định thiết bị khác đang được ghép nối (tức là xác thực) được coi là gần và do đó là từ xa.
Các lỗi xảy ra trong quy trình ghép nối nhưng trước khi người dùng đồng ý (tức là uỷ quyền) được thiết lập được coi là gần và do đó là từ xa.
Các lỗi xảy ra sau khi người dùng đồng ý được coi là lỗi cục bộ, ngay cả khi ghép nối cuối cùng không thành công.

Các vectơ tấn công vật lý được coi là cục bộ. Những lỗi này bao gồm các lỗi chỉ có thể bị kẻ tấn công có quyền truy cập vật lý vào thiết bị khai thác, chẳng hạn như lỗi trên màn hình khoá hoặc lỗi yêu cầu cắm cáp USB. Vì thường thì thiết bị sẽ được mở khoá khi cắm vào USB, nên các cuộc tấn công yêu cầu kết nối USB cũng có mức độ nghiêm trọng như nhau, bất kể thiết bị có được yêu cầu mở khoá hay không.

Bảo mật mạng

Android giả định rằng tất cả mạng đều có thể tấn công hoặc theo dõi lưu lượng truy cập. Mặc dù bảo mật tầng liên kết (ví dụ: mã hoá Wi-Fi) bảo mật giao tiếp giữa một thiết bị và Điểm truy cập mà thiết bị đó kết nối, nhưng lớp bảo mật này không bảo mật các liên kết còn lại trong chuỗi giữa thiết bị và các máy chủ mà thiết bị đó đang giao tiếp.

Ngược lại, HTTPS thường bảo vệ toàn bộ quá trình giao tiếp từ đầu đến cuối, mã hoá dữ liệu tại nguồn, sau đó chỉ giải mã và xác minh dữ liệu đó khi đã đến đích cuối cùng. Do đó, các lỗ hổng làm tổn hại đến bảo mật mạng ở lớp liên kết được đánh giá là ít nghiêm trọng hơn so với các lỗ hổng trong HTTPS/TLS: Chỉ riêng việc mã hoá Wi-Fi là không đủ cho hầu hết các hoạt động giao tiếp trên Internet.

Xác thực bằng sinh trắc học

Xác thực bằng sinh trắc học là một lĩnh vực đầy thách thức và ngay cả những hệ thống tốt nhất cũng có thể bị đánh lừa bằng một kết quả gần khớp (xem Blog dành cho nhà phát triển Android: Các điểm cải tiến về màn hình khoá và xác thực trong Android 11). Các mức độ nghiêm trọng này phân biệt giữa hai loại tấn công và nhằm phản ánh rủi ro thực tế đối với người dùng cuối.

Loại tấn công đầu tiên cho phép bỏ qua quy trình xác thực sinh trắc học theo cách tổng quát, mà không cần dữ liệu sinh trắc học chất lượng cao của chủ sở hữu. Ví dụ: nếu kẻ tấn công có thể đặt một miếng kẹo cao su lên cảm biến vân tay và miếng kẹo đó cấp quyền truy cập vào thiết bị dựa trên chất dính còn lại trên cảm biến, thì đó là một cuộc tấn công đơn giản có thể được thực hiện trên bất kỳ thiết bị nào dễ bị tấn công. Phương thức này không yêu cầu bạn phải biết bất kỳ thông tin nào về chủ sở hữu thiết bị. Do có thể áp dụng rộng rãi và có khả năng ảnh hưởng đến nhiều người dùng hơn, nên cuộc tấn công này nhận được điểm xếp hạng mức độ nghiêm trọng đầy đủ (ví dụ: Cao, đối với trường hợp bỏ qua màn hình khoá).

Loại tấn công khác thường liên quan đến một công cụ tấn công trình bày (giả mạo) dựa trên chủ sở hữu thiết bị. Đôi khi, thông tin sinh trắc học này tương đối dễ lấy (ví dụ: nếu ảnh hồ sơ của một người trên mạng xã hội là đủ để đánh lừa quy trình xác thực sinh trắc học, thì hành vi bỏ qua quy trình xác thực sinh trắc học sẽ nhận được điểm xếp hạng mức độ nghiêm trọng cao nhất). Tuy nhiên, nếu kẻ tấn công cần phải thu thập dữ liệu sinh trắc học trực tiếp từ chủ sở hữu thiết bị (ví dụ: quét hồng ngoại khuôn mặt của họ), thì đó là một rào cản đủ lớn để hạn chế số lượng người bị ảnh hưởng bởi cuộc tấn công, do đó, có một hệ số sửa đổi là -1.

SYSTEM_ALERT_WINDOW và tapjacking

Để biết thông tin về chính sách của chúng tôi liên quan đến SYSTEM_ALERT_WINDOW và tapjacking, hãy xem phần "Lỗ hổng Tapjacking/lớp phủ SYSTEM_ALERT_WINDOW trên màn hình không quan trọng về bảo mật" trên trang Lỗ hổng không ảnh hưởng đến bảo mật của BugHunter University.

Tính năng bảo mật nhiều người dùng trong Android Automotive OS

Android Automotive OS sử dụng mô hình bảo mật nhiều người dùng khác với các hệ số hình dạng khác. Mỗi người dùng Android phải là một cá nhân khác nhau. Ví dụ: bạn có thể chỉ định một người dùng khách tạm thời cho một người bạn mượn xe của chủ sở hữu xe. Để đáp ứng các trường hợp sử dụng như vậy, theo mặc định, người dùng có quyền truy cập vào các thành phần cần thiết để sử dụng xe, chẳng hạn như chế độ cài đặt Wi-Fi và mạng di động.

Thành phần bị ảnh hưởng

Nhóm phát triển chịu trách nhiệm khắc phục lỗi sẽ phụ thuộc vào thành phần chứa lỗi. Đó có thể là một thành phần cốt lõi của nền tảng Android, trình điều khiển hạt nhân do nhà sản xuất thiết bị gốc (OEM) cung cấp hoặc một trong các ứng dụng được tải sẵn trên thiết bị Pixel.

Nhóm kỹ sư của Android sẽ khắc phục lỗi trong mã AOSP. Các lỗi có mức độ nghiêm trọng thấp, lỗi trong một số thành phần nhất định hoặc lỗi đã được công bố có thể được khắc phục trực tiếp trong nhánh chính AOSP có sẵn công khai; nếu không, các lỗi này sẽ được khắc phục trước trong kho lưu trữ nội bộ của chúng tôi.

Thành phần này cũng là một yếu tố ảnh hưởng đến cách người dùng nhận thông tin cập nhật. Lỗi trong khung hoặc hạt nhân yêu cầu bản cập nhật phần mềm không dây (OTA) mà mỗi nhà sản xuất thiết bị gốc (OEM) cần đẩy. Bạn có thể gửi lỗi trong một ứng dụng hoặc thư viện được phát hành trên Google Play (ví dụ: Gmail, Dịch vụ Google Play hoặc WebView) đến người dùng Android dưới dạng bản cập nhật từ Google Play.

Thông báo cho đối tác

Khi một lỗ hổng bảo mật trong AOSP được khắc phục trong Bản tin bảo mật Android, chúng tôi sẽ thông báo cho các đối tác Android về thông tin chi tiết về vấn đề và cung cấp bản vá. Danh sách các phiên bản được hỗ trợ điều chỉnh cho phiên bản cũ sẽ thay đổi theo từng bản phát hành Android mới. Hãy liên hệ với nhà sản xuất thiết bị để biết danh sách thiết bị được hỗ trợ.

Phát hành mã cho AOSP

Nếu lỗi bảo mật nằm trong một thành phần AOSP, thì bản sửa lỗi sẽ được đẩy đến AOSP sau khi bản cập nhật OTA được phát hành cho người dùng. Bạn có thể gửi trực tiếp bản sửa lỗi cho các vấn đề có mức độ nghiêm trọng thấp đến nhánh chính của AOSP trước khi bản sửa lỗi được cung cấp cho các thiết bị thông qua bản cập nhật OTA.

Nhận bản cập nhật Android

Các bản cập nhật cho hệ thống Android thường được phân phối cho thiết bị thông qua các gói cập nhật OTA. Những bản cập nhật này có thể đến từ nhà sản xuất thiết bị gốc (OEM) đã sản xuất thiết bị hoặc nhà mạng cung cấp dịch vụ cho thiết bị. Bản cập nhật thiết bị Google Pixel do nhóm Google Pixel cung cấp sau khi trải qua quy trình kiểm thử chấp nhận kỹ thuật (TA) của nhà mạng. Google cũng phát hành hình ảnh gốc của Pixel có thể tải không qua cửa hàng ứng dụng vào thiết bị.

Cập nhật các dịch vụ của Google

Ngoài việc cung cấp bản vá cho các lỗi bảo mật, nhóm bảo mật Android còn xem xét các lỗi bảo mật để xác định xem có cách nào khác để bảo vệ người dùng hay không. Ví dụ: Google Play quét tất cả ứng dụng và xoá mọi ứng dụng cố gắng khai thác lỗi bảo mật. Đối với các ứng dụng được cài đặt từ bên ngoài Google Play, các thiết bị có Dịch vụ Google Play cũng có thể sử dụng tính năng Xác minh ứng dụng để cảnh báo người dùng về những ứng dụng có khả năng gây hại.

Tài nguyên khác

Thông tin dành cho nhà phát triển ứng dụng Android: https://developer.android.com

Thông tin bảo mật có trên trang web dành cho nhà phát triển và trang web Nguồn mở Android. Bạn nên bắt đầu từ những nơi sau:

Báo cáo

Đôi khi, Nhóm bảo mật Android sẽ xuất bản báo cáo hoặc sách trắng. Hãy xem Báo cáo bảo mật để biết thêm thông tin chi tiết.