wrong ```flutter-version in ci.yml?

[IzzySoft]

Your ci.yml specifies flutter-version: '3.19.0'. However, trying to build with that fails:

Because no versions of flutter_lints match >6.0.0 <7.0.0 and flutter_lints 6.0.0 requires SDK version ^3.8.0, flutter_lints ^6.0.0 is forbidden.
So, because habo depends on flutter_lints ^6.0.0, version solving failed.

--- END BUILD LOG ---

Is the version out of sync there? Could you please bring it in sync again? Thanks in advance!

[xpavle00]

Hey, yeah, it is a bit outdated.I will look at this and fix somehow to not cause confusion.

[IzzySoft]

Thanks! 🤗 For some background on our build: it's for Reproducible Builds. With Flutter, the version needs to match (as need the build paths, as Flutter embeds them in its native libs).

[xpavle00]

I hope it works now.

[IzzySoft]

At the 3rd try, a successful build – but the APKs do not match. First and very strange:

     XML ELEM START [lineno=2, name='manifest', #attributes=7]
-      ATTR: http://schemas.android.com/apk/res/android:versionCode=7002
+      ATTR: http://schemas.android.com/apk/res/android:versionCode=2001
       ATTR: http://schemas.android.com/apk/res/android:versionName='3.1.0'

Your APK has versionCode 7002, ours 2001. Looking at pubspec.yaml I see version: 3.1.0+1 – is this really the very first version? In that case, 2001 would make sense: Flutter's default for per-ABI splits is to add 1000 x ABIcode to it – and 2001 matches arm64 for versionCode 1. But I've got no idea how your APK comes with 7002; looks like an inverted one, using versionCode x 1000 + ABI; much more sane than what Flutter's default is – but where does the 7 come from, and why does our build not get that?)

But there are plenty more differences – as if the APK was not built from the same commit. Unfortunately, Flutter does not manage to embed the correct vcsInfo, so we cannot tell what your APK was built from – we can just assume it must be from the tagged commit, but it looks like it was not. Could have another reason, though. For example, many PNGs differ:

  -rw----     0.0 fat     1096 b-     1096 stor 1981-01-01 01:01:02 452a314b res/h7.9.png
- -rw----     0.0 fat    12582 b-    12582 stor 1981-01-01 01:01:02 bd34ffef res/h7.png
+ -rw----     0.0 fat    12582 b-    12582 stor 1981-01-01 01:01:02 b761266b res/h7.png
  -rw----     0.0 fat      520 b-      286 defN 1981-01-01 01:01:02 cd414cb6 res/hI.xml

This could be PNG crunching, or vector graphics generated during the build – see e.g. Differing *.png files. Next:

  -rw-r--r--  0.0 unx     1321 b-      275 defN 1981-01-01 01:01:02 e4296315 assets/flutter_assets/FontManifest.json
- -rw-r--r--  0.0 unx   137743 b-   135879 defN 1981-01-01 01:01:02 dd4e5b09 assets/flutter_assets/NOTICES.Z
+ -rw-r--r--  0.0 unx   137743 b-   135879 defN 1981-01-01 01:01:02 12e7f6ef assets/flutter_assets/NOTICES.Z
  -rw-r--r--  0.0 unx       45 b-       47 defN 1981-01-01 01:01:02 eb8653b5 assets/flutter_assets/NativeAssetsManifest.json

we see this quite often. I could not yet figure what causes it; this file seems to be partly cobbled together at build time. Fun thing here is (and that's not the usual case) even the uncompressed size is identical. And that diff cannot find any difference – though the checksums differ. Leaves me clueless; but lets first go for the remaining diff: native libraries.

  -rw-r--r--  0.0 unx   264400 b-   264400 stor 1981-01-01 01:01:02 91d42fc1 lib/arm64-v8a/libFLAC.so
- -rw-r--r--  0.0 unx  9503664 b-  9503664 stor 1981-01-01 01:01:02 cf36d807 lib/arm64-v8a/libapp.so
+ -rw-r--r--  0.0 unx  9503664 b-  9503664 stor 1981-01-01 01:01:02 38125223 lib/arm64-v8a/libapp.so
  -rw-r--r--  0.0 unx     7112 b-     7112 stor 1981-01-01 01:01:02 4f56ac38 lib/arm64-v8a/libdatastore_shared_counter.so
- -rw-r--r--  0.0 unx 11107920 b- 11107920 stor 1981-01-01 01:01:02 57a19629 lib/arm64-v8a/libflutter.so
- -rw-r--r--  0.0 unx  1693064 b-  1693064 stor 1981-01-01 01:01:02 8ce904d9 lib/arm64-v8a/libflutter_soloud_plugin.so
+ -rw-r--r--  0.0 unx 11107920 b- 11107920 stor 1981-01-01 01:01:02 e9404d55 lib/arm64-v8a/libflutter.so
+ -rw-r--r--  0.0 unx  1693064 b-  1693064 stor 1981-01-01 01:01:02 0039671e lib/arm64-v8a/libflutter_soloud_plugin.so
  -rw-r--r--  0.0 unx    29968 b-    29968 stor 1981-01-01 01:01:02 94543576 lib/arm64-v8a/libogg.so

I have a vague hunch, let me run diffoscope and see if it confirms it… OK, first finding is something different, but could explain this as well: your build uses a different version of the Dart SDK. You didn't really pin its version: sdk: ">=3.0.0 <4.0.0" is pretty vague, and so we have 3.10.4 with your build, and 3.10.3 with ours. Could not find what I was looking for, but could it be you've built that APK locally on your machine, and not with the Github action? Flutter embeds the full build path into its native libraries, so we need to match them – which means they need to match each build 😉

Attaching you the full diffs if you want to look at them yourself: diff.zip

Thanks for your help with this!

[xpavle00]

Hey, I was building it on my machine for a long time. This time, I tried to do separate APKs with Codemagic, as I am building an ABI for the store. Maybe that does some strange things? Should I build it again on my machine to fix that for now?

Also, I had versions 5000, 6000, 7000 due to some mistake in the past(standard builds are 5000+), so my builds started at 5000+

[IzzySoft]

Well, we don't have any mages here. Could you explain what that means to the build process? This is the recipe we've been using here:

build:
  - sed -r '/signingConfigs.release/d' -i android/app/build.gradle
  - echo -e "keyAlias=keyAlias\nkeyPassword=keyPassword\nstorePassword" > key.properties
  - FLUTTER_VERSION="$(sed -rn 's/^\s*flutter-version:\ .([0-9\.]*).*?/\1/p' .github/workflows/ci.yml | head -n 1)"
  - git clone -b $FLUTTER_VERSION https://github.com/flutter/flutter
  - export PUB_CACHE=$(pwd)/.pub-cache
  - export PATH="${PATH}:${PWD}/flutter/bin"
  - flutter config --no-analytics
  - flutter pub get
  - dart run flutter_iconpicker:generate_packs --packs fontAwesomeIcons
  - dart format --set-exit-if-changed .
  - flutter build apk --release --split-per-abi --target-platform=android-arm64 --no-tree-shake-icons

We were going by your Github action there (also paths have been set to that accordingly).

I was building it on my machine for a long time.

That could explain indeed, as Flutter embeds the build paths into its native libs. Can you please tell what exact path you build in, so we can adjust the recipe accordingly? That would mostly be these 3 settings:

build_home_dir: /home/runner
build_repo_dir: /home/runner/work/Habo/Habo/Habo
build_user: runner

Alternatively, having the release builds done by that GHA would be a really good idea. And in case you wonder about the first 2 lines of our recipe: we need to build an unsigned APK here, but your setup enforces signing, so we need to adjust that accordingly. See also Signing Config in our documentaion for how to make signing optional (e.g. only enforce it when the keystore file is present).

[xpavle00]

Ok, I changed a bit of ci.yml and signed the build from GitHub action. Hope it helps.

[IzzySoft]

Looks like now we have multiple issues here:

• APK size exceeds the per-app limit (30 MB) at IzzyOnDroid
• we cannot RB this, as you include "Github internals" with your build: --build-number=$((5100 + ${{ github.run_number }})) – we cannot obtain that "run_number" at our end, sorry.

The first point could be resolved would you enable "legacy compression" for the native libs – which currently make up more than 25 MB. This would probably bring the APK size close to 20 MB again. The second one would mean to simply set the versionCode properly in your pubspec.yaml. If you insist on automating that: OK, use that run_number – but have it update pubspec.yaml instead, commit that, and tag that commit for the release. Then our build (and yours, too) can simply read the number from there.