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