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

Производители устройств 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-модулем.

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

Используемые функции
Только АОСП (Украина) Расширенный (UX)
Определенные функциональные возможности Только АОСП (ДА) ДАУА DAUX
Расширенный (DX) DXUA DXUX

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

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

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

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