Hình ảnh hệ thống chia sẻ của Android

Trang này trình bày một số cơ chế mà OEM của thiết bị Android có thể sử dụng để có hình ảnh hệ thống (SSI) được chia sẻ riêng 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 để xây dựng SSI do OEM sở hữu dựa trên hình ảnh hệ thống chung (GSI) do AOSP tạo.

Thông tin khái quát

Với Dự án Treble, Android nguyên khối được chia thành hai 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 đượ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 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 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 của 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 phương thức triển khai của nhà cung cấp cũ. Ví dụ: hình ảnh hệ thống chung được tạo từ các nguồn AOSP của Android 10 có thể chạy trên mọi thiết bị tuân thủ chuẩn Treble chạy Android 8 trở lên. Phiên bản Android xuất xưởng trên thiết bị tiêu dùng được nhà cung cấp SoC và OEM sửa đổi. (Xem phần Vòng đời của bản phát hành Android.) Những thay đổi và phần mở rộng này được thực hiện đối với khung không được viết để duy trì khả năng tương thích ngược, dẫn đến độ phức tạp tăng lên và chi phí cao hơn trong quá trình nâng cấp hệ điều hành. Các thay đổi và 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 xây dựng tiện ích mô-đun cho khung Android OS. 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ị, nhằm 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, đồng thời 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 nhất thiết phải sử dụng cả 4 bước. Các bước bạn chọn (ví dụ: chỉ Bước 1) phụ thuộc vào cách bạn triển khai.

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. Nhà sản xuất thiết bị gốc (OEM) có thể chọn tạo một SSI hoặc có một số ít SSI để sử dụng trên nhiều SKU thiết bị. Khi phiên bản mới của hệ điều hành Android được phát hành, OEM (Nhà sản xuất thiết bị gốc) chỉ đầu tư một lần vào việc cập nhật các SSI lên bản phát hành Android mới nhất. Các ứng dụng này 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.

Lưu ý rằng 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 tuỳ chỉnh và nội dung sửa đổi mà OEM cần. Các cơ chế và phương pháp hay nhất được cung cấp trên trang này dành cho 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 cho nhiều SKU thiết bị.
  • Cập nhật hệ thống Android bằng các tiện ích mô-đun để nâng cấp hệ điều hành dễ dàng hơn.

Ý tưởng cốt lõi của 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ư ý tưởng của Treble về việc tách các thành phần dành riêng cho SoC vào phân vùng của 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 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 và 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 giao diện. Phần này giải thích chi tiết về từng phân vùng và giao diện.

Các phân vùng và giao diện xung quanh sơ đồ khối SSI

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: SSI là hình ảnh phổ biến đối với nhà sản xuất thiết bị gốc (OEM) và có thể tồn tại trên nhiều thiết bị. Không có thành phần 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 đượ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 hoặc một phân vùng /system và /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 tiện ích của nhà cung cấp OEM và SoC cũng như các thành phần được ghép nối chặt chẽ với các thành phần AOSP. Ví dụ: thư viện khung Java của OEM cung cấp API tuỳ chỉnh cho các ứng dụng của chính OEM sẽ phù hợp hơn trong /system_ext so với trong phân vùng /system. Nội dung cho cả phân vùng /system và /system_ext được tạo từ các nguồn Android đã được 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 kết hợp chặt chẽ với các thành phần dựa trên AOSP (Dự án nguồn mở Android). 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 đó 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: 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 phần tuỳ chỉnh và tiện ích của OEM cho 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 một 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 là OEM (bạn không bắt buộc phải gửi kèm 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 không được xác định bằng quyền sở hữu mà là do 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: 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, còn 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 lẫn hình ảnh 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ó hai giao diện chính dành cho hình ảnh nhà cung cấp và sản phẩm liên quan đến SSI:

  • Giao diện nhà cung cấp (VINTF): VINTF là giao diện cho các thành phần nằm trong nhà cung cấp và hình ảnh ODM. Các thành phần trong hình ảnh sản phẩm và hình ảnh hệ thống chỉ có thể tương tác với hình ảnh của nhà cung cấp và ODM thông qua giao diện này. Ví dụ: hình ảnh của nhà cung cấp không được 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. Ban đầu, điều này được xác định trong Project Treble, phân tách 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ỉ khả dụng cho 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 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 giao diện ổn định giống như VINTF. Tuy nhiên, chỉ các API VNDK và SDK Android mới được thực thi cho các thiết bị chạy 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 hiện có để hỗ trợ SSI trong Android 11.

Phân vùng /system_ext

Phân vùng /system_ext được giới thiệu trong Android 11 dưới dạng một phân vùng không bắt buộc. (Đây là nơi dành cho 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 cho 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 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 lệnh gọi API riêng tư vào phân vùng /system_ext.

Vì hai phân vùng này được ghép nối chặt chẽ, nên cả hai phân vùng sẽ được nâng cấp cùng nhau khi có phiên bản Android mới. Một 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 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 các 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ý

Dưới đây là một số thông tin về 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ổ biến hay không, trong 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 ghép nối chặt chẽ sang phân vùng /product, bạn phải mở rộng giao diện sản phẩm. Điều này thường đòi hỏi phải tái cấu trúc rộng rãi chính thành phần đó, 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ữ các thành phần chưa sẵn sàng để di chuyển sang phân vùng /product. Mục tiêu của SSI là 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 gần với AOSP nhất có thể. Với SSI, hầu hết nỗ lự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 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.

Bỏ gói 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 một phân vùng /product 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. Để hỗ trợ 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 phải tuân thủ các quy định hạn chế về việc sử dụng các thành phần hệ thống như phân vùng /product trong Android 9. Kể từ Android 10, bạn phải tách phân vùng /product khỏi phân vùng /system và phải sử dụng giao diện ổn định từ các 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 hệ thống, thay vì 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 huỷ gói các mô-đun dành riêng cho sản phẩm và di chuyển các mô-đun đó 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ở thành mô-đun chung cho các thiết bị. (Để biết thêm thông tin chi tiết, hãy xem phần Đặt phân vùng /system_ext làm phân vùng chung.)

Để tách 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 như phân vùng /vendor đã được tách nhóm với Project Treble.

Kể từ Android 11, 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 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 khỏi các phân vùng khác. Các phần phụ thuộc duy nhất được phép từ 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à các ứng dụng sản phẩm phụ thuộc vào 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ì các API này không ổn định. Các mô-đun này chỉ được sử dụng API công khai và API hệ thống từ phân vùng /system, cũng như 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.

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

Các phân vùng đượ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. 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ể sử dụng để kiểm thử khả năng tương thích của ứng dụng khi không có thiết bị thực chạy phiên bản Android bắt buộc.

Nhà sản xuất thiết bị gốc (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, nhà sản xuất thiết bị gốc (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 mình 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 nhà sản xuất thiết bị gố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 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 native_system.mk cho hình ảnh hệ thống của OEM (Hình ảnh hệ thống của nhà sản xuất thiết bị gốc)

Bằng cách kế thừa generic_system.mk (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 (GSI OEM) bao gồm tất cả các tệp mà GSI AOSP có. Các OEM có thể sửa đổi các tệp này để GSI OEM có thể chứa các tệp độc quyền của OEM ngoài các tệp GSI AOSP. Tuy nhiên, OEM không được phép chỉnh sửa tệp generic_system.mk.

Kế thừa "generic_system.mk" cho hình ảnh hệ thống OEM

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. Bạn phải di chuyển các tệp độc quyền của OEM sang các phân vùng system_ext hoặc product.

Di chuyển các tệp đã thêm ra khỏi GSI của OEM (Nhà sản xuất thiết bị gốc)

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 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 của OEM. Lấy GSI AOSP từ mục tiêu bữa ăn trưa AOSP generic_system_*.

Bằng cách chạy định kỳ công cụ compare_images 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 được phép. Điều này giúp bạn không cần phải sửa đổi thêm GSI của OEM.

Xác định danh sách cho phép để giảm danh sách tệp đã sửa đổi trong GSI 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. Đặt tệp nhị phân của GSI OEM giống với tệp nhị phân của GSI AOSP

Việc dọn dẹp danh sách cho phép cho phép 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, nhà sản xuất thiết bị gốc (OEM) có thể bỏ qua các thay đổi trong GSI của OEM hoặc ngược dòng thay đổi lên AOSP để AOSP bao gồm các thay đổi của họ.

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

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

Định nghĩa SSI cho OEM (Nhà sản xuất thiết bị gốc)

Bảo vệ phân vùng /system tại thời điểm tạo bản 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 tệp makefile có tên là require-artifacts-in-path để ngăn mọi nội dung khai báo mô-đun hệ thống sau khi macro được gọi. Xem ví dụ về cách 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.

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 này phải trống để GSI OEM trở thành danh sách chung cho tất 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.

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

Để đảm bảo phân vùng /product không được gói, OEM có thể đảm bảo thiết bị của họ thực thi 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 sẽ được tự động đặt 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.

Đặt phân vùng /system_ext thành chung

Các thiết bị có thể có phân vùng /system_ext khác nhau vì phân vùng này có thể có các mô-đun đi kèm 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 sẽ khiến OEM không thể 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 xoá mọi điểm khác biệt và làm cho phân vùng /system_ext trở thành phổ biến.

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

Nhiều ứng dụng dành riêng cho sản phẩm không được cài đặt trong phân vùng sản phẩm vì chúng sử dụng API ẩn, vốn bị cấm trong phân vùng sản phẩm. Để 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 ngừng sử dụng API ẩn.

Cách ưu tiên để xoá API ẩn khỏi ứng dụng là tìm API công khai thay thế hoặc API hệ thống để thay thế chúng. Nếu không có API nào thay thế được API ẩn, nhà sản xuất thiết bị gốc (OEM) có thể đóng góp cho AOSP để xác định 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 riêng trong phân vùng /system_ext. Ứng dụng 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 phân vùng nhà cung cấp. 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 tập mẹ của tất cả APK và bỏ qua một số lượt cài đặt gói 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ị. Bạn có thể gặp khó khăn khi tách các mô-đun APK này để chuyển sang sản phẩm hoặc phân vùng nhà cung cấp. Để giải quyết tạm thời, OEM có thể đưa tất cả các mô-đun vào SSI, sau đó lọc ra các 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, việc 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à thiết lập đúng cách. Bằng cách thiết lập 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ấu hình chi tiết, hãy xác định RRO theo cách thủ công thay vì dựa vào cấu hình đượ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). OEM cũng có thể xác định 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 thuộc tính android:requiredSystemPropertyName và android:requiredSystemPropertyValue.

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

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ị). OEM có thể cố gắng làm cho phân vùng system_ext trở nên phổ biến, như mô tả trong phần Làm cho phân vùng system_ext phổ biến. 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, nhà sản xuất thiết bị gốc (OEM) có thể xác định một tệp makefile mới cho GSI OEM kế thừa tệp generic_system.mk và sử dụng tệp makefile mới. Để biết ví dụ, hãy xem phần Thực thi 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 bạn cho rằng một mô-đun không cần thiết, vui lòng gửi lỗi để cập nhật tệp generic_system.mk trong AOSP.