[Android Apps and Games] Dark3n:
SD Maid v4.6.3 because there is always something to improve.

Remarks:

I've changed the way SD Maid detects the correct architecture for a device. This mainly affects X86 and MIPS devices where SD Maid used the ARM binary due to emulations modes existing that could make this work. SD Maid should use the "preferred" architecture in most of these cases such that emulation modes are not used. I'd love some feedback from people with non-ARM devices whether a difference in performance is noticeable.

In v4.6.2 I introduced a bug that was actually nice to have. The change caused SD Maid to crash if APK export failed (because SD Maid tried to read a value out of an empty list). Within the crash reports i spotted that the reason for the failing export was actually another bug within the "ShellTasks" that SD Maid executes (ShellTasks are SD Maids Java wrapper for IO operations via shell). Whether something fails it's usually detected via shell command exitcode. In this case it was not the actual `cp` command that failed but a `mount` command before and after it. If necessary SD Maid can remount read-only storages to make modifications. This is internally done by supplying an `autoRemount` flag when creating the ShellTask. For safety reasons this is usually only set for tasks originating from Explorer, Searcher or AppControl, as other tools don't have a reasonable use-case where they need to delete something from a read-only storage.

Checking the code I've first noticed that not all ShellTasks actually honored the `autoRemount` flag, move+delete did, but copy didn't. So the task shouldn't have attempted to remount anyways, checked and fixed this for all tasks where this was not the case. Bug fixed, case closed, go to sleep.

Wait a sec. Why was it remounting anyways, doesn't the export by default go to primary public storage? When has that ever been mounted read-only... Checking crash logs again I could see that SD Maid looked up the mountpoint for `/storage/emulated/0` and returned `/`. So SD Maid couldn't find a closer match than that and just went with this. Well emulated storage is always a special case so I've just made the decision to exclude all storages flagged as `EMULATED` from remounting.

Why did remounting `/` fail though, SD Maid can remount that... oh the crashing devices were not rooted... remounting without root doesn't work in any case I know, so lets also automatically set `autoRemount` to false on shells that are not running with root. So the little export crash actually helped fix 3 different issues.

A bit more extra refactoring work and I could also test this well so I added ~20 unit tests to cover these remount cases. I'm quite happy with the results. The world of Android and rooting never stops suprising :).

http://sdmaid.darken.eu/download

http://sdmaid.darken.eu/changelog

http://sdmaid.darken.eu/issues﻿

On a sidenote for the LG G5/V20 users out there:

There is probably a bug in LG's 7.0 ROM for a few devices which can cause random crashes if an app tries to use the API to kill other apps.

It's pretty standard api call that throws an NullPointerException in it's internal routines.

For more details see here:

https://github.com/d4rken/sdmaid-public/issues/748

The fix is pretty easy, if an app dev wants to do LG users a favor (which I did <3) but yay Android fragmentation :rolleyes:.