ankerwache VS fdroiddata

I hope it's better this time. Thanks to your question I actually did some simulations for false and true alarm rates (See https://github.com/mRcSchwering/ankerwache/blob/main/specificity_sensitivity.py). It turns out I can actually increase that counter to 5. That would make false alarms far less likely. I'm going to do that with the next update.

Fork this repository.

For reference my app: project: https://github.com/balzack/databag merge request: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12183

You should add a new entry in "Builds". Have a look at how Newpipe does it for each new version here for example.

To me it's not very clear whether those terms practically apply only to their app, since clearly they can't grab logs from Aurora if Aurora doesn't dump those logs for example... but if this is something the F-Droid team should look into, open an issue on https://gitlab.com/fdroid/fdroiddata/-/issues or inquire in one of their official channels on OFTC (#fdroid) or Matrix (#fdroid:f-droid.org).

OsmAnd~ from F-Droid not having Android Auto is a known bug: see the discussions at https://gitlab.com/fdroid/fdroiddata/-/issues/2567 , https://github.com/osmandapp/OsmAnd/issues/13514, https://github.com/osmandapp/OsmAnd/issues/3391 and https://github.com/osmandapp/OsmAnd/issues/15400

You can also get F-Droid Build Status which I believe will let you see apps that are being attempted to be built even if their build isn't succeeding yet, again for the "catching things early experience". Or, just keep an eye on the issues, merge requests and commits at fdroiddata which is where people actually add new metadata for new apps to be built by F-Droid, and it often takes a while between an app being first mentioned, and it being able to be included, for many possible reasons.