Chainfire/librootjava

app_process issues on Android Q

KieronQuinn opened this issue · 4 comments

Obviously Q is in early stages at the moment, but it appears something has changed. It seems that app_process (64 in this case) has some restrictions on it, which prevent it from finding the runtime namespace when copied outside of /system/bin.

This is the launch script generated for running:

#app_process=/data/data/com.kieronquinn.app.configurator/cache/.app_process64_cefa02da-6d16-41da-99cb-2a8db8e0d05e
toybox cp /system/bin/app_process64 /data/data/com.kieronquinn.app.configurator/cache/.app_process64_cefa02da-6d16-41da-99cb-2a8db8e0d05e >/dev/null 2>/dev/null
toybox chmod 0766 /data/data/com.kieronquinn.app.configurator/cache/.app_process64_cefa02da-6d16-41da-99cb-2a8db8e0d05e >/dev/null 2>/dev/null
restorecon /data/data/com.kieronquinn.app.configurator/cache/.app_process64_cefa02da-6d16-41da-99cb-2a8db8e0d05e >/dev/null 2>/dev/null
supolicy --live "allow appdomain supersu binder { call transfer }" "allow appdomain magisk binder { call transfer }" >/dev/null 2>/dev/null
NO_ADDR_COMPAT_LAYOUT_FIXUP=1 ANDROID_ROOT=/system LD_LIBRARY_PATH=/system/lib64:/system/lib64/drm:/system/lib64/bootstrap:/system/lib64/hw:/system/lib64/vndk-Q:/system/lib64/vndk-sp-Q:/vendor/lib64:/vendor/lib64/egl:/vendor/lib64/hw:/vendor/lib64/mediacas:/vendor/lib64/mediadrm:/vendor/lib64/soundfx:/data/data/com.kieronquinn.app.configurator/cache:/librootjava CLASSPATH=/data/app/com.kieronquinn.app.configurator-yQZhhz0ii4xqio3QAnC40w==/base.apk /data/data/com.kieronquinn.app.configurator/cache/.app_process64_cefa02da-6d16-41da-99cb-2a8db8e0d05e /system/bin --nice-name=com.kieronquinn.app.configurator:root com.kieronquinn.app.configurator.root.RootLaunch
toybox rm /data/data/com.kieronquinn.app.configurator/cache/.app_process64_cefa02da-6d16-41da-99cb-2a8db8e0d05e >/dev/null 2>/dev/null

Which gives the following result:

Error finding namespace of apex: no namespace called runtime
Aborted

This error comes from the main app_process running line.

If I modify the script to run app_process64 directly from /system/bin, and run just that (not the copying or supolicy lines), as follows:

NO_ADDR_COMPAT_LAYOUT_FIXUP=1 ANDROID_ROOT=/system LD_LIBRARY_PATH=/system/lib64:/system/lib64/drm:/system/lib64/bootstrap:/system/lib64/hw:/system/lib64/vndk-Q:/system/lib64/vndk-sp-Q:/vendor/lib64:/vendor/lib64/egl:/vendor/lib64/hw:/vendor/lib64/mediacas:/vendor/lib64/mediadrm:/vendor/lib64/soundfx:/data/data/com.kieronquinn.app.configurator/cache:/librootjava CLASSPATH=/data/app/com.kieronquinn.app.configurator-yQZhhz0ii4xqio3QAnC40w==/base.apk /system/bin/app_process64 /system/bin --nice-name=com.kieronquinn.app.configurator:root com.kieronquinn.app.configurator.root.RootLaunch

It runs fine, and the Java code runs as expected.

Not really sure if it's an issue in Magisk (as it does seem to have issues with SELinux) or if something has changed in Q.

The android runtime in Q is in an APEX image now and not actually at the same location as before. Pretty sure this behavior is related to some of the APEX changes.

I don't have a device on Q yet. Can you check for me what context your Java process runs as when executed straight from /system/bin ?

ps -AZ

The whole reason we relocate is because we may end up with a restrictive context, if that is no longer true on Q, we can stop doing that. Probably not, but hey let's see.

Fixed in v1.3.0... for now.