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

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

Врезная замена

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

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

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

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

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

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

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