Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

F-Droid inclusion #47

Open
shuvashish76 opened this issue Sep 15, 2024 · 37 comments
Open

F-Droid inclusion #47

shuvashish76 opened this issue Sep 15, 2024 · 37 comments

Comments

@shuvashish76
Copy link

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

@HemantKArya
Copy link
Owner

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
Copy link
Author

ping @linsui for help

@linsui
Copy link

linsui commented Sep 16, 2024

@HemantKArya
Copy link
Owner

HemantKArya commented Sep 17, 2024

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
Copy link

linsui commented Sep 17, 2024 via email

@HemantKArya
Copy link
Owner

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
Copy link

linsui commented Sep 17, 2024

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
Copy link
Owner

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

run: flutter build apk --release --split-per-abi --build-number ${{github.run_number}}
.

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
Copy link

linsui commented Sep 21, 2024

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
Copy link
Owner

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
Copy link

linsui commented Sep 22, 2024

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
Copy link
Owner

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
Copy link

linsui commented Sep 22, 2024 via email

@HemantKArya
Copy link
Owner

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
Copy link

linsui commented Sep 23, 2024

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
Copy link
Owner

HemantKArya commented Sep 23, 2024

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

@linsui
Copy link

linsui commented Sep 23, 2024

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

@HemantKArya
Copy link
Owner

HemantKArya commented Sep 23, 2024

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 (bc86121) 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
Copy link

linsui commented Sep 23, 2024

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
Copy link
Owner

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
Copy link

linsui commented Sep 23, 2024

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

@HemantKArya
Copy link
Owner

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
Copy link

linsui commented Sep 23, 2024

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
Copy link
Owner

HemantKArya commented Sep 23, 2024

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
Copy link

linsui commented Sep 24, 2024

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
Copy link
Owner

@linsui
Copy link

linsui commented Sep 24, 2024

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

@HemantKArya
Copy link
Owner

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

@linsui
Copy link

linsui commented Sep 24, 2024

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

@linsui
Copy link

linsui commented Sep 24, 2024

Please add the pubspec.lock in git.

@HemantKArya
Copy link
Owner

you mean here in github right?

@linsui
Copy link

linsui commented Sep 24, 2024

Yes. :)

@HemantKArya
Copy link
Owner

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

@linsui
Copy link

linsui commented Sep 25, 2024

We need to build isar from source. You need to add a lock file for it. See immich-app/immich#12705 for example.

@HemantKArya
Copy link
Owner

HemantKArya commented Sep 25, 2024

@HemantKArya
Copy link
Owner

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

@linsui
Copy link

linsui commented Sep 26, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants