Publish on F-Droid

[apognu]

As was requested in #1, F-Droid publication is on the way.

I submitted the metadata tonight and, seeing as it is my first ever F-Droid app, my guess is my build won't succeed on the first try.

I'll keep this issue updated as to its status.

[apognu]

For reference, the MR for Otter can be found here.

It appears F-Droid does not handle Kotlin Gradle build scripts, even though build passes successfully. I'll wait for their confirmation and decide how to progress from there.

We might have to revert back to Groovy (or maybe use both).

[strypey]

Just a suggestions from the cheap seats, but one way to progress getting an F-Droid listing - as well as allowing users to try out your builds using the F-Droid app - is to set up your own F-Droid repo: https://f-droid.org/en/docs/Setup_an_F-Droid_App_Repo/

The Pattle.im crew did this, and it seemed to speed the plow on getting Pattle releases into the main repo.

[Nutomic]

An easier option would be adding your app to the IzzyOnDroid repo: https://android.izzysoft.de/repo

You can contact the owner on Mastodon: https://mastodon.technology/@IzzyOnDroid

[IzzySoft]

Or you can wait until he magically pops up because his name was mentioned :rofl: Otter should show up here with the next sync in about 22h.

Suggestions:

• remove dependencies to proprietary libraries (my scanner e.g. reports GMS)
• add Fastlane file structures so you can maintain summary+description yourself without the need of opening an MR on every change (especially useful now, when things are changing fast), provide screenshots, etc.
• check with the RFP opened, they wait for your feedback there :wink:
• for the listing in my repo: if possible, could you attach a release build instead-of/in-addition-to the debug build? Not a big deal, if it's intended to be shipped as debug-build until beta/gamma state. But I doubt the Play Store one will be a debug build, and the flag might irritate users.

[apognu]

Hi!

I have not been able to maintain this project for a few months now, until now. So my memory is a bit fuzzy. As for your remarks:

• I'll try and pinpoint where GMS come from. This may come from Exoplayer's Chromecast plugin that was loaded (even though the Chromecast feature is not yet finished). I removed it from now since it has no use. What tool do you use to check these?
• I added any information I could into the fastlane directory.
• If I remember correctly, I had a few issues with F-Droid because I generate my version code dynamically from git tags, and my use of Kotlinscript Gradle files was not supported by F-Droid at the time.

For your repository, how does it work exactly? Do you fetch APKs from GitHub's release page, or do you build the project from scratch? I understand the need, and will update my CI workflow to produce release builds if the APKs are taken from my releases.

[IzzySoft]

Thanks for your response, @apognu – I'll try to answer your questions:

What tool do you use to check these?

My own library scanner. It's a mix of LibRadar (which it originally started with), extended by scanning the ApkTool-output (Smali) again for what LibRadar missed (which is quite a lot, as its library base wasn't updated for quite a while) – so it's rather a "static check" (i.e. it tells what is in the code, but not whether it is actually used). Side-note: my own library definitions are available here if you want to take a peek, and from time to time get picked from by Exodus Privacy.

I added any information I could into the fastlane directory.

Thanks a lot! I've updated metadata here so my updater will pick the changelog automatically on releases (I did it just now manually for the release already here, you will see in about 2h from now). Apologies for missing that you'd already set up Triple-T, which F-Droid can work with as well (though my repo cannot)…

issues with F-Droid

• dynamic versionCode/versionName make it hard to detect updates. That's still an issue with F-Droid. If, when creating the tag (to be more precise: the tag must already cover this, but it should be done as close to tagging as possible) you could provide the "exact numbers" by other means (e.g. a text file just holding something like versionCode:1000016\nversionName:1.0.16\n), that could be used for update checks then.
• "use of Kotlinscript Gradle files was not supported by F-Droid at the time": it is now.

For your repository, how does it work exactly?

As it's details page describes :smile: To address the core question: yes, it fetches the APKs from release tags (checking once a day at around 7:30 pm CE[S]T). My updater will also inform me on most "AntiFeature changes" – in your case, it will tell me when the APK is no longer "debuggable", so I can remove that AntiFeature. I usually check then if other (library-based) AntiFeatures can be removed as well – for your app this would be NonFreeDep once the GMS dependency is gone.

[IzzySoft]

PS: Could it be the changelog file name has a zero too much? versionCode is 1000016, the file name is 10000016.txt.

[apognu]

Indeed, I'll fix that in the next commit.

Thank you for the details you provided. No issue on Triple-T, anyway, it does not support separate release notes by version, as far as I know, and Play Store tracks have no equivalent on F-Droid, as far as I know. I don't mind having both, since apparently, symlinks do work.

One last detail, if I may: if my proprietary dependency issue is indeed related to Chromecast, I may have to release two separate builds of the app at some point (with and without this feature/dependency, for the user for whom it may matter). Do you have a way to list several variants of a version or should I decide to publish only one?

[IzzySoft]

Yeah, looks like. I could fetch the latest changelog file fine using its corresponding fastlane URL. Well, you might decide dropping Triple-T later and consolidate things in Fastlane (I prefer fastlane as it's easier to deal with, also more stable on F-Droid; Triple-T AFAIK only has its strong points if you target different markets with different builds, as each flavor has its own tree (which OTOH means you have to cater multiple trees with overlapping details, which IMHO only adds complexity and increases chances you forget something).

You can cater different variants by using build flavors. I'd recommend using one (called floss, foss or even fdroid) without any proprietary stuff for F-Droid, and another one (call it anything else: full, play, tainted :rofl:, chromecast, nonfree …) with the things F-Droid won't accept. You'll then need to consider whether to give them different package names / applicationIds, which I'd recommend (please don't use applicationIdSuffix for that, AFAIR F-Droid cannot deal with that, but always use applicationId inside the flavors). Maybe adding .fdroid to the F-Droid variant, while keeping the other as-is. That way both variants can even be installed simultaneously.

Looking for examples? The F-Droid metadata (Yaml files) might give pointers, wherever gradle is used and not just simply set to "yes" but to a flavor name. I've no easy one on my mind at the moment; following my own advice brought up e.g. this one: flavors fdroid and playStore – so watch out where the gradle distinguishes what should go to only one of them by using fdroidImplementation resp. playStoreImplementation instead of simply implementation (the latter would go to both flavors).

Hope this helps!

[apognu]

Thansk for the detailed explanation, I will come back to it whenever this is necessary.

I just set up release signing on the generated APKs, so the next version will be in release mode.

Thanks for all your help!

[keunes]

You'll then need to consider whether to give them different package names / applicationIds, which I'd recommend [@IzzySoft]

Why would you recommend it? I don't really see an advantage of running both at the same time, and it could lead to confusion for users icons & app names are the same.

[IzzySoft]

@keunes first, it's a good practice to clearly distinguish between FOSS and non-FOSS – so you know exactly which package to grab. Second, there might be no good reason to always run them in parallel, agreed. But there are good reasons for temporarily doing so – e.g. to see if a "bug" happens in "the other one" as well, or if "Chromecast support is really woth it". So being able to run the other one in parallel avoids uninstalling one (and losing your settings) just to try the other. Third, indeed a slightly different icon could be useful then :smile:

[IzzySoft]

@apognu as expected, my updater just informed me to remove the ApplicationDebuggable AntiFeature. Done that. Also expected: removed NonFreeDep as well – congrats! Next sync will clean that officially. Thought you'd like to know :wink:

[apognu]

Very good to know, thank you for keeping me posted!

Glad to have confirmation Chromecast was the only culprit.

[apognu]

@IzzySoft I would like to set up a specific release which always contains a build from the tip of my develop branch.

Is there a way for your synchronization process to not pick up that tag/release? Maybe add a filter or some kind of tag deny list?

[IzzySoft]

Should be. My metadata say:

AutoUpdateMode: Version %v

so it should only look at tags matching the versionName (without any prefix). Your current tip tag should be ignored as it has no version info. At least that's the theory… But that's something I just started to implement recently, so I'm not sure how well that works yet (it will be rather flaky, as that "feature" is not yet completed here – but as long as there are no digits in the tag name, it should work, as "0" or "(empty)" is always smaller than any version number :wink:).

The safer variant would be if you'd mark those I shall pick as "releases" – and only those I shall skip "pre-release" (currently, all your tags are marked as pre-release). That mechanism is proven to work for years now. But I don't know the reason behind your sticking to "pre" with the tags, so this might not be feasible for you.

The third variant is giving the APK file a specific name part. That's easy for me to put on your record's ApkIgnore RegExp.

The fourth is to combine all of the above, for super-paranoia-mode :laughing:

[apognu]

I will remove the pre-release flag from my actual releases, to be on the safe side of things. Thank you for answering. :D

[IzzySoft]

OK, I tell my updater to skip pre-releases from your app then, starting with tomorrow's run.

[apognu]

Thank you! :)

[IzzySoft]

For paranoia mode, I could also tell it to ignore /debug/i files :laughing: But we should be safe with the current configuration.

[keunes]

With all due respect for the great work IzzySoft is doing, it would still be beneficial to get Otter in the main F-Droid repo. It'll be easier for users to install (as they don't have to add another repository), and it'll help with discoverability. Are there any blockers to this? Or any other reason for not pursuing this (anymore)?

[apognu]

Oh, I was not suppose to close this. I started working on this again this afternoon and must have misclicked.

Some issues I encountered last time seem to have been resolved. I still have to work around an issue with the FLAC driver, which is a precompiled blob right now, which is not supported by F-Droid.

[apognu]

Most modifications have been made, local F-Droid builds succeed properly. I just need two more modifications:

• Create a new package ID for F-Droid that will be used for the FOSS version (which as of now, is strictly identical to the Play Store version, but that could change when some features are implemented).
• Create a full test with a new dummy tag on the repo (right now, builds are hacked from a branch).

After this, I believe I'll be able to update my MR to F-Droid, and hopefully everything will pass OK.

[IzzySoft]

@apognu did you forget about your MR at F-Droid? It's waiting for your update, but it seems our pings are not getting through to you. Could you please check and fill the gaps? Thanks!

[IzzySoft]

@apognu your MR at F-Droid waits for your response now for more than 2 months, and already had the "ait-for-submitter" label added. According to our policies, it now becomes "candidate-to-close":

If there is no activity on the MR in the next 4 weeks, we will close it to reduce the number of open issues. On the wiki you can see more details about this process.

Last question was if you could update the yaml to v1.0.21, where the GMS issue seems solved already (at least I see not flag on your app in my repo, and GMS is not listed with identified libraries at least since v1.0.19). Unfortunately you used a master branch to create the MR from, so it's protected by GitLab and we cannot perform those modifications ourselves. I hope you find some minutes to perform that step? Would be really great having Otter at F-Droid!