Tổng quan về Bộ công cụ phát triển gốc dành cho nhà cung cấp (VNDK)

Vendor Native Development Kit (VNDK) là một nhóm thư viện được các thư viện hoặc tệp nhị phân khác sử dụng trong phân vùng nhà cung cấp hoặc sản phẩm, trong thời gian chạy cho dlopen.

Ngừng sử dụng

NDK của nhà cung cấp được ra mắt trong Android 8.0 để cung cấp các API giữa khung và mã của nhà cung cấp. Mặc dù VNDK đã được sử dụng thành công trong nhiều năm, nhưng vẫn có một số hạn chế:

• Dung lượng lưu trữ
• Một gói APEX VNDK duy nhất sẽ đóng gói tất cả các thư viện VNDK, bất kể chúng có được dùng trên thiết bị hay không.
• GSI chứa nhiều phiên bản của VNDK APEX để hỗ trợ nhiều phiên bản của hình ảnh nhà cung cấp.
• Khả năng cập nhật
• Khó cập nhật riêng các APEX VNDK với bản cập nhật nền tảng.
• Hình ảnh nhà cung cấp thường được cập nhật qua mạng (OTA), làm giảm lợi ích của việc đóng gói VNDK trong hình ảnh hệ thống.

Dựa trên những vấn đề này, chúng tôi quyết định ngừng sử dụng VNDK kể từ Android 15.

Thông tin chi tiết về việc ngừng sử dụng VNDK

Tất cả các thư viện VNDK đều được đóng gói vào VNDK APEX và được cài đặt trong hình ảnh hệ thống (-ext). Khi VNDK không được dùng nữa, các thư viện VNDK trước đây sẽ được cài đặt trong hình ảnh nhà cung cấp (hoặc sản phẩm), giống như các thư viện khác do nhà cung cấp cung cấp. Các tính năng này sẽ bị xoá cùng với việc ngừng sử dụng VNDK:

• VNDK APEX cho Android 15
• Các thuộc tính hệ thống cho biết phiên bản VNDK mục tiêu sẽ bị xoá nếu các phân vùng của nhà cung cấp hoặc sản phẩm được tạo cho Android 15:
  • ro.vndk.version
  • ro.product.vndk.version
• Không có VNDK nên bạn sẽ không thể sử dụng các hoạt động tối ưu hoá VNDK:
  • TARGET_VNDK_USING_CORE_VARIANT cho thiết bị Android Go
  • use_vndk_as_stable cho APEX của nhà cung cấp
• Ảnh chụp nhanh nhà cung cấp, phụ thuộc nhiều vào VNDK

Các trường hợp ngoại lệ đối với việc ngừng cung cấp

Các tính năng này sẽ không thay đổi khi VNDK không được dùng nữa:

• VNDK APEX có VNDK phiên bản 14 trở xuống, cần thiết để hỗ trợ các hình ảnh hiện có của nhà cung cấp.
• LL-NDK không thuộc VNDK.

Tại sao lại là VNDK?

AOSP cho phép chỉ cập nhật khung, trong đó phân vùng hệ thống có thể được nâng cấp lên phiên bản khung mới nhất trong khi phân vùng nhà cung cấp không thay đổi. Mặc dù được tạo vào những thời điểm khác nhau, nhưng các tệp nhị phân trong mỗi phân vùng phải có khả năng hoạt động với nhau.

Các bản cập nhật chỉ dành cho khung bao gồm những thách thức sau:

• Mối quan hệ phụ thuộc giữa các mô-đun khung và mô-đun nhà cung cấp. Trước Android 8.0, các mô-đun trong phân vùng nhà cung cấp và hệ thống có thể liên kết với nhau. Tuy nhiên, các phần phụ thuộc từ mô-đun của nhà cung cấp đã áp đặt những hạn chế không mong muốn đối với quá trình phát triển mô-đun khung.
• Tiện ích cho các thư viện AOSP. Android yêu cầu tất cả các thiết bị Android phải vượt qua CTS khi phân vùng hệ thống được thay thế bằng Hình ảnh hệ thống chung (GSI) tiêu chuẩn. Tuy nhiên, khi các nhà cung cấp mở rộng thư viện AOSP để tăng hiệu suất hoặc thêm các chức năng bổ sung cho việc triển khai HIDL, việc flash phân vùng hệ thống bằng GSI tiêu chuẩn có thể làm hỏng việc triển khai HIDL của nhà cung cấp. Để biết các nguyên tắc ngăn chặn những trường hợp như vậy, hãy xem phần Tiện ích VNDK.

Để giải quyết những thách thức này, Android có một số tính năng như VNDK (được mô tả trong phần này), HIDL, hwbinder, lớp phủ cây thiết bị và lớp phủ sepolicy.

Điều khoản dành riêng cho VNDK

Các tài liệu liên quan đến VNDK sử dụng thuật ngữ sau:

• Mô-đun đề cập đến thư viện dùng chung hoặc tệp thực thi. Các mô-đun tạo phần phụ thuộc trong thời gian xây dựng.
• Quy trình là các tác vụ của hệ điều hành được tạo từ các tệp thực thi. Các quy trình tạo phần phụ thuộc trong thời gian chạy.
• Các điều khoản đủ điều kiện theo khung có liên quan đến phân vùng system:
• Tệp thực thi khung đề cập đến các tệp thực thi trong /system/bin hoặc /system/xbin.
• Thư viện chia sẻ khung đề cập đến các thư viện chia sẻ trong /system/lib[64].
• Mô-đun khung đề cập đến cả thư viện dùng chung của khung và tệp thực thi của khung.
• Quy trình khung là các quy trình được tạo từ các tệp thực thi khung, chẳng hạn như /system/bin/app_process.
• Các điều khoản đủ tiêu chuẩn của nhà cung cấp có liên quan đến các phân vùng vendor:
• Tệp thực thi của nhà cung cấp đề cập đến các tệp thực thi trong /vendor/bin
• Thư viện dùng chung của nhà cung cấp đề cập đến các thư viện dùng chung trong /vendor/lib[64].
• Các mô-đun của nhà cung cấp đề cập đến cả tệp thực thi của nhà cung cấp và thư viện dùng chung của nhà cung cấp.
• Quy trình của nhà cung cấp là các quy trình được tạo ra từ Vendor Executables (Tệp thực thi của nhà cung cấp), chẳng hạn như /vendor/bin/android.hardware.camera.provider@2.4-service.

Lưu ý: Hình ảnh hệ thống chung (GSI) là hình ảnh hệ thống Android tiêu chuẩn được tạo từ các nhánh tương ứng (tương tự như nhánh phát hành nhưng có một số bản sửa lỗi hoặc một số khái quát hoá) và do Google phát hành.

Các khái niệm về VNDK

Trong thế giới lý tưởng của Android 8.0 trở lên, các quy trình khung không tải thư viện dùng chung của nhà cung cấp, tất cả các quy trình của nhà cung cấp chỉ tải thư viện dùng chung của nhà cung cấp (và một phần thư viện dùng chung của khung), đồng thời hoạt động giao tiếp giữa các quy trình khung và quy trình của nhà cung cấp được điều chỉnh bằng HIDL và trình liên kết phần cứng.

Một thế giới như vậy bao gồm cả khả năng các API công khai, ổn định từ các thư viện dùng chung của khung có thể không đủ cho nhà phát triển mô-đun của nhà cung cấp (mặc dù các API có thể thay đổi giữa các bản phát hành Android), yêu cầu một phần của các thư viện dùng chung của khung có thể truy cập được vào các quy trình của nhà cung cấp. Ngoài ra, vì các yêu cầu về hiệu suất có thể dẫn đến những thoả hiệp, nên một số HAL quan trọng về thời gian phản hồi phải được xử lý khác.

Các phần sau đây trình bày chi tiết cách VNDK xử lý các thư viện dùng chung của khung cho nhà cung cấp và HAL cùng quy trình (SP-HAL).

Thư viện chia sẻ khung cho nhà cung cấp

Phần này mô tả các tiêu chí để phân loại các thư viện dùng chung mà các quy trình của nhà cung cấp có thể truy cập. Có 2 phương pháp để hỗ trợ các mô-đun của nhà cung cấp trên nhiều bản phát hành Android:

1. Ổn định ABI/API của các thư viện dùng chung trong khung. Các mô-đun khung mới và mô-đun nhà cung cấp cũ có thể sử dụng cùng một thư viện dùng chung để giảm mức sử dụng bộ nhớ và kích thước bộ nhớ. Một thư viện dùng chung duy nhất cũng giúp tránh được một số vấn đề về việc tải hai lần. Tuy nhiên, chi phí phát triển để duy trì các ABI/API ổn định là rất cao và việc ổn định tất cả các ABI/API do mọi thư viện dùng chung của khung xuất là điều không thực tế.
2. Sao chép các thư viện dùng chung của khung cũ. Đi kèm với quy định hạn chế nghiêm ngặt đối với các kênh phụ, được xác định là tất cả các cơ chế giao tiếp giữa các mô-đun khung và mô-đun của nhà cung cấp, bao gồm (nhưng không giới hạn ở) liên kết, ổ cắm, ống dẫn, bộ nhớ dùng chung, tệp dùng chung và thuộc tính hệ thống. Không được có hoạt động giao tiếp trừ phi giao thức giao tiếp được cố định và ổn định (ví dụ: HIDL thông qua hwbinder). Việc tải thư viện dùng chung hai lần cũng có thể gây ra vấn đề; ví dụ: nếu một đối tượng do thư viện mới tạo được truyền vào các hàm từ thư viện cũ, thì có thể xảy ra lỗi vì các thư viện này có thể diễn giải đối tượng theo cách khác.

Các phương pháp khác nhau được sử dụng tuỳ thuộc vào đặc điểm của các thư viện dùng chung. Do đó, các thư viện dùng chung của khung được phân loại thành 3 danh mục phụ:

• Thư viện LL-NDK là Thư viện dùng chung của khung được biết là ổn định. Các nhà phát triển của họ cam kết duy trì tính ổn định của API/ABI.
  • LL-NDK bao gồm các thư viện sau: libEGL.so, libGLESv1_CM.so, libGLESv2.so, libGLESv3.so, libandroid_net.so, libc.so, libdl.so, liblog.so, libm.so, libnativewindow.so, libneuralnetworks.so, libsync.so, libvndksupport.so và libvulkan.so,
• Thư viện VNDK đủ điều kiện (VNDK) là Thư viện dùng chung của khung và có thể sao chép hai lần mà không gây ra vấn đề. Các mô-đun khung và Các mô-đun của nhà cung cấp có thể liên kết với các bản sao của riêng chúng. Thư viện dùng chung của khung chỉ có thể trở thành thư viện VNDK đủ điều kiện nếu đáp ứng các tiêu chí sau:
  • Nó không gửi/nhận IPC đến/từ khung.
  • Nó không liên quan đến máy ảo ART.
  • Công cụ này không đọc/ghi các tệp/phân vùng có định dạng tệp không ổn định.
  • Nó không có giấy phép phần mềm đặc biệt yêu cầu đánh giá pháp lý.
  • Chủ sở hữu mã này không phản đối việc sử dụng của nhà cung cấp.
• Thư viện chỉ dành cho khung (FWK-ONLY) là Thư viện dùng chung của khung không thuộc các danh mục nêu trên. Các thư viện này:
  • Được coi là thông tin chi tiết về việc triển khai nội bộ của khung.
  • Không được các mô-đun nhà cung cấp truy cập.
  • Có ABI/API không ổn định và không đảm bảo khả năng tương thích API/ABI.
  • Không được sao chép.

HAL cùng quy trình (SP-HAL)

HAL cùng quy trình (SP-HAL) là một nhóm HAL được xác định trước, được triển khai dưới dạng Thư viện dùng chung của nhà cung cấp và được tải vào Quy trình khung. SP-HAL được cách ly bằng một không gian tên trình liên kết (kiểm soát các thư viện và biểu tượng mà các thư viện dùng chung có thể nhìn thấy). SP-HAL chỉ được phụ thuộc vào LL-NDK và VNDK-SP.

VNDK-SP là một tập hợp con được xác định trước của các thư viện VNDK đủ điều kiện. Các thư viện VNDK-SP được xem xét kỹ lưỡng để đảm bảo việc tải các thư viện VNDK-SP hai lần vào các quy trình của khung không gây ra vấn đề. Cả SP-HAL và VNDK-SP đều do Google xác định.

Các thư viện sau đây là SP-HAL được phê duyệt:

• libGLESv1_CM_${driver}.so
• libGLESv2_${driver}.so
• libGLESv3_${driver}.so
• libEGL_${driver}.so
• vulkan.${driver}.so
• [e-mail]
• [e-mail]

Các thư viện VNDK-SP chỉ định vndk: { support_system_process: true } trong tệp Android.bp. Nếu vndk: {private:true} cũng được chỉ định, thì các thư viện này được gọi là VNDK-SP-Private và không hiển thị với SP-HAL.

Sau đây là các thư viện chỉ dành cho khung có ngoại lệ RS (FWK-ONLY-RS):

• libft2.so (RenderScript)
• libmediandk.so (RenderScript)

Thận trọng: Kể từ Android 12, API RenderScript sẽ không được dùng nữa. Các API này sẽ tiếp tục hoạt động, nhưng nhà sản xuất thiết bị và thành phần dự kiến sẽ ngừng cung cấp dịch vụ hỗ trợ tăng tốc phần cứng theo thời gian. Để khai thác tối đa tính năng tăng tốc GPU, AOSP khuyên bạn nên Di chuyển khỏi RenderScript.

Phiên bản VNDK

Thư viện dùng chung VNDK được lập phiên bản:

• Thuộc tính hệ thống ro.vndk.version sẽ tự động được thêm vào /vendor/default.prop.
• Các thư viện dùng chung VNDK và VNDK-SP được cài đặt dưới dạng đỉnh VNDK com.android.vndk.v${ro.vndk.version} và được gắn vào /apex/com.android.vndk.v${ro.vndk.version}.

Giá trị của ro.vndk.version được thuật toán chọn như sau:

• Nếu BOARD_VNDK_VERSION không bằng current, hãy dùng BOARD_VNDK_VERSION.
• Nếu BOARD_VNDK_VERSION bằng current:
• Nếu PLATFORM_VERSION_CODENAME là REL, hãy sử dụng PLATFORM_SDK_VERSION (ví dụ: 28).
• Nếu không, hãy sử dụng PLATFORM_VERSION_CODENAME (ví dụ: P).

Bộ thử nghiệm của nhà cung cấp (VTS)

Bộ kiểm thử của nhà cung cấp Android (VTS) bắt buộc phải có thuộc tính ro.vndk.version không trống. Cả thiết bị mới ra mắt và thiết bị nâng cấp đều phải xác định ro.vndk.version. Một số trường hợp kiểm thử VNDK (ví dụ: VtsVndkFilesTest và VtsVndkDependencyTest) dựa vào thuộc tính ro.vndk.version để tải các tập dữ liệu thư viện VNDK đủ điều kiện phù hợp.