Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

android: remove legacy support #241

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

muelli
Copy link

@muelli muelli commented Feb 24, 2023

Legacy support depends on non-free software.
That, in turn, prevents other software, which depends on r-n-f-s to become non-free.

#240

This depends on non-free software.
That, in turn, prevents other software, which depends on r-n-f-s
to become non-free.
Copy link
Collaborator

@mikehardy mikehardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But minSdkVersion is 16 here

Granted, that's quite wide and not normally supported these days, but 21 is still likely to be in use throughout the react-native ecosystem as 21 is the current minSdkVersion for react-native itself

So this is a pretty big breaking change to the supported APIs. I don't see any reason why couldn't maintain this in a fork though such that you could use it personally

@muelli
Copy link
Author

muelli commented Feb 25, 2023

thanks for having a look.

For better or worse, it's not about me, personally. This particular module is preventing apps, Joplin in particular, from being shipped through F-Droid, because this module unconditionally depends on proprietary binaries.
I hope you can see that in itself as a bug that deserves fixing.

@mikehardy
Copy link
Collaborator

I like F-Droid. I like Fully non-proprietary software, I do agree this is a problem.

However, my comment stands: the minSdkVersion in the react-native ecosystem is 21 in general and your PR moves it to 24 (by removing support for fingerprint readers on popular devices between API21-23). So I don't think it will go in as is.

I recommend using patch-package if F-Droid can handle that (not sure their build system can...) or depending on a fork of your own for this, until minSdkVersion 24 is a reasonable stance for a library

@mikehardy
Copy link
Collaborator

Additionally, the PR should probably include the bump to build.gradle's minSdkVersion to 24 and PR title changed to reflect the same - it's aggressive right now but in a year might be perfect, and then it's just a merge...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants