search

jamie-mh / AuthenticatorPro

📱 Two-Factor Authentication (2FA) client for Android + Wear OS
https://authenticatorpro.jmh.me
GNU General Public License v3.0
2.85k stars 195 forks source link

F-Droid Inclusion #2

Open TPS opened 5 years ago

TPS commented 5 years ago

@jamie-mh Any objections to an F-Droid RFP?

Ping @IzzySoft re: any showstoppers?

jamie-mh commented 5 years ago

@TPS That's fine with me. Go ahead.

IzzySoft commented 5 years ago

@jamie-mh may I suggest to establish Fastlane (or Triple-T) structures in this repo here, to hold screenshots (and optionally also localized descriptions plus per-release changelog <versionCode>.txt)? Both can be used for (automatic) publishing to Play Store as well, so you'd just to do the job once and benefit twice. You can find some details here (including links to the Fastlane and Triple-T projects for more).

@TPS I cannot tell what show-stoppers there might be. This project doesn't use gradle and is written in a language I'm not familiar with (C#). Not even our bot can handle it. So we need to wait until one of our "integrators" can take a look and check things manually.

jamie-mh commented 5 years ago

@IzzySoft The project is now using Fastlane. Hopefully everything is in the right format.

IzzySoft commented 5 years ago

@jamie-mh cool, and even including the changelogs! Could you also tag your releases wo we'd know which commit(s) to build?

I've already tagged the app xamarin in the RFP, so those familiar with it can see there's something to do for them :wink:

jamie-mh commented 5 years ago

@IzzySoft I've tagged all the releases I could find.

IzzySoft commented 5 years ago

Thanks a lot, @jamie-mh! Starting with the newest would have sufficed (as long as you keep it up for future ones) – but good to see the others as well! I'll prepare metadata for the RFP then.

IzzySoft commented 5 years ago

PS: Can you move the latest tag to a commit that already has the fastlane data? Otherwise they are ignored. If you plan another release soon (e.g. within a week), we can also wait for that of course.

jamie-mh commented 5 years ago

@IzzySoft I think I've done it, GitHub isn't updating the tags for me at the moment.

IzzySoft commented 5 years ago

There's that. And now it shows up for me at 1.5 (while funnily there are 2 newer tags named 1.2.1 and 1.3 – but never mind that, I've set up metadata for 1.5 now). Thanks again! Now we need to wait until a team member with Xamarin experience can pick up.

IzzySoft commented 5 years ago

OK, looks like Xamarin was never dealt with at F-Droid yet, so this will be delayed until someone finds time to get familiar with that. Until it's ready there, I could take it into my repo if you wish – but for that I'd need the APK (preferably attached to its corresponding tag/release). Just let me know, I happily do so then.

jamie-mh commented 5 years ago

@IzzySoft Sure, that sounds good. However I usually split the app into multiple APKs depending on the ABI. Is that going to be a problem?

IzzySoft commented 5 years ago

Not really a problem: in most such cases, I simply pick one of the resulting APKs (usually the ARM one). My updater script cannot deal with multiple APKs per app, so I have to chose – it's too rare a case to be worth the effort of "coding this special case".

As most Android devices are ARM based, I think that's a good compromise. You could of course attach the other APKs to their corresponding release as well: as long as the naming scheme is clear (the ARM one can always be recognized by a given RegExp like .*_arm\.apk$), I can easily work with that. And point out in the description where to find the APK for the other ABIs.

Would that be an approach you could go with? As soon as the official repo kicks in, the other ABIs can probably be taken care of as well (though I'd need to ask one of our "builders" if and how that can be achieved).

jamie-mh commented 5 years ago

@IzzySoft I've attached the apks to the latest release. However there is a release for ARM 64 and one for ARM, are they in a format you can recognise?

IzzySoft commented 5 years ago

Thanks! RegEx .*armeabi.*\.apk$ matches the one I'd pick, and no other – so yes, perfectly fine with me. Given the size, I'd keep exactly one version in my repo (always the latest of course). Should show up here with the next sync (in about 21h if I don't trigger a manual one before).

Note there's nothing I can do about the 2 "AntiFeatures" shown: your signature still uses MD5 algorithm which is long deprecated.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

IzzySoft commented 3 years ago

Well, somehow the bot has its point: will there be any activity towards inclusion with "F-Droid proper"?

jamie-mh commented 3 years ago

The F-Droid build server still isn't capable of building Xamarin apps (https://gitlab.com/fdroid/fdroiddata/-/issues/1529), until then, there's not much more I can do.

TPS commented 3 years ago

I think I read sometime in the last few weeks that there's some progress on Xamarin compilation for F-droid. Is that correct? Would resetting the bot @ the RFP confirm that, or is there a specific expert we could ask?

Nm, this was answered 1 min before I posted this.

proletarius101 commented 2 years ago

Since endless waiting for the f-droid.org inclusion, as a workaround, can you publish a custom fdroid repo using github pages? Example: https://github.com/bitwarden/mobile/blob/master/.github/workflows/release.yml#L93...L175. I can also help if you are not familiar with it @jamie-mh

IzzySoft commented 2 years ago

@proletarius101 maybe you've missed that the app is already available in a custom repo? As per the Readme it is available in mine :wink:

Btw: Apart from the Xamarin build issues, the app has another show-stopper: it comes with GMS (proprietary) and Android Wear (proprietary) – most likely the latter drags in the former. The ugly thing is, I've no idea if there's a FOSS replacement for the wear stuff…

proletarius101 commented 2 years ago

@IzzySoft yes and I appreciate that. But there is only the armv7 optimized version, which is an uncommon arch nowadays

IzzySoft commented 2 years ago

Indeed. If the app gets too large, I just pick the ARMv7 APK. oks on most devices. And while the ARMv7 also works on most arm64 devices, the opposite can not be said (which is why I decided this way). As for "uncommon": 2 out of my 3 devices are running ARMv7 only (not everyone has "always the latest") – but I fully agree with you that it's a good idea having the other archs available as well, so your suggestion absolutely makes sense, thanks!

proletarius101 commented 2 years ago

Just a side note: you only need a phone manufactured after 2015 to use arm64, which is by far about 7 years ago

IzzySoft commented 2 years ago

That's the theory, yes. Mine are from 2015 (Fairphone 2) and 2016 (Wileyfox Swift, BQ Aquaris X5 Plus). Only one of them is arm64.

proletarius101 commented 2 years ago

I'm not interested in preventing armv7 device holders from using the app. It would also work if @jamie-mh releases the all-in-one apk and @IzzySoft catches them

IzzySoft commented 2 years ago

Provided it doesn't exceed the per-app size limit then – which it unfortunately will: the per-ABI APK already is 22M. Even if only the two ARM builds would be put into a single APK, we'd probably be at 35 M already :cry:

jamie-mh commented 2 years ago

I could setup a repo for the app like Bitwarden, but I don't see what the advantage would be over Izzy's repo. What would be the benefit?

If I make a build with all the proprietary bits removed, I would then will have to explain why the Wear OS app doesn't work. As far as I know there is no free replacement for the watch stuff. I don't know if this is feasible.

As far as making a single APK for all ABIs, the full file is 46mb which is rather huge!

proletarius101 commented 2 years ago

I could setup a repo for the app like Bitwarden, but I don't see what the advantage would be over Izzy's repo. What would be the benefit?

If I make a build with all the proprietary bits removed, I would then will have to explain why the Wear OS app doesn't work. As far as I know there is no free replacement for the watch stuff. I don't know if this is feasible.

As far as making a single APK for all ABIs, the full file is 46mb which is rather huge!

If you setup a custom repo, you will be able to provide arm64 native apks (as the abi-agonistic apk is too large to be delivered on Izzy's repo), which is a performance gain for a large portion of users

proletarius101 commented 2 years ago

If I make a build with all the proprietary bits removed, I would then will have to explain why the Wear OS app doesn't work. As far as I know there is no free replacement for the watch stuff. I don't know if this is feasible.

You don't need to if you set up a custom repo. It's pretty fair to do so as long as you set up the correct anti-feature flag. Removing all proprietary libs is a requirement only for inclusion to the fdroid.org repo

IzzySoft commented 2 years ago

I'm running out of thumbs… :see_no_evil: Thanks to both of you!

MagicLike commented 1 year ago

Repost from #646

Related to https://github.com/jamie-mh/AuthenticatorPro/pull/576

Explanation: https://github.com/jamie-mh/AuthenticatorPro/pull/576#issuecomment-1418019197

@jamie-mh @IzzySoft

IzzySoft commented 1 year ago

Just add a link to the RFP, @MagicLike :wink: