Corpse cleaner removes apps on A14?

[cozykitten]

Somehow found my way on here so feel free to ignore my review on SDMaid 2 on PlayStore.

Device: Pixel 6a
Android version: Android 14 (October)
Root: yes, Magisk

I ran corpse cleaner and it found some obsolete(?) apk files.
Since corpse cleaner never showed anything (outside of dalvic cache stuff) I was a bit cautious about removing all of that on SDM2, so I instead ran corpse cleaner from SDM1 first since I assumed that was more likely to be stable and safe, especially since it has this nice colour coding and only showed green.
After that I scanned with SDM2 corpse cleaner and only found safe sounding stuff, like no app files, so I ran that too.

Then my android bugged a bit, duckduckgo would crash on launch, I rebooted and found my phone to be unrooted, and some apps missing, including f.e. magisk, SDM1, Syncthing-fork, overdrop, and some more.

So I reinstalled Magisk, re-rooted, all my settings and modules were still there, it also said "Do you want to install an update for this app" instead of "Do you want to install this app" when installing the Magisk apk, indicating that the app and the others weren't really uninstalled but only somewhat gone.

I added back the missing apps through AppManager backup and PlayStore update did take care of the System Webview and Trichrome library that seemed to have been gone missing as well.

Now I went back to SDM1 and checked corpse cleaner and it looks like the screenshot attached below.
It calls those "incompletely installed APK files" but I'm afraid that might happen again if I press "clean" again.

Might this be an A14 related thing or what might be causing this issue?
Is it safe to delete those apk's?
Screenshot_20231007-151349
Screenshot_20231007-151406
Screenshot_20231007-151412
Screenshot_20231007-151426

[d4rken]

No those don't look safe to delete. I think the detection of SD Maid 1 is not working correctly with Android 14.

What does SD Maid 2 show though?

[cozykitten]

Initially I scanned with SDM 2 and it showed ~4.5gb to remove for the corpse cleaner, since that stroke me as a little unusual that's why I went to SDM 1 and it showed some ~800mb, so I ran that first, thinking I'd be on the safe side with that.
After that I re-scanned with SDM 2 and it only showed a few kb to remove, kinda confusing, but I figured since it wasn't anything major I could run it too.

Now, (after re-rooting, adding things back, including SDM 1) it shows the ~4.5gb on SDM 1 with all the /data/app stuff (as in the screenshots above) and only ~4mb on SDM 2, including /data/app data from com.google.ar.core and com.google.android.accessibility.switchaccess.
It might be worth to note that I recently removed those two system apps with adb shell cmd package uninstall --user 0 <package>.
So perhaps whatever triggered SDM to think the files in /data/app were "leftover" or some "incomplete" files got resolved when SDM ran the corpse cleaner (while also sort of removing the apps)?
Screenshot_20231007-182615
Screenshot_20231007-182604

[cozykitten]

It's not a big deal for me if I can't use them for now, I never had any nasty apps that left leftovers so corpse cleaner usually always found nothing to remove for me on A13.

The main thing I use SDM for is it's app control feature, cause it's easy to sort for latest installed or updated while also filtering for multiple filters at once, such as frozen & system.

That always made it super easy to keep tabs on what new apps got silently added by the latest ota such as f.e. the useless switch access app now.
And it helped to easily identify auto start receivers so I could disable those in AppManager (cuz I don't need instagram to keep running in the background when I only open it once a week).

Kinda off topic, but the new design of SDM 2 is nice, especially that it shows a brief description what each category means.
Although the green, yellow, red markers from SDM 1 were really helpful to quickly signal what to read carefully and what is okay to mindlessly click on.

And thanks to the built in explorer I didn't have to install a separate and mostly ugly root explorer app just to backup my wifi file and stuff.

[d4rken]

So I reinstalled Magisk, re-rooted, all my settings and modules were still there, it also said "Do you want to install an update for this app" instead of "Do you want to install this app" when installing the Magisk apk, indicating that the app and the others weren't really uninstalled but only somewhat gone.

The filter only targets the install files, so the "apk data" was removed, the data was not.

It might be worth to note that I recently removed those two system apps with adb shell cmd package uninstall --user 0 .
So perhaps whatever triggered SDM to think the files in /data/app were "leftover" or some "incomplete" files got resolved when SDM ran the corpse cleaner (while also sort of removing the apps)?

The screenshots of the 3 results in SDM 2 look good in relation to the two uninstalled system apps.

Initially I scanned with SDM 2 and it showed ~4.5gb to remove for the corpse cleaner

This is what concerns me, that sounds like a boatload of false-positives. Why does this not show anymore after a reinstall? Are the same filters enabled?
Can you reproduce this? ⚠️

I went to SDM 1 and it showed some ~800mb, so I ran that first, thinking I'd be on the safe side with that.

SDM 1 support ends with Android 12~13. For 12 it's still tested and safe AFAIK, for 13 it may not work correctly on all ROMs with root, and 14 it's uncharted territory.

Although the green, yellow, red markers from SDM 1 were really helpful to quickly signal what to read carefully and what is okay to mindlessly click on.

It was a very subjective thing though, I just colored them by personal judgement. I'm open to adjusting the UI for this in SDM2. Maybe we open a discussion about this topic, see what other users think?

And thanks to the built in explorer I didn't have to install a separate and mostly ugly root explorer app just to backup my wifi file and stuff.

Interesting use-case. SDM2 doesn't have one because it is a lot of maintenance and very problematic, specifically the cross-filesystem access, e.g. if people tried to copy a file with root from /data/data to an external sdcard. It can be made to work, but it is super painful and impossible to get as polished as I want my features to be... :(

And it helped to easily identify auto start receivers so I could disable those in AppManager (cuz I don't need instagram to keep running in the background when I only open it once a week).

Contentious topic for me, I think most users don't understand how it works and treat all receivers like "Windows autostart". I don't want to be responsible for apps not working correctly and users writing the developers about it.

[cozykitten]

The filter only targets the install files, so the "apk data" was removed, the data was not.

Out of curiosity, why is it a problem if the base apk's are deleted after an app is installed already? aren't they just the "installer files" essentially?
In SDM 2 the setting is called "App installation data, i.e. where APK's go", that would make me think that it would judge all installed apps' apk's as unnecessary and delete them, but SDM 2 only shows entries for the AR-core and switch-access apps, while SDM 1 shows a bunch of like most (or all) of my installed apps.
Stragely enough only about 5-6 apps were affected and not all of the ones that have their apk's in /data/app, that's another thing I don't get, like if I run SDM 1's corpse scanner with that setting and clean, it would remove those apk's for all of my apps.

I would try that and see if perhaps just those 5-6 apps have a problem with this and the other apps just don't care about it or somehow recreate those files, but I don't wanna risk breaking stuff again, would it be safe if I copied the entire /data/app folder, tried it and pasted it back in case something went wrong?
Is that even doable from android permissions point of view, f.e. if stuff breaks apps or the system might write new stuff in there that I would overwrite with the backup I took before, would that be safe to do?

The screenshots of the 3 results in SDM 2 look good in relation to the two uninstalled system apps.

So it's normal that their apk's remain there and removing them won't prevent me from running adb shell cmd package install-existing --user <user> <package> ?

This is what concerns me, that sounds like a boatload of false-positives. Why does this not show anymore after a reinstall? Are the same filters enabled?
Can you reproduce this?

My memory might be playing tricks on me but I'm almost positive that it was SDM 2 that showed those, because I remember being confused about SDM 1 showing only 800mb and after running that SDM 2 showed only a few kb and I wondered how that added up to 4.5gb, so I'm thinking it might've just been a really strange bug.

Idk how SDM does stuff under the hood but perhaps whatever triggers SDM to think those are "incompletely installed apk's" or otherwise unnecessary might've been resolved after reinstalling those apps or restoring them from AppManager's backup.

Sadly I can't reproduce it at all, maybe it would be possible to ask someone who just did the OTA to A14 and didn't run SDM yet since then?

What I really don't get tho is how it would unroot my device... it somehow removed the magisk app but that wouldn't remove root.
Actually, I sideload OTA's to both slots so should I manually switch to the other slot and see if it boots with root or if it's maybe broken and throws me back to the current slot?
Since perhaps it didn't remove root but Android switched me over to the other slot (which was also OTA'd but not rooted)?

It was a very subjective thing though, I just colored them by personal judgement. I'm open to adjusting the UI for this in SDM2. Maybe we open a discussion about this topic, see what other users think?

I think a discussion might be a good idea, personally I think even if it's just your personal judgement, you're still able to mark things as "green" that have no issues being removed, caches and whatnot, and mark things as red that users probably wanna think twice about, such as backups from apps, files in internal storage, files that may affect app functionality, etc

If nothing is marked I don't think most people would take the time to carefully look at every item and think about it, they'd trust SDM to know what's best and delete everything it shows.
But if some of it is red, it's an additional hint "hey you might've checked some additional settings that you might wanna pay extra attention to".

@file explorer

I mean SDMaid isn't primarily a root explorer app so I totally understand where you're coming from, it was just a nice extra so far.

Contentious topic for me, I think most users don't understand how it works and treat all receivers like "Windows autostart". I don't want to be responsible for apps not working correctly and users writing the developers about it.

They (we) probably don't lol, but in the end isn't that the case for SDMaid in general? You could totally delete more than you want to by checking every option or in case of SDM 1 delete stuff through explorer, but I think in the case of disabling / enabling receivers it's not that much of a big deal, after all if some app breaks, 1. it's on the users themselves, 2. it's easily reversible and it's not something that might bootloop the device to my understanding.

If you end up deciding to implement the AppControl feature from SDM 1 in SDM 2 I have a few more suggestions:

• Perhaps the advanced app control features could detect uninstalled system apps?
  I like unninstalling system apps that I don't need for the current user, that way they could still be added back if I needed them with "install-existing", SDM 1 shows them as "stopped" while Androids app list shows them as "Not installed for this user".
• In SDM 1 freezing system apps wouldn't persist after a reboot anymore on A13 (that's why I eventually came across the cmd package commands)
• In SDM 1 disabling autostart receivers would reset after the app got an update, I ended up just finding the "Boot completed" receivers through SDM and actually disabling them with AppManager, since AM doesn't differentiate them from other receivers, idk though if they persist after updates if they're disabled in AM either tho, or if implementing that is even possible or practical.
• Oh and it would be great if it would be possible to hide a multi-selection of apps from showing up in future AppControl scans.
  F.e. I use Iconify and it installs like 100 overlay apk's as magisk module so they work systemlessly but they take a lot of scrolling to get past in SDM (and AM too sadge)

[d4rken]

Out of curiosity, why is it a problem if the base apk's are deleted after an app is installed already? aren't they just the "installer files" essentially?

That's the install, there are not any extra files.

I would try that and see if perhaps just those 5-6 apps have a problem with this and the other apps just don't care about it or somehow recreate those files, but I don't wanna risk breaking stuff again, would it be safe if I copied the entire /data/app folder, tried it and pasted it back in case something went wrong?
Is that even doable from android permissions point of view, f.e. if stuff breaks apps or the system might write new stuff in there that I would overwrite with the backup I took before, would that be safe to do?

Unsure, but you wouldn't have to delete anything, reproducing would just require the files to be listed in the scan results.

What I really don't get tho is how it would unroot my device... it somehow removed the magisk app but that wouldn't remove root.

Root still needs the service provided by Magisk app though, AFAIK.

Actually, I sideload OTA's to both slots so should I manually switch to the other slot and see if it boots with root or if it's maybe broken and throws me back to the current slot?
Since perhaps it didn't remove root but Android switched me over to the other slot (which was also OTA'd but not rooted)?

Plausible

Sadly I can't reproduce it at all, maybe it would be possible to ask someone who just did the OTA to A14 and didn't run SDM yet since then?

I think I can reproduce it.

I took a Pixel 6, flashed Android 13, installed some random apps, rooted it, checked corpses with SDM1 and SDM2, looked okay.
I unrooted, OTA'd to Android 14 Beta2, re-rooted, checked corpses again.

In SDM2 there were like 8MB of dalvik file corpses, likely related to deactivated system apps, looked normal.

In SDM1 though most of the entries of /data/app were listed as corpse, which are likely all false-positives. So could it have been SDM1 in your case and not SDM2?

Then there would be no bug in SDM2 🥳.

I'm thinking about disabling this filter in SDM1 for Android14 though to prevent unexpecting users from causing issues. 🤔

[cozykitten]

Unsure, but you wouldn't have to delete anything, reproducing would just require the files to be listed in the scan results.

What I meant was I could actually run SDM 1 corpse cleaner and let it remove all 4.5gb of app apk's and see if maybe only those 5-6 of my apps mind having their apk's removed and the other ones don't really care about it.

So could it have been SDM1 in your case and not SDM2?

That could totally be the case, as I said, I was pretty sure it was SDM 2 due to me remembering the weird size differnces but it was also early after waking up, I was literally still in bed and I had a doctor appointment the day before and was on meds that made me memory fuzzy, too.

I'm thinking about disabling this filter in SDM1 for Android14 though to prevent unexpecting users from causing issues.

Would def be helpful, if only to calm the "I see results I need to remove" trigger lol.
Either way, even if it was a bug, if it was a unique one-off it's all good and if not then you'll probably hear about it again from someone with better memory anyway :P

[d4rken]

SD Maid 1 v5.6.2 will disable the problematic filter on Android 14.