Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Phần mở rộng VNDK

Các nhà sản xuất thiết bị Android thay đổi mã nguồn của các thư viện AOSP vì nhiều lý do khác nhau. Một số nhà cung cấp thực hiện lại các chức năng trong thư viện AOSP để tăng hiệu suất trong khi các nhà cung cấp khác thêm móc mới, API mới hoặc chức năng mới vào thư viện AOSP. Phần này cung cấp các hướng dẫn để mở rộng thư viện AOSP theo cách không phá vỡ CTS / VTS.

Thay thế thả

Tất cả các thư viện được chia sẻ đã sửa đổi phải tương thích với hệ nhị phân, các thư viện thay thế cho đối tác AOSP của chúng. Tất cả người dùng AOSP hiện tại phải có thể sử dụng thư viện được chia sẻ đã sửa đổi mà không cần biên dịch lại. Yêu cầu này bao hàm những điều sau:

  • Các chức năng AOSP không được gỡ bỏ.
  • Các cấu trúc không được thay đổi nếu các cấu trúc đó được tiếp xúc với người dùng của chúng.
  • Điều kiện trước của các chức năng không được tăng cường.
  • Các hàm phải cung cấp các chức năng tương đương.
  • Điều kiện sau của các chức năng không được suy yếu.

Phân loại mô-đun mở rộng

Phân loại các mô-đun theo các chức năng mà chúng xác địnhsử dụng .

Lưu ý : Các chức năng được sử dụng ở đây thay vì API / ABI vì có thể thêm chức năng mà không cần thay đổi bất kỳ API / ABI nào.

Tùy thuộc vào các chức năng được xác định trong một mô-đun, các mô-đun có thể được phân loại thành Mô-đun DA và Mô-đun DX :

  • Mô-đun chỉ định nghĩa AOSP (DA-Mô-đun) không xác định các chức năng mới không có trong đối tác AOSP.
    • Ví dụ 1. Một thư viện AOSP nguyên vẹn chưa sửa đổi là DA-Module.
    • Ví dụ 2. Nếu một nhà cung cấp viết lại các chức năng trong libcrypto.so bằng hướng dẫn SIMD (mà không thêm các chức năng mới), thì libcrypto.so đã sửa đổi sẽ là DA-Module.
  • Mô-đun Định nghĩa-Mở rộng (DX-Mô-đun) hoặc xác định các chức năng mới hoặc không có đối tác AOSP.
    • Ví dụ 1. Nếu một nhà cung cấp thêm một hàm trợ giúp vào libjpeg.so để truy cập một số dữ liệu nội bộ, thì libjpeg.so đã sửa đổi sẽ là DX-Lib và hàm mới được thêm vào sẽ là phần mở rộng của thư viện.
    • Ví dụ 2. Nếu một nhà cung cấp xác định một thư viện không phải AOSP có tên libfoo.so , thì libfoo.so sẽ là một DX-Lib.

Tùy thuộc vào các chức năng được sử dụng bởi một mô-đun, các mô-đun có thể được phân loại thành Mô-đun UA và Mô-đun UX .

  • Chỉ sử dụng Mô-đun AOSP (Mô-đun UA) chỉ sử dụng các chức năng AOSP trong việc triển khai của chúng. Họ không dựa vào bất kỳ phần mở rộng không phải AOSP nào.
    • Ví dụ 1. Một thư viện AOSP nguyên vẹn chưa sửa đổi là một mô-đun UA.
    • Ví dụ 2. Nếu một thư viện được chia sẻ đã sửa đổi libjpeg.so chỉ dựa trên các API AOSP khác, thì nó sẽ là một Mô-đun UA.
  • Mô-đun Sử dụng-Mở rộng (Mô-đun UX) dựa vào một số chức năng không phải AOSP trong quá trình triển khai của chúng.
    • Ví dụ 1. Nếu một libjpeg.so được sửa đổi dựa trên một thư viện không phải AOSP khác có tên libjpeg_turbo2.so , thì libjpeg.so đã sửa đổi sẽ là một UX-Module.
    • Ví dụ 2. Nếu một nhà cung cấp thêm một chức năng mới vào libexif.so đã sửa đổi của họ và libjpeg.so đã sửa đổi của họ sử dụng chức năng mới được thêm vào từ libexif.so , thì libjpeg.so đã sửa đổi của họ sẽ là một UX-Module.

Các định nghĩa và cách sử dụng độc lập với nhau:

Các chức năng đã sử dụng
Chỉ AOSP (UA) Mở rộng (UX)
Chức năng xác định Chỉ AOSP (DA) DAUA DAUX
Mở rộng (DX) DXUA DXUX

Cơ chế gia hạn VNDK

Mô-đun nhà cung cấp dựa trên các chức năng mở rộng sẽ không hoạt động vì thư viện AOSP có cùng tên không có chức năng mở rộng. Nếu mô-đun của nhà cung cấp phụ thuộc trực tiếp hoặc gián tiếp vào các chức năng mở rộng, thì nhà cung cấp nên sao chép các thư viện dùng chung DAUX, DXUA và DXUX vào phân vùng của nhà cung cấp (các quy trình của nhà cung cấp luôn tìm kiếm các thư viện được chia sẻ trong phân vùng của nhà cung cấp trước). Tuy nhiên, các thư viện LL-NDK không được sao chép, do đó, các mô-đun của nhà cung cấp không được dựa vào các chức năng mở rộng được xác định bởi các thư viện LL-NDK đã sửa đổi.

Thư viện chia sẻ DAUA có thể vẫn còn trên phân vùng hệ thống nếu thư viện AOSP tương ứng có thể cung cấp cùng chức năng và mô-đun của nhà cung cấp tiếp tục hoạt động khi phân vùng hệ thống bị Hình ảnh Hệ thống Chung (GSI) ghi đè.

Thay thế Drop-in rất quan trọng vì các thư viện VNDK chưa được sửa đổi trong GSI sẽ liên kết với các thư viện được chia sẻ đã sửa đổi khi xung đột tên. Nếu các thư viện AOSP được sửa đổi theo cách không tương thích API / ABI, thì các thư viện AOSP trong GSI có thể không liên kết hoặc dẫn đến các hành vi không xác định.