Profile cover photo
Profile photo
I enjoy Android development!
I enjoy Android development!

darken's posts

Post has attachment
Anyone up for testing a filter for old WhatsApp backups?

v4.7.2 with some core changes and little bit of features and fixes.

The actual update was 4.7.0, but it had a bug.
Then there was 4.7.1 which was supposed to fix 4.7.0, but I didn't understand the bug yet so my bugfix didn't work, at least that's what the bugtracker told me when I woke up.
But the few hours of sleep helped and when I understood the issue the fix was trivial. I've added a few tests to prevent this mistake in the future and 4.7.2 was born :).

There are quite a few core changed related to setting up and using binaries (e.g. toybox/busybox).
There are more details here:
But the gist of it is that SD Maid can now mix and use applets from multiple binaries.
This allows SD Maid to better support different ROMs and work around security restrictions (e.g. applets only working from specific locations).

Okay, enough of that what else is interesting?

Custom filters now support max/min file age (last modification). Based on ticket #333, the idea is that this would allow for a filter that deletes old WhatsApp backups. Maybe some crafty users can build a filter for that and if it works well we integrate it as a default option.

SD Maid can't always be sure about an apps size, this is now visible in AppControl. So instead of "5MB" you will see "5MB >" because SD Maid thinks there is more, but doesn't know exactly (possibly due to permission issues).

SD Maid should now also run fairly well on Android O, at least without root (how do i root my Pixel on Android O?).

For more details please check the full changelog.

SD Maid stuck at "In queue".
I'm getting reports that since a few updates ago SD Maid is stuck at "In queue" on unrooted devices. As far as I can tell SD Maid is stuck during root check. Disabling it via the debug menu fixes it.

It would help me a lot if someone with this issue could record a debuglog and mail me the logfile. Unfortunately no one was able to do so yet among those who reported this.

Post has attachment
v4.6.5 is now in rollout to production.

Lots of little improvements:
• Improved translations
• Updated clutter database
• Improved hidden cache filter
• Improved preview loading
• Fixed sharing (correct file type)
• Replaced searcher exclusions with extra filter field
• Fixed UninstallWatcher on Android O
• Fixed app size determination without root
• Fixed accessibility related text size issues
• Various design/layout tweaks.

There are still quite a few issues on Android O but I'm working on them. New beta coming soon too.

For more details please check the full changelog.

Post has attachment
v4.6.5 yay!

Lots of little improvements.

Some notes:
I've refactored root related code, added tests and changed some structures that will make it easier to move it into an extra module. I fancy the idea of open sourcing a few root related parts of SD Maid as I think it would help the root app community to have better tools.
Moved analytics tracking to full encryption (yay letsencrypt), update check will follow in a future update.
I rewrote the code related to enabling the "Pro" features. Instead of a "isPro()", it's now more of a "hasFeature(X)". Overall consolidating the pro/upgrade related code. I want to test different ways of upgrading SD Maid, maybe making it optional to actually install the unlocker app. I don't have a good solution yet because Google doesn't offer good access to purchase related data. So for now I'm just experimenting a bit, it certainly doesn't hurt to improve SD Maids architecture, even if we don't use it yet. Good architecture makes us future proof :).
I've got my eye on Android O, but didn't do much testing yet. There are a few tickets on the issue tracker related to changed we need to make and a few things are already fixed in this update. If you are already using Android O and notice issues that are not on the tracker yet, please make a ticket.

Post has attachment
Any input on this issue?

When would one use searcher exclusions?
What's the usecase here?

Post has attachment
SD Maid v4.6.4 is now rolling out.

• Updated translations and clutter database
• Improved clutter matching (regular expression support)
• A few crash fixes
• Internal code changes to improve automated tests

Post has attachment
Sorry for the late post, so yeah there is a new beta, v4.6.4.

The changes are mostly under the hood.
I've refactored code to improve unit testing and also improved the clutter matching system.
So now instead of defining "/sdcard/AppDev"<>"com.appdev.someapp", "/sdcard/AppDev"<>"com.appdev.someotherapp" etc., we can just create a clutter marker "/sdcard/AppDev"<>"com.appdev.*".
This reduces the chance for false positives as now any new app matching this pattern would automatically be matched correctly instead of requiring a manual database update.

Post has attachment
SD Maid v4.6.3 is now the latest production version and currently in staged rollout.

• Faster AppCleaner deletion and scan
• Support for `/data/sdext2`
• More StorageAnalyzer infos.
• Corpse filter for Link/App 2SD
• Faster AppControl scan and more details without root
• Fixed copy/export issue to emulated storage
• Improved binary setup on MIPS/X86
• Updated clutter definitions & translations
• Various UI tweaks & internal code changes.

If you want a few more details than what the changelog provides, checkout these posts.


v4.6.1 - v4.6.2:


Post has attachment
SD Maid v4.6.3 because there is always something to improve.

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 is 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 device 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 :).

Wait while more posts are being loaded