Android app "open release"

[IzzySoft]

With the app being open source, did you consider submitting it to open places as well? Thinking of F-Droid for the Android app, or at least attaching it to the corresponding release where the packages for other OSes are already present – so folks outside Google's walled garden (think Huawei devices, privacy folks) can access it as well. Thanks in advance!

[mbruel]

attaching it to the corresponding release where the packages for other OSes are already present

not sure what you mean...

yeah I considered publishing it on F-Droid. The process seems to required a lot a disk space from what I've seen which is quite boring.... I'll need to have a second look...

Would it help if I publish the apk with the other releases? Here is the apk.

[IzzySoft]

attaching it to the corresponding release where the packages for other OSes are already present
not sure what you mean...

Well, to put it into other words:

Would it help if I publish the apk with the other releases?

Yupp, that's exactly what I meant, thanks!

yeah I considered publishing it on F-Droid. The process seems to required a lot a disk space

But not necessarily on your end. Of course we're¹ happy if the developer tests everything up to the build with fdroidserver and then submits a MR that goes straight through. But that's not mandatory. If you're there should issues arise with the build, that would be much appreciated already. But basically, you'd just need to open a RFP (Request For Packaging), we'd then step in and help.

¹ _{disclosure: I'm one of the F-Droid maintainers}

What we'd like to have is something you'd probably even welcome: Fastlane structures here in your repo. Why would you welcome it? You could use the very same structures to deploy your app to Play Store and Apple Store, using Fastlane's binaries. For F-Droid, just the metadata files will suffice. I could provide you with a "starter kit" for this if you wish.

Thanks to your providing the APK, I'm just adding your app to my repo now – where it will become available with the next regular sync tomorrow (we just missed today's by about an hour). There I've already set up said "starter kit" and integrated your screenshots. You will then find it here.

Oh, seeing the results of my library scanner I understand you will have some issues with F-Droid: it's a Qt app. AFAIR we cannot (yet) build Qt apps, or at least not easily (I'm not a packager, so I'm not familiar with the details). Nevertheless: though the size limit for my repo usually is 30M per app, and ClementineRemote is slightly beyond that² – if it's OK with you I'll keep it in my repo for the time being. Updates would be fetched within 24h of your creating a new tag with an APK attached. And if you'd establish Fastlane to maintain description etc, my updater would fetch changes from there right along (I gladly provide you that "starter kit", containing summary and description for EN and DE). What do you think?

² _{I'm afraid it won't get smaller; once it goes beyond 35M per APK, maybe you could provide an ARMv7-only APK to shrink it a bit?}

[mbruel]

But basically, you'd just need to open a RFP (Request For Packaging), we'd then step in and help.

done, here it is.

What we'd like to have is something you'd probably even welcome: Fastlane structures here in your repo

well, I'm not really interested in doing it. I'm building for all OS, including desktops. I don't need something specific to android. I've a release_notes.txt which is pretty basic but enough for such app.

There I've already set up said "starter kit" and integrated your screenshots. You will then find it here.

well will I be able to edit it and maintain it myself? How is it working?

AFAIR we cannot (yet) build Qt apps, or at least not easily (I'm not a packager, so I'm not familiar with the details)

well it's not hard, and I can provide the apks or aab if needed. the app also depends on the protocol buffer library compiled for C++.
Or should everything be compiled within FDroid?

if it's OK with you I'll keep it in my repo for the time being. Updates would be fetched within 24h of your creating a new tag with an APK attached.

I didn't really get how FDroid is working... Can we publish stuff pre-built? Is it decentralized repo? How does it work when we're the owner of the APP and want to set the description and more important manage the new versions? I hope it is not rebuild at each push on the master branch in GitHub is it?

And if you'd establish Fastlane to maintain description etc, my updater would fetch changes from there right along (I gladly provide you that "starter kit", containing summary and description for EN and DE). What do you think?

so back using fastlane. Is it not possible to do it on FDroid web interface? I'd prefer...

² I'm afraid it won't get smaller; once it goes beyond 35M per APK, maybe you could provide an ARMv7-only APK to shrink it a bit?

the apk is less than 35MB. So it should be fine no?
I could provide 2 apks: for armeabi-v7a and arm64-v8a. Why would you prefer one of them?

[IzzySoft]

done, here it is.

Yes, I already received a notification (RFP is the area I am responsible for). As usual, I'll wait until the "issue bot" has reported (it scans the repo and reports its finding), and then chime in there. Thanks!

well, I'm not really interested in doing it.

Hehe… yeah, understandable you don't want additional work. Hence my offer with the "starter kit". Once set up, it really isn't much work anymore: updating the app description when needed (usually when new features have been added you'd want to be "promoted" in the description), replacing screenshots when needed (the design changed, or new important screens have been added). On average, how often will that happen? To my experience, rarely – maybe twice a year.

well will I be able to edit it and maintain it myself? How is it working?

That's exactly the idea behind it! You know best what should be there. In the "starter kit", it's two files (per language): a 1-line summary limited to max 80 chars which almost never changes, and a full description. Let me show you the English variants I've set up for your app:

short_description.txt: "Remote Control for Clementine Music Player"

full_description.txt:

<i>ClementineRemote</i> is a Remote Control for the <a href='https://www.clementine-player.org/'>Clementine Music Player</a>, available for all major platforms. Its main goal was to add the Files View missing in the Android Remote. It's also made like a player, so you always see the running track, can pause or go next.

<b>Features:</b>

* a <b>Player</b> to start previous/next track, play, pause, skip, shuffle, change volume, etc.
* a <b>Playlist Menu</b> to manipulate the playlist – edit, search, rename, clear …
* a <b>Files Menu</b> to walk the directories below Clementine's root folder, download tracks, append tracks to the playlist, and more
* a <b>Library Menu</b> to search Clementine's library for text (incl. using regular expressions) in title, author etc.
* an <b>Internet Radio Menu</b>
* a <b>Global Search Menu
* …and more…

That's it – all else is optional. Idea is that you who know best can take care to describe the app best, and keep that description up-to-date. Now, copy those two files to fastlane/metadata/android/en-US/ – and you're done already 😃

_{(some details on the format here – it's what proved best working with F-Droid, my repo and Play; basically some "Markdown light": F-Droid applies nl2br, my repo fully understands Markdown, and Google strips down to plain text)}

I can provide the apks or aab if needed

Now, that won't work 😄 The idea behind F-Droid is that all is completely built from source – by the F-Droid team – using only open-source tools. The entire build process runs on Debian based, headless VMs – so everything needing a GUI and buttons to be clicked is "out" as well.

Or should everything be compiled within FDroid?

That, yes.

so back using fastlane. Is it not possible to do it on FDroid web interface?

No, that's "read only" (static pages). It could theoretically be done via our git repo – but then we'd be back at step one: you'd need to open MRs for each and every single change. With us having far to few hands (our backlog is too high already now), you wouldn't really want that. Which is exactly why we "outsourced" it. This way it's simply part of your app – and gets pulled with your app's updates.

I didn't really get how FDroid is working...

Ugh… well, for starters, may I direct you to some articles I wrote on this? About 5min reading and covers most of it: https://android.izzysoft.de/articles/named/fdroid-intro (3 parts: 1) general overview for users, 2) for advanced users and developers, 3) for those who want to run their own repo)

and want to set the description

Err… Fastlane? That's exactly what I'm trying to introduce to you 😃

manage the new versions?

You tag – we build. No additional work on your end. We'll come to that when I set up metadata in your RFP. But a teaser:

AutoUpdateMode: Version v%v
UpdateCheckMode: Tags
CurrentVersion: '1.0'
CurrentVersionCode: 1

This is an example of how updates are dealt with, basically saying: "Watch out for tags following the pattern v<versionName>. If you see one with a versionCode bigger than what we have, trigger an update." Very much simplified of course, but you get the idea. Full process is explained in our docs, btw.

I hope it is not rebuild at each push on the master branch in GitHub is it?

No, of course not! We wouldn't have the hardware for that, with thousands of apps in our repo. Just the tags – you tag anyway to mark releases, right? So we just pick up that signal as trigger. Takes a few days for the updated app to show on our site, though: it needs to be built, signing is manual ("human intervention" on an "air-gapped system"), etc.

the apk is less than 35MB. So it should be fine no?

The 30M per-app-limit is only for my repo – which runs on personal space, so it's not unlimited. There's no funding to speak of, so I cannot expand "infinitely".

I could provide 2 apks: for armeabi-v7a and arm64-v8a. Why would you prefer one of them?

That's kind of a compromise. ARMv7 runs fine on all ARM systems v7 and higher. An ARMv7-only APK is much smaller than a multi-arch. Now combining that with above paragraph: it helps me keeping resources available by reducing APK size while still being able to provide the same amount of apps – using the "freed space" for "more apps" or, in other words, serving more apps with the same resources.

[mbruel]

@IzzySoft here you go for ClemRemote_v1.0_api28_armv7.apk
I've decrease the API to 28 (Android 9) as I've this on my personal phone. It's google that asked me to upgrade to 29 and to add the arm64 version...

Something is still unclear. You say the aim of FDroid is to compile from the source. But you don't support Qt Apps for now... So can you still publish my app with the apk I sent you? Can users download it from the store?

I'll read the rest tomorrow, time to go to bed for me.

[IzzySoft]

here you go

Ah, that's great, thanks! So I can increase versions-to-keep from 1 to 2 even, yay! Am I guessing correctly that future tags will have this ARMv7 APK matching *armv7.apk – so I can tell my updater to watch out for that?

It's google that asked me to upgrade to 29 and to add the arm64 version...

Yeah, no such enforcements at F-Droid (we currently have some issues with "reproducible builds" targeting SDK30, enforcing v2 signing – not that easy bringing v2 signing together with reproducible builds).

Something is still unclear.

Part 2 of my above linked articles should shed some light on that:

You say the aim of FDroid is to compile from the source.

Yes, that's a valid rule for f-droid.org (and the Guardian Repo as well).

can you still publish my app with the apk I sent you?

Sure, in my repo I'm "boss" 😄 There are many repos around – everyone and their little sister can run their own repo. The most famous ones are:

• F-Droid.org: most trusted, as there're strong rules (as just pointed out: everything from source only, no non-free parts, etc – details in the inclusion policy). Over 3.000 apps (as of now: 3,182)
• Guardian: same trust level, but only few (13) specific apps
• my repo: more than 600 apps (as of today: 625 plus yours tomorrow). Less strict rules, APKs are built by their own authors and also signed by them.

Most other repos usually cater few apps only, but are still useful in their own terms. Using the F-Droid Android client, you can access them all (make your pick, configure/enable those you trust and want to use). So my repo is the second largest currently, and pretty well known – use the search engine of your choice and look for "izzyondroid repo -site:izzysoft.de" (just exclude my "self appraisals").

Can users download it from the store?

Yes, they can download it either via the website using their browser – or preferably directly install it using the F-Droid client. In the latter case, they also get updates shipped automatically, as they would when installing with Play Store. Think of it as an alternative, distributed eco-system for "foss lovers", "privacy folks" and "safety-concious" users.

Besides, one of the reasons I run my own repo is for apps like yours – which cannot (yet) be built/included by F-Droid itself, do not fully fit the strong inclusion criteria, etc. So that users who prefer avoiding the walled gardens (and especially Google) get a broader selection of apps to choose from. This week, my app listings just reached the point where every 8th app listed there is available from either F-Droid.org or my repo (and 3 out of 4 are available from Google Play; the difference is e.g. Xposed and Aptoide, which my lists also cover). Out of currently 14k5 apps listed.

I'll read the rest tomorrow, time to go to bed for me.

Yes, sure – take your time. And thanks for your openness and help, much appreciated!

---

PS: Ugh, that never happened to me… this comment was open in my browser for 2 weeks and I forgot to hit the send button 🙈 Can't remember what might have distracted me. Luckily, it even survived a browser restart 😄

[FestplattenSchnitzel]

@mbruel Since you changed the licence you probably want to remove the last characters of the old one …
See here …

[mbruel]

@FestplattenSchnitzel thanks man, I've updated it
@IzzySoft I should have some time next week to start again the fastlane structure ;)

[IzzySoft]

@mbruel I see you've merged my PR, thanks! Any hint towards and ETA for the next release? At F-Droid we'd need a tag that includes Fastlane.

[IzzySoft]

@mbruel looks like my notifications do not reach you. According to our Issue Cleanup Policy, your RFP now enters "waiting" (aka "pending") state. With no activity in the next few weeks, it will soon become "candidate to close". I'd prefer closing it via a merge request that brings ClementineRemote to F-Droid 😉

So may I ask once more for an ETA of the next release/tag which comes with Fastlane inside, so we can process your request? Thanks in advance!

[mbruel]

Hi @IzzySoft
Sorry for the delay, I'm quite busy since mid February and not in my place.
I'll definitely make a new version / tag by the end of April, when I'll be back home and be able to test my changes on all devices (Android + iOS).
I'll try to update the Fastlane and a small new feature before that ;)

[IzzySoft]

Thanks a lot, Matthieu! I'll make a note to the RFP so the counter is reset 😄 Just giving it a short "status update" every 3..4 weeks should keep it open, so if you could do that once Fastlane has been updated, that would be great!

[IzzySoft]

@mbruel any progress? It's mid May already, and our warning system brought your RFP up again.

[mbruel]

yep, I'm back home, I've just changed the armrests of my chair, ready to do some coding! I'll make an update by the end of the week, the fastlane information and probably a new version :)

[IzzySoft]

Great news, thanks – happy coding!