Google is committed to advancing racial equity for Black communities. See how.
Эта страница переведена с помощью Cloud Translation API.
Switch to English

Расширения 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-модуль) либо определяют новые функции, либо не имеют аналога 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 могут не связываться или приводить к неопределенному поведению.