¿Qué se necesita para ejecutar binarios ELF compilados a partir de APKs de Android?
Un simple aplicación hello world que no hace nada más que imprimir Hola, mundo. (sin animaciones, sin sonidos, sin menús), funcionando en un dispositivo Android 9:
- Abre
30+ archivos, inodos anónimos y sockets UNIX explícitamente.
- Acciones
500+ archivos mapeados en memoria de /data , /system , /vendor y /dev .
- Comunica, al menos, a Flinger de superficie (a través de Window Manager en
system_server ) para mostrar algo en pantalla. Es posible que haya más IPCs (Binders u otros).
- Necesita el gestor de actividades, el gestor de paquetes y posiblemente otros servicios que se ejecuten en
system_server que gestionan las clases de la aplicación relacionadas con la creación de actividades y los permisos.
- Necesita
zygote proceso que se ejecuta para bifurcar VMs para system_server y la propia aplicación.
Así que todos estos requisitos deben cumplirse para ejecutar el binario ELF (objeto compartido: /data/app/com.ravipatel.helloworld.test-*/oat/arm64/base.odex ) compilado desde el APK.
A modo de comparación, un programa Java hello world compilado con GCJ enlaza dinámicamente con menos de 5 bibliotecas. Mientras que un programa similar en C (enlazado estáticamente) no tiene dependencias en tiempo de ejecución, excepto la arquitectura requerida.
Supongo que creó un proceso Dalkiv en el kernel de 'Linux' que era simplemente una VM que ejecutaba el dex bytecode.
No. Dalvik no era una máquina virtual basada en el núcleo ( KVM (si es eso a lo que te refieres). Tanto Dalvik como ART son Procesar VMs que se ejecutan en el espacio de usuario.
Para ART, el bytecode dex se compila en instrucciones en la arquitectura del procesador (ocurre durante el proceso de instalación).
Es guiado por el perfil, rara vez ocurre durante el proceso de instalación.
¿Qué es? /runtime ? ¿Es un programa, una biblioteca?
El tiempo de ejecución es un entorno en el que se ejecutan los programas escritos en un lenguaje específico. ART es un tiempo de ejecución para Java. Se compone principalmente de binarios ejecutables nativos / bibliotecas compartidas (incluyendo una VM / intérprete / compilador JIT y compilador OAT) y bibliotecas de clases Java estándar (sobre todo en el de .jar archivos) guardados en /system .
Otro ejemplo muy conocido es Java Runtime Environment ( JRE ) de Oracle/Sun que se encuentra en la mayoría de los PC.
¿Es el Runtime de Android algo que se enlaza junto con el binario ELF generado de dex ¿butecode?
Correcto.
¿Este binario ELF se lanza simplemente como un proceso Linux?
No. El binario ELF compilado a partir de .dex en APK no es un ejecutable sino un objeto compartido. Así que necesita ser cargado en la memoria junto con otras dependencias por algún otro proceso, que es ART (VM).
Supongamos que quiero ejecutar este binario ELF en Linux. Además de ashmem y binder módulos del núcleo, ¿qué más necesitaría? ¿Qué bibliotecas requiere este binario ELF?
En primer lugar, no puedes ejecutar el binario ELF en un sistema Linux que no sea Android porque el binario no es un ejecutable enlazado estáticamente. Pero incluso si lo es, hay limitaciones aún mayores, en particular la abstracción de hardware de Android. binders y ashmem son mecanismos de la CIP. Sólo tienen sentido si los procesos con los que la aplicación quiere comunicarse también existen, lo que no es el caso. Con los SDKs de Java basados en Linux es relativamente fácil de conseguir.
RELACIONADO:
0 votos
¿Has visto? source.Android.com/devices/tech/dalvik/jit-compiler
0 votos
Los binarios ELF suelen ser completamente independientes de Dalvic, ART, .... Simplemente funcionan como lo hacen en todos los sistemas Linux. Pueden requerir algunas bibliotecas enlazadas dinámicamente. Dependiendo de la biblioteca que ya son bahía por defecto presente en el dispositivo o usted tiene que colocar a lo largo del binario ELF. Las aplicaciones pueden simplemente ejecutar dicho binario. Puedes comprobarlo interactivamente usando una aplicación de terminal como Termux.