What is needed to run ELF binaries compiled from android APKs? (understanding android internals) I'm trying to understand how Android works internally. Before ART, it used Dalvik to run java code. I guess it created a Dalkiv process in 'Linux' kernel which was simply a VM that ran the dex bytecode.

For ART, the dex bytecode is compiled into instructions in the processor's architecture (happens during the installation process). This compiled dex bytecode is stored into an ELF binary. So it's somethig that 'Linux' kernel can understand.

So suppose I wanted to run this ELF binary on Linux. Besides ashmem and binder kernel modules, what more would I need? Which libraries do this ELF binary require? Is this ELF binary simply launched as a linux process? 

I tried reading anbox.io source code, but I couldn't understand how it launched an ELF binary from an APK. Maybe understanding what it's required to run it will make me understand anbox.io's source code better.

I also found https://android.googlesource.com/platform/art/+/refs/heads/master/runtime/ but I don't know where to begin. What is /runtime? Is it a program, a library? Is Android Runtime something that is linked together with the ELF binary generated from dex bytecode?
What is needed to run ELF binaries compiled from Android APKs?


A simple hello world app which does nothing except printing Hello World! (no animations, no sounds, no menus), running on Android 9 device:


Opens 30+ files, anonymous inodes and UNIX sockets explicitly.
Shares 500+ memory-mapped files from /data, /system, /vendor and /dev.
Communicates, at least, to Surface Flinger (through Window Manager in system_server) to display something on screen. There can possibly be more IPCs (Binders or others).
Needs Activity Manager, Package Manager and possibly other services running in system_server which manage app's classes related to activity creation and permissions.
Needs zygote process running to fork VMs for system_server and the app itself.


So all of these requirements must be fulfilled to run ELF binary (shared object: /data/app/com.ravipatel.helloworld.test-*/oat/arm64/base.odex) compiled from APK.

As a comparison, a hello world Java program compiled with GCJ dynamically links to less than 5 libraries. While a similar C program (statically linked) has no runtime dependencies except the required architecture.


  I guess it created a Dalkiv process in 'Linux' kernel which was simply a VM that ran the dex bytecode.


No. Dalvik wasn't a Kernel-based Virtual Machine (KVM; if that's what you mean). Both Dalvik and ART are Process VMs which run in userspace.


  For ART, the dex bytecode is compiled into instructions in the processor's architecture (happens during the installation process).


It's profile-guided, rarely happens during the installation process.


  What is /runtime? Is it a program, a library?


Runtime is an environment in which programs written in a specific language run. ART is a runtime for Java. It mainly consists of native executable binaries / shared libraries (including a VM / interpreter / JIT compiler and OAT compiler) and standard Java class libraries (mostly in the from of .jar files) saved in /system.

Other well-known example is Java Runtime Environment (JRE) by Oracle/Sun which is found on mostly PCs.


  Is Android Runtime something that is linked together with the ELF binary generated from dex bytecode?


Correct.


  Is this ELF binary simply launched as a Linux process?


No. The ELF binary compiled from .dex file in APK is not an executable but a shared object. So it needs to be loaded in memory along with other dependencies by some other process, which is ART (VM).


  So suppose I wanted to run this ELF binary on Linux. Besides ashmem and binder kernel modules, what more would I need? Which libraries do this ELF binary require?


First of all you cannot run the ELF binary on a non-Android Linux system because the binary is not a statically linked executable. But even if it is, there are even bigger constraints, particularly Android's hardware abstraction. binders and ashmem are IPC mechanisms. They make sense only if the processes to whom the app wants to communicate also exist, which is not the case. With Linux based Java SDKs it's relatively easy to achieve.



RELATED:


Android apps for “armeabi-v7a” and “x86” architecture: SoC vs. Processor vs. ABI
AOT Compilation in HotSpot (jaotc)
JIT vs. AOT: Unity And Conflict of Dynamic and Static Compilers