Hình ảnh hệ thống dùng chung

Trang này trình bày một số cơ chế mà Nhà sản xuất thiết bị gốc (OEM) Android có thể sử dụng để có hình ảnh hệ thống dùng chung (SSI) trên các dòng sản phẩm. Trang này cũng đề xuất một quy trình để dựa trên hình ảnh hệ thống dùng chung (SSI) do OEM sở hữu trên hình ảnh hệ thống chung (GSI) được tạo bằng Dự án nguồn mở Android (AOSP).

Nền

Khung Dự án nguồn mở Android (AOSP) tuân thủ kiến trúc Mainline để duy trì khả năng tương thích ngược với các hoạt động triển khai cũ của nhà cung cấp. Ví dụ: Hình ảnh hệ thống chung (GSI) được tạo từ các nguồn AOSP Android 10 có thể chạy trên mọi thiết bị tuân thủ Treble chạy Android 8 trở lên.

Mainline đạt được điều này bằng cách chia Android thành 2 phần riêng biệt: hoạt động triển khai dành riêng cho phần cứng của nhà cung cấp và khung hệ điều hành Android chung. Mỗi thành phần được cài đặt trong một phân vùng riêng biệt – phân vùng nhà cung cấp cho phần mềm dành riêng cho phần cứng và phân vùng hệ thống cho hệ điều hành chung. Một giao diện được phân phiên bản, gọi là giao diện nhà cung cấp (VINTF), được thực thi giữa chúng. Hệ thống phân vùng này cho phép OEM sửa đổi phân vùng hệ thống mà không ảnh hưởng đến phân vùng nhà cung cấp và ngược lại.

Trước đây, các nhà cung cấp SoC và OEM đã sửa đổi đáng kể phiên bản khung Android được vận chuyển trên các thiết bị tiêu dùng (để biết thông tin chi tiết, hãy xem bài viết Vòng đời của bản phát hành Android). Vì các tiện ích khung này hiếm khi được thiết kế có tính đến khả năng tương thích ngược, nên các sửa đổi dành riêng cho thiết bị đã làm tăng đáng kể độ phức tạp và chi phí tài chính của các bản nâng cấp hệ điều hành tiếp theo. Trong Android 10 (API cấp 29) trở xuống, hệ sinh thái thiếu một kiến trúc rõ ràng, được tiêu chuẩn hoá cho phép các đối tác xây dựng các tiện ích mô-đun cho khung Android.

Trang này trình bày cách các nhà cung cấp SoC và OEM có thể xây dựng hình ảnh hệ thống dùng chung (SSI). SSI là một hình ảnh khung hợp nhất được tạo từ các nguồn hệ điều hành Android có thể được sử dụng lại trên nhiều thiết bị. Bằng cách duy trì khả năng tương thích ngược rõ ràng với các hoạt động triển khai của nhà cung cấp thông qua kiến trúc được phân vùng này, SSI giúp giảm đáng kể chi phí và độ phức tạp của các bản nâng cấp hệ điều hành Android.

Để biết thông tin chi tiết về cách triển khai, hãy xem phần Các bước được đề xuất cho SSI dựa trên GSI. Các bước này là mô-đun; tuỳ thuộc vào kiến trúc của bạn, bạn có thể chọn triển khai các giai đoạn cụ thể (chẳng hạn như Bước 1: Kế thừa generic_system.mk cho hình ảnh hệ thống OEM (OEM GSI)) thay vì tất cả các giai đoạn.

Tổng quan về SSI

Với SSI, các thành phần phần mềm dành riêng cho sản phẩm và tiện ích OEM được đặt trong một phân vùng /product mới. Các thành phần trong phân vùng /product sử dụng một giao diện ổn định, được xác định rõ ràng để tương tác với các thành phần trong phân vùng /system. OEM có thể chọn xây dựng một SSI hoặc có một số lượng nhỏ SSI để sử dụng trên nhiều SKU thiết bị. Khi một phiên bản mới của hệ điều hành Android được phát hành, OEM chỉ đầu tư một lần vào việc cập nhật SSI của họ lên bản phát hành Android mới nhất. Họ có thể sử dụng lại SSI để cập nhật nhiều thiết bị mà không cần cập nhật phân vùng /product.

OEM và nhà cung cấp SoC có thể xây dựng SSI bao gồm các tính năng và sửa đổi tuỳ chỉnh. Các cơ chế và phương pháp hay nhất được cung cấp trên trang này là dành cho OEM sử dụng để đạt được các mục tiêu chính sau:

• Sử dụng lại SSI trên nhiều SKU thiết bị.
• Cập nhật hệ thống Android bằng các tiện ích mô-đun để giúp việc nâng cấp hệ điều hành trở nên đơn giản hơn.

Ý tưởng cốt lõi về việc tách các thành phần dành riêng cho sản phẩm vào phân vùng sản phẩm tương tự như việc Mainline tách các thành phần dành riêng cho SoC vào phân vùng nhà cung cấp. Giao diện sản phẩm (tương tự như VINTF) cho phép giao tiếp giữa SSI và phân vùng sản phẩm. Đối với SSI, thuật ngữ thành phần mô tả tất cả tài nguyên, tệp nhị phân, văn bản và thư viện được cài đặt vào hình ảnh, trở thành các phân vùng.

Các phân vùng xung quanh SSI

Hình 1 cho thấy các phân vùng xung quanh SSI và các giao diện được phân phiên bản trên các phân vùng và chính sách trên các giao diện. Phần này giải thích chi tiết từng phân vùng và giao diện.

Hình 1. Các phân vùng và giao diện xung quanh SSI.

Hình ảnh và phân vùng

Thông tin trong phần này phân biệt giữa các thuật ngữ hình ảnh và phân vùng.

• Hình ảnh là một phần mềm khái niệm có thể được cập nhật độc lập.
• Phân vùng là một vị trí lưu trữ thực tế có thể được cập nhật độc lập.

Các phần trong Hình 1 được xác định như sau:

• SSI: Một hình ảnh chung cho OEM và có thể tồn tại trên nhiều thiết bị. Hình ảnh này không có thành phần dành riêng cho phần cứng hoặc thành phần dành riêng cho sản phẩm. Theo định nghĩa, mọi thứ trong một SSI nhất định đều được chia sẻ giữa tất cả các thiết bị sử dụng SSI đó. SSI bao gồm một /system hình ảnh hoặc các phân vùng /system và /system_ext.

• Hình ảnh sản phẩm: Một tập hợp các thành phần dành riêng cho sản phẩm hoặc thiết bị đại diện cho các tiện ích và tuỳ chỉnh của OEM đối với hệ điều hành Android. Đặt các thành phần dành riêng cho SoC vào phân vùng /vendor. Nhà cung cấp SoC cũng có thể sử dụng phân vùng /product cho các thành phần thích hợp, chẳng hạn như các thành phần độc lập với SoC. Ví dụ: nếu nhà cung cấp SoC cung cấp một thành phần độc lập với SoC cho khách hàng OEM của họ (không bắt buộc phải vận chuyển cùng sản phẩm), thì nhà cung cấp SoC có thể đặt thành phần đó vào hình ảnh sản phẩm. Vị trí của một thành phần được xác định theo mục đích của thành phần đó chứ không phải quyền sở hữu.

• Hình ảnh nhà cung cấp: Một tập hợp các thành phần dành riêng cho SoC.

• Hình ảnh ODM: Một tập hợp các thành phần dành riêng cho bo mạch không do SoC cung cấp. Thông thường, nhà cung cấp SoC sở hữu hình ảnh nhà cung cấp, trong khi nhà sản xuất thiết bị sở hữu hình ảnh ODM. Khi không có phân vùng /odm riêng biệt, cả hình ảnh nhà cung cấp SoC và hình ảnh ODM đều được hợp nhất trong phân vùng /vendor.

Phân vùng /system_ext

Phân vùng /system_ext là không bắt buộc. Sử dụng phân vùng này cho mọi tính năng và tiện ích tuỳ chỉnh được liên kết chặt chẽ với các thành phần dựa trên AOSP. Phân vùng này được giả định là tiện ích dành riêng cho OEM đối với phân vùng /system, không có giao diện được xác định trên 2 phân vùng. Các thành phần trong phân vùng /system_ext có thể thực hiện các lệnh gọi API riêng tư vào phân vùng /system và các thành phần trong phân vùng /system có thể thực hiện các lệnh gọi API riêng tư vào phân vùng /system_ext.

Vì 2 phân vùng được liên kết chặt chẽ, nên cả 2 phân vùng đều được nâng cấp cùng nhau khi một phiên bản Android mới được phát hành. Phân vùng /system_ext được tạo cho bản phát hành Android trước đó không cần tương thích với /system phân vùng trong bản phát hành Android tiếp theo.

Để cài đặt một mô-đun vào phân vùng /system_ext, hãy thêm system_ext_specific: true vào tệp Android.bp. Trên các thiết bị không có /system_ext phân vùng, hãy cài đặt các mô-đun như vậy vào thư mục con ./system_ext trong /system phân vùng.

Lịch sử: Mục tiêu thiết kế ban đầu của phân vùng /system_ext là đặt tất cả các thành phần dành riêng cho OEM, bất kể chúng có chung hay không, vào phân vùng /product. Tuy nhiên, việc di chuyển tất cả các thành phần cùng một lúc là không khả thi, đặc biệt là khi một số thành phần có mối liên kết chặt chẽ với phân vùng /system. Để di chuyển một thành phần được liên kết chặt chẽ vào phân vùng /product, bạn phải mở rộng giao diện sản phẩm. Việc này thường yêu cầu phải tái cấu trúc thành phần đó một cách rộng rãi, tốn nhiều thời gian và công sức. Phân vùng /system_ext bắt đầu là nơi tạm thời lưu trữ những thành phần chưa sẵn sàng để chuyển sang phân vùng /product. Mục tiêu của SSI là cuối cùng loại bỏ phân vùng /system_ext.

Tuy nhiên, phân vùng /system_ext rất hữu ích để giữ cho phân vùng /system càng gần với AOSP càng tốt. Với SSI, hầu hết nỗ lực nâng cấp đều tập trung vào các thành phần trong phân vùng /system và /system_ext. Khi hình ảnh hệ thống được tạo từ các nguồn càng giống với các nguồn trong AOSP càng tốt, bạn có thể tập trung nỗ lực nâng cấp vào hình ảnh system_ext.

Giao diện giữa các hình ảnh

Có 2 giao diện chính cho hình ảnh nhà cung cấp và sản phẩm xung quanh SSI:

• Giao diện nhà cung cấp (VINTF): VINTF là giao diện cho các thành phần nằm trong hình ảnh nhà cung cấp và ODM. Các thành phần trong hình ảnh sản phẩm và hệ thống chỉ có thể tương tác với hình ảnh nhà cung cấp và ODM thông qua giao diện này. Ví dụ: hình ảnh nhà cung cấp không thể phụ thuộc vào một phần riêng tư của hình ảnh hệ thống và ngược lại. Điều này được xác định trong kiến trúc Treble (hiện là một phần của kiến trúc Mainline rộng hơn), chia hình ảnh thành các phân vùng hệ thống và nhà cung cấp. Giao diện được mô tả bằng các cơ chế sau:

  • HIDL (HAL truyền qua chỉ có sẵn cho system và system_ext mô-đun)
  • AIDL ổn định
  • Cấu hình
    • API thuộc tính hệ thống
    • API giản đồ tệp cấu hình
  • VNDK (Bộ công cụ phát triển gốc dành cho nhà cung cấp)
  • API SDK Android
  • Thư viện SDK Java

• Giao diện sản phẩm: Giao diện sản phẩm là giao diện giữa SSI và hình ảnh sản phẩm. Việc xác định một giao diện ổn định sẽ tách các thành phần sản phẩm khỏi các thành phần hệ thống trong SSI.

Bật SSI

Phần này giải thích cách hỗ trợ SSI trong Android 11 trở lên.

Gỡ gói các thành phần

Để gỡ gói phân vùng /product khỏi các thành phần hệ thống, phân vùng /product phải có cùng chính sách thực thi với phân vùng /vendor đã được gỡ gói bằng Mainline.

• Giao diện tích hợp: Các mô-đun tích hợp trong phân vùng /product phải được gỡ gói khỏi các phân vùng khác. Các phần phụ thuộc duy nhất được phép từ các mô-đun sản phẩm là một số thư viện VNDK (bao gồm LLNDK) từ phân vùng /system. Các thư viện JNI mà ứng dụng sản phẩm phụ thuộc phải là thư viện NDK.
• Giao diện Java: Các mô-đun Java (ứng dụng) trong phân vùng /product không thể sử dụng các API ẩn vì chúng không ổn định. Các mô-đun này chỉ được sử dụng các API công khai và API hệ thống từ phân vùng /system và thư viện SDK Java trong phân vùng /system hoặc /system_ext. Bạn có thể xác định thư viện SDK Java cho các API tuỳ chỉnh.

Thực thi giao diện sản phẩm

Để đảm bảo rằng phân vùng /product được gỡ gói, OEM có thể yêu cầu thiết bị của họ thực thi các giao diện sản phẩm bằng cách đặt PRODUCT_PRODUCT_VNDK_VERSION:= current cho các mô-đun tích hợp và PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true cho các mô-đun Java. Các biến này được đặt tự động nếu PRODUCT_SHIPPING_API_LEVEL của thiết bị lớn hơn hoặc bằng 30. Để biết thông tin chi tiết, hãy xem phần Thực thi giao diện phân vùng sản phẩm.

Các bước được đề xuất cho SSI dựa trên GSI

Hình 2. Các phân vùng được đề xuất cho SSI dựa trên GSI.

Hình ảnh hệ thống chung (GSI) là hình ảnh hệ thống được tạo trực tiếp từ AOSP. Hình ảnh này được dùng cho các bài kiểm tra tuân thủ (ví dụ: CTS-on-GSI) và làm nền tảng tham chiếu mà nhà phát triển ứng dụng có thể dùng để kiểm thử khả năng tương thích của ứng dụng khi họ không có thiết bị thực chạy phiên bản Android cần thiết.

OEM cũng có thể sử dụng GSI để tạo SSI. Như đã giải thích trong phần Hình ảnh và phân vùng, SSI bao gồm hình ảnh hệ thống cho các thành phần do AOSP xác định và hình ảnh system_ext cho các thành phần do OEM xác định. Khi GSI được dùng làm hình ảnh system, OEM có thể tập trung vào hình ảnh system_ext để nâng cấp.

Phần này cung cấp hướng dẫn cho các OEM muốn mô-đun hoá các tuỳ chỉnh của họ vào các phân vùng /system_ext và /product trong khi sử dụng hình ảnh hệ thống AOSP hoặc gần AOSP. Nếu OEM tạo hình ảnh hệ thống từ các nguồn AOSP, thì họ có thể thay thế hình ảnh hệ thống mà họ tạo bằng GSI do AOSP cung cấp. Tuy nhiên, OEM không cần phải thực hiện bước cuối cùng (sử dụng GSI như hiện tại) cùng một lúc.

Bước 1: Kế thừa generic_system.mk cho hình ảnh hệ thống OEM (OEM GSI)

Bằng cách kế thừa generic_system.mk (được đặt tên là mainline_system.mk trong Android 11 và đổi tên thành generic_system.mk trong AOSP), hình ảnh hệ thống (OEM GSI) bao gồm tất cả các tệp mà AOSP GSI có. Các tệp này có thể được OEM (Nhà sản xuất thiết bị gốc) sửa đổi để OEM GSI (Hình ảnh hệ thống chung) có thể chứa các tệp thuộc quyền sở hữu riêng của OEM ngoài các tệp AOSP (Dự án nguồn mở Android) GSI (Hình ảnh hệ thống chung).

Hình 3. Kế thừa generic_system.mk cho hình ảnh hệ thống của OEM.

Bước 2: Tạo OEM GSI có cùng danh sách tệp với AOSP GSI

OEM GSI không thể có thêm tệp ở giai đoạn này, vì vậy, hãy di chuyển các tệp độc quyền của OEM sang phân vùng system_ext hoặc product.

Hình 4. Di chuyển các tệp đã thêm ra khỏi OEM GSI.

Bước 3: Xác định danh sách cho phép để giới hạn các tệp đã sửa đổi trong OEM GSI

Để kiểm tra các tệp đã sửa đổi, OEM có thể sử dụng công cụ compare_images và so sánh AOSP GSI với OEM GSI. Lấy AOSP GSI từ mục tiêu khởi chạy AOSP generic_system_*.

Bằng cách chạy công cụ compare_images định kỳ với tham số allowlist, bạn có thể theo dõi các điểm khác biệt bên ngoài danh sách cho phép. Điều này ngăn các sửa đổi bổ sung đối với OEM GSI.

Hình 5. Xác định danh sách cho phép để giảm danh sách tệp đã sửa đổi trong OEM GSI.

Bước 4: Tạo OEM GSI có cùng tệp nhị phân với AOSP GSI

Việc dọn dẹp danh sách cho phép cho phép OEM sử dụng AOSP GSI làm hình ảnh hệ thống cho các sản phẩm của riêng họ. Để dọn dẹp danh sách cho phép, OEM có thể từ bỏ các thay đổi của họ trong OEM GSI hoặc chuyển các thay đổi của họ lên AOSP để AOSP GSI bao gồm các thay đổi của họ.

Hình 6. Tạo OEM GSI có cùng tệp nhị phân với AOSP GSI.

Xác định SSI

OEM có thể sử dụng hướng dẫn sau để xác định SSI của họ.

Bảo vệ phân vùng /system trong thời gian xây dựng

Để tránh mọi thay đổi dành riêng cho sản phẩm trong phân vùng /system và xác định OEM GSI, OEM có thể sử dụng macro makefile có tên là require-artifacts-in-path để ngăn mọi khai báo mô-đun hệ thống sau khi macro được gọi. Xem ví dụ trong Bước 1: Tạo makefile và bật tính năng kiểm tra đường dẫn thành phần.

OEM có thể xác định một danh sách để cho phép cài đặt tạm thời các mô-đun dành riêng cho sản phẩm trong phân vùng /system. Tuy nhiên, danh sách phải trống để tạo OEM GSI chung cho tất cả các sản phẩm của OEM. Quy trình này dùng để xác định OEM GSI và có thể độc lập với các bước cho AOSP GSI.

Tạo phân vùng /system_ext chung

Phân vùng /system_ext có thể khác nhau giữa các thiết bị vì phân vùng này có thể có các mô-đun được gói theo hệ thống dành riêng cho thiết bị. Vì SSI bao gồm các phân vùng /system và /system_ext nên sự khác biệt trong phân vùng /system_ext cản trở OEM xác định SSI. OEM có thể có SSI riêng và có thể chia sẻ SSI đó giữa nhiều thiết bị bằng cách loại bỏ mọi điểm khác biệt và tạo phân vùng /system_ext chung.

Phần này đưa ra các đề xuất để tạo phân vùng /system_ext chung.

Hiển thị các API ẩn trong phân vùng hệ thống

Nhiều ứng dụng dành riêng cho sản phẩm không thể được cài đặt trong phân vùng sản phẩm vì chúng sử dụng các API ẩn bị cấm trong phân vùng sản phẩm. Để di chuyển các ứng dụng dành riêng cho thiết bị sang phân vùng sản phẩm, hãy loại bỏ việc sử dụng các API ẩn.

Cách ưu tiên để loại bỏ các API ẩn khỏi ứng dụng là tìm các API công khai hoặc API hệ thống thay thế. Nếu không có API nào để thay thế các API ẩn, OEM có thể đóng góp cho AOSP để xác định các API hệ thống mới cho thiết bị của họ.

Ngoài ra, OEM có thể xác định các API tuỳ chỉnh bằng cách tạo thư viện SDK Java của riêng họ trong phân vùng /system_ext. Thư viện này có thể sử dụng các API ẩn trong phân vùng hệ thống và có thể cung cấp các API cho các ứng dụng trong phân vùng sản phẩm hoặc nhà cung cấp. OEM phải đóng băng các API hướng đến sản phẩm để tương thích ngược.

Thay thế việc tắt ứng dụng dành riêng cho SKU

Android 16 đã ngừng sử dụng và loại bỏ cơ chế cũ để tắt có chọn lọc các tệp APK dựa trên SKU phần cứng bằng cách sử dụng lớp phủ tài nguyên khung (config_disableApksUnlessMatchedSku_apk_list và config_disableApkUnlessMatchedSku_skus_list). Để biết thông tin chi tiết, hãy xem aosp/3444399.

Giải pháp thay thế được đề xuất là sử dụng cấu hình hệ thống install-in-user-type trong các thư mục dành riêng cho SKU. Phương pháp này ngăn không cho cài đặt gói cho bất kỳ người dùng nào trên một SKU cụ thể, thay vì chỉ tắt gói đó sau khi cài đặt.

1. Đưa tất cả các tệp APK (siêu tập hợp của tất cả các ứng dụng tiềm năng cho tất cả các SKU trong hình ảnh hệ thống của bạn) vào hình ảnh, thường là trong phân vùng /product.

2. Đảm bảo SKU thiết bị được đặt chính xác trong thuộc tính hệ thống ro.boot.hardware.sku (hệ thống dùng để xác định SKU thiết bị tại thời điểm khởi động).

3. Tạo các thư mục con sysconfig dành riêng cho SKU trong /product/etc/sysconfig/ bằng quy ước đặt tên sku_<SKU_NAME>. Hệ thống sẽ tự động tải các cấu hình từ thư mục khớp với thuộc tính ro.boot.hardware.sku. Đường dẫn ví dụ: /product/etc/sysconfig/sku_basic_model/.

4. Định cấu hình tính năng ngăn cài đặt ứng dụng. Bên trong thư mục dành riêng cho SKU, hãy tạo một tệp cấu hình XML (ví dụ: disabled_apps.xml) và sử dụng thẻ <do-not-install-in> để loại trừ các gói cụ thể.

Ví dụ XML (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

Dưới đây là bảng so sánh 2 phương pháp:

Đối với các trường hợp yêu cầu kiểm soát chi tiết hơn (tức là tắt một ứng dụng thường được cài đặt theo mặc định trên tất cả các SKU), Android cũng hỗ trợ các thẻ disabled-in-sku và enabled-in-sku-override trong sysconfig:

• <disabled-in-sku package="com.example.app" /> tắt ứng dụng trên toàn cầu.

• <enabled-in-sku-override package="com.example.app" /> bật lại ứng dụng cho một SKU cụ thể khi được đặt trong thư mục sku_<name> tương ứng.

Xác định RRO thay vì sử dụng lớp phủ tài nguyên tĩnh

Lớp phủ tài nguyên tĩnh thao tác các gói được phủ. Tuy nhiên, lớp phủ này có thể cản trở việc xác định SSI, vì vậy, hãy đảm bảo rằng các thuộc tính cho RRO được bật và đặt đúng cách. Bằng cách đặt các thuộc tính như sau, OEM có thể có tất cả các lớp phủ được tạo tự động dưới dạng RRO.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Nếu bạn cần cấu hình chi tiết, hãy xác định RRO theo cách thủ công thay vì dựa vào RRO được tạo tự động. Để biết thông tin chi tiết, hãy xem Thay đổi giá trị của tài nguyên ứng dụng trong thời gian chạy. OEM cũng có thể xác định các RRO có điều kiện phụ thuộc vào các thuộc tính hệ thống bằng cách sử dụng các thuộc tính android:requiredSystemPropertyName và android:requiredSystemPropertyValue.

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

Sau đây là các câu hỏi thường gặp về SSI.

Tôi có thể xác định nhiều SSI không?

Điều này phụ thuộc vào tính phổ biến và đặc điểm của thiết bị (hoặc nhóm thiết bị). OEM có thể cố gắng tạo phân vùng system_ext chung, như mô tả trong phần Tạo phân vùng system_ext chung. Nếu một nhóm thiết bị có nhiều điểm khác biệt, thì bạn nên xác định nhiều SSI.

Tôi có thể xoá các mô-đun khỏi generic_system.mk xung đột với hoạt động triển khai của mình không?

Không. GSI có một tập hợp tối thiểu các mô-đun có thể khởi động và kiểm thử. Nếu bạn cho rằng một mô-đun không cần thiết, hãy báo cáo lỗi để cập nhật tệp generic_system.mk.