Question: Should I be able to execute AOSP binaries via the adeb shell?

[kheaactua]

adeb is awesome in that I now have my usual zsh shell with vim working on my device (much like Termux on my phone), my original hope though was that I would get tools like ldd and be able to execute AOSP binaries via the adeb shell (and vice versa execute adeb binaries via the adb shell)

Using readelf I see that a different linker/interpreter is used (/lib/ld-linux-aarch64.so.1 vs /apex/com.android.runtime/bin/linker64 (not mounted in the adeb shell)). Is there however a way to execute AOSP binaries?

In one AOSP training exercise I did before finding adeb, we setup a rootfs system, manually built binaries with a gcc toolchain, installed all the deps in /lib and /lib64, and I was able to execute these from the adb shell.

Thanks

[bjacob]

I'm running into this now. To be clear, the symptom is: unable to execute any command-line program built by the Android NDK toolchain. Indeed, these have the linker mentioned in the above question, in /apex, which is not mounted, as explained above. Just pointing out that the issue is really far-reaching - I'd like to use adeb to profile with perf my binaries built with the Android NDK toolchain, I'm not looking to replace my toolchain altogether.

[senyuuri]

Same issue here. I think this only affects Android 10+ which introduced a new apex mechanism (https://source.android.com/devices/tech/ota/apex) to make low-level system components (e.g. the bionic runtime) upgradable. According to apex's documentation, apex components are essentially zip files under /system/apex. Each zip file contains an image named apex_payload.img which includes the actual system bins/libs (e.g. bin/linker64). The documentation has also briefly described how to mount it:

At next boot, the APEX manager starts, reads the internal database, and does the following for each APEX file listed:

• Verifies the APEX file.
• Creates a loopback device from the APEX file.
• Creates a device mapper block device on top of the loopback device.
• Mounts the device mapper block device onto a unique path (for example, /apex/name@ver).

You can see how apex files are mounted through /proc/mount

~$ adb shell cat /proc/mounts
...
/dev/block/loop24 /apex/com.android.runtime@1 ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop24 /apex/com.android.runtime ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop25 /apex/com.android.cellbroadcast@300000000 ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop25 /apex/com.android.cellbroadcast ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop26 /apex/com.android.extservices@300000000 ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop26 /apex/com.android.extservices ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop27 /apex/com.android.vndk.v28@1 ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop27 /apex/com.android.vndk.v28 ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop28 /apex/com.android.vndk.v29@1 ext4 ro,dirsync,seclabel,nodev,noatime 0 0
/dev/block/loop28 /apex/com.android.vndk.v29 ext4 ro,dirsync,seclabel,nodev,noatime 0 0

However, somehow I can't mount a loop device in adeb.

root@localhost:/home# cp /system/apex/com.android.runtime.apex /home
root@localhost:/home# unzip com.android.runtime.apex
root@localhost:/home# file apex_payload.img
apex_payload.img: Linux rev 1.0 ext2 filesystem data, UUID=7d1522e1-9dfa-5edb-a43e-98e3a4d20250 (extents) (large files) (huge files)
root@localhost:/home# mount -t ext2 -o loop,rw apex_payload.img /mnt/apex_payload/
mount: /mnt/apex_payload/: failed to setup loop device for /home/apex/apex_payload.img

The only partial workaround that worked for me was to manually extract the content of apex_payload.img (using exftstools https://github.com/nlitsme/extfstools.git) then copy it over to the original mount point of the corresponding volumes. This fixes broken links in the system libs (see below. because /apex doesn't exist ).

root@localhost:/# ls /system/lib64/libc.so -l
lrw-r--r--. 1 root root 46 Jan  1  2009 /system/lib64/libc.so -> /apex/com.android.runtime/lib64/bionic/libc.so
root@localhost:/# file /system/bin/linker64
/system/bin/linker64: broken symbolic link to /apex/com.android.runtime/bin/linker6

However, simply copying the files over breaks uprobes in bionic libraries. For example, if you try to attach to a pthread_create uprobe in/apex/com.android.runtime/lib64/bionic/libc.so(like #35), bcc will show an empty output.

root@localhost:/# vi /usr/share/bcc/tools//threadsnoop
# point the path to the bionic libc
b.attach_uprobe(name="/apex/com.android.runtime/lib64/bionic/libc.so", sym="pthread_create", fn_name="do_entry")

root@localhost:/# threadsnoop
TIME(ms)   PID    COMM             FUNC
^C

[buzhishishi]

Hi , I have the same problem： b.attach_uprobe(name="/apex/com.android.runtime/lib64/bionic/libc.so", sym="strlen", fn_name="count"); Monitoring and management in place