Request for publishing: Neat Launcher

Apps
1

Hi!

My github account is Moehriegitt and I am new here.

For my new app, I would like to ask for inclusion in fdroid. Here is the initial fdroid metadata yml file:

https://raw.githubusercontent.com/moehriegitt/NeatLauncher/master/fdroiddata/metadata/de.theiling.neatlauncher.yml

Gitlab asks too many questions, so I have no gitlab account. For this reason, I put the yml in the source repo of the app.

I really hope this a viable way to announce the app. I know this has been discussed but I found no recent hints on how to propose inclusion of a new app into fdroid without a gitlab account.

If this is not the right way, please point me to more docs, I am happy to read and learn.

Best regards,
Moehriegitt

2

Will take a look, thanks

3

do add wrapper/gradle-wrapper.properties in NeatLauncher/gradle at master · moehriegitt/NeatLauncher · GitHub so we know which gradle version you need

4

OK, done! Thanks for the quick look and for guiding me!

5

reading Pithus report for NeatLauncher - de.theiling.neatlauncher I see APK analysis: 0x504b4453: Dependency metadata

looking at your current APK on github:

$ apksigtool parse --json neatlauncher-release-1.0.apk | jq -r '.pairs[].value._type'
APKSignatureSchemeBlock
DependencyInfoBlock
VerityPaddingBlock

hmm looks like you have the DependencyInfoBlock thing :disappointed:

Can you add this fix: APK Signing Block considerations (#1056) · Issues · F-Droid / fdroidserver · GitLab ?

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

first build failed

<   "buildSystemVersion": "8.7",
---
>   "buildSystemVersion": "8.10",

as said, we need to use the same Gradle version

also

<   revision: "f7aa560dd565a75f15cf3a3526f8008e78ad00ee"
---
>   revision: "a0c577088b22804ded4b31390d96a83d2aa19c34"

looks like you tagged from 1.0 to a0c577088b22804ded4b31390d96a83d2aa19c34 but the APK uploaded was built from the tree at f7aa560dd565a75f15cf3a3526f8008e78ad00ee

we understand you need to test commits, but please, when a release is ready, after tagging, build the APK from the tagged commit

up next, we’ll need a new version, tag, release to fix all these issues :wink:

6

Thank you, and sorry! I will fix those things.
How can I make sure to use the same Gradle version? Is including the gradle-wrapper.properties going to fix this or do I need to do more?

7

yes, the tooling reads that and uses the right version :wink:

8

OK, I fixed dep config, tagged, compiled, made a release v1.1. Before, I checked with apksigtool that the depinfoblock issue is gone, and I also double checked the tagging. So maybe the release process issues are fixed now.

Then I updated the fdroid metadata yml file in a commit after the v1.1 release (on master) to include the new release.

1 Like
9

that does not matter as only our metadata file will be used

10

1.1 builds fine and reproducible :tada:

11

report: Pithus report for NeatLauncher - de.theiling.neatlauncher

done: Newapp: Neat Launcher (!15735) · Merge requests · F-Droid / Data · GitLab

@moehriegitt fyi FAQ · Wiki · F-Droid / wiki · GitLab

12

Thank you again for the quick response! :smile:

1 Like
13

I will download your app

14

I have the same problem with my build: Revision numbers do not match.

Could you explain in simple words what exactly is compared to what? Even after a year or so I’m still quite lost in the whole compile & compare process.

For me, the log says
==== detail begin ====
verification of APK with copied signature failed
Comparing reference APK to APK with copied signature…
Unexpected diff output:
diff -r /tmp/tmp0jcz7b22/tmp_binaries_de.chadenas.cpudefense_42.binary/content/META-INF/version-control-info.textproto /tmp/tmp0jcz7b22/_tmp_tmp0jcz7b22_sigcp_de.chadenas.cpudefense_42/content/META-INF/version-control-info.textproto
4c4
< revision: “097c4573fdb625608916436ec0be4081319d2ae5”
—
> revision: “89c02393e9c114aae4a8580bd23fc507af4db2e9”
==== detail end ====

The second revision number is the correct one. But where is the first one from?

15

The checkupdate bot picksup the Tag, and builds from the tagged commit.

We usually see devs do this:

  • edit code
  • build locally an APK
  • verify APK, it’s ok
  • commit code
  • tag from commit
  • push old TESTed APK to release

Do you notice the mistake?

The APK was build from the tree at that point, when it was pointing to an older commit. And your changes were UNcommited. Hence the two commit hashes that differ.

We can remove that info, there’s a guide in Docs, but I like that since it signals these mistakes and others, and helps up track differences in builds.

We understand you need to test your commits, but please follow the steps:

  • code
  • decide to release
  • commit everything you have ready
  • tag
  • build from the tagged commit
  • upload this APK
16

And if the apk is always created before tagging the release, we can also just soft reset the repo before building.

17

Thanks for the explanation. The build has succeeded now. In fact, the commit string in my log above was the second-to-last commit, so that confirms what you have said.

But now I’m seriously wondering why this has ever worked … I have always built first and then tagged later. Maybe I was just lucky that there were no changes to any other file.

18

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.