lxc-android: Support non-flattened APEXs

[erikinkinen]

This is required for Android 14 support as AOSP has dropped support for flattened APEXs. This also requires APEX mounting to be moved before container start due to the new vndk APEX containing libc.so.

[g7]

Hmm, looks good to me, I will try to run this on my android 11 and 13 devices this weekend.

We might consider to split the apex mounting stuff in a separate tool, not a super fan of having to mix python here with the rest. But can be done in a second moment 😉

[g7]

aren't we filtering too much here? I have quite a lot of more mounted APEXes with the old method

[g7]

Okay, so I checked this on bahamut.

Aside from the aforementioned thing on the too strict filter (I would mount them all to be honest):

1. On api30 at least, /android/system/apex/com.android.vndk.current gets mounted to /android/system/apex/com.android.vndk.v30, while here this is not handled and gets mounted to com.android.vndk.current

2. WLAN broke for me. I think it is due to the notify signalling now being faster (since we're not awaiting apexd anymore). Adding an (overkill) sleep 30 in lxc-android-notify fixed it, but I suppose this is a behaviour change that might bite other devices too.
   I think it is fair to expect that when systemd notifies that the lxc-container is ready, the apexes are properly mounted both in the system AND the container

This makes me wonder... is the problem that waitforservice cannot run since the apexes are not flattened? What if we keep the logic as before and just mount com.android.runtime if needed? Then we can wait for apexd as before and replicate the bindmounts

[erikinkinen]

@g7 , hmm, what if we try mount these 4 in mount-android.sh and then do the rest and wait for apexd in lxc-notify? libhybris not finding libc.so caused other issues as well between mount-androis.sh and lxc-notify iirc.

[g7]

yeah sounds sensible to me, just mount what is needed to wait and then wait