Tổng quan về Bộ công cụ phát triển gốc của nhà cung cấp (đồngK)

Bộ công cụ phát triển gốc của nhà cung cấp (VNK) là một tập hợp các thư viện được sử dụng bởi các thư viện hoặc tệp nhị phân khác, trong phân vùng nhà cung cấp hoặc sản phẩm, trong thời gian chạy cho dlopen.

Tại sao lại là VNĐK?

AOSP cho phép 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 xây dựng ở 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 các thách thức sau:

  • Sự 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 hệ thống và nhà cung cấp có thể liên kết với nhau. Tuy nhiên, sự phụ thuộc từ các mô-đun của nhà cung cấp đã áp đặt những hạn chế không mong muốn đối với việc phát triển mô-đun khung.
  • Phần mở rộng cho 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 của họ, việc flash phân vùng hệ thống bằng GSI tiêu chuẩn có thể phá vỡ việc triển khai HIDL của nhà cung cấp. Để biết hướng dẫn ngăn chặn những sự cố như vậy, hãy xem phần mở rộng VNĐK .

Để giải quyết những thách thức này, Android chứa 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 riêng của VNĐK

Các tài liệu liên quan đến VNĐK sử dụng các thuật ngữ sau:
  • Các 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 sự phụ thuộc vào thời gian xây dựng.
  • Các tiến trình là các tác vụ của hệ điều hành được sinh ra từ các tệp thực thi. Các quy trình tạo ra sự phụ thuộc vào thời gian chạy.
  • Các thuật ngữ đủ điều kiện của Framework có liên quan đến phân vùng system :
    • Các 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 được chia sẻ trong /system/lib[64] .
    • Các mô-đun khung đề cập đến cả thư viện chia sẻ khung và các tệp thực thi khung.
    • Các quy trình khung là các quy trình được tạo ra từ các tệp thực thi của khung, chẳng hạn như /system/bin/app_process .
  • Các điều khoản đủ điều kiện của nhà cung cấp có liên quan đến phân vùng vendor :
    • Các 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 chia sẻ của nhà cung cấp đề cập đến các thư viện được chia sẻ trong /vendor/lib[64] .
    • Các mô-đun của nhà cung cấp đề cập đến cả các tệp thực thi của nhà cung cấp và thư viện chia sẻ của nhà cung cấp.
    • Các quy trình của nhà cung cấp là các quy trình được tạo ra từ các 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 ảnh.provider@2.4-service .

khái niệm VNĐK

Trong thế giới Android 8.0 lý tưởng trở lên, các quy trình khung không tải các thư viện chia sẻ của nhà cung cấp, tất cả các quy trình của nhà cung cấp chỉ tải các thư viện chia sẻ của nhà cung cấp (và một phần thư viện chia sẻ khung) và 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à phần cứng chất kết dính.

Một thế giới như vậy bao gồm khả năng các API công khai, ổn định từ các 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ù các API có thể thay đổi giữa các bản phát hành Android), yêu cầu một số phần của thư viện chia sẻ khung có thể truy cập được đối với 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, một số HAL quan trọng về thời gian phản hồi phải được xử lý khác nhau.

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

Thư viện chia sẻ khung dành 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. Có hai cách tiếp cận để 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 chia sẻ 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 dung lượng bộ nhớ và kích thước lưu trữ. Thư viện chia sẻ duy nhất cũng tránh được một số vấn đề tải kép. Tuy nhiên, chi phí phát triển để duy trì ABI/API ổn định là cao và việc ổn định tất cả ABI/API được xuất bởi mọi thư viện chia sẻ khung là không thực tế.
  2. Sao chép các thư viện chia sẻ khung cũ . Đi kèm với hạn chế mạnh mẽ đối với các kênh bên, được định nghĩa là tất cả cá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) chất kết dính, ổ cắm, đường ống, bộ nhớ dùng chung, tệp dùng chung và thuộc tính hệ thống. Không được có giao tiếp trừ khi giao thức liên lạc bị đóng băng và ổn định (ví dụ: HIDL thông qua hwbinder). Việc tải kép các thư viện dùng chung cũng có thể gây ra sự cố; ví dụ: nếu một đối tượng được tạo bởi thư viện mới được chuyển vào các hàm từ thư viện cũ thì có thể xảy ra lỗi do các thư viện này có thể diễn giải đối tượng theo cách khác.

Các cách tiếp cận khác nhau được sử dụng tùy thuộc vào đặc điểm của các thư viện dùng chung. Do đó, các thư viện chia sẻ khung được phân thành ba loại phụ:

  • Thư viện LL-NDKThư viện dùng chung 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 API/ABI của họ.
    • 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.solibvulkan.so ,
  • Thư viện VNĐK đủ điều kiện (VNK)các Thư viện chia sẻ khung an toàn để sao chép hai lần. Mô-đun khungMô-đun 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 chia sẻ khung chỉ có thể trở thành thư viện VNĐK đủ đ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.
    • Nó không đọc/ghi 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 cần được xem xét về mặt pháp lý.
    • Chủ sở hữu mã của nó không phản đối việc sử dụng của nhà cung cấp.
  • Thư viện chỉ dành cho khung (CHỈ FWK)các Thư viện chia sẻ khung không thuộc các danh mục được đề cập ở trên. Các thư viện này:
    • Được coi là chi tiết triển khai nội bộ khung.
    • Không được truy cập bởi các mô-đun của nhà cung cấp.
    • Có ABI/API không ổn định và không có đảm bảo về 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 chia sẻ của nhà cung cấp và được tải vào Quy trình khung . SP-HAL được cách ly bởi một không gian tên trình liên kết (kiểm soát các thư viện và ký hiệu hiển thị với các thư viện dùng chung). SP-HAL chỉ được phụ thuộc vào LL-NDKVNDK-SP .

VNĐK-SP là tập hợp con được xác định trước của các thư viện VNĐK đủ đ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 kép thư viện VNDK-SP vào các quy trình framework không gây ra vấn đề gì. Cả SP-HAL và VNDK-SP đều do Google xác định.

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

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

Thư viện VNDK-SP chỉ định vndk: { support_system_process: true } trong tệp Android.bp của họ. 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 vô hình đối 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 (Bản kết xuất)
  • libmediandk.so (Bản kết xuất)

Phiên bản VNĐK

Thư viện chia sẻ của VNDK được phiên bản:

  • Thuộc tính hệ thống ro.vndk.version được tự động thêm vào /vendor/default.prop .
  • Thư viện chia sẻ VNDK và VNDK-SP được cài đặt dưới dạng VNDK apex 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 chọn theo thuật toán dưới đây:

  • Nếu BOARD_VNDK_VERSION không bằng current thì sử dụng BOARD_VNDK_VERSION .
  • Nếu BOARD_VNDK_VERSION bằng current :
    • Nếu PLATFORM_VERSION_CODENAMEREL , 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ộ thử nghiệm nhà cung cấp Android (VTS) yêu cầu 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ụ VtsVndkFilesTestVtsVndkDependencyTest ) dựa vào thuộc tính ro.vndk.version để tải bộ dữ liệu thư viện VNDK đủ điều kiện phù hợp.