Расширения ВНДК

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

Оперативная замена

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

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

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

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

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

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

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

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

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

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

Механизм расширения ВНДК

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

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

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