Hình ảnh hệ thống dùng chung của Android

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

Thông tin khái quát

Với Project Treble, Android nguyên khối được chia thành 2 phần: phần dành riêng cho phần cứng (phương thức triển khai của nhà cung cấp) và phần hệ điều hành chung (khung hệ điều hành Android). Phần mềm cho mỗi phân vùng được cài đặt trong một phân vùng riêng biệt: phân vùng của 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 phần mềm hệ điều hành chung. Một giao diện có phiên bản, được gọi là giao diện nhà cung cấp (VINTF), được xác định và thực thi trên cả hai phân vùng. Bằng cách sử dụng hệ thống phân vùng này, bạn có thể sửa đổi phân vùng hệ thống mà không cần sửa đổi phân vùng nhà cung cấp và ngược lại.

Động lực

Mã khung được phát hành trong AOSP tuân thủ cấu trúc Treble và duy trì khả năng tương thích ngược với các cách triển khai cũ của nhà cung cấp. Ví dụ: hình ảnh hệ thống chung đượ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ủ chuẩn Treble đang chạy Android 8 trở lên. Phiên bản Android được phân phối trên các thiết bị tiêu dùng do nhà cung cấp SoC và OEM sửa đổi. (Xem phần Vòng đời của một bản phát hành Android.) Những thay đổi và tiện ích được thực hiện đối với khung này không được viết để duy trì khả năng tương thích ngược, điều này dẫn đến sự gia tăng độ phức tạp và chi phí cao hơn khi nâng cấp hệ điều hành. Các thay đổi và nội dung sửa đổi dành riêng cho thiết bị làm tăng chi phí và độ phức tạp của việc nâng cấp phiên bản hệ điều hành Android.

Trước Android 11, không có cấu trúc rõ ràng nào cho phép các đối tác tạo tiện ích mô-đun cho khung hệ điều hành Android. Tài liệu này mô tả các bước mà nhà cung cấp SoC và OEM có thể thực hiện để tạo SSI. Điều này có nghĩa là một hình ảnh, được tạo từ các nguồn khung hệ điều hành Android để sử dụng lại trên nhiều thiết bị, để duy trì khả năng tương thích ngược với các phương thức triển khai của nhà cung cấp và để giảm đáng kể độ phức tạp và chi phí nâng cấp hệ điều hành Android. Để biết các bước cụ thể cần thực hiện để tạo SSI, hãy xem phần Các bước đề xuất cho SSI dựa trên GSI và lưu ý rằng bạn không bắt buộc phải sử dụng cả 4 bước. Các bước bạn chọn (ví dụ: chỉ Bước 1) tuỳ thuộc vào quá trình triển khai của bạ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à các tiện ích OEM sẽ đượ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õ để tương tác với các thành phần trong phân vùng /system. Các OEM có thể chọn tạo 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, các 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 các SSI để cập nhật nhiều thiết bị mà không cần cập nhật phân vùng /product.

Xin lưu ý rằng các nhà sản xuất thiết bị gốc (OEM) và nhà cung cấp SoC tạo ra các SSI bao gồm tất cả các tính năng và nội dung sửa đổi tuỳ chỉnh mà một OEM cần. 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 các nhà sản xuất thiết bị gốc (OEM) sử dụng để đạt được những 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 dễ dàng 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 thành phân vùng sản phẩm tương tự như ý tưởng của Treble về việc tách các thành phần dành riêng cho SoC thành 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. Xin lưu ý rằng đố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, thư viện, v.v. được cài đặt vào hình ảnh, về cơ bản sẽ trở thành các phân vùng.

Vách ngăn xung quanh SSI

Hình 1 cho thấy các phân vùng xung quanh SSI, cũng như các giao diện có 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. 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 theo 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: SSI là hình ảnh thường thấy ở một OEM và có thể xuất hiện trên nhiều thiết bị. Nó không có bất kỳ thành phần nào dành riêng cho phần cứng hoặc 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 hình ảnh /system duy nhất hoặc một hình ảnh /system và các phân vùng /system_ext, như trong Hình 1.

  • Phân vùng /system chứa các thành phần dựa trên AOSP, trong khi /system_ext (khi được triển khai) chứa các thành phần và tiện ích của nhà cung cấp SoC và OEM được liên kết chặt chẽ với các thành phần AOSP. Ví dụ: một thư viện khung Java OEM cung cấp các API tuỳ chỉnh cho các ứng dụng riêng của OEM sẽ phù hợp hơn với phân vùng /system_ext so với phân vùng /system. Nội dung cho cả phân vùng /system và /system_ext đều được tạo từ các nguồn Android do OEM sửa đổi.

  • Phân vùng /system_ext là không bắt buộc, nhưng bạn nên 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. Sự khác biệt này giúp bạn xác định những thay đổi cần thực hiện để di chuyển các thành phần như vậy từ phân vùng /system_ext sang phân vùng /product trong một khoảng thời gian.

• 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 chế độ tuỳ chỉnh và tiện ích 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 (không bắt buộc phải vận chuyển cùng với sản phẩm), thì nhà cung cấp SoC có thể đặt thành phần đó trong hình ảnh sản phẩm. Vị trí của một thành phần không được xác định bằng quyền sở hữu mà được quy định bằng mục đích của thành phần đó.

• Nhà cung cấp: Tập hợp các thành phần dành riêng cho SoC.

• ODM: Một tập hợp các thành phần dành riêng cho bảng 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 của nhà cung cấp SoC và ODM sẽ được hợp nhất với nhau trong phân vùng /vendor.

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

Có 2 giao diện chính cho hình ảnh của nhà cung cấp và sản phẩm trong 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 của 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 của nhà cung cấp và nhà sản xuất thiết bị gốc (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 ban đầu được xác định trong Dự án Treble, giúp phân chia hình ảnh thành các phân vùng hệ thống và nhà cung cấp. Giao diện này được mô tả bằng các cơ chế sau:

  • HIDL (HAL truyền qua chỉ có trong các mô-đun system và system_ext)
  • 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
  • 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. Giao diện sản phẩm yêu cầu các giao diện ổn định giống như VINTF. Tuy nhiên, chỉ có VNDK và API SDK Android được thực thi cho các thiết bị ra mắt cùng với Android 11 (trở lên).

Bật SSI trong Android 11

Phần này giải thích cách sử dụng các tính năng mới để hỗ trợ SSI trong Android 11.

Phân vùng /system_ext

Phân vùng /system_ext được ra mắt trong Android 11 dưới dạng một phân vùng không bắt buộc. (Đây là nơi chứa các thành phần không phải AOSP có mối liên kết chặt chẽ với các thành phần do AOSP xác định trong phân vùng /system.) Phân vùng /system_ext được giả định là tiện ích dành riêng cho OEM của phân vùng /system mà không có giao diện được xác định trên hai 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 này được liên kết chặt chẽ với nhau, nên cả hai phân vùng sẽ đượ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 trước của Android không cần tương thích với phân vùng /system 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. Đối với những thiết bị không có phân vùng /system_ext, hãy cài đặt các mô-đun như vậy vào thư mục con ./system_ext trong phân vùng /system.

Nhật ký

Sau đây là một số thông tin về lịch sử của phân vùng /system_ext. Mục tiêu thiết kế là đặt tất cả các thành phần dành riêng cho OEM, bất kể chúng có phải là thành phần 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 liên kết chặt chẽ đến 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 đòi hỏi bản thân thành phần phải được tái cấu trúc một cách rộng rãi, điều này tiêu tốn rất 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 sẽ loại bỏ phân vùng /system_ext.

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

Huỷ nhóm các thành phần từ phân vùng /system và /system_ext vào phân vùng /product

Android 9 giới thiệu phân vùng /product được ghép nối với phân vùng /system. Các mô-đun trong phân vùng /product sử dụng tài nguyên hệ thống mà không có bất kỳ hạn chế nào và ngược lại. Để có thể sử dụng SSI trong Android 10, các thành phần sản phẩm được chia thành các phân vùng /system_ext và /product. Phân vùng /system_ext không cần tuân thủ các hạn chế về việc sử dụng các thành phần hệ thống mà phân vùng /product đã thực hiện trong Android 9. Kể từ Android 10, phân vùng /product phải được tách khỏi phân vùng /system và phải sử dụng các giao diện ổn định từ phân vùng /system và /system_ext.

Mục đích chính của phân vùng /system_ext là mở rộng các tính năng của hệ thống, chứ không phải để cài đặt các mô-đun sản phẩm đi kèm, như mô tả trong phần /system_ext partition. Để thực hiện việc này, hãy tách các mô-đun dành riêng cho sản phẩm và di chuyển chúng vào phân vùng /product. Việc tách các mô-đun dành riêng cho sản phẩm sẽ giúp /system_ext trở nên phổ biến đối với các thiết bị. (Để biết thêm thông tin chi tiết, hãy xem bài viết Làm cho phân vùng /system_ext trở nên phổ biến.)

Để tách 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 tách bằng Project Treble.

Kể từ Android 11, các giao diện gốc và Java cho phân vùng /product sẽ được thực thi như mô tả bên dưới. Để biết thêm thông tin, hãy xem phần Thực thi các giao diện phân vùng sản phẩm.

• Giao diện gốc: Các mô-đun gốc trong phân vùng /product phải được tách ra 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 cả 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, cũng như các thư viện Java SDK trong phân vùng /system hoặc /system_ext. Bạn có thể xác định các thư viện Java SDK cho các API tuỳ chỉnh.

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

Hình 2. 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. GSI được dùng cho các bài kiểm thử tuân thủ Treble (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.

Các OEM cũng có thể sử dụng GSI để tạo SSI của riêng họ. Như đã giải thích trong phần Hình ảnh và phân vùng, SSI bao gồm ảnh hệ thống cho các thành phần do AOSP xác định và ả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 chế độ tuỳ chỉnh của họ thành 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 các 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, các OEM không cần phải đạt được 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 của OEM (OEM GSI)

Bằng cách kế thừa generic_system.mk (có tên là mainline_system.mk trong Android 11 và được đổi tên thành generic_system.mk trong AOSP), hình ảnh hệ thống (GSI OEM) bao gồm tất cả các tệp mà GSI AOSP có. Các tệp này có thể được OEM sửa đổi để GSI của OEM có thể chứa các tệp độc quyền của OEM ngoài các tệp GSI của AOSP. Tuy nhiên, các OEM không được phép sửa đổi chính tệp generic_system.mk.

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

Bước 2. Đảm bảo GSI của OEM có cùng danh sách tệp với GSI của AOSP

GSI của OEM không thể có các tệp bổ sung ở giai đoạn này. Các tệp độc quyền của OEM phải được di chuyển ra các phân vùng system_ext hoặc product.

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

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

Để 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 GSI AOSP với GSI OEM. Lấy GSI AOSP từ mục tiêu khởi động AOSP generic_system_*.

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

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

Bước 4. Đảm bảo GSI của OEM có cùng các tệp nhị phân với GSI của AOSP

Việc dọn dẹp danh sách cho phép giúp các OEM sử dụng GSI AOSP 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, các OEM có thể huỷ bỏ các thay đổi của mình trong GSI OEM hoặc chuyển các thay đổi của mình lên AOSP để GSI AOSP bao gồm các thay đổi của họ.

Hình 6. Đảm bảo GSI của OEM có cùng tệp nhị phân với GSI của AOSP

Xác định SSI cho OEM

Bảo vệ phân vùng /system tại thời điểm tạo

Để 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 GSI của OEM, các OEM có thể sử dụng một macro makefile có tên là require-artifacts-in-path để ngăn mọi khai báo về các mô-đun hệ thống sau khi macro được gọi. Xem ví dụ Tạo tệp makefile và bật tính năng kiểm tra đường dẫn cấu phần phần mềm.

Các OEM có thể xác định một danh sách để cho phép tạm thời cài đặt 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 này phải trống để GSI của OEM dùng chung cho tất cả các sản phẩm của OEM. Quy trình này dùng để xác định GSI OEM và có thể độc lập với các bước đối với GSI AOSP.

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

Để đảm bảo phân vùng /product không được tách rời, các OEM có thể đảm bảo rằng 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 gốc 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 các giao diện phân vùng sản phẩm.

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 dành riêng cho thiết bị, được hệ thống đi kèm. 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 sẽ cản trở các OEM xác định SSI. Các 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 phổ biến.

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

Bạn không thể cài đặt nhiều ứng dụng dành riêng cho sản phẩm trong phân vùng sản phẩm vì các ứng dụng này sử dụng 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 xoá việc sử dụng các API ẩn.

Cách tốt nhất để xoá 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ế để thay thế chúng. Nếu không có API nào để thay thế các API bị ẩn, thì 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, các OEM có thể xác định API tuỳ chỉnh bằng cách tạo thư viện Java SDK của riêng họ trong phân vùng /system_ext. Nó 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 này cho các ứng dụng trong phân vùng sản phẩm hoặc nhà cung cấp. Các OEM phải đóng băng các API hướng đến sản phẩm để đảm bảo khả năng tương thích ngược.

Bao gồm siêu tập hợp của tất cả các tệp APK và bỏ qua một số gói cài đặt cho từng thiết bị

Một số gói đi kèm với hệ thống không phổ biến trên các thiết bị. Việc tách các mô-đun APK này để di chuyển chúng sang phân vùng sản phẩm hoặc nhà cung cấp có thể sẽ khó khăn. Là một giải pháp tạm thời, OEM có thể đưa tất cả các mô-đun vào SSI, sau đó lọc bỏ những mô-đun không mong muốn bằng cách sử dụng thuộc tính SKU (ro.boot.hardware.sku). Để sử dụng bộ lọc, OEM sẽ phủ các tài nguyên khung config_disableApkUnlessMatchedSku_skus_list và config_disableApksUnlessMatchedSku_apk_list.

Để có chế độ cài đặt chính xác hơn, hãy khai báo một broadcast receiver vô hiệu hoá các gói không cần thiết. Broadcast receiver gọi setApplicationEnabledSetting để tắt gói khi nhận được thông báo ACTION_BOOT_COMPLETED.

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 sẽ thao tác với các gói được phủ. Tuy nhiên, điều này có thể cản trở việc xác định một SSI, vì vậy, hãy đảm bảo rằng các thuộc tính cho RRO được bật và thiết lập đúng cách. Bằng cách đặt các thuộc tính như sau, OEM có thể có tất 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 cần có 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 phần Lớp phủ tài nguyên thời gian chạy (RRO). Các OEM cũng có thể xác định RRO có điều kiện tuỳ 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 (FAQ)

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

Điều này phụ thuộc vào điểm chung và đặc điểm của các thiết bị (hoặc nhóm thiết bị). Các 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ể sửa đổi generic_system.mk (mainline_system.mk) cho GSI của OEM không?

Không. Tuy nhiên, OEM có thể xác định một tệp makefile mới cho GSI của OEM kế thừa tệp generic_system.mk và sử dụng tệp makefile mới thay thế. Để biết ví dụ, hãy xem phần Thực thi các giao diện phân vùng sản phẩm.

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

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