Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Usando Binder IPC

Esta página describe los cambios en el controlador de la carpeta en Android 8, proporciona detalles sobre el uso de la carpeta IPC de la carpeta y enumera la política SELinux requerida.

Cambios en el controlador de carpeta

A partir de Android 8, el marco de Android y los HAL ahora se comunican entre sí mediante Binder. Como esta comunicación aumenta drásticamente el tráfico de la carpeta, Android 8 incluye varias mejoras diseñadas para mantener la carpeta IPC rápida. Los proveedores de SoC y los OEM deben fusionarse directamente desde las ramas relevantes de android-4.4, android-4.9 y superior del kernel / proyecto común .

Múltiples dominios de carpeta (contextos)

Común-4.4 y superior, incluido aguas arriba

Para dividir limpiamente el tráfico de la carpeta entre el marco (independiente del dispositivo) y el código del proveedor (específico del dispositivo), Android 8 introdujo el concepto de un contexto de carpeta . Cada contexto de carpeta tiene su propio nodo de dispositivo y su propio administrador de contexto (servicio). Puede acceder al administrador de contexto solo a través del nodo del dispositivo al que pertenece y, al pasar un nodo de carpeta a través de un determinado contexto, es accesible desde ese mismo contexto solo por otro proceso, aislando completamente los dominios entre sí. Para obtener detalles sobre el uso, consulte vndbinder y vndservicemanager .

Dispersión-reunión

Común-4.4 y superior, incluido aguas arriba

En versiones anteriores de Android, cada pieza de datos en una llamada de carpeta se copiaba tres veces:

  • Una vez para serializarlo en un Parcel en el proceso de llamada
  • Una vez en el controlador del núcleo para copiar el Parcel al proceso de destino
  • Una vez para deserializar el Parcel en el proceso de destino

Android 8 utiliza la optimización de dispersión-reunión para reducir el número de copias de 3 a 1. En lugar de serializar primero los datos en un Parcel , los datos permanecen en su estructura original y diseño de memoria y el controlador los copia de inmediato al proceso de destino. Una vez que los datos están en el proceso de destino, la estructura y el diseño de la memoria son los mismos y los datos se pueden leer sin requerir otra copia.

Bloqueo de grano fino

Común-4.4 y superior, incluido aguas arriba

En versiones anteriores de Android, el controlador de carpeta utilizaba un bloqueo global para proteger contra el acceso concurrente a estructuras de datos críticas. Si bien hubo una contención mínima para el bloqueo, el problema principal era que si un subproceso de baja prioridad obtenía el bloqueo y luego se le adelantaba, podría retrasar seriamente los subprocesos de mayor prioridad que necesitaban obtener el mismo bloqueo. Esto provocó un tirón en la plataforma.

Los intentos iniciales para resolver este problema implicaron deshabilitar la preferencia mientras se mantiene el bloqueo global. Sin embargo, esto fue más un truco que una verdadera solución, y eventualmente fue rechazado por aguas arriba y descartado. Los intentos posteriores se centraron en hacer que el bloqueo sea más detallado, una versión de la cual se ejecuta en dispositivos Pixel desde enero de 2017. Si bien la mayoría de esos cambios se hicieron públicos, se realizaron mejoras sustanciales en las versiones posteriores.

Después de identificar pequeños problemas en la implementación de bloqueo de grano fino, ideamos una solución mejorada con una arquitectura de bloqueo diferente y presentamos los cambios en todas las ramas comunes del núcleo. Continuamos probando esta implementación en una gran cantidad de dispositivos diferentes; Como no tenemos conocimiento de ningún problema pendiente, esta es la implementación recomendada para dispositivos que se envían con Android 8.

Herencia prioritaria en tiempo real

Common-4.4 y common-4.9 (próximamente)

El controlador de carpeta siempre ha admitido una herencia de prioridad agradable. Como un número cada vez mayor de procesos en Android se ejecutan con prioridad en tiempo real, en algunos casos ahora tiene sentido que si un subproceso en tiempo real realiza una llamada de carpeta, el subproceso en el proceso que maneja esa llamada también se ejecuta con prioridad en tiempo real . Para admitir estos casos de uso, Android 8 ahora implementa la herencia de prioridad en tiempo real en el controlador de carpeta.

Además de la herencia de prioridad de nivel de transacción, la herencia de prioridad de nodo permite que un nodo (objeto de servicio de enlace) especifique una prioridad mínima en la que se deben ejecutar las llamadas a este nodo. Las versiones anteriores de Android ya admitían la herencia de prioridad de nodo con buenos valores, pero Android 8 agrega compatibilidad con la herencia de nodo de políticas de programación en tiempo real.

Cambios de espacio de usuario

Android 8 incluye todos los cambios de espacio de usuario necesarios para trabajar con el controlador de carpeta actual en el kernel común con una excepción: la implementación original para deshabilitar la herencia de prioridad en tiempo real para /dev/binder utilizó un ioctl . El desarrollo posterior cambió el control de la herencia prioritaria a un método más detallado que es por modo de carpeta (y no por contexto). Por lo tanto, el ioctl no está en la rama común de Android y, en cambio, se envía a nuestros núcleos comunes .

El efecto de este cambio es que la herencia de prioridad en tiempo real está deshabilitada de manera predeterminada para cada nodo. El equipo de rendimiento de Android ha encontrado beneficioso habilitar la herencia de prioridad en tiempo real para todos los nodos en el dominio hwbinder . Para lograr el mismo efecto, seleccione este cambio en el espacio de usuario.

SHA para granos comunes

Para obtener los cambios necesarios en el controlador de carpeta, sincronice con el SHA apropiado:

  • Común-3.18
    cc8b90c121de ANDROID: carpeta: no verifique los permisos de prio en la restauración.
  • Común-4.4
    76b376eac7a2 ANDROID: carpeta: no verifica los permisos de prio en la restauración.
  • Común-4.9
    ecd972d4f9b5 ANDROID: carpeta: no verifique los permisos de prio en la restauración.

Usando la carpeta IPC

Históricamente, los procesos del proveedor han utilizado la comunicación entre procesos de enlace (IPC) para comunicarse. En Android 8, el nodo del dispositivo /dev/binder convierte en exclusivo de los procesos del marco, lo que significa que los procesos del proveedor ya no tienen acceso a él. Los procesos del proveedor pueden acceder a /dev/hwbinder , pero deben convertir sus interfaces AIDL para usar HIDL. Para los proveedores que desean continuar utilizando las interfaces AIDL entre los procesos del proveedor, Android admite el IPC de la carpeta como se describe a continuación.

vndbinder

Android 8 admite un nuevo dominio de aglutinante para uso de los servicios del proveedor, al que se accede mediante /dev/vndbinder lugar de /dev/binder . Con la adición de /dev/vndbinder , Android ahora tiene los siguientes tres dominios IPC:

Dominio IPC Descripción
/dev/binder IPC entre procesos de marco / aplicación con interfaces AIDL
/dev/hwbinder IPC entre procesos de marco / proveedor con interfaces HIDL
IPC entre procesos de proveedor con interfaces HIDL
/dev/vndbinder IPC entre proveedor / procesos de proveedor con interfaces AIDL

Para que aparezca /dev/vndbinder , asegúrese de que el elemento de configuración del núcleo CONFIG_ANDROID_BINDER_DEVICES esté configurado en "binder,hwbinder,vndbinder" (este es el valor predeterminado en los árboles de kernel comunes de Android).

Normalmente, los procesos del proveedor no abren el controlador de carpeta directamente y en su lugar se vinculan con la biblioteca libbinder userspace, que abre el controlador de carpeta. Agregar un método para ::android::ProcessState() selecciona el controlador de carpeta para libbinder . Los procesos del proveedor deben llamar a este método antes de llamar a ProcessState, IPCThreadState o antes de realizar llamadas de IPCThreadState en general. Para usar, realice la siguiente llamada después del main() de un proceso de proveedor (cliente y servidor):

ProcessState::initWithDriver("/dev/vndbinder");

vndservicemanager

Anteriormente, los servicios de carpeta se registraban con servicemanager , donde podían ser recuperados por otros procesos. En Android 8, servicemanager ahora se usa exclusivamente por el marco y los procesos de aplicaciones y los procesos de proveedores ya no pueden acceder a él.

Sin embargo, los servicios del proveedor ahora pueden usar vndservicemanager , una nueva instancia de servicemanager que usa /dev/vndbinder lugar de /dev/binder y que se construye a partir de las mismas fuentes que framework servicemanager . Los procesos del proveedor no necesitan hacer cambios para hablar con vndservicemanager ; Cuando se abre un proceso de proveedor / dev/vndbinder , las búsquedas de servicio van automáticamente a vndservicemanager .

El binario vndservicemanager está incluido en los vndservicemanager MAKE de dispositivos predeterminados de Android.

Política de SELinux

Los procesos de proveedores que desean utilizar la funcionalidad de carpeta para comunicarse entre sí necesitan lo siguiente:

  1. Acceso a /dev/vndbinder .
  2. La carpeta {transfer, call} engancha en vndservicemanager .
  3. binder_call(A, B) para cualquier dominio de proveedor A que desee llamar al dominio de proveedor B a través de la interfaz de enlace de proveedor.
  4. Permiso para {add, find} servicios en vndservicemanager .

Para cumplir los requisitos 1 y 2, use la macro vndbinder_use() :

vndbinder_use(some_vendor_process_domain);

Para cumplir con el requisito 3, el binder_call(A, B) para los procesos de proveedor A y B que necesitan hablar sobre el aglutinante puede permanecer en su lugar y no necesita cambiar el nombre.

Para cumplir el requisito 4, debe realizar cambios en la forma en que se manejan los nombres de servicio, las etiquetas de servicio y las reglas.

Para obtener detalles sobre SELinux, consulte Linux con seguridad mejorada en Android . Para obtener detalles sobre SELinux en Android 8.0, consulte SELinux para Android 8.0 .

Nombres de servicio

Anteriormente, el proveedor procesaba los nombres de servicios registrados en un archivo service_contexts y agregaba las reglas correspondientes para acceder a ese archivo. Ejemplo de archivo service_contexts del device/google/marlin/sepolicy :

AtCmdFwd                              u:object_r:atfwd_service:s0
cneservice                            u:object_r:cne_service:s0
qti.ims.connectionmanagerservice      u:object_r:imscm_service:s0
rcs                                   u:object_r:radio_service:s0
uce                                   u:object_r:uce_service:s0
vendor.qcom.PeripheralManager         u:object_r:per_mgr_service:s0

En Android 8, vndservicemanager carga el archivo vndservice_contexts lugar. Los servicios del proveedor que migran a vndservicemanager (y que ya están en el antiguo archivo service_contexts ) deben agregarse al nuevo archivo vndservice_contexts .

Etiquetas de servicio

Anteriormente, las etiquetas de servicio como u:object_r:atfwd_service:s0 se definían en un archivo service.te . Ejemplo:

type atfwd_service,      service_manager_type;

En Android 8, debe cambiar el tipo a vndservice_manager_type y mover la regla al archivo vndservice.te . Ejemplo:

type atfwd_service,      vndservice_manager_type;

Reglas de administrador de servicio

Anteriormente, las reglas otorgaban a los dominios acceso para agregar o buscar servicios de servicemanager . Ejemplo:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;

En Android 8, tales reglas pueden permanecer en su lugar y usar la misma clase. Ejemplo:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;