RenderScript es un marco para la ejecución de tareas computacionalmente intensivas a un alto rendimiento en Android. Está diseñado para usarse con cómputo de datos en paralelo, aunque las cargas de trabajo en serie también pueden beneficiarse. El tiempo de ejecución de RenderScript paraleliza el trabajo en los procesadores disponibles en un dispositivo, como las CPU y GPU de varios núcleos, lo que permite a los desarrolladores centrarse en expresar algoritmos en lugar de programar el trabajo. RenderScript es especialmente útil para aplicaciones que realizan procesamiento de imágenes, fotografía computacional o visión por computadora.
Los dispositivos que ejecutan Android 8.0 y versiones posteriores utilizan el siguiente marco de RenderScript y los HAL del proveedor:

Las diferencias con RenderScript en Android 7.xy versiones anteriores incluyen:
- Dos instancias de bibliotecas internas de RenderScript en un proceso. Un conjunto es para ruta de CPU de reserva y es de directamente en
/system/lib
; el otro conjunto es para ruta de GPU y es de/system/lib/vndk-sp
. - RS libs internos en
/system/lib
se construyen como parte de la plataforma y se actualizan a medidasystem.img
se actualiza. Sin embargo, en libs/system/lib/vndk-sp
se construyen para el vendedor y no se actualizan cuandosystem.img
se actualiza (mientras que pueden ser actualizados para una revisión de seguridad, su ABI sigue siendo el mismo). - Código de proveedor (RS HAL, RS conductor, y el
bcc plugin
) están vinculados contra los libs internos renderScript situados en/system/lib/vndk-sp
. No pueden enlazar con libs en/system/lib
porque libs de ese directorio se construyen para la plataforma y por lo tanto puede no ser compatible con el código de proveedor (es decir, los símbolos se puede retirar). Hacerlo haría imposible una OTA de solo marco.
Diseño
Las siguientes secciones detallan el diseño de RenderScript en Android 8.0 y versiones posteriores.
Libs de RenderScript disponibles para proveedores
En esta sección se enumeran las bibliotecas de RenderScript (conocidas como NDK de proveedor para HAL del mismo proceso o VNDK-SP) que están disponibles para el código de proveedor y con las que se pueden vincular. También detalla bibliotecas adicionales que no están relacionadas con RenderScript pero que también se proporcionan al código del proveedor.
Si bien la siguiente lista de bibliotecas puede diferir entre las versiones de Android, es inmutable para una versión específica de Android; para obtener una lista actualizada de las bibliotecas disponibles, consulte /system/etc/ld.config.txt
.
Libs de RenderScript | Libs que no son de RenderScript |
---|---|
|
|
Configuración del espacio de nombres del vinculador
La restricción de vinculación que evita que las bibliotecas que no están en VNDK-SP sean utilizadas por el código del proveedor se aplica en tiempo de ejecución mediante el espacio de nombres del vinculador. (Para más detalles, consulte la VNDK Diseño presentación).
En un dispositivo con Android 8.0 y superior, todos HAL mismo proceso (SP-HAL) excepto RenderScript se cargan en el interior del enlazador espacio de nombres sphal
. RenderScript se carga en el espacio de nombres específicos RenderScript- rs
, un lugar que permita la aplicación de un poco más flojo en las librerías renderScript. Debido a que las necesidades de implementación RS para cargar el código binario compilado, /data/*/*.so
se añade a la trayectoria de la rs
espacio de nombres (otros SP-HAL no se les permite libs de carga desde la partición de datos).
Además, el rs
espacio de nombres permite que más librerías que el estipulado por otros espacios de nombres. libmediandk.so
y libft2.so
están expuestos al rs
espacio de nombres porque libRS_internal.so
tiene una dependencia interna de estas bibliotecas.

Cargando controladores
Ruta de respaldo de la CPU
En función de la existencia de la RS_CONTEXT_LOW_LATENCY
poco al crear un contexto RS, se selecciona la CPU o GPU ruta. Cuando se selecciona la trayectoria de CPU, libRS_internal.so
(la implementación principal del marco RS) es directamente dlopen
ed del espacio de nombres enlazador predeterminada en la que la versión de la plataforma de RS se proporcionan libs.
El RS aplicación HAL desde el proveedor no se utiliza en absoluto cuando se toma el camino de la CPU de reserva, y un RsContext
objeto se crea con nula mVendorDriverName
. libRSDriver.so
es (por defecto) dlopen
ed y la lib conductor se carga desde el default
espacio de nombres debido a que la persona que llama ( libRS_internal.so
) también se carga en el default
espacio de nombres.

Ruta de la GPU
Por el camino GPU, la libRS_internal.so
se carga de manera diferente. En primer lugar, libRS.so
utiliza android.hardware.renderscript@1.0.so
(y su subyacente libhidltransport.so
) para cargar android.hardware.renderscript@1.0-impl.so
(una aplicación de proveedor de RS HAL) en un espacio de nombres enlazador diferente llamado sphal
. El RS Hal entonces dlopen
s libRS_internal.so
en un enlazador otro espacio de nombres llamados rs
.
Los vendedores pueden proporcionar su propio controlador RS estableciendo el indicador del tiempo de construcción OVERRIDE_RS_DRIVER
, que se incrusta en el RS aplicación HAL ( hardware/interfaces/renderscript/1.0/default/Context.cpp
). Este nombre del controlador es entonces dlopen
ed para el contexto RS para la trayectoria de la GPU.
La creación de la RsContext
objeto se delega a la aplicación RS HAL. Las llamadas HAL atrás al marco RS utilizando rsContextCreateVendor()
función con el nombre del conductor para su uso como un argumento. El marco RS continuación, carga el controlador especificado cuando el RsContext
se inicializa. En este caso, la biblioteca del controlador se carga en el rs
espacio de nombres debido a que el RsContext
se crea en el interior del objeto rs
espacio de nombres y /vendor/lib
está en la ruta de búsqueda del espacio de nombres.

Cuando la transición de la default
de espacio de nombres para el sphal
espacio de nombres, libhidltransport.so
los usos android_load_sphal_library()
la función para ordenar explícitamente el enlazador dinámico para cargar el -impl.so
biblioteca de la sphal
espacio de nombres.
Cuando la transición de la sphal
espacio de nombres al rs
espacio de nombres, la carga se hace indirectamente por la línea siguiente en /system/etc/ld.config.txt
:
namespace.sphal.link.rs.shared_libs = libRS_internal.so
Esta línea especifica el enlazador dinámico se debe cargar libRS_internal.so
de la rs
espacio de nombres cuando el lib no se pueden encontrar / cargado desde el sphal
espacio de nombres (que es siempre el caso debido a sphal
espacio de nombres no busca /system/lib/vndk-sp
donde libRS_internal.so
reside). Con esta configuración, un simple dlopen()
llamada a libRS_internal.so
es suficiente para hacer la transición del espacio de nombres.
Cargando complemento Bcc
bcc plugin
es una biblioteca proporcionado por el proveedor cargado en la bcc
compilador. Debido bcc
es un proceso del sistema en el /system/bin
directorio, el bcc plugin
biblioteca puede ser considerado como un SP-HAL (es decir, un HAL proveedor que puede ser cargado directamente en el proceso de sistema sin ser revestidas con un aglutinante). Como un SP-HAL, la bcc-plugin
de biblioteca:
- No se puede enlazar con marco de sólo librerías como
libLLVM.so
. - Se puede vincular solo con las bibliotecas VNDK-SP disponibles para el proveedor.
Esta restricción es impuesta por la carga del bcc plugin
en el sphal
espacio de nombres usando el android_sphal_load_library()
función. En las versiones anteriores de Android, el nombre del plugin se especificó usando el -load
opción y el lib se cargó utilizando el sencillo dlopen()
por libLLVM.so
. En Android 8.0 y superior, esto se especifica en el -plugin
opción y de la librería se carga directamente por el bcc
en sí. Esta opción habilita una ruta no específica de Android al proyecto LLVM de código abierto.


Rutas de búsqueda para ld.mc
Al ejecutar ld.mc
, algunas librerías RS tiempo de ejecución se dan como entradas al enlazador. El código de bits RS de la aplicación está vinculado con las bibliotecas en tiempo de ejecución y cuando el código de bits convertido se carga en un proceso de la aplicación, las bibliotecas en tiempo de ejecución se vinculan nuevamente dinámicamente desde el código de bits convertido.
Las bibliotecas en tiempo de ejecución incluyen:
-
libcompiler_rt.so
-
libm.so
-
libc.so
- RS controlador (ya sea
libRSDriver.so
oOVERRIDE_RS_DRIVER
)
Al cargar el código binario compilado en el proceso de aplicación, proporcionar la misma biblioteca exacta que fue utilizado por ld.mc
. De lo contrario, es posible que el código de bits compilado no encuentre un símbolo que estuviera disponible cuando se vinculó.
Para ello, el marco RS utiliza diferentes rutas de búsqueda para las bibliotecas de tiempo de ejecución al ejecutar ld.mc
, dependiendo de si el marco RS sí se carga desde /system/lib
o desde /system/lib/vndk-sp
. Esto se puede determinar mediante la lectura de la dirección de un símbolo arbitrario de un marco lib RS y el uso de dladdr()
para obtener la ruta del archivo asignado a la dirección.
Política de SELinux
Como resultado de los cambios en la política de SELinux en Android 8.0 y posteriores, debe seguir reglas específicas (forzadas a través neverallows
) al etiquetar los archivos adicionales en vendor
partición:
-
vendor_file
debe ser la etiqueta por defecto en todos los archivos devendor
partición. La política de la plataforma requiere esto para acceder a las implementaciones de HAL de paso. - Todas las novedades
exec_types
añadidas envendor
partición a través de proveedores SEPolicy deben tenervendor_file_type
atributo. Esto se aplica a travésneverallows
. - Para evitar conflictos con la plataforma de futuro / actualizaciones marco, archivos de etiquetado evitar otros que
exec_types
envendor
partición. - Todas las dependencias de bibliotecas para identificados-AOSP mismos HAL proceso deben ser etiquetados como
same_process_hal_file
.
Para más detalles sobre la política de SELinux, consulte Security-Enhanced Linux en Android .
Compatibilidad ABI para código de bits
Si no se agregan nuevas API, lo que significa que no hay cambios en la versión de HAL, los marcos de RS seguirán usando el controlador de GPU (HAL 1.0) existente.
Para cambios menores de HAL (HAL 1.1) que no afectan al código de bits, los marcos deberían recurrir a la CPU para estas API recién agregadas y seguir usando el controlador GPU (HAL 1.0) en otros lugares.
Para cambios importantes de HAL (HAL 2.0) que afectan la compilación / vinculación de código de bits, los marcos de RS deben optar por no cargar controladores de GPU proporcionados por el proveedor y, en su lugar, usar la ruta de CPU o Vulkan para la aceleración.
El consumo de código de bits de RenderScript se produce en tres etapas:
Escenario | Detalles |
---|---|
Compilar |
|
Enlace |
|
Carga |
|
Además de HAL, las API de tiempo de ejecución y los símbolos exportados también son interfaces. Ninguna interfaz ha cambiado desde Android 7.0 (API 24) y no hay planes inmediatos para cambiarla en Android 8.0 y posteriores. Sin embargo, si la interfaz cambia, la versión HAL también aumentará.
Implementaciones de proveedores
Android 8.0 y superior requiere algunos cambios en el controlador de GPU para que el controlador de GPU funcione correctamente.
Módulos de controlador
- Módulos de los controladores no deben depender de ninguna librería del sistema que no están en la lista .
- El conductor debe proporcionar su propia
android.hardware.renderscript@1.0-impl_{NAME}
, o declarar la implementación predeterminadaandroid.hardware.renderscript@1.0-impl
como su dependencia. - Aplicación de la CPU
libRSDriver.so
es un buen ejemplo de cómo quitar dependencias no VNDK-SP.
Compilador de código de bits
Puede compilar el código de bits de RenderScript para el controlador del proveedor de dos formas:
- Invoke específico del proveedor RenderScript compilador en
/vendor/bin/
(método preferido de compilación GPU). Al igual que en otros módulos de los controladores, el binario proveedor compilador no puede depender de cualquier biblioteca de sistema que no está en la lista de RenderScript librerías disponibles para los vendedores . - Invoke sistema bcc:
/system/bin/bcc
con un proveedor proporcionado porbcc plugin
; este plugin no puede depender de cualquier biblioteca de sistema que no está en la lista de RenderScript librerías disponibles para los vendedores .
Si el vendedor bcc plugin
necesidades a interferir con la compilación de la CPU y su dependencia de libLLVM.so
no se puede quitar fácilmente, el vendedor debe copiar bcc
(y todas las dependencias de la no-LL-NDK, incluyendo libLLVM.so
, libbcc.so
) en /vendor
partición.
Además, los proveedores deben realizar los siguientes cambios:

- Copiar
libclcore.bc
a/vendor
partición. Esto aseguralibclcore.bc
,libLLVM.so
, ylibbcc.so
están sincronizados. - Cambiar la ruta de acceso al
bcc
ejecutable mediante el establecimiento deRsdCpuScriptImpl::BCC_EXE_PATH
de la aplicación HAL RS.
Política de SELinux
La política de SELinux afecta tanto al controlador como a los ejecutables del compilador. Todos los módulos de los controladores deben estar etiquetados same_process_hal_file
en el dispositivo de file_contexts
. Por ejemplo:
/vendor/lib(64)?/libRSDriver_EXAMPLE\.so u:object_r:same_process_hal_file:s0
El ejecutable compilador debe ser capaz de ser invocado por un proceso de aplicación, como lo hace la copia proveedor de bcc ( /vendor/bin/bcc
). Por ejemplo:
device/vendor_foo/device_bar/sepolicy/file_contexts: /vendor/bin/bcc u:object_r:same_process_hal_file:s0
Dispositivos heredados
Los dispositivos heredados son aquellos que cumplen las siguientes condiciones:
- PRODUCT_SHIPPING_API_LEVEL es inferior a 26.
- PRODUCT_FULL_TREBLE_OVERRIDE no está definido.
Para los dispositivos de legado, no se aplican las restricciones al actualizar a Android 8.0 y superior, es decir, los conductores pueden seguir un enlace a las bibliotecas en /system/lib[64]
. Sin embargo, debido al cambio de la arquitectura relacionada con OVERRIDE_RS_DRIVER
, android.hardware.renderscript@1.0-impl
debe estar instalado a /vendor
partición; si no lo hace, el tiempo de ejecución de RenderScript vuelve a la ruta de la CPU.
Para obtener información acerca de la motivación de la desaprobación renderScript, ver el Android Blog de desarrolladores: Android GPU Calcular ir adelante . La información de recursos para esta desaprobación incluye lo siguiente:
- Migrar desde Renderscript
- Muestra RenderScriptMigration
- Intrínseco reemplazo Toolkit README
- Intrínsecos reemplazo Toolkit.kt