AuthenticatorPro

AuthenticatorPro copied to clipboard

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

Ping @IzzySoft re: any showstoppers?

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

@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.

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

@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:

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

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.

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.

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

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.

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.

@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?

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).

@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?

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.

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.

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

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.

~~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.

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

@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…

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

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!

Just a side note: you only need a phone manufactured after 2015 to use arm64, which is by far about 7 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.

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

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:

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!

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

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

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