Hình ảnh hệ thống chia sẻ 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. Nó cũng đề xuất một quy trình dựa trên hình ảnh hệ thống chung (GSI) do AOSP sở hữu.

Lý lịch

Với Project Treble , Android nguyên khối được chia thành hai phần: phần dành riêng cho phần cứng (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 loại được cài đặt trong một phân vùng riêng: 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. 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 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ủ kiến ​​trúc Treble và duy trì khả năng tương thích ngược với các triển khai cũ của nhà cung cấp. Ví dụ: hình ảnh hệ thống chung được xây dựng từ nguồn AOSP của Android 10 có thể chạy trên mọi thiết bị tương thích Treble chạy trên Android 8 trở lên. Phiên bản Android được cung cấp trên các thiết bị tiêu dùng được sửa đổi bởi các nhà cung cấp SoC và OEM. (Xem Vòng đời của một bản phát hành Android .) Những thay đổi và tiện ích mở rộng được thực hiện cho 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 độ phức tạp tăng lên và chi phí nâng cấp hệ điều hành cao hơn. Những thay đổi và sửa đổi dành riêng cho thiết bị sẽ làm tăng thêm 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ó kiến ​​trúc rõ ràng nào cho phép các đối tác xây dựng các tiện ích mở rộng 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 xây dựng từ các nguồn khung hệ điều hành Android để tái sử dụng trên nhiều thiết bị, nhằm duy trì khả năng tương thích ngược với việc triển khai của nhà cung cấp và để giảm đáng kể độ phức tạp cũng như chi phí nâng cấp hệ điều hành Android. Để biết các bước cụ thể mà bạn cần để tạo SSI, hãy xem phần Các bước được đề xuất cho SSI dựa trên GSI và lưu ý rằng bạn không phải sử dụng cả bốn bước. Những bước bạn chọn (ví dụ: chỉ Bước 1) tùy thuộc vào việc 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à phần mở rộng OEM được đặt trong phân vùng /product mới. Các thành phần trong phân vùng /product sử dụng 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 phiên bản hệ điều hành Android mới đượ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 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 các nhà cung cấp OEM và SoC xây dựng SSI bao gồm tất cả các tính năng tùy chỉnh và 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 nhằm mục đích giúp OEM sử dụng để đạt được các mục tiêu chính sau:

  • Tái sử dụng SSI trên nhiều SKU thiết bị.
  • Cập nhật hệ thống Android với các tiện ích mở rộng mô-đun để nâng cấp hệ điều hành 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 vào phân vùng sản phẩm tương tự như ý tưởng Treble về việc 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ự VINTF ) cho phép giao tiếp giữa SSI và phân vùng sản phẩm. Lưu ý rằng đối với SSI, thuật ngữ “thành phần” mô tả tất cả cá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 phân vùng.

Phân vùng xung quanh SSI

Hình 1 hiển thị 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 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.

Partitions and interfaces around SSI block diagram

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 thuật ngữ hình ảnh và phân vùng .

  • Hình ảnh là một phần khái niệm của phần mềm có thể được cập nhật độc lập.
  • Phân vùng là một vị trí lưu trữ vật lý 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 OEM và có thể tồn tại trên nhiều thiết bị. Nó không có bất kỳ thành phần dành riêng cho phần cứng hoặc sản phẩm nào. 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 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 sẽ chứa các thành phần và tiện ích mở rộng của nhà cung cấp OEM và SoC được liên kết chặt chẽ với các thành phần AOSP. Ví dụ: thư viện khung Java OEM cung cấp API tùy chỉnh cho các ứng dụng riêng của OEM phù hợp với /system_ext hơn trong phân vùng /system . Nội dung cho cả phân vùng /system và /system_ext được xây dựng từ các nguồn Android được OEM sửa đổi.

    • Phân vùng /system_ext là tùy chọn, nhưng sẽ có ích khi sử dụng nó cho mọi tính năng và tiện ích mở rộng tùy chỉnh được kết hợp 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 bạn 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 tùy chỉnh và tiện ích mở rộng OEM cho HĐH Android. Đặt các thành phần dành riêng cho SoC vào phân vùng /vendor . Các 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 thành phần độc lập với SoC cho khách hàng OEM của họ (đó là tùy chọn đi kèm với 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ởi quyền sở hữu của nó mà được quyết định bởi mục đích của 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 được SoC cung cấp. Thông thường, nhà cung cấp SoC sở hữu hình ảnh của 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à ODM đều được hợp nhất với nhau trong phân vùng /vendor .

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

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

  • 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 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 Project Treble, 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 đượ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 lược đồ tệp cấu hình
    • VNĐK
    • 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 tương tự như VINTF. Tuy nhiên, chỉ có API VNĐK và SDK Android được thực thi cho các thiết bị chạy Android 11 (trở lên).

Kích hoạ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 phân vùng tùy chọn. (Đây là nơi dành cho các thành phần không phải AOSP có 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 coi là phần mở rộng dành riêng cho OEM cho phân vùng /system , 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 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 vào phân vùng /system_ext .

Vì hai phân vùng được liên kết chặt chẽ nên cả hai phân vùng đều được nâng cấp cùng nhau khi 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 phải 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 đó vào thư mục ./system_ext trong phân vùng /system .

Lịch sử

Đây là một số lịch sử 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ả chúng cùng một lúc là không khả thi, đặc biệt khi một số thành phần có mối liên hệ 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ới phân vùng /product , giao diện sản phẩm phải được mở rộng. Điều này thường đòi hỏi bản thân thành phần phải được tái cấu trúc rộng rãi, việc này tiêu tốn rất nhiều thời gian và công sức. Phân vùng /system_ext ban đầu là nơi lưu trữ tạm thời 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 cuối cùng 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ữ phân vùng /system càng gần AOSP càng tốt. Với SSI, phần lớn nỗ lực nâng cấp được 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 xây dựng từ các nguồn giống 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 .

Tách các thành phần khỏi /system và /system_ext vào phân vùng /product

Android 9 đã giới thiệu phân vùng /product được kết hợp 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 phải tuân theo 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. Bắt đầu từ Android 10, phân vùng /product phải được tách nhóm khỏi phân vùng /system và phải sử dụng các 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 của hệ thống, thay vì cài đặt các mô-đun sản phẩm đi kèm, như được 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 nhóm các mô-đun dành riêng cho sản phẩm làm cho /system_ext trở nên phổ biến đối với các thiết bị. (Để biết thêm chi tiết, hãy xem Tạo phân vùng /system_ext 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ó chính sách thực thi giống như phân vùng /vendor đã được tách nhóm với Project Treble.

Bắt đầu từ Android 11, giao diện gốc và giao diện 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 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 nhóm khỏi các phân vùng khác. Các 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 VNĐK (bao gồm LLNDK) từ phân vùng /system . 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 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 Java SDK cho API tùy chỉnh.

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

Suggested partitions for GSI-based SSI

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 xây dựng trực tiếp từ AOSP. Nó được sử dụng cho các thử nghiệm 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 tra tính 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 yêu cầu.

Các OEM cũng có thể sử dụng GSI để tạo ra SSI của mình. Như đã giải thích trong 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 sử 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 hóa các tùy 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 OEM xây dựng 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ọ xây dựng bằng GSI do AOSP cung cấp. Tuy nhiên, các OEM không cần phải đi đến bước cuối cùng (sử dụng GSI) cùng một lúc.

Bước 1. Kế thừa generic_system.mk cho image hệ thống của 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à được đổ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 sửa đổi bởi các OEM để OEM GSI có thể chứa các tệp độc quyền của OEM ngoài các tệp AOSP GSI. Tuy nhiên, OEM không được phép sửa đổi tệp generic_system.mk .

Inheriting `generic_system.mk` for OEM system image

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

Bước 2. Làm cho OEM GSI có cùng danh sách tệp với AOSP GSI

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

Moving added files out of the OEM GSI

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 được 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 bữa trưa 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 những khác biệt bên ngoài danh sách được phép. Điều này ngăn cản việc cần phải sửa đổi bổ sung cho OEM GSI.

Define an allowlist to reduce the list of modified files in 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. Làm cho OEM GSI có các tệp nhị phân giống như AOSP GSI

Việc xóa danh sách cho phép cho phép các 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ọ. Để xóa danh sách cho phép, OEM có thể hủy bỏ các thay đổi của họ trong OEM GSI hoặc ngược dòng các thay đổi của họ lên AOSP để AOSP GSI bao gồm các thay đổi của họ.

Make OEM GSI have the same binaries as AOSP GSI

Hình 6. Làm cho OEM GSI có các tệp nhị phân giống như AOSP GSI

Xác định SSI cho OEM

Bảo vệ phân vùng /system khi 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 tạo tệp 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ụ về Tạo tệp tạo tệp và bật đường dẫn tạo tác .

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

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

Để đảm bảo rằng phân vùng /product không được nhóm, OEM có thể đảm bảo 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 Thực thi giao diện phân vùng sản phẩm .

Làm cho phân vùng /system_ext trở nên phổ biến

Phân vùng /system_ext có thể khác nhau giữa các thiết bị vì nó có thể có các mô-đun đi kèm 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ẽ 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 khác biệt và làm cho phân vùng /system_ext trở nên phổ biến.

Phần này đưa ra các khuyến nghị để 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

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ì chúng sử dụng các API ẩn vố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 để xóa 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ế chúng. 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 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 tùy 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 . Nó có thể sử dụng các API ẩn trong phân vùng hệ thống và có thể cung cấp 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 tới sản phẩm để có 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 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ị. Việc tách các mô-đun APK này để di chuyển chúng sang sản phẩm hoặc phân vùng nhà cung cấp có thể khó khăn. Là một giải pháp tạm thời, OEM có thể làm cho SSI bao gồm tất cả các mô-đun, sau đó lọc 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, các OEM sẽ phủ lên các tài nguyên khung config_disableApkUnlessMatchedSku_skus_list và config_disableApksUnlessMatchedSku_apk_list .

Để có cài đặt chính xác hơn, hãy khai báo bộ thu phát sóng để tắt các gói không cần thiết. Bộ thu quảng bá 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 thao tác với các gói được phủ. Tuy nhiên, nó 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 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 cấu hình được tạo tự động. Để biết thông tin chi tiết, hãy xem Lớp phủ tài nguyên thời gian chạy (RRO) . OEM cũng có thể xác định các RRO có điều kiện phụ thuộc vào 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ác câu hỏi thường gặp (FAQ)

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

Nó phụ thuộc vào tính phổ biến 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 làm cho phân vùng system_ext trở nên phổ biến, như được mô tả trong Làm cho phân vùng system_ext trở nên phổ biến . Nếu một nhóm thiết bị có nhiều điểm khác biệt thì tốt hơn nên xác định nhiều SSI.

Tôi có thể sửa đổi generic_system.mk ( mainline_system.mk ) cho OEM GSI không?

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

Tôi có thể xóa các mô-đun khỏi generic_system.mk xung đột với việc triển khai của tôi không?

Không. GSI có một bộ mô-đun có thể khởi động và kiểm tra tối thiểu. 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.