Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Aplicación de interfaces de partición de productos

Android 11 unbundles el product partición, por lo que es independiente de los system y vendor particiones. Como parte de estos cambios, ahora puede controlar el product de acceso de partición para interfaces nativas y Java (lo cual es similar a cómo funciona la aplicación de la interfaz para vendor particiones).

Hacer cumplir las interfaces nativas

Para habilitar la ejecución interfaz nativa, juego PRODUCT_PRODUCT_VNDK_VERSION al current . (La versión se ajusta automáticamente a current cuando el nivel de API de envío para el blanco es mayor que 29.) Aplicación permite:

  • Los módulos nativos en el product partición de enlace:
    • Estática o dinámicamente a otros módulos en el product partición que incluyen estático, común, o bibliotecas de cabecera.
    • Dinámicamente a las bibliotecas VNDK en el system partición.
  • Bibliotecas JNI en APK desagregados en el product partición para enlazar a las bibliotecas en /product/lib o /product/lib64 (esto es en adición a las bibliotecas NDK).

La aplicación no permite que otros enlaces a las particiones que no sean el product partición.

Aplicación del tiempo de compilación (Android.bp)

En Android 11, los módulos del sistema pueden crear una variante de imagen de producto además de variantes de imagen de proveedor y de núcleo. Cuando se habilita la aplicación de la interfaz nativa ( PRODUCT_PRODUCT_VNDK_VERSION se establece en current ):

  • Los módulos nativos en el product de partición están en la variante de producto en lugar de la variante de núcleo.

  • Los módulos con vendor_available: true en sus Android.bp archivos están disponibles para la variante de producto y la variante vendedor.

  • Bibliotecas o archivos binarios que especifican product_specific: true enlace lata a otras bibliotecas que especifican product_specific: true o vendor_available: true en sus Android.bp archivos.

  • Bibliotecas VNDK deben tener vendor_available: true en sus Android.bp archivos de modo product binarios pueden enlazar con bibliotecas VNDK.

La siguiente tabla resume los Android.bp propiedades que se utilizan para crear una imagen variantes.

Propiedades en Android.bp Variantes creadas
Antes de la aplicación Después de la aplicación
predeterminado (ninguno) centro

(incluye /system , /system_ext y /product )

centro

(incluye /system y /system_ext pero no /product )

system_ext_specific: true centro centro
product_specific: true centro producto
vendor: true vendedor vendedor
vendor_available: true núcleo, proveedor núcleo, producto, proveedor
system_ext_specific: true Y vendor_available: true núcleo, proveedor núcleo, producto, proveedor
product_specific: true Y vendor_available: true núcleo, proveedor producto, vendedor

Aplicación del tiempo de compilación (Android.mk)

Cuando está habilitada la aplicación de la interfaz nativa, módulos nativos instalados en el product partición tienen una native:product tipo de enlace que se puede vincular sólo a otros native:product o native:vndk módulos. Si se intenta vincular a cualquier módulo que no sean estos, el sistema de compilación generará un error de verificación del tipo de vínculo.

Aplicación del tiempo de ejecución

Cuando se habilita la aplicación de la interfaz nativa, la configuración de engarce para el enlazador biónico no permite procesos del sistema para el uso product bibliotecas, creando un product sección para los product procesos que no pueden enlazar con bibliotecas fuera del product partición (sin embargo, tales procesos pueden enlace a las bibliotecas VNDK). Los intentos de violar la configuración del enlace en tiempo de ejecución causa el proceso de fallar y generar una CANNOT LINK EXECUTABLE mensaje de error.

Hacer cumplir las interfaces de Java

Para habilitar la aplicación de interfaz de Java, juego PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE de true . (El valor se establece automáticamente en true cuando el nivel de la API de envío para el destino es mayor que 29.) Cuando está activada, la aplicación permite / no permite el acceso siguiente.

API /sistema / system_ext /producto /vendedor /datos
API pública
@SystemApi
@hide API

Al igual que en el vendor partición, una aplicación o una biblioteca de Java en el product está permitido partición para utilizar las API única públicas y del sistema; No se permite vincular a una biblioteca que usa API ocultas. Esta restricción incluye la vinculación en tiempo de compilación y la reflexión en tiempo de ejecución.

Construir cumplimiento de tiempo

En tiempo de compilación, Marca y Soong verificar que los módulos de Java en el product partición no utilizan las API ocultos por el control de los platform_apis y sdk_version campos. El sdk_version de aplicaciones en el product partición debe estar llena de current , system_current , o la versión numérica de la API y la platform_apis campo debe estar vacío.

Aplicación en tiempo de ejecución

Las verifica en tiempo de ejecución de Android que las aplicaciones en el product partición no se usan API ocultos, incluyendo la reflexión. Para más detalles, consulte Restricciones de interfaces no SDK .

Habilitación de la aplicación de la interfaz del producto

Siga los pasos de esta sección para habilitar la aplicación de la interfaz del producto.

Paso Tarea Requerido
1 Definir su propio sistema de makefile que especifica los paquetes para el system partición, a continuación, establecer el requisito de comprobación de ruta artefactos en el device.mk (para evitar que los módulos no son del sistema de instalación en el system partición). norte
2 Limpia la lista de permitidos. norte
3 Aplique interfaces nativas e identifique fallas de enlace en tiempo de ejecución (se puede ejecutar en paralelo con la aplicación de Java). Y
4 Aplique las interfaces Java y verifique el comportamiento del tiempo de ejecución (se puede ejecutar en paralelo con la aplicación nativa). Y
5 Verifique los comportamientos en tiempo de ejecución. Y
6 Actualización device.mk con la aplicación de la interfaz del producto. Y

Paso 1: cree un archivo MAKE y habilite la verificación de la ruta del artefacto

En este paso, se define el system archivo MAKE.

  1. Crear un archivo MAKE que define los paquetes para el system partición. Por ejemplo, crear una oem_system.mk archivo con el siguiente:

    $(call inherit-product, $(SRC_TARGET_DIR)/product/handheld_system.mk)
    $(call inherit-product, $(SRC_TARGET_DIR)/product/telephony_system.mk)
    
    # Applications
    PRODUCT_PACKAGES += \
        CommonSystemApp1 \
        CommonSystemApp2 \
        CommonSystemApp3 \
    
    # Binaries
    PRODUCT_PACKAGES += \
        CommonSystemBin1 \
        CommonSystemBin2 \
        CommonSystemBin3 \
    
    # Libraries
    PRODUCT_PACKAGES += \
        CommonSystemLib1 \
        CommonSystemLib2 \
        CommonSystemLib3 \
    
    PRODUCT_SYSTEM_NAME := oem_system
    PRODUCT_SYSTEM_BRAND := Android
    PRODUCT_SYSTEM_MANUFACTURER := Android
    PRODUCT_SYSTEM_MODEL := oem_system
    PRODUCT_SYSTEM_DEVICE := generic
    
    # For system-as-root devices, system.img should be mounted at /, so we
    # include ROOT here.
    _my_paths := \
     $(TARGET_COPY_OUT_ROOT)/ \
     $(TARGET_COPY_OUT_SYSTEM)/ \
    
    $(call require-artifacts-in-path, $(_my_paths),)
    
  2. En el device.mk archivo, heredad el makefile común para el system partición y activar la ruta de artefacto comprobación de los requisitos. Por ejemplo:

    $(call inherit-product, $(SRC_TARGET_DIR)/product/oem_system.mk)
    
    # Enable artifact path requirements checking
    PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := strict
    

Acerca de los requisitos de la ruta de artefactos

Cuando PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS se establece en true o strict , los paquetes impide que el sistema de construcción definidos en otros archivos make desde la instalación de las rutas definidas en require-artifacts-in-path paquetes y evita que se definen en el archivo MAKE actual de la instalación de artefactos fuera de las rutas definidas en require-artifacts-in-path .

En el ejemplo anterior, con PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS SET para strict , makefiles fuera oem_system.mk no puede incluir módulos instalados a la root o system partición. Para incluir estos módulos, se debe definir ya sea ellos en el oem_system.mk fichero o bien en un archivo MAKE incluido. Los intentos de instalar módulos en rutas no permitidas provocan interrupciones en la construcción. Para corregir las roturas, realice una de las siguientes acciones:

  • Opción 1: Incluir el módulo de sistema en los archivos make incluidos en oem_system.mk . Esto hace que se cumpla el requisito de la ruta del artefacto (ya que los módulos ahora existen en un archivo MAKE incluido) y, por lo tanto, permite la instalación en el conjunto de rutas en `require-artifacts-in-path.

  • Opción 2: Instalación de módulos a la system_ext o product partición (y no instale módulos al system partición).

  • Opción 3: Añadir módulos a la PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST . Esto enumera los módulos permitidos para ser instalados.

Paso 2: vaciar la lista de permitidos

En este paso, a tomar la PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST vacío, así todos los dispositivos que comparten oem_system.mk también puedan compartir un único system imagen. Para vaciar la lista de permitidos, mover los módulos en la lista a la system_ext o product partición o añadirlos a system archivos de maquillaje. Este paso es opcional, ya que la definición de un común system imagen no es necesario para habilitar la aplicación de la interfaz del producto. Sin embargo, el vaciado de la lista permitida es de gran ayuda para definir el system límite con system_ext .

Paso 3: hacer cumplir las interfaces nativas

En este paso, se establece PRODUCT_PRODUCT_VNDK_VERSION := current , a continuación, busque la estructura y de tiempo de ejecución errores y resolverlos. Para verificar el inicio y los registros del dispositivo y encontrar y corregir fallas de enlace en tiempo de ejecución:

  1. Conjunto PRODUCT_PRODUCT_VNDK_VERSION := current .

  2. Construya el dispositivo y busque errores de construcción. Es probable que veas algunas interrupciones en la compilación para las variantes de productos que faltan o las variantes principales. Los descansos comunes incluyen:

    • Cualquier hidl_interface módulo que tiene product_specific: true no estará disponible para los módulos del sistema. Para solucionarlo, vuelva a colocar product_specific: true con system_ext_specfic: true .
    • Es posible que a los módulos les falte la variante de producto necesaria para los módulos de producto. Para fijar, asegurar que el módulo de disposición del product partición mediante el establecimiento de vendor_available: true o mover el módulo al product partición mediante el establecimiento de product_specific: true .
  3. Resuelva los errores de compilación y asegúrese de que el dispositivo se compile correctamente.

  4. Actualice la imagen y busque errores de tiempo de ejecución en el inicio y los registros del dispositivo.

    • Si el linker etiqueta de un registro de casos de prueba muestra una CANNOT LINK EXECUTABLE mensaje, el archivo de marca no se encuentra una dependencia (y no fue capturado en tiempo de compilación).
    • Para comprobarlo del sistema de construcción, añadir la biblioteca requerida para los shared_libs: o required: campo.
  5. Resuelva las dependencias que faltan utilizando la guía proporcionada anteriormente.

Paso 4: hacer cumplir las interfaces Java

En este paso, se establece PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true , a continuación, encontrar y corregir errores de generación resultantes. Busque dos tipos específicos de errores:

  • Errores de tipo de enlace. Este error indica que una aplicación Java enlaza con módulos que tienen un amplio sdk_version . Para solucionarlo, se puede ampliar la aplicación de sdk_version o restringir de la biblioteca sdk_version . Error de ejemplo:

    error: frameworks/base/packages/SystemUI/Android.bp:138:1: module "SystemUI" variant "android_common": compiles against system API, but dependency "telephony-common" is compiling against private API.Adjust sdk_version: property of the source or target module so that target module is built with the same or smaller API set than the source.
    
  • Errores de símbolo. Este error indica que no se puede encontrar un símbolo porque está en una API oculta. Para solucionarlo, use una API visible (no oculta) o busque una alternativa. Error de ejemplo:

    frameworks/opt/net/voip/src/java/com/android/server/sip/SipSessionGroup.java:1051: error: cannot find symbol
                ProxyAuthenticate proxyAuth = (ProxyAuthenticate)response.getHeader(
                                               ^
      symbol:   class ProxyAuthenticate
      location: class SipSessionGroup.SipSessionImpl
    

Paso 5: comprobar los comportamientos en tiempo de ejecución

En este paso, verificará que los comportamientos en tiempo de ejecución sean los esperados. Para aplicaciones que son depurable, puede supervisar el uso API oculta por el registro utilizando StrictMode.detectNonSdkApiUsage (que genera un registro de aplicación cuando el utiliza una API oculta). Alternativamente, se puede utilizar el Veridex herramienta de análisis estático para obtener el tipo de uso (que une o reflexión), el nivel de restricción, y la pila de llamadas.

  • Sintaxis Veridex:

    ./art/tools/veridex/appcompat.sh --dex-file={apk file}
    
  • Ejemplo de resultado veridex:

    #1: Linking greylist-max-o Landroid/animation/AnimationHandler;-><init>()V use(s):
           Lcom/android/systemui/pip/phone/PipMotionHelper;-><init>(Landroid/content/Context;Landroid/app/IActivityManager;Landroid/app/IActivityTaskManager;Lcom/android/systemui/pip/phone/PipMenuActivityController;Lcom/android/internal/policy/PipSnapAlgorithm;Lcom/android/systemui/statusbar/FlingAnimationUtils;)V
    
    #1332: Reflection greylist Landroid/app/Activity;->mMainThread use(s):
           Landroidx/core/app/ActivityRecreator;->getMainThreadField()Ljava/lang/reflect/Field;
    

Para más detalles sobre el uso de Veridex, referirse a prueba utilizando la herramienta Veridex .

Paso 6: Actualiza device.mk

Después de arreglar todos los fallos de compilación y tiempo de ejecución, y verificar que los comportamientos de tiempo de ejecución son como se esperaba, establecer lo siguiente en device.mk :

  • PRODUCT_PRODUCT_VNDK_VERSION := current
  • PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true