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

Bộ phát triển gốc của nhà cung cấp (VNDK) là một nhóm thư viện mà 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 giới thiệu trong Android 8.0 để cung cấp 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ế:

• Bộ nhớ
• Một VNDK APEX duy nhất sẽ đóng gói tất cả thư viện VNDK, cho dù các thư viện đó có được sử dụng trên thiết bị hay không.
• GSI chứa nhiều phiên bản VNDK APEX để hỗ trợ nhiều phiên bản hình ảnh của nhà cung cấp.
• Khả năng cập nhật
• Rất khó để cập nhật các APEX của VNDK một cách riêng biệt với việc cập nhật nền tảng.
• Hình ảnh của nhà cung cấp thường xuyên được cập nhật qua mạng không dây (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ả 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 ngừng hoạt động, 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 cũng sẽ ngừng hoạt động cùng với việc VNDK ngừng hoạt động:

• VNDK APEX dành 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 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ó tính năng tối ưu hoá VNDK vì không có 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 của nhà cung cấp, phụ thuộc nhiều vào VNDK

Trường hợp ngoại lệ đối với việc ngừng sử dụng

Các tính năng này sẽ không thay đổi khi VNDK ngừng hoạt động:

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

Tại sao nên dùng VNDK?

AOSP cho phép các bản cập nhật chỉ dành cho 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 của nhà cung cấp không thay đổi. Mặc dù được tạo tại các 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ó thể hoạt động với nhau.

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

• Phần 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 các quy định hạn chế không mong muốn đối với việc phát triển mô-đun khung.
• Các tiện ích cho thư viện AOSP. Android yêu cầu tất cả thiết bị Android đều 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 quá trình triển khai HIDL, việc cài đặt ROM cho phân vùng hệ thống bằng GSI tiêu chuẩn có thể làm hỏng quá trình triển khai HIDL của nhà cung cấp. Để biết hướng dẫn về cách ngăn chặn các sự cố đó, hãy xem các 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.

Các điều khoản dành riêng cho VNDK

Các tài liệu liên quan đến VNDK sử dụng các 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 ra các phần phụ thuộc tại 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 thời gian chạy.
• Các thuật ngữ đủ điều kiện Khung có liên quan đến phân vùng system:
• Tệp thực thi của khung đề cập đến các tệp thực thi trong /system/bin hoặc /system/xbin.
• Thư viện dùng chung của khung đề cập đến các thư viện dùng chung trong /system/lib[64].
• Mô-đun khung tham chiếu đến cả thư viện dùng chung của khung và tệp thực thi 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 thuật ngữ đủ tiêu chuẩn của Nhà cung cấp 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 thư viện dùng chung trong /vendor/lib[64].
• 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 từ 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ố bản tổng quát) và do Google phát hành.

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

Trong một thế giới Android 8.0 trở lên lý tưởng, 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ả 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) và 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 quản lý bởi HIDL và trình liên kết phần cứng.

Trong một thế giới như vậy, các API công khai, ổn định từ thư viện chia sẻ khung có thể không đủ cho các nhà phát triển mô-đun của nhà cung cấp (mặc dù API có thể thay đổi giữa các bản phát hành Android), đòi hỏi một số phần của thư viện chia sẻ khung phải có thể truy cập được cho 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 sự thỏa hiệp, nên một số HAL quan trọng về thời gian phản hồi phải được xử lý theo cách khác.

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

Thư viện dùng chung khung cho nhà cung cấp

Phần này mô tả các tiêu chí để phân loại thư viện dùng chung mà các quy trình của nhà cung cấp có thể truy cập. Có hai 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 thư viện dùng chung khung. Các mô-đun khung mới và mô-đun của 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 đề 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à không thực tế khi cố gắng ổn định tất cả ABI/API do mọi thư viện dùng chung khung xuất.
2. Sao chép thư viện dùng chung của khung cũ. Đi kèm với quy định hạn chế mạnh mẽ đối với các kênh bên, được xác định là tất cả cơ chế để giao tiếp giữa các mô-đun khung và mô-đun nhà cung cấp, bao gồm (nhưng không giới hạn ở) liên kết, ổ cắm, ống, 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 bị treo và ổn định (ví dụ: HIDL qua hwbinder). Việc tải hai lần thư viện dùng chung 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ì lỗi có thể xảy ra vì các thư viện này có thể diễn giải đối tượng theo cách khác nhau.

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

• Thư viện LL-NDK là Thư viện chia sẻ khung được biết là ổn định. Nhà phát triển của các công cụ này 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 chia sẻ khung an toàn cho việc sao chép hai lần. Mô-đun khung và Mô-đun nhà cung cấp có thể liên kết với các bản sao của riêng chúng. Một thư viện dùng chung khung chỉ có thể trở thành một thư viện VNDK đủ điều kiện nếu đáp ứng các tiêu chí sau:
  • Lớp này không gửi/nhận IPC đến/từ khung.
  • Không liên quan đến máy ảo ART.
  • Ứng dụng này không đọc/ghi tệp/phân vùng có định dạng tệp không ổn định.
  • Ứng dụng không có giấy phép phần mềm đặc biệt yêu cầu xem xét pháp lý.
  • Chủ sở hữu mã không phản đối việc nhà cung cấp sử dụng.
• Thư viện chỉ khung (FWK-ONLY) là Thư viện dùng chung 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 của 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 tập hợp các 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 tách biệt 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 hiển thị cho các thư viện dùng chung). SP-HAL chỉ 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. Thư viện VNDK-SP được xem xét kỹ lưỡng để đảm bảo việc tải hai lần thư viện VNDK-SP vào các quy trình khung không gây ra sự cố. 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]

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à chúng sẽ không hiển thị với SP-HALS.

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

• libft2.so (Tập lệnh RenderScript)
• libmediandk.so (Renderscript)

Thận trọng: Kể từ Android 12, các API RenderScript sẽ không còn đượ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 sẽ từng bước ngừng cung cấp dịch vụ hỗ trợ tăng tốc phần cứng. Để khai thác tối đa tính năng tăng tốc GPU, AOSP đề xuất bạn Di chuyển từ RenderScript.

Phiên bản VNDK

Thư viện dùng chung VNDK được phân chia theo 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.
• Thư viện dùng chung VNDK và VNDK-SP được cài đặt dưới dạng com.android.vndk.v${ro.vndk.version} đỉnh VNDK và được gắn vào /apex/com.android.vndk.v${ro.vndk.version}.

Thuật toán dưới đây chọn giá trị của ro.vndk.version:

• Nếu BOARD_VNDK_VERSION không bằng current, hãy sử 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 nhà cung cấp (VTS)

Bộ kiểm thử nhà cung cấp Android (VTS) yêu cầu thuộc tính ro.vndk.version không được để 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 phù hợp của thư viện VNDK đủ điều kiện.