Check for dependant apps and suggest deletion if dependencies not met

[mbirth]

Create database of dependant apps, e.g. "Taskei" or "Pics from Reddit" - both only work when "Muzei" is installed. However, Muzei is the only one with a launcher icon, so when uninstalling Muzei, you might forget to uninstall the other two.

SD Maid should check for dependencies and suggest uninstalling apps when their dependencies are not met.

[d4rken]

Intresting idea. Is this a common enough use-case to warrant this? After all it's another database we have to maintain and update.

This first use-case that comes to mind for me is stuff like apps with themes. Where you have e.g. a keyboard app and dozens of different theme "plugin" apps. What about unlocker apps?

This would be used by AppControl when uninstalling apps and by the CorpseFinder when searching for leftovers. Probably as a new corpse filter module and as an extra option in AppControl. What do you think?

There are quite a few cases we have to think about:

• Chained dependencies: App4 depends on App3, App3 depends on App2, App2 depends on App1. If App1 is uninstall do we suggest App2, App3 and also App4 for deletion?
• What about an app with multiple dependencies and only one of the dependencies is uninstalled? App1 depends on App2 and App3. We uninstall App2, do we uninstall App1?
• Are dependencies strictly hierachical? Or can they form circles, meaning if there is a set of 3 apps and any one of them is installed, the other two will be suggest for deletion?

[mbirth]

I think chained dependencies are very rare. Most cases I've seen are simple unlocker apps, plugins or extensions. Specific examples:

• AutoNotification (has icon) + AutoNotification Unlocker (hidden, depends on AutoNotification)
• FX + FX Key (same as above)
• Muzei (has icon) + Pics from Reddit (no icon, depends on Muzei), Taskei, all other Muzei extensions
• Automate (has icon) + various permissions plugins
• Amazon + Amazon Video (both have icons), where Video doesn't work without the main app (afaik)
• Android Wear + various AW plugins/watchfaces/extensions
• Special case: Solid Explorer Unlocker can be used for the old version AND the new version of Solid Explorer, so it depends on either one and should only be suggested for uninstall if BOTH dependencies are missing.

I don't think you have to watch out for chained dependencies. In the worst case, the remaining app would pop up on the next run of CorpseFinder (or even during uninstall with AppControl).

Multiple dependencies should always be OR'd, so if you uninstall one but not the other, the app should stay. (Are there "bridge"-apps, which need exactly two other apps to work?)

Circular references are interesting. I'm not sure if this can become a problem... but the parser should at least stop when it finds the same app twice, to not end up in an endless parsing loop.

To be researched: Is it possible to get dependencies from the Manifest (permissions)? If so, you wouldn't need to maintain another database and could use the info from the device.

[d4rken]

Multiple dependencies should always be OR'd, so if you uninstall one but not the other, the app should stay. (Are there "bridge"-apps, which need exactly two other apps to work?)

Probably tasker plugins? Some need the app they provide functionality for, and they also need the tasker app (probably applies for apps similar to tasker too).

To be researched: Is it possible to get dependencies from the Manifest (permissions)? If so, you wouldn't need to maintain another database and could use the info from the device.

I don't think so, maybe in some edge cases where apps declare custom permissions for each other. But I don't think this would work without another database, stuff like SD Maid + Unlocker would not be detectable.

One more issue would be that this could also lead to false positives again, where an app has more "parent apps" than we think and we erroneously suggest it to be removed, despite the other parent app being installed. This is already an issue with the current clutter databases, would this be more or less likely to happen with app dependencies? Maybe with inclusion of another database we should think about making this and the clutter database remotely updateable. I'm thinking about something like publishing the database file in this repo and SD Maid can download it from a beta or production branch depending on its build. Users could then also transparently submit new dependencies that I could merge. To prevent unexpected behavior such an update should probably only happen on demand?

We could start by building a list of dependencies in this or another ticket and then once we have enough data to warrant it, I could start coding a module for it.

[mbirth]

Probably tasker plugins? Some need the app they provide functionality for, and they also need the tasker app (probably applies for apps similar to tasker too).

At first, I thought of AutoWear, a Tasker plugin for Android Wear. You could think it would depend on Android Wear and Tasker. But it actually only depends on Tasker, because Android Wear works fine without it, and so does Tasker. And the plugin also works without Android Wear (or will show an error in Tasker), so that's not something SD Maid should be adapted for. Only when Tasker is missing (and all other apps working with Tasker plugins), the AutoWear plugin should be suggested for uninstall.

N.b.: For Tasker plugins, there needs to be a list of all apps which can handle Tasker plugins, e.g. Tasker, Automagic, Automate, Locale (not sure?) and maybe a few more. I think we should be able to gather most from the Play Store listings.

One more issue would be that this could also lead to false positives again, where an app has more "parent apps" than we think and we erroneously suggest it to be removed, despite the other parent app being installed. This is already an issue with the current clutter databases, would this be more or less likely to happen with app dependencies?

Yes, this could happen. SD Maid should never automatically try to uninstall anything. And maybe show a warning window every time the user wants to uninstall something (with a checkbox [X] I've understood.) which explains that it's possible there are more apps needing this and how to report this.

And online updateable database would be awesome. (btw: I'm missing the reporting feature for directories and their apps in the Explorer) And update-check should show if there is a newer database available, the update itself should be manually at first - with the option to update it automatically.

We could start by building a list of dependencies in this or another ticket and then once we have enough data to warrant it, I could start coding a module for it.

What format would be best for you to import into a database later?

[d4rken]

N.b.: For Tasker plugins, there needs to be a list of all apps which can handle Tasker plugins, e.g. Tasker, Automagic, Automate, Locale (not sure?) and maybe a few more. I think we should be able to gather most from the Play Store listings.

Well that's the tough part, we can never really be sure we got all possible parent apps and not missed...

Yes, this could happen. SD Maid should never automatically try to uninstall anything. And maybe show a warning window every time the user wants to uninstall something (with a checkbox [X] I've understood.) which explains that it's possible there are more apps needing this and how to report this.

The CorpseFinder would have an extra filter and for AppControl these things would have to be determined on scan and could then be listed in details and and be shown within the confirmation dialog. What gets a bit difficult is making the CorpseFinder uninstall such an orhphaned app completely. It would have to run the AppControl routines, otherwise we just remove the app, but then on second scan might find corpses from the just uninstalled app. The CorpseFinder has no notion of "Uninstalling apps", and only knows removing files.

(btw: I'm missing the reporting feature for directories and their apps in the Explorer)

You either need to have an email in the bug report settings or be in debug mode 2. It sucks to have to make this to cumbersome, but even now the amount of nonsense reports is overwhelming. From 200 reports, 185 are bullshit, even with weird messages in the comment field 😦 .

And update-check should show if there is a newer database available, the update itself should be manually at first - with the option to update it automatically.

Valid for AppControl and CorpseFinder so probably in general settings or advanced settings?

What format would be best for you to import into a database later?

I'm tending to JSON currently as it makes handling a bit easier than XML, all but the clutter data base is already moved to JSON format in V4. For actual structure we would first need to come up with a scheme. If multiple plugins can depend on multiple apps, we have some kind of N-to-N relation ship. What kind of info do we need? For the database:

• A version number

For the entries:

• A list of parent packagenames
• A list of child packagenames

Should we call it parent & child or do you have a better idea? How do we handle multiple entries? What is valid and what isn't valid?

• {ChildA,ChildB} depends on {ParentD}
• {ChildB} depends on {ParentC}

Is that allowed? Or would it have to be:

• {ChildA} depends on {ParentD}
• {ChildB} depends on {ParentD,ParentC}

Do we need some kind of extra flags or options for an entry, such as the current KEEPER flag for clutter entries?

[SuperSandro2000]

Should we call it parent & child or do you have a better idea?

I just thought off depends_on and dependency_of

{AppA} depends on {AppD} {AppB} depends on {AppC,AppD}

{AppD} is a dependency of {AppA,AppB}

Do we need some kind of extra flags

Some Apps could be system components. I could imagine ARCore on newer VR orientated devices but they don't need to be. Maybe always keep System apps. Maybe we would need soft and hard dependencies too. Can't think of an example right now but AppA could depend on AppB and AppC but could function in a limited way without C. Maybe it shows a prompt to install C on the next run and shouldn't be deleted.