Расширения VNDK

Производители устройств Android меняют исходный код библиотек AOSP по разным причинам. Некоторые поставщики повторно реализуют функции в библиотеках AOSP для повышения производительности, в то время как другие поставщики добавляют новые перехватчики, новые API-интерфейсы или новые функции в библиотеки AOSP. В этом разделе приведены рекомендации по расширению библиотек AOSP таким образом, чтобы не нарушать работу CTS / VTS.

Прямая замена

Все модифицированные разделяемые библиотеки должны быть двоично-совместимыми , заменяющими их аналогами AOSP. Все существующие пользователи AOSP должны иметь возможность использовать измененную общую библиотеку без перекомпиляции. Это требование подразумевает следующее:

  • Функции AOSP удалять нельзя.
  • Структуры не должны изменяться, если такие структуры открыты для их пользователей.
  • Предварительное условие функций не должно быть усилено.
  • Функции должны обеспечивать эквивалентные функциональные возможности.
  • Пост-состояние функций не должно ослабляться.

Расширенные классификации модулей

Классифицируйте модули по функциям, которые они определяют и используют .

Примечание: Функциональность используется здесь вместо API / ABI , потому что можно добавить функциональность без изменения API / ABI.

В зависимости от функций, определенных в модуле, модули можно разделить на DA-Module и DX-Module :

  • Модули только для определения AOSP (DA-Module) не определяют новые функции, которых не было в аналоге AOSP.
    • Пример 1. Неповрежденная немодифицированная библиотека AOSP - это DA-модуль.
    • Пример 2. Если поставщик переписывает функции в libcrypto.so с инструкциями SIMD (без добавления новых функций), то измененный libcrypto.so будет DA-модулем.
  • Модули определения-расширения (DX-Module) либо определяют новые функции, либо не имеют аналога AOSP.
    • Пример 1. Если поставщик добавляет вспомогательную функцию к libjpeg.so для доступа к некоторым внутренним данным, то измененный libjpeg.so будет DX-Lib, а вновь добавленная функция будет расширенной частью библиотеки.
    • Пример 2. Если поставщик определяет не-AOSP библиотеку с именем libfoo.so , то libfoo.so будет DX-Lib.

В зависимости от функций, используемых модулем, модули можно разделить на UA-Module и UX-Module .

  • Модули using-only-AOSP (UA-Module) используют только функции AOSP в своих реализациях. Они не полагаются ни на какие расширения, не относящиеся к AOSP.
    • Пример 1. Неповрежденная немодифицированная библиотека AOSP - это UA-модуль.
    • Пример 2. Если модифицированная разделяемая библиотека libjpeg.so полагается только на другие API AOSP, то это будет UA-модуль.
  • Модули Using-Extension (UX-Module) в своей реализации полагаются на некоторые функции, не относящиеся к AOSP.
    • Пример 1. Если модифицированный libjpeg.so опирается на другую библиотеку, libjpeg_turbo2.so AOSP, с именем libjpeg_turbo2.so , то измененный libjpeg.so будет UX-модулем.
    • Пример 2. Если поставщик добавляет новую функцию к своему измененному libexif.so а его модифицированный libjpeg.so использует недавно добавленную функцию из libexif.so , то его измененный libjpeg.so будет UX-модулем.

Определения и употребления независимы друг от друга:

Используемые функции
Только AOSP (UA) Расширенный (UX)
Определенные функции Только AOSP (DA) DAUA DAUX
Расширенный (DX) DXUA DXUX

Механизм расширения VNDK

Модули поставщика, которые полагаются на расширенные функции, не будут работать, потому что библиотека AOSP с тем же именем не имеет расширенных функций. Если модули поставщика прямо или косвенно зависят от расширенных функций, поставщики должны скопировать разделяемые библиотеки DAUX, DXUA и DXUX в раздел поставщика (процессы поставщика всегда сначала ищут разделяемые библиотеки в разделе поставщика). Однако библиотеки LL-NDK нельзя копировать, поэтому модули поставщика не должны полагаться на расширенные функции, определенные модифицированными библиотеками LL-NDK.

Совместно используемые библиотеки DAUA могут оставаться в системном разделе, если соответствующая библиотека AOSP может обеспечивать ту же функциональность, и модули поставщика продолжают работать, когда системный раздел перезаписывается общим образом системы (GSI).

Прямая замена важна, потому что немодифицированные библиотеки VNDK в GSI будут связываться с измененными разделяемыми библиотеками при конфликте имен. Если библиотеки AOSP изменяются несовместимым с API / ABI способом, библиотеки AOSP в GSI могут не связываться или приводить к неопределенному поведению.