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

Se usó la API de Cloud Translation para traducir esta página.

Aplica interfaces de partición de producto

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

Aplica interfaces nativas

Para habilitar la aplicación forzosa de la interfaz nativa, configura PRODUCT_PRODUCT_VNDK_VERSION a current. (La versión se establece automáticamente en current cuando se envía el nivel de API del destino es superior a 29). La aplicación permite lo siguiente:

Módulos nativos en la partición product que se vincularán:
- De forma estática o dinámica a otros módulos en la partición product que incluir bibliotecas estáticas, compartidas o de encabezado.
- De forma dinámica a las bibliotecas de VNDK en la partición system.
Bibliotecas JNI en APKs sin agrupar en la partición product para vincular con bibliotecas en /product/lib o /product/lib64 (esto se suma al NDK).

La aplicación forzosa no permite otros vínculos a particiones que no sean product por cada partición.

Aplicación en el tiempo de compilación (Android.bp)

En Android 11, los módulos del sistema pueden crear un producto de imagen dinámica, además de las variantes de imagen principal y de proveedor. Cuando sea nativo la aplicación forzosa de la interfaz esté habilitada (PRODUCT_PRODUCT_VNDK_VERSION se establece en current):

Los módulos nativos en la partición product están en la variante del producto de la variante principal.
Los módulos con product_available: true en sus archivos Android.bp tienen disponibles para la variante del producto.
Los objetos binarios o las bibliotecas que especifican product_specific: true pueden vincularse a otros elementos bibliotecas que especifiquen product_specific: true o product_available: true en sus archivos Android.bp.
Las bibliotecas del VNDK deben tener product_available: true en sus archivos Android.bp. por lo que los objetos binarios product se pueden vincular a las bibliotecas del VNDK.

En la siguiente tabla, se resumen las propiedades de Android.bp que se usan para crear imágenes variantes.

Propiedades en Android.bp	Se crearon las variantes
Propiedades en Android.bp	Antes de la aplicación	Después de la aplicación forzosa
predeterminado (ninguno)	núcleo (incluye `/system`, `/system_ext` y `/product`)	núcleo (incluye `/system` y `/system_ext`, pero no `/product`)
`system_ext_specific: true`	core	core
`product_specific: true`	core	producto
`vendor: true`	de proveedor	de proveedor
`vendor_available: true`	núcleo, proveedor	núcleo, proveedor
`product_available: true`	N/A	núcleo, producto
`vendor_available: true` Y `product_available: true`	N/A	núcleo, producto, proveedor
`system_ext_specific: true` Y `vendor_available: true`	núcleo, proveedor	núcleo, proveedor
`product_specific: true` Y `vendor_available: true`	núcleo, proveedor	producto, proveedor

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

Cuando se habilita la aplicación forzosa de la interfaz nativa, los módulos nativos instalados en el product partición tiene un tipo de vínculo native:product que solo se puede vincular a otros módulos native:product o native:vndk. Intentar vincular a alguna módulos que no sean estos provoca que el sistema de compilación genere una verificación del tipo de vínculo. .

Aplicación del entorno de ejecución

Cuando se habilita la aplicación forzosa de la interfaz nativa, la configuración del vinculador para la el vinculador biónico no permite que los procesos del sistema usen bibliotecas product Creando una sección product para los procesos product que no se pueden vincular fuera de la partición product (sin embargo, esos procesos pueden vincularse a VNDK). Los intentos de infringir la configuración del vínculo del entorno de ejecución provocan falle y se genere un mensaje de error CANNOT LINK EXECUTABLE.

Aplica interfaces de Java

Para habilitar la aplicación forzosa de la interfaz de Java, configura De PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE a true. (El valor es Se establece automáticamente en true cuando el nivel de API de envío para el destino es superior a 29). Cuando se habilita, la aplicación forzosa permite o rechaza lo siguiente acceso:

API	/system	/system_ext	/product	/vendor	/data
API pública
@SistemaApi
API de @hide

Como en la partición vendor, una app o biblioteca de Java en product la partición puede usar solo APIs públicas y del sistema; vincular a una biblioteca que use APIs ocultas. Esta restricción incluye la vinculación en la compilación el tiempo y los reflejos en el tiempo de ejecución.

Aplicación del tiempo de compilación

Durante el tiempo de compilación, Make y Soong verifican los módulos de Java en el archivo product. no usen APIs ocultas con solo verificar la platform_apis y sdk_version. El sdk_version de las apps en la partición product debe Completar con current, system_current o la versión numérica de la API el campo platform_apis debe estar vacío.

Aplicación del entorno de ejecución

El tiempo de ejecución de Android verifica que las apps de la partición product no usen la configuración APIs ocultas, incluida la reflexión. Para obtener más información, consulta Restricciones sobre no perteneciente al SDK interfaces de programación de aplicaciones.

Habilitar la aplicación de la interfaz del producto

Sigue los pasos que se indican en esta sección para habilitar la aplicación forzosa de la interfaz de producto.

Paso	Tarea	Obligatorio
1	Define tu propio archivo makefile del sistema que especifique los paquetes de la partición `system` y, luego, configura la verificación de requisitos de la ruta de acceso de los artefactos en el archivo `device.mk` (para evitar que se instalen módulos que no sean del sistema a la partición `system`).	N
2	Limpia la lista de permitidos.	N
3	Imponga interfaces nativas e identifique fallas en los vínculos del entorno de ejecución (puede ejecutarse en paralelo con la aplicación de Java).	S
4	Aplica interfaces de Java y verifica el comportamiento del entorno de ejecución (se puede ejecutar en paralelo) con la aplicación nativa.	S
5	Verifica los comportamientos del tiempo de ejecución.	S
6	Actualiza `device.mk` con la aplicación de la interfaz de producto.	S

Paso 1: Crea un archivo makefile y habilita la verificación de ruta de acceso del artefacto

En este paso, definirás el archivo makefile system.

Crea un archivo makefile que defina los paquetes para la partición system. Para Por ejemplo, crea un archivo oem_system.mk con lo 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),)

En el archivo device.mk, hereda el archivo makefile común para system. partición y habilitar la verificación de requisitos de la ruta de acceso a los artefactos. 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 acceso a los artefactos

Cuando PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS se establece en true o strict, el sistema de compilación evita que se instalen paquetes definidos en otros archivos makefile en las rutas definidas en require-artifacts-in-path y evita que los paquetes definidos en el archivo makefile actual a partir de la instalación de artefactos fuera de las rutas de acceso se define en require-artifacts-in-path.

En el ejemplo anterior, con PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS configurado como strict, los archivos makefile fuera de oem_system.mk no pueden incluir módulos instalados en la partición root o system. Para incluir estos módulos, debes hacer lo siguiente: puedes definirlas en el archivo oem_system.mk o en un archivo makefile incluido. Los intentos de instalar módulos en rutas de acceso no permitidas causan interrupciones de compilación. Para corregir realiza una de las siguientes acciones:

Opción 1: Incluye el módulo del sistema en los archivos makefile incluidos en oem_system.mk Así, se cumple el requisito de ruta del artefacto (ya que ahora existen en un archivo makefile incluido) y, por lo tanto, permite la instalación en el conjunto de rutas de acceso en `require-artifacts-in-path.
Opción 2: Instala módulos en la partición system_ext o product (y no instales módulos en la partición system).
Opción 3: Agrega módulos al módulo PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST Aquí se muestran los módulos permitidos instalarse.

Paso 2: Vacía la lista permitida

En este paso, harás que el elemento PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST vacío para que todos los dispositivos que comparten oem_system.mk también puedan compartir un solo system imagen. Para vaciar la lista permitida, mueve los módulos de la lista al Haz una partición de system_ext o product, o agrégalos a los archivos de creación system. Esta el paso es opcional porque no es necesario definir una imagen system común para habilitar la aplicación forzosa de la interfaz de producto. Sin embargo, vaciar la lista permitida útil para definir el límite system con system_ext.

Paso 3: Aplica interfaces nativas

En este paso, configurarás PRODUCT_PRODUCT_VNDK_VERSION := current y, luego, buscarás en busca de errores de compilación y entorno de ejecución, y resolverlos. Cómo verificar el inicio y los registros del dispositivo y solucionar problemas relacionados con vínculos en tiempo de ejecución:

Establece PRODUCT_PRODUCT_VNDK_VERSION := current.
Compila el dispositivo y busca errores de compilación. Es probable que veas que algunas pausas para variantes de productos o variantes principales faltantes. Pausas comunes incluyen:
- Cualquier módulo hidl_interface que tenga product_specific: true no se disponibles para los módulos del sistema. Para solucionarlo, reemplaza product_specific: true. con system_ext_specific: true.
- Es posible que en los módulos falte la variante del producto requerida para este módulos. Para solucionarlo, haz que ese módulo esté disponible para la partición product. Para ello, haz lo siguiente: Configura product_available: true o mueve el módulo a product. por separado mediante la configuración de product_specific: true.
Nota: Las pausas de compilación son similares para los módulos descritos en Android.mk.
Resuelve los errores de compilación y asegúrate de que el dispositivo compile correctamente.
Escribe la imagen en la memoria flash y busca errores de entorno de ejecución en el arranque y los registros del dispositivo.
- Si la etiqueta linker de un registro de casos de prueba muestra una CANNOT LINK EXECUTABLE. mensaje, al archivo make le falta una dependencia (y este no se capturó en tiempo de compilación).
- Para comprobarlo desde el sistema de compilación, agrega la biblioteca requerida a la Campo shared_libs: o required:.
Resuelve las dependencias faltantes con la guía anterior.

Paso 4: Aplica las interfaces de Java

En este paso, configurarás PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true, y, luego, encontrar y corregir los errores de compilación resultantes. Busca dos tipos específicos de errores:

Errores de tipo de vínculo. Este error indica que una app se vincula a módulos de Java. que tienen un sdk_version más amplio. Para corregir el problema, puedes ampliar el alcance sdk_version o restringe el sdk_version de la biblioteca. Ejemplo de error:

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ímbolos. Este error indica que no se puede encontrar un símbolo porque está en una API oculta. Para solucionarlo, usa una API visible (no oculta) o busca un alternativa. Ejemplo de error:

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: Verifica los comportamientos del tiempo de ejecución

En este paso, verificarás que los comportamientos del entorno de ejecución sean los esperados. Para las apps que son depurable, puedes supervisar el uso oculto de APIs mediante registro con StrictMode.detectNonSdkApiUsage (que genera un registro cuando la app usa un API oculta). Como alternativa, puedes usar el veridex una herramienta de análisis estático para conocer el tipo de uso (vínculo o reflexión). el nivel de restricción y la pila de llamadas.

Sintaxis de veridex:

./art/tools/veridex/appcompat.sh --dex-file={apk file}

Ejemplo de resultado de 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 obtener detalles sobre el uso de veridex, consulta Realiza pruebas con veridex de la aplicación.

Paso 6: Actualiza device.mk

Después de corregir todas las fallas de compilación y entorno de ejecución, y verificar que el entorno de ejecución comportamientos sean los esperados, establece lo siguiente en device.mk:

PRODUCT_PRODUCT_VNDK_VERSION := current
PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true