@kelson42 I'd like to take this up.
I have an idea on how to add a new app to fdroid.
But I don't have any experience in updating an app on fdroid. Could you please guide me as to how do we update an existing app on fdroid?
@yashk2000 Thx, look at #1698, 3.2.1 should be published.
@kelson42 I just wanted to confirm the version code. 230201 is the current version code right?
I am referring to https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6232/diffs for sending the merge request.
@yashk2000 I can not help you for that, you need to ask other devs. But obviously, this is not the same naymore.
@yashk2000 I guess the new code should be 230201 yes
@kelson42 I made the merge request on GitLab.
@macgills could I please get some help here?
The apk which is generated seems to be signed already. The disableSigning config seems to not be working as expected.
@yashk2000 You are not able to fix the option yourself? Or understand what goes wrong?
@kelson42 this is the code that handles the release configuration:
getByName("release") {
buildConfigField("boolean", "KIWIX_ERROR_ACTIVITY", "true")
if (properties.containsKey("disableSigning")) {
signingConfig = null
}
}
Here the signing config is made null.
This should work if a release apk is being made. So I generated release apks for the application and ran the following command:
apksigner verify --print-certs dev-universal-release.apk
Here, it shows that the apk is already signed.
Signer #1 certificate DN: CN=Alexandre Saveau, OU=Robot Scouter, O=SUPERCILEX
If the apk was unsinged, this shouldn't have been the value of CN.
I'm not sure how to give disableSigning as an option in the input to test what's happening or whether disableSigning is automatically taken as an input.
I removed this condition:
if (properties.containsKey("disableSigning")) {
signingConfig = null
}
I just put signingConfig = null without a condition which worked. So I want to know how to give disableSigning as an input paramter while generating apks inorder to test it. Or whether it is automatically there.
that property is there so when it is built on fdroid's side it does not try to sign it for example
gradlew -PdisableSigning app:assembleRelease
will produce an unsigned apk.
Kiwix has dummy credentials in source control so people can sign things locally without issue and our build are more repeatable. On CI these dummy credentials get overwritten and the real signing keys are used.
The only thing I see different in the merge request is there is no .gradle under scanIgnore
- versionName: 3.1.3
versionCode: 230103
commit: 3.1.4
subdir: app
gradle:
- yes
output: build/outputs/apk/release/dev-universal-release-unsigned.apk
scanignore:
- buildSrc
- .gradle
gradleprops:
- disableSigning
- versionName: 3.2.1
versionCode: 230201
commit: 3.2.1
subdir: app
gradle:
- yes
output: build/outputs/apk/release/dev-universal-release.apk
scanignore:
- buildSrc
gradleprops:
- disableSigning
If disableSigning has been broken you should investigate why. For the fdroid build we want signingconfig to be null
@macgills I tried this command. It generates the unsigned apk. This means that disableSigning isn't broken.
Have you tried a merge request with
``
scanignore:
- buildSrc
- .gradle
````
the.gradle` present? That is the only difference I see in the 2 blocks
@abdulwd @mhutti1 Would one of you be able to make that happens?
@kelson42 I did open an mr on GitLab for this purpose, but I didn't receive any updates on it later on.
Have you tried a merge request with
scanignore:
- buildSrc
- .gradle
the .gradle present? That is the only difference I see in the 2 blocks
@macgills yes I tried that. But the fdroid maintainer told me to remove it because the .gradle folder is no more. Here is a link to his comment.
is this output: build/outputs/apk/release/dev-universal-release.apk correct when you build an unisgned apk with disableSigning? I would imagine the apk should be named with an unsigned
@macgills on running ./gradlew -PdisableSigning app:assembleRelease I get dev-universal-release-unsigned.apk
Then this is the offending line
output: build/outputs/apk/release/dev-universal-release.apk
because it is not pointing at the unsigned version
@macgills could this be fixed by explicitly defining the output apk path in the build.gradle?
Just update the merge request to have the correct path
@macgills did that. Actually I made the change in the path because the fdroid maintainer told me to.
I reverted that change now and asked for a review again.
Let's hope we get a response fast.
@macgills could you please look into this?
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6415#note_326678907
It still isn't working. I changed the path, and disableSigning also seems to be working when I tried it.
@kelson42 @macgills this issue can be closed now.
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6415
The MR has been merged now.
@yashk2000 Thx, so far I don't see 3.2 in FDroid (might come in a few days)... and we need anyway to do 3.3 now!
@kelson42 The MR just got merged a few minutes ago. 3.2 should be available soon.
If we are ready for the 3.3 release, I can open a new MR for 3.3 now.
@yashk2000 This is probably a bit too early to make a new PR, lets way around a week so the 3.3 milestone is closed first.
@kelson42 sure. The release is supposed to be made by April end according to the milestone.
So I'll open a new MR then :)
Yes, we want to wait for 3.3.1 which will be the public release, 3.3.0 is a beta release only
@macgills I would really like to see this happening and secure the publication happens automatically in the future #1682. You can put that high on your prio list.
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6790 merge request open
We have a serious problems if MR are not merged. We really need to move on with automatic publishing...
We have both tried contacting the person we have had most contact with at fdroid, I don't know if the current MR is unsatisfactory or licaon is just busy? I don't know what is the appropriate channel for reaching out to them
@macgills PR has been merged. Should we close this ticket?
And I suppose open a new one for the 3.4 release? We will be skipping over a few releases on fdroid.
Or we could do a release of 3.3.4? quite a stable version I believe
@macgills if 3.3.4 is easy to publish manually, OK to me. But from 3.4, I would like to have https://github.com/kiwix/kiwix-android/issues/1682 implemented so we don't bother too much in the future.