F-Droid inclusion

[shuvashish76]

Hello, would you consider publishing the app on F-Droid please? Documentation : https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md

[HemantKArya]

Hi @shuvashish76 thanx for suggesting this idea. However, I remember for once in the past I tried to search for docs for flutter specific and it was somewhat not able to clear my mind about how to ready a CI/CD like pipeline for flutter apps. Since it is easy to publish one APK but for continuous integration it was bit unclear to me (when I read about it few months ago.). So, if you have any clearance or any guide for flutter specific then please share it here. I am leaving this issue open if anyone have any suggestion or PR related to this then please discuss it here I will always welcome for that here.

[shuvashish76]

ping @linsui for help

[linsui]

See the template in https://gitlab.com/fdroid/fdroiddata/-/blob/master/templates/build-flutter.yml. We can extract the flutter version from https://github.com/HemantKArya/BloomeeTunes/blob/main/.github/workflows/main.yml#L25.

[HemantKArya]

Thank you so much @linsui it's great to have help from you. Since I am new to this, I want to ask that do i have to public my app signing keys in build file or is there any way to use them during build process using env keys?

[linsui]

No, we don't use your key in any way.

[HemantKArya]

https://gitlab.com/HemantKArya/fdroiddata/-/blob/master/metadata/ls.bloomee.musicplayer.yml this is what I come up with if it is possible to help then please guide me and also how to use my keys to sign app. also is there any doc related to how to extract the version code and version from latest tags or if anything wrong with this setup draft I made.

[linsui]

The version name and version code should be extracted from https://github.com/HemantKArya/BloomeeTunes/blob/main/pubspec.yaml#L19, i.e.,

UpdateCheckData: pubspec.yaml|version:\s.+\+(\d+)|.|version:\s(.+)\+

and please check the pubspec.lock file into the repo.

[HemantKArya]

i get it that you want the version code to be from pubspec.yml. but my version code is the number which is used from the github action workflow run number. And my build number in pubspec.yml file is always have build number 0 it is updated by the github action workflow command when app is built using command flutter build like in this workflow https://github.com/HemantKArya/BloomeeTunes/blob/1af0475e675b72486dc0d172ae7cff9dbaa7bc13/.github/workflows/main.yml#L49 .

and if use the build number again from 0 then when someone update the app it will say the app is either old or corrupted. So is there any way to you suggest for this scenario.

Another doubt is that I sign my app with my own personal keys which are already saved at github workflow env, so they all are automatic built and released when new commits are pushed. How to replicate this pipeline. If I can't use private keys to sign app then should I consider publishing my app with different public keys so that everyone can sign using those keys?

[linsui]

Then you can put the build number in a file published along with the apk so that we can extract it, e.g., build-number.txt. We sign the apk with out own key, or use your signature if reproducible build is enabled. See https://f-droid.org/docs/Reproducible_Builds/.

[HemantKArya]

Thanx you so much for replying @linsui, This is what i came up with extracting the signature and uploaded to fdroiddata repo at https://gitlab.com/HemantKArya/fdroiddata/-/tree/master/metadata/ls.bloomee.musicplayer/signatures/140

and the yml file: https://gitlab.com/HemantKArya/fdroiddata/-/blob/master/metadata/ls.bloomee.musicplayer.yml

now the problem is

1. I want to publish the universal APK but its size is appox ~ 39 mb, will it be any problem.
2. do you mean publishing the built-number.txt in my release tags? and automatically extracted from there?
3. If it is fine for you will have a look on this yml file and is it ready for automatic buildings?

[linsui]

Do note that if you extract the signature, you need to upload it to fdroiddata manually for every version. If you use Binaries instead it can be updated automatically.

I want to publish the universal APK but its size is appox ~ 39 mb, will it be any problem.

Why not publish the splitted apks?

do you mean publishing the built-number.txt in my release tags? and automatically extracted from there?

Yes.

If it is fine for you will have a look on this yml file and is it ready for automatic buildings?

We can do that in an MR. :) It still needs some midification.

[HemantKArya]

Okay then if put binaries link in yml file then it will automatically extract the signature from it, If I understood correctly.

Why not publish the splitted apks?

because the splited variants have different build number basically it is intended behaviour added by Google itself in App Builder so that's why I wanted to use the default universal APK with default build number that is passed during building. like the variants have build number n+2000 or n+1000 according to how it is set under the hood, while the main one have original build number n.

We can do that in an MR. :) It still needs some modification.

Thanx you so much 😊 @linsui.

I will update my main.yml workflow to create file in release with name build-number.txt with content having build number.

[linsui]

F-Droid supports split abi. You just need to change the version code scheme. See https://github.com/nfcim/nfsee/blob/1302225df144a2747ecc8130bf43edee2440f1a4/android/app/build.gradle#L99 for example.

[HemantKArya]

Thanx @linsui I just updated the release workflow changed the released apk abis to have same build number so now I can release the split-per-abi apks.

https://github.com/HemantKArya/BloomeeTunes/releases/download/v2.9.12%2B141/build-number.txt

can you have a check here and how to include the GitHub release binaries there automatically the latest's APK builds from release section. like this https://github.com/HemantKArya/BloomeeTunes/releases/download/v2.9.12%2B141/bloomee_tunes_android_v2.9.12+141_arm64-v8a.apk link is only for this version but what if release next release.

[linsui]

You can take a look at this example. :) %v is the version name and %c is the version code. But please note that the version code is not 141. It's 1411, 1412, 1413. So we can't generate the url if 141 is needed.

[HemantKArya]

So what if we make something like that VercodeOperation: '%c'

[linsui]

VercodeOperation is used to calculate the version code from the number we extract. The binary url is calculated from the version code. So if the version code is 1411 then it can only use 1411. :shrug:

[HemantKArya]

So if you mean versioncode extracted from one of the APK generated by fdroid then it is fine cause I recently updated by build.gradle file (bc861212d2839fccb17c31bfa0a6377de12d38b1) to only use the n as version code not n*10+1 or anything else. And if the generated apk has the version code (build number) n then I guess the URL calculator will calculate URL on basis of n right?

[linsui]

When checking update, a number is extracted from upstream files. Then the version code for different abis are calculated according to VercodeOperation. These version codes are write to the metadata as versionCode. When building the apk, the url is calculated from versionCode in metadata. The number extracted from upstream files are not known when building the apk.

[HemantKArya]

I'm really sorry I just missed what you said especially -

The number extracted from upstream files are not known when building the apk

so, what should I do for desired behaviour you suggest?

[linsui]

Can you remove the build number from the tag name and the apk file name?

[HemantKArya]

If I am correctly getting you are saying to change the tags name from v2.9.11+141 to something like v2.9.11 and same for the apk names from bloomee_tunes_android_v2.9.12+141_arm64-v8a.apk to bloomee_tunes_android_v2.9.12_arm64-v8a.apk right?

But that is Intended behaviour I made to track the versioning properly. Is there any no other working arounds? Without renaming those.

[linsui]

You can also change the version name to 2.9.11+141... The url is generated from a template with placeholder for version name and version code.

[HemantKArya]

okay then if i replace the name to from v2.9.11+141 to 2.9.11+141 in tags is enough or do i have to change the name in app name also ? because if your program logic search for pattern than it doesn't matter if it starts from any name If I understand correctly right?

[linsui]

For every apk, there is a corresponding block in the metadata. The versionName and versionCode should match with the apk and are used to calculate the url of upstream apk. The checkupdates step doesn't care about the tag name. But when building the apk the url to the upstream apk needs to be calculated. If you change the version name to 2.9.11+141 then the url can be calculated.

[HemantKArya]

Ohhh..... So, how about now https://gitlab.com/HemantKArya/fdroiddata/-/blob/master/metadata/ls.bloomee.musicplayer.yml

[linsui]

If you set the version name as this then it works. :)

[HemantKArya]

you mean in this metadata yml file right? Or should I now submit this as PR?

[linsui]

The versionName in the metadata should match the on in the apk.

[linsui]

Please add the pubspec.lock in git.

[HemantKArya]

you mean here in github right?

[linsui]

Yes. :)

[HemantKArya]

Is that all now 🙂. Will it be final after that or something else so that I can push it in next release.

[linsui]

We need to build isar from source. You need to add a lock file for it. See https://github.com/immich-app/immich/pull/12705 for example.

[HemantKArya]

Here it is now: https://github.com/HemantKArya/BloomeeTunes/blob/main/pubspec.lock

[HemantKArya]

H @linsui are all necessary steps are done, mean should I send a merge req to your official repo server?

[linsui]

Please open an MR in https://gitlab.com/fdroid/fdroiddata/-/merge_requests, we can continue there. :)