SD Maid v4.3.4 took a lot of work for relatively few changes.
A few crash fixes but mostly a new way of setting up busybox/toybox binaries.http://sdmaid.darken.eu/downloadhttp://sdmaid.darken.eu/changeloghttp://sdmaid.darken.eu/issues
Let me tell you a story about developing a root app:
Since some 5.0+ Android version SELinux forbids apps to run binaries from their own folder in /data/data with root permission. This sucks because some apps need to run it's binary from /data/data with root (including SD Maid).
What now? A bit of research showed that this restriction only exist for certain places, copying SD Maids binary with root into /system would work, but copying binaries into /system is uncool though modifying /system screws with OTA updates and other things.
Although a rooted device likely modified /system already it would be way cleaner if SD Maid just wasn't part of that equation. A bit more research showed that there is also no restriction for binaries placed in the RootFS (e.g. /strawberry), as the RootFS sits in RAM and gets wiped on reboot, this would also mean any changes SD Maid makes there are gone after a reboot, yay that's clean! So i wrote a system that tries different approaches to get this to work:
* Try SD Maids internal path (the default app files)
* If that fails we check if we can just use something pre existing on the device
* Can't use default and nothing existing allows us to work so we try RootFS, by first checking whether a systemless su install already created a location in RootFS, otherwise we make our own
* If that fails too we can only resort to placing our binary into /system which is the last resort effort before giving up and relinquishing root access
This all worked nice and well for a long time, until enough bug reports collected in the crash tracker to become noticeable. The reports said SD Maid couldn't detect any storages at all. People to so much weird stuff with rooted devices and I didn't think this was a bug for a while. Initially I was pretty stumped on the causes, but through a few users that made the effort to mail me about this I figured it out. Not all devices/rom combinations allow executing a binary from RootFS without root! Oh right, makes sense. So I just made SD Maid use root for this and published v4.3.1.
All was well in SD Maid world until I started to get mails about SD Maid showing no storage information for the sdcard or not detecting it all. sigh
But thanks to the effort of a few users, supplying debug logs, this was quickly figured out. Depending on the superuser application (and superuser application settings, e.g. SuperSUs "Mount namespace separation") and your ROM, looking up mounts as root returns different results than looking them up without root. To be honest here, i knew about this behavior, but forgot about it... (and didn't notice it because I used SuperSU with "Namespace separation" turned on for testing). So the problem is easy enough to fix right? Call it once with root and once without, then merge the results.... Well, remember the above? There are devices where binaries can't be run from our apps folder with root and can't be run without root from RootFS. Sure we could jam the binary into /system which allows both user and root to access it but as mentioned, this is pretty dirty and SD Maid is all about neat & tidy, right?
So I thought this can't be too common, let's just add a fallback method that tries to use the default mount applet from /system, while they usually don't work very well to remount stuff, just listing the mounts should reliably work... and v4.3.3 was published.
But.... nope. Trying the system's native mount applet wasn't reliable at all, not even just for listing mounts. This was aggravated by SD Maids not calling applets directly, but by using a list of applets that were checked for compatibility during setup and this checking was quite harsh (as it should be though) and also ruled out most native mount applets.
v4.3.4 enters the stage. I bit the bullet and rewrote every line of code that uses a binary, to ask for a specific binary (user/root) and rewrote SD Maids setup routine to allow setting up two different binaries in two different locations if that means avoiding modifying `/system`. The new routines setup binaries preferring a single binary over multiple while opting for the least invasive way that allows SD Maid to work with root on the device (own-locations > pre-existing > rootfs_systemless > rootfs_custom > system_inject).
Oh my, what don't I do to keep your devices neat & tidy :).
If this finally fixes the storage detection / mount detection issues, it can go into production.