This screen that #Google shows on #Android when installing #FDroid really bugs me. It is purely based on the integer value targetSdkVersion, without considering our security model, public audits results, track record over 10+ years, exclusive use of memory safe languages, or even what our code actually does. It is as if #FDroid marked anything that comes from Google as containing ads and trackers. 1/2
I will go one step further and say that calling #FDroid an "unsafe app" by this standard is dishonest. It seems that some at #Google also agreed, since the older version of that screen was honest: "Blocked by Play Protect" instead of "Unsafe app blocked". Looks like the #GooglePlay team is still focused on protecting their #monopoly, this time using scare tactics. 2/2
@mynacol I agree that bumping targetSdkVersion is good when there is no cost. When there is a cost, then devs should do a cost-benefit analysis. The targetSdkVersion sandbox also breaks features that people rely on, #UserFreedom means giving users real choices.
Looking at the new screen, it looks like Google has blocked installing the app. Many users have said as much. That's the monopolistic part.
And F-Droid v1.17 will have a higher targetSdkVersion. That cost a lot of dev time and money.
@eighthave What sandbox restrictions break existing features? Maybe we developers have to change APIs/add new permission requests etc., but fundamentally all the stuff the F-Droid client does should be possible.
(Except for the stuff #Termux does, there is currently no method known how to support current targetSDK versions)