La herramienta de definición VNDK ayuda a los proveedores a migrar su árbol fuente a un Entorno de Android 8.0 Esta herramienta analiza archivos binarios del sistema y del proveedor imágenes, resuelve las dependencias. Según el gráfico de dependencias del módulo, el también puede detectar infracciones a conceptos del VNDK y proporcionar estadísticas/sugerencias para mover módulos entre particiones. Si se trata de un sistema genérico Si se especifica la imagen (GSI), la herramienta de definición VNDK puede comparar con la GSI y determinar las bibliotecas extendidas.
Esta sección abarca tres comandos que se usan con frecuencia para la definición de VNDK. herramienta:
vndk
Compute VNDK_SP_LIBRARIES, VNDK_SP_EXT_LIBRARIES y EXTRA_VENDOR_LIBRARIES para la solución alternativa del sistema de compilación en Android 8.0 y mayores.check-dep
Comprueba las dependencias del módulo con incumplimientos en módulos de proveedores a bibliotecas compartidas de framework no aptas.deps
Imprime las dependencias entre las bibliotecas compartidas y ejecutables.
Para obtener más detalles sobre el uso de comandos avanzados, consulta README.md en el repositorio de la herramienta de definición VNDK.
Vndk
El subcomando vndk
carga las bibliotecas compartidas y los ejecutables.
de la partición del sistema y las particiones del proveedor, resuelve
las dependencias para determinar las bibliotecas que se deben copiar
/system/lib[64]/vndk-sp-${VER}
y /vendor/lib[64]
.
Las opciones para el subcomando vndk
incluyen las siguientes:
Opción | Descripción |
---|---|
--system |
Apunta a un directorio que contenga los archivos que se encuentran en el sistema. por cada partición. |
--vendor |
Apuntar a un directorio que contenga los archivos que residen en un proveedor por cada partición. |
--aosp-system |
Diríjase a un directorio que contenga los archivos que residen en el directorio genérico: imagen del sistema (GSI). |
--load-extra-deps |
Apunta a un archivo que describa las dependencias implícitas, como
dlopen() |
Por ejemplo, para calcular los conjuntos de bibliotecas de VNDK, ejecuta el siguiente comando:
Subcomando vndk
:
./vndk_definition_tool.py vndk \
--system ${ANDROID_PRODUCT_OUT}/system \
--vendor ${ANDROID_PRODUCT_OUT}/vendor \
--aosp-system ${ANDROID_PRODUCT_OUT}/../generic_arm64_ab/system\
--load-extra-deps dlopen.dep
Especifica dependencias adicionales con un formato de archivo simple. Cada línea representa un con el archivo antes de los dos puntos, según el archivo después de dos puntos. Por ejemplo:
/system/lib/libart.so: /system/lib/libart-compiler.so
Esta línea le indica a la herramienta de definición VNDK que libart.so
depende de libart-compiler.so
.
Destino de instalación
La herramienta de definición VNDK enumera bibliotecas y directorios de instalación correspondientes. para las siguientes categorías:
Categoría | Directorio |
---|---|
vndk_sp | Se debe instalar en /system/lib[64]/vndk-sp-${VER} |
vndk_sp_ext | Se debe instalar en /vendor/lib[64]/vndk-sp |
bibliotecas_adicionales | Se debe instalar en /vendor/lib[64] |
Compila plantillas de sistemas
Después de recopilar los resultados de la herramienta de definición VNDK, el proveedor puede crear un
Android.mk
y completa VNDK_SP_LIBRARIES
,
VNDK_SP_EXT_LIBRARIES
y EXTRA_VENDOR_LIBRARIES
para
automatizar el proceso de copiar bibliotecas a la instalación designada
destino.
ifneq ($(filter $(YOUR_DEVICE_NAME),$(TARGET_DEVICE)),) VNDK_SP_LIBRARIES := ##_VNDK_SP_## VNDK_SP_EXT_LIBRARIES := ##_VNDK_SP_EXT_## EXTRA_VENDOR_LIBRARIES := ##_EXTRA_VENDOR_LIBS_## #------------------------------------------------------------------------------- # VNDK Modules #------------------------------------------------------------------------------- LOCAL_PATH := $(call my-dir) define define-vndk-lib include $$(CLEAR_VARS) LOCAL_MODULE := $1.$2 LOCAL_MODULE_CLASS := SHARED_LIBRARIES LOCAL_PREBUILT_MODULE_FILE := $$(TARGET_OUT_INTERMEDIATE_LIBRARIES)/$1.so LOCAL_STRIP_MODULE := false LOCAL_MULTILIB := first LOCAL_MODULE_TAGS := optional LOCAL_INSTALLED_MODULE_STEM := $1.so LOCAL_MODULE_SUFFIX := .so LOCAL_MODULE_RELATIVE_PATH := $3 LOCAL_VENDOR_MODULE := $4 include $$(BUILD_PREBUILT) ifneq ($$(TARGET_2ND_ARCH),) ifneq ($$(TARGET_TRANSLATE_2ND_ARCH),true) include $$(CLEAR_VARS) LOCAL_MODULE := $1.$2 LOCAL_MODULE_CLASS := SHARED_LIBRARIES LOCAL_PREBUILT_MODULE_FILE := $$($$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_INTERMEDIATE_LIBRARIES)/$1.so LOCAL_STRIP_MODULE := false LOCAL_MULTILIB := 32 LOCAL_MODULE_TAGS := optional LOCAL_INSTALLED_MODULE_STEM := $1.so LOCAL_MODULE_SUFFIX := .so LOCAL_MODULE_RELATIVE_PATH := $3 LOCAL_VENDOR_MODULE := $4 include $$(BUILD_PREBUILT) endif # TARGET_TRANSLATE_2ND_ARCH is not true endif # TARGET_2ND_ARCH is not empty endef $(foreach lib,$(VNDK_SP_LIBRARIES),\ $(eval $(call define-vndk-lib,$(lib),vndk-sp-gen,vndk-sp,))) $(foreach lib,$(VNDK_SP_EXT_LIBRARIES),\ $(eval $(call define-vndk-lib,$(lib),vndk-sp-ext-gen,vndk-sp,true))) $(foreach lib,$(EXTRA_VENDOR_LIBRARIES),\ $(eval $(call define-vndk-lib,$(lib),vndk-ext-gen,,true))) #------------------------------------------------------------------------------- # Phony Package #------------------------------------------------------------------------------- include $(CLEAR_VARS) LOCAL_MODULE := $(YOUR_DEVICE_NAME)-vndk LOCAL_MODULE_TAGS := optional LOCAL_REQUIRED_MODULES := \ $(addsuffix .vndk-sp-gen,$(VNDK_SP_LIBRARIES)) \ $(addsuffix .vndk-sp-ext-gen,$(VNDK_SP_EXT_LIBRARIES)) \ $(addsuffix .vndk-ext-gen,$(EXTRA_VENDOR_LIBRARIES)) include $(BUILD_PHONY_PACKAGE) endif # ifneq ($(filter $(YOUR_DEVICE_NAME),$(TARGET_DEVICE)),)
check-dep
El subcomando check-dep
analiza los módulos de proveedores y comprueba su
dependencias. Si detecta incumplimientos, se imprime la persona dependiente infractora.
usos de bibliotecas y símbolos:
./vndk_definition_tool.py check-dep \
--system ${ANDROID_PRODUCT_OUT}/system \
--vendor ${ANDROID_PRODUCT_OUT}/vendor \
--tag-file eligible-list.csv \
--module-info ${ANDROID_PRODUCT_OUT}/module-info.json \
1> check_dep.txt \
2> check_dep_err.txt
Por ejemplo, el siguiente resultado de ejemplo muestra una dependencia en incumplimiento de
De libRS_internal.so
a libmediandk.so
:
/system/lib/libRS_internal.so MODULE_PATH: frameworks/rs /system/lib/libmediandk.so AImageReader_acquireNextImage AImageReader_delete AImageReader_getWindow AImageReader_new AImageReader_setImageListener
Las opciones para el subcomando check-dep
incluyen las siguientes:
Opción | Descripción |
---|---|
--tag-file |
Debe hacer referencia a un archivo de etiquetas de biblioteca apto (descrito a continuación), que es un Hoja de cálculo proporcionada por Google que describía las categorías del marco compartidas bibliotecas. |
--module-info |
Apunta al module-info.json generado por la compilación de Android
en un sistema de archivos. Ayuda a la herramienta de definición VNDK a asociar módulos binarios con código fuente
código. |
Archivo de etiqueta de biblioteca apto
Google proporciona una hoja de cálculo del VNDK apta (p.ej.,
eligible-list.csv
) que etiqueta las bibliotecas compartidas del framework que
pueden usar los módulos de proveedores:
Etiqueta | Descripción |
---|---|
LL-NDK | Bibliotecas compartidas con ABI y APIs estables que ambos pueden usar del marco de trabajo y los módulos de los proveedores. |
LL-NDK-Privado | Dependencias privadas de las bibliotecas LL-NDK. Los módulos de proveedor no deben acceder estas bibliotecas directamente. |
VNDK-SP | Dependencias de las bibliotecas compartidas del framework de SP-HAL. |
VNDK-SP-Privado | Dependencias del VNDK-SP a las que no todos los proveedores pueden acceder directamente módulos. |
VNDK | Las bibliotecas compartidas del framework que están disponibles para los módulos de los proveedores (excepto SP-HAL y SP-HAL-Dep). |
VNDK: privado | Dependencias del VNDK a las que no todos los proveedores puedan acceder directamente módulos. |
SOLO PARA FWK | Bibliotecas compartidas solo del framework a las que el proveedor no debe acceder módulos (ni directa ni indirectamente). |
SOLO FWK-RS | Bibliotecas compartidas solo del framework a las que el proveedor no debe acceder (excepto para usos de RS). |
En la siguiente tabla, se describen las etiquetas que se usan para las bibliotecas compartidas de proveedores:
Etiqueta | Descripción |
---|---|
HAL del SP | Bibliotecas compartidas de implementación de HAL en el mismo proceso. |
SP-HAL-Dep | Dependencias de bibliotecas compartidas del proveedor de SP-HAL (también llamadas dependencias de SP-HAL) excluyendo LL-NDK y VNDK-SP). |
SOLO VND | Bibliotecas compartidas invisibles al framework a las que no deba acceder módulos del framework. Las bibliotecas extendidas del VNDK que se copiaron se etiquetan de la siguiente manera: Y SOLO VND. |
Relaciones entre las etiquetas:
Figura 1: Las relaciones entre las etiquetas.
dependencias
Para depurar las dependencias de la biblioteca, el subcomando deps
imprime
las dependencias del módulo:
./vndk_definition_tool.py deps \
--system ${ANDROID_PRODUCT_OUT}/system \
--vendor ${ANDROID_PRODUCT_OUT}/vendor
El resultado consta de varias líneas. La línea sin un carácter de tabulación comienza una nueva sección. La línea con un carácter de tabulación depende del valor anterior sección. Por ejemplo:
/system/lib/ld-android.so /system/lib/libc.so /system/lib/libdl.so
Este resultado muestra que ld-android.so
no tiene una dependencia.
y libc.so
depende de libdl.so
.
Cuando especificas la opción --revert
, deps
subcomando imprime los usos de las bibliotecas (invertido
dependencias):
./vndk_definition_tool.py deps \
--revert \
--system ${ANDROID_PRODUCT_OUT}/system \
--vendor ${ANDROID_PRODUCT_OUT}/vendor
Por ejemplo:
/system/lib/ld-android.so /system/lib/libdl.so
En este resultado, se muestra que ld-android.so
usa
libdl.so
o, en otras palabras, libdl.so
depende de
ld-android.so
Además, este resultado muestra que
libdl.so
es el único usuario de ld-android.so
.
Cuando especificas la opción --symbol
, deps
el subcomando muestra los símbolos utilizados:
./vndk_definition_tool.py deps \
--symbol \
--system ${ANDROID_PRODUCT_OUT}/system \
--vendor ${ANDROID_PRODUCT_OUT}/vendor
Por ejemplo:
/system/lib/libc.so /system/lib/libdl.so android_get_application_target_sdk_version dl_unwind_find_exidx dlclose dlerror dlopen dlsym
En este resultado, se muestra que libc.so
depende de seis funciones exportadas
desde libdl.so
. Si tanto la opción --symbol
como
Se especifican la opción --revert
, los símbolos utilizados por el usuario
se imprimen.