Sorry, I'm not trying to be obtuse, it was a genuine question. As the options for "system-less" things expands, I think these are valid questions so that we can be sure to all follow the same guidelines.
If no special meaning should be held to the layout of /system, then its no problem to use /su/lib32 and /su/lib64. Perhaps it adds additional complexity to falling back to /system/lib (when relevant) but only trivially so. I guess in hindsight SuperSU could have used /su/lib64 when appropriate, but SuperSU's implementation should be treated as a blackbox anyway (imho) so we shouldn't expect SuperSU to fit "our" patterns.
Regarding mixing libraries, can you elaborate? Is it possible for the dynamic linker to load a 32-bit library into a 64-bit binary (or vice-versa)? I've never had luck with that. Additionally, unless these /su/lib* paths are being added to every process's LD_LIBRARY_PATH, how is the linker ever going to even find them? Remember, at least for Xposed, the libraries placed there are bind mounted to /system (where the linker is actually looking).
Lastly, regarding lib32_bind and lib64_bind, are these documented anywhere? I find nothing in Google for them except for your earlier post today. They seem like what we really want anyway (at least here).
Thanks for the heads up! I learned a lot from your systemless SuperSU, also shamelessly "borrowed" your ramdisk patching binary to save a lot of headache unpacking/repacking boot image . Here I'll answer the questions
The flashing script will also handle the case that /data is not able to mount, such as devices with proprietary encryption that TWRP cannot decrypt correctly. I'll create /cache/su.img if /data/su.img and /cache/su.img are both not found, and place the files over there. I this case, we cannot access the sukernel installed into su.img. Then the mount_xposed.sh should merge /cache/su.img to /data/su.img (the same thing you've done in launch_daemonsu.sh).
What are the disadvantages including the binaries in the package? May you tell me the potential issues that might happen in the future?
Just like what @romracer said, I reflected the layout of /system, so that the flashing script is easy to write. I can separate the library installing commands with their own functions, but I don't see what will really cause problems. I bind mount individual files in the folders, not mirror the whole directory into system. If you're really concerned about the issue, a better way is to put all Xposed released files into a directory, and reflect system folders as subdirectories in that folder (so I don't have to massively change my flashing script).
|android pay, ota, systemless, xposed|
|Thread Tools||Search this Thread|