Since redroid 15, the x86_64 images advertise arm64-v8a in the ABI list but do not ship a native bridge. The result is that ARM-only apps install successfully and then crash the moment they are opened, which is a worse experience than refusing to install them.
Measured on a build from the current branches:
ro.dalvik.vm.native.bridge = libnb.so
ro.product.cpu.abilist = x86_64,arm64-v8a,x86,armeabi-v7a,armeabi
libnb.so does not exist anywhere in the tree. device/redroid/redroid_x86_64/device.mk has declared that name since the native bridge support was added, and nothing provides it.
The package manager reads the ABI list at install time, so an ARM-only APK is accepted and given primaryCpuAbi=arm64-v8a. libnativebridge then fails to load libnb.so at launch.
Why this is a decision, not a patch
The translator (libndk_translation.so and its proxy libraries) is a proprietary Google binary that has to be extracted from the official emulator system images. It cannot be redistributed, so it cannot simply be added to the published images. I assume that is exactly why redroid does not ship one.
That leaves two consistent options, and picking between them is yours:
1. Keep ARM support, and let the user supply the translator.
Point ro.dalvik.vm.native.bridge at the real name and document that the user must extract the translator from Google's emulator images themselves. Working, but it needs a documented extraction step and the ABI list is only honest once that step has been done.
2. Stop advertising arm64-v8a.
Drop it from the ABI list, so ARM-only apps fail cleanly at install time with a reason the user can act on, instead of crashing later with a stack trace that points nowhere useful.
Option 2 is a two-line change and makes the current behaviour honest. Option 1 is more work but keeps a feature people clearly want.
What I can contribute
I have this working on Android 17 with the translator extracted from the API 37.0 emulator image: VLC 3.7.1 arm64-only runs with its native libraries loaded, and Termux installs its bootstrap and runs ARM binaries through binfmt_misc.
Two things I found along the way, in case they are useful whichever option you
pick:
-
The API 36 translator does not load on Android 17. It fails with dlopen failed: library "libndk_translation.so" not found, which sends you looking at linker namespaces. The API 37.0 one loads first try with no other changes.
-
Google's own binfmt_misc launcher has a bug. With the P flag the kernel calls interpreter <path> <original-argv0> [args], but the launcher resolves the executable from argv[0] instead of from the path, so a program invoked by name (the normal case, since execvp keeps the short name as argv[0]) fails with Unable to get realpath of <name>. This is what stops Termux from installing its bootstrap. I have a fix written against AOSP for that one.
My open Android 17 pull requests deliberately leave this alone, because neither option is mine to pick. Once you decide, I will send a separate pull request for it.
Since redroid 15, the x86_64 images advertise
arm64-v8ain the ABI list but do not ship a native bridge. The result is that ARM-only apps install successfully and then crash the moment they are opened, which is a worse experience than refusing to install them.Measured on a build from the current branches:
libnb.sodoes not exist anywhere in the tree.device/redroid/redroid_x86_64/device.mkhas declared that name since the native bridge support was added, and nothing provides it.The package manager reads the ABI list at install time, so an ARM-only APK is accepted and given
primaryCpuAbi=arm64-v8a.libnativebridgethen fails to loadlibnb.soat launch.Why this is a decision, not a patch
The translator (
libndk_translation.soand its proxy libraries) is a proprietary Google binary that has to be extracted from the official emulator system images. It cannot be redistributed, so it cannot simply be added to the published images. I assume that is exactly why redroid does not ship one.That leaves two consistent options, and picking between them is yours:
1. Keep ARM support, and let the user supply the translator.
Point
ro.dalvik.vm.native.bridgeat the real name and document that the user must extract the translator from Google's emulator images themselves. Working, but it needs a documented extraction step and the ABI list is only honest once that step has been done.2. Stop advertising
arm64-v8a.Drop it from the ABI list, so ARM-only apps fail cleanly at install time with a reason the user can act on, instead of crashing later with a stack trace that points nowhere useful.
Option 2 is a two-line change and makes the current behaviour honest. Option 1 is more work but keeps a feature people clearly want.
What I can contribute
I have this working on Android 17 with the translator extracted from the API 37.0 emulator image: VLC 3.7.1 arm64-only runs with its native libraries loaded, and Termux installs its bootstrap and runs ARM binaries through
binfmt_misc.Two things I found along the way, in case they are useful whichever option you
pick:
The API 36 translator does not load on Android 17. It fails with
dlopen failed: library "libndk_translation.so" not found, which sends you looking at linker namespaces. The API 37.0 one loads first try with no other changes.Google's own
binfmt_misclauncher has a bug. With thePflag the kernel callsinterpreter <path> <original-argv0> [args], but the launcher resolves the executable fromargv[0]instead of from the path, so a program invoked by name (the normal case, sinceexecvpkeeps the short name asargv[0]) fails withUnable to get realpath of <name>. This is what stops Termux from installing its bootstrap. I have a fix written against AOSP for that one.My open Android 17 pull requests deliberately leave this alone, because neither option is mine to pick. Once you decide, I will send a separate pull request for it.