Optionally filter out anti-features

Either enabled or disabled by default, we should offer the option to hide apps with certain anti-features.

This used to be the case in very old versions of F-Droid prior to content providers. I think they got dropped because they were non-trivial to port over to the new system, and making F-Droid not crash due to out-of-memory exceptions was more important.

@pserwylo since you wrote the whole the whole content provider stuff, perhaps you have an idea on how to implement this? If you explain it briefly, maybe someone else will provide a patch.

Note that I hadn't opened this yet because I was sure we already had an issue for it. But seeing that I can't find it, opened one.

Added ~16415 label

Replicant specifically requested this. They include F-Droid by default, but do not like that by default it shows non-free apps, or apps that promote or rely on non-free things.

There are no non-free apps in our repo. Unless you mean the one app that is using a non-commercial license for its layouts.

I think Replicant's definition is stricter, as is anything that relies on something non-free to functional. Something like NewPipe as it is now does nothing without YouTube. But the app's source code is all free software.

That doesn't make the app non-free. We already have an anti-feature for that. They should instead say "apps with anti-features".

That's F-Droid lingo. The same thing in Debian lingo would be contrib and would not be allowed in the main package repo.

Sure. But you don't go saying that packages in contrib are non-free :) Just want to avoid confusion with our inclusion policy.

Debian absolutely calls contrib non-free, that's why its separate, and that's why lots of people are constantly lobbying to get contrib and non-free dropped from Debian entirely.

Off topic, but needs clarification: contrib packages contain DFSG-compliant software, but have dependencies not in main (possibly packaged for Debian in non-free).

contrib is free software that depends on non-free to be built or run

https://wiki.debian.org/SourcesList

Here are the related issues for Replicant:

• http://redmine.replicant.us/issues/1629
• http://redmine.replicant.us/issues/1635
• http://redmine.replicant.us/issues/1647

Milestone changed to %1.1

@pserwylo I think this is something to consider for the groundwork for the UX overhaul.

I'm going to do some work on this. I think it can be done without concern for the UX overhaul, given that it will always be tucked away in Settings (which will no doubt still exist somewhere after the UX overhaul). The only other changes are database related, which of course will not affect the UX.

My plan of attack to make this so that it can be done in a performant way is the following:

• Write tests to ensure that an App correctly gets anti features populated when read from AppProvider
• Create a new database table called antifeatures
• Extract the comma separated string features column from fdroid_app into a join table appAntiFeatures and add a join onto this anti features table when querying for apps.
• Add preferences for filtering out anti features, and then use the result of those preferences to limit the results based on the join table.

This has many benefits:

• It will be very amenable to good tests to ensure the database migration works successfully
• The query to get apps and exclude certain anti features will actually work (it isn't actually possible with the current database setup)
• The query to get apps and exclude certain anti features will be performant, as it will make good use of SQLite indexes.
• Each of the steps I outlined above can be committed to master separately so it doesn't need to happen at once.

@pserwylo sounds good!

plan sounds good overall, but shouldn't anti-features be per-APK rather than per-app?

I guess anti-features are now in the app. What if an app fixes anti-features? Like removes tracking or ads? I guess we can just start with the existing per-app data, and deal with per-APK later.

@eighthave indeed, they have always been per-app. Replacing with per-apk would probably be better, but it's a server side change, and not a client one.

What we do currently is remove the anti-feature if an app gets rid of the cause, even if it's still present in earlier versions.

mentioned in merge request !339 (merged)

Hi,

Sorry for replaying so late to the bugreport.

Replicant is supported and promoted by the FSF as a distribution that is FSDG compliant (Free software Distribution Guidelines): https://www.gnu.org/distros/free-non-gnu-distros.html https://www.gnu.org/distros/free-system-distribution-guidelines.html

As such we are supposed to follow such guidelines.

The issue is that:

• We ship f-droid as part of our images.
• Its default repository is not compliant.
• We don't have the manpower to fork it and maintain our own repository.

Denis.

As Replicant developers are really busy, and are more used to system programming(C, hardware related) than write/modify Android applications. I fear that trying to fix it ourselves will take way too much time and delay the fix a lot.

However many of the Replicant users that might like to help Replicant often lack system programming skills, but are really good at writing Android applications.

Due to the above, we could make an announcement on the blog, to ask such users for help to fix this really problematic issue.

Denis.

@GNUtoo we're starting work on the core changes needed to support this. As always, it'll get implemented sooner with more contributors.

mentioned in issue #691 (closed)

mentioned in merge request !384 (merged)

Mentioned in issue fdroiddata#549 (closed)

Mentioned in issue fdroiddata#554 (closed)

mentioned in merge request !452 (merged)