A fully statically compiled Linux ARM64 binary which only interacts with the kernel through syscalls should run no problem on ARM64 Android. From the kernel's perspective, there is no difference between a "Linux binary" and an "Android binary" because the kernel in Android is Linux.

Most programs want to interact with various system libraries and system services though. Android and your typical desktop Linux system share pretty much nothing aside from the kernel.

▲ pjmlp 4 hours ago | parent | next [-]

Only if they restrict themselves to the officially supported syscalls, otherwise Android will kill the application.

▲ 6 hours ago | parent | prev | next [-]

[deleted]

▲ westurner 17 hours ago | parent | prev [-]

Why is it easier to run a Linux ARM64 binary on Android than to run an Android ARM64 binary on Linux?

My guess is that the reason is the same reason that there aren't official updated Android containers

▲ mort96 17 hours ago | parent [-]

I don't know what you mean by an "Android ARM64 binary". If you make an ELF file containing ARM64 machine code, it doesn't matter to Linux whether you meant for it to run on Linux in an Android system, on Linux in a desktop GNU system, or on Linux in some environment with without much of a userspace at all (such as a stripped down initramfs environment).

If you mean something like an Android app, the answer is that there's a ton of system stuff that the app depends on, it interacts with more than just the kernel.

▲ westurner 4 minutes ago | parent [-]

  CC= clang
  CXX=clang++
  $CC hello.c -o hello_android_c
  $CXX hello.cpp -o hello_android_cpp -static-libstdc++
  $CXX hello_asm.cpp -o hello_android_cpp_asm_syscalls_only -ffreestanding -nostdlib -fuse-ld=lld
  find -name hello_android -exec readelf -l {} \;

But go binaries don't require (bionic) libc unless you compile with CGO_ENABLED=1