[Bug] wrong build?

[IzzySoft]

It looks like you did not only rebrand (bringing our updates out of step, which complained about the "illegal APK" with a wrong AppID), but also built from a dirty tree: Reproducible Build failed for v1.1.0. Significant marker:

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

As even the latest commit here states a versionCode of 1100, the APK must have been built from somewhere else. With several more changes, as the APK diff suggests:

  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 05cd8676 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx      841 b-      841 stor 1981-01-01 01:01:02 8b81a20f assets/dexopt/baseline.prof
- -rw-r--r--  0.0 unx      140 b-      140 stor 1981-01-01 01:01:02 bf501688 assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  3379064 b-  1316158 defN 1981-01-01 01:01:02 ee8a010b classes.dex
- -rw-r--r--  0.0 unx 10814368 b-  4182684 defN 1981-01-01 01:01:02 b02bad6e lib/arm64-v8a/libapp.so
+ -rw-r--r--  0.0 unx      791 b-      791 stor 1981-01-01 01:01:02 b17a93df assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx      140 b-      140 stor 1981-01-01 01:01:02 080812f6 assets/dexopt/baseline.profm
+ -rw-r--r--  0.0 unx  3387540 b-  1318885 defN 1981-01-01 01:01:02 9af09ed2 classes.dex
+ -rw-r--r--  0.0 unx 10814368 b-  4204655 defN 1981-01-01 01:01:02 2b184b3e lib/arm64-v8a/libapp.so
  -rw-r--r--  0.0 unx     7112 b-     2630 defN 1981-01-01 01:01:02 4f56ac38 lib/arm64-v8a/libdatastore_shared_counter.so
- -rw-r--r--  0.0 unx 11057504 b-  5101058 defN 1981-01-01 01:01:02 a2008240 lib/arm64-v8a/libflutter.so
+ -rw-r--r--  0.0 unx 11277704 b-  5187655 defN 1981-01-01 01:01:02 47d214bf lib/arm64-v8a/libflutter.so
  -rw-r--r--  0.0 unx     1922 b-      410 defN 1981-01-01 01:01:02 7de01059 assets/flutter_assets/AssetManifest.bin
  -rw-r--r--  0.0 unx     1753 b-      364 defN 1981-01-01 01:01:02 a8a213ed assets/flutter_assets/AssetManifest.json
  -rw-r--r--  0.0 unx      557 b-      193 defN 1981-01-01 01:01:02 232e4036 assets/flutter_assets/FontManifest.json
- -rw-r--r--  0.0 unx   105748 b-   100603 defN 1981-01-01 01:01:02 0176a8d7 assets/flutter_assets/NOTICES.Z
+ -rw-r--r--  0.0 unx   100253 b-    96158 defN 1981-01-01 01:01:02 a1d78cf4 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
  -rw-r--r--  0.0 unx   178423 b-   178423 stor 1981-01-01 01:01:02 00cfb87e assets/flutter_assets/assets/GooglePay_QR.png
  -rw-r--r--  0.0 unx  1830080 b-  1830080 stor 1981-01-01 01:01:02 c3280c51 assets/flutter_assets/assets/Logo.png
@@ -37,7 +37,7 @@
  -rw-r--r--  0.0 unx   130633 b-    28566 defN 1981-01-01 01:01:02 66ba4e0d assets/flutter_assets/assets/onboarding/svgs/serverControl.svg
  -rw-r--r--  0.0 unx    10876 b-     6431 defN 1981-01-01 01:01:02 4ae6ec58 assets/flutter_assets/fonts/MaterialIcons-Regular.otf
  -rw-r--r--  0.0 unx     1376 b-      972 defN 1981-01-01 01:01:02 d5f6c8ad assets/flutter_assets/packages/cupertino_icons/assets/CupertinoIcons.ttf
- -rw-r--r--  0.0 unx    21632 b-     5155 defN 1981-01-01 01:01:02 fea5ac3b assets/flutter_assets/shaders/ink_sparkle.frag
+ -rw-r--r--  0.0 unx    21320 b-     5137 defN 1981-01-01 01:01:02 f2f40228 assets/flutter_assets/shaders/ink_sparkle.frag
  -rw----     2.0 fat     1738 b-      782 defN 1981-01-01 01:01:02 d5ac4dc2 DebugProbesKt.bin
  -rw----     2.0 fat        6 b-        8 defN 1981-01-01 01:01:02 21d1b1c6 META-INF/androidx.activity_activity-ktx.version
  -rw----     2.0 fat        6 b-        8 defN 1981-01-01 01:01:02 21d1b1c6 META-INF/androidx.activity_activity.version
@@ -106,7 +106,7 @@
  -rw----     2.0 fat    18640 b-     5252 defN 1981-01-01 01:01:02 f77f89dd kotlin/kotlin.kotlin_builtins
  -rw----     2.0 fat     3399 b-     1292 defN 1981-01-01 01:01:02 cb3b8aed kotlin/ranges/ranges.kotlin_builtins
  -rw----     2.0 fat     2426 b-     1286 defN 1981-01-01 01:01:02 7e3e3d18 kotlin/reflect/reflect.kotlin_builtins
- -rw----     0.0 fat     9096 b-     2400 defN 1981-01-01 01:01:02 39519192 AndroidManifest.xml
+ -rw----     0.0 fat     9096 b-     2401 defN 1981-01-01 01:01:02 9bda3a37 AndroidManifest.xml
  -rw----     0.0 fat      281 b-      281 stor 1981-01-01 01:01:02 ead36c57 res/-B.png
  -rw----     0.0 fat     1088 b-      493 defN 1981-01-01 01:01:02 920202ad res/0E.xml
  -rw----     0.0 fat     1064 b-      339 defN 1981-01-01 01:01:02 a227cfec res/0M.xml
@@ -609,7 +609,4 @@
  -rw----     0.0 fat      464 b-      268 defN 1981-01-01 01:01:02 52f5d8f4 res/zq.xml
  -rw----     0.0 fat       67 b-       67 stor 1981-01-01 01:01:02 88b2a3b0 res/zz.png
  -rw----     0.0 fat   423600 b-   423600 stor 1981-01-01 01:01:02 72542186 resources.arsc

At IzzyOnDroid, we hence had to stop all updates for your app. The badge on your Readme still points to the version available here, so please leave it at that until we were able to switch to your rebranded version. For that, first we need to get the build fixed. May I suggest a v1.1.1 release for that, as v1.1.0 might already have been picked up by some? We also can check your build for that before you publish, to be on the safe side.

Thanks in advance!

[prathameshkhade]

Oh, I see! I actually forgot to update the Flutter version to 3.32.5 in the build-android and build-ios jobs. That’s likely what's causing the reproducible build issue, isn’t it?

At IzzyOnDroid, we hence had to stop all updates for your app. The badge on your Readme still points to the version available here, so please leave it at that until we were able to switch to your rebranded version.

Understood. I'll leave it as it is for now.

May I suggest a v1.1.1 release for that, as v1.1.0 might already have been picked up by some? We also can check your build for that before you publish, to be on the safe side.

Yes, thank you so much for your support!

What should I do next?
Should I update the workflow (with the correct Flutter version), build the APK (locally on my Kali Linux?), and share it here for you to check before releasing it — or is there anything else you'd recommend?

[IzzySoft]

I actually forgot to update the Flutter version to 3.32.5 in the build-android and build-ios jobs. That’s likely what's causing the reproducible build issue, isn’t it?

That's one part. The other is that you must have had local changes when building that APK. As outlined, your APK presents a versionCode higher than the latest available in your repo.

Should I update the workflow (with the correct Flutter version), build the APK (locally on my Kali Linux?), and share it here for you to check before releasing it — or is there anything else you'd recommend?

Else, sorry – as that won't work unless you build in /home/runner/work//SysAdmin/SysAdmin, as your Github workflow does (Flutter embeds path information into its libraries). Of course adjust the workflow, but also make sure the versionCode matches (no idea how you could have built that APK using the workflow; where would it have taken the versionCode from?). When all code should be fine and committed, manually trigger the build-android job (which then should build the APKs, but not create a release). We can then pluck the APKs from the artifacts at Github to run a check and make sure everything fits. Then you can either create the release manually, or trigger the release workflow.

[prathameshkhade]

Hi @IzzySoft,

I’ve updated the workflow to use the correct Flutter version (3.32.5) and verified that the versionCode now matches both locally and in the GitHub Actions build.

APKs from GitHub Actions:

apkanalyzer manifest version-code SysAdmin-v1.1.1-arm64-v8a.apk
11100

apkanalyzer manifest version-code SysAdmin-v1.1.1-armeabi-v7a.apk
11100

apkanalyzer manifest version-code SysAdmin-v1.1.1-x86_64.apk
11100

Locally built APK:

apkanalyzer manifest version-code ~/projects/sysadmin/build/app/outputs/apk/release/app-arm64-v8a-release.apk
11100

Let me know if everything looks good on your end, or if there's anything else I should adjust before proceeding with the release.

[IzzySoft]

If you can provide me the arm64 APK and the commit it was built from, I can check if it is RB. As for versionCode: you're sure you want it identical for all ABIs? I've no problem with that, but e.g. F-Droid could only host multiple ABIs if they have distinctive versionCode each. Example:

• universal APK: 11100
• x86 (ABI=1): 11101
• x86_64 (ABI=2): 11102
• armeabi (3): 11103
• arm64 (4): 11104

So for per-ABI builds, versionCode would be "base versionCode" (from the universal one) with the ABI code added. arm64 > armeabi, x86_64 > x86 (as clients supporting 32bit and 64 bit would choose the APK with the higher versionCode).

Again, not mandatory – I just want to make sure you know this background 😉

[prathameshkhade]

If you can provide me the arm64 APK and the commit it was built from, I can check if it is RB.

Sure! Here's the commit 7c2debe the APK was built from — and I’ve attached the artifact ZIP here as well.
sysadmin-arm64-v8a.tar.gz

So for per-ABI builds, versionCode would be "base versionCode" (from the universal one) with the ABI code added. arm64 > armeabi, x86_64 > x86 (as clients supporting 32bit and 64 bit would choose the APK with the higher versionCode).
Again, not mandatory – I just want to make sure you know this background 😉

Ohh, thanks a lot for this new information regarding ABI-specific versionCodes — that really helps!
Just to confirm: if I want to follow this practice, should I manually generate each APK using Gradle properties like this?

$ flutter build apk --release --target-platform android-arm64 \
  --build-name=1.1.1 --build-number=11104

Or is there a more standard or recommended method to handle this cleanly, especially when using GitHub Actions?

[IzzySoft]

Sure! Here's the commit …

Congrats:

--- END BUILD LOG ---
Keeping 'f934466643a83e27aaa9a3caee25040e3e3f6cace1aff097eb07c6ca3b9fd91d-dev.prathameshkhade.sysadmin-7c2debee3e2d577c1078f9bcc38902a91d8a255a-upstream.apk'...
Keeping '510a3f0e94366823fa650062435d38eaffbee65c0db79a64f4330eb561458823-dev.prathameshkhade.sysadmin-7c2debee3e2d577c1078f9bcc38902a91d8a255a-unsigned.apk'...
Reproducible: True

That is fine! 🥳

Or is there a more standard or recommended method to handle this cleanly, especially when using GitHub Actions?

Sure. Via gradle. Take a look at this example, which does what I described above.

[prathameshkhade]

That is fine! 🥳

Wohoo, thanks! 😃

Sure. Via gradle. Take a look at this example, which does what I described above.

As per the example you shared, I’ve made changes in my build.gradle to include ABI-based offsets for versionCode.

Just one thing — instead of multiplying by 10, I'm directly adding the ABI offset. Is that okay?

// ABI-specific version code configuration
ext.abiCodes = ["x86_64": 1, "armeabi-v7a": 2, "arm64-v8a": 3]
import com.android.build.OutputFile
android.applicationVariants.all { variant ->
    variant.outputs.each { output ->
        def abiVersionCode = project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))
        if (abiVersionCode != null) {
            output.versionCodeOverride = variant.versionCode + abiVersionCode
        }
    }
}

Here’s what I’m doing:

• For version v1.1.0, I use versionCode = 11000

• For v1.1.1, I use versionCode = 11010

  • 11011 → x86
  • 11012 → x86_64
  • 11013 → armeabi-v7a
  • 11014 → arm64-v8a

• Next release v1.1.2 will start from 11020, and follow the same pattern

This way, each ABI has a unique and predictable versionCode for every release.

Does that sound correct and compatible with F-Droid’s expectations?

Thanks again for all your help! 🙌

[IzzySoft]

instead of multiplying by 10, I'm directly adding the ABI offset. Is that okay?

That very much depends on how much you increase the base versionCode. The multiplier is a safeguard there, to ensure there's always enough room for all ABIs. So what you describe there is: you already do the factor-10 in the base versionCode, so it matches. It's basically the same thing, just implemented differently – and requiring you to remember keeping the space.

Does that sound correct and compatible with F-Droid’s expectations?

F-Droid does not much care how you implemented it, as ling as "each ABI has a unique and predictable versionCode for every release" 😉

Thanks again for all your help! 🙌

Gladly!

So once the next release is out, please give me a ping here so I set up RB for it 😃

[prathameshkhade]

F-Droid does not much care how you implemented it, as ling as "each ABI has a unique and predictable versionCode for every release" 😉

Ohh 😁

Gladly!

🤗

So once the next release is out, please give me a ping here so I set up RB for it 😃

Yeah, sure 😄

[prathameshkhade]

Hii @IzzySoft ,
Just released v1.1.1 with 11010 version code, please check

[IzzySoft]

Success! 🥳 Please update your badge then once the next sync is through, so it points to the new app. I've aslo prepended a hint to the "old app" indicating the switch, so people find their way over. Will leave both in place for a while (a month or so) for that, then remove the "old app".

All set then I guess. If everything shows up correctly with the next sync (around 6 pm UTC), this issue can then be closed. Thanks for your help!

[IzzySoft]

Oh, PS: by then, a new nice shield will be available to you:

[<img src="https://shields.rbtlog.dev/simple/dev.prathameshkhade.sysadmin" alt="RB shield">](https://shields.rbtlog.dev/dev.prathameshkhade.sysadmin)

will show its RB status. Using the "old app", this is how it looks:

Seeing you love shields, I thought you might wish to add this one to your Readme, too 😉

[prathameshkhade]

Success! 🥳 Please update your badge then once the next sync is through, so it points to the new app. I've aslo prepended a hint to the "old app" indicating the switch, so people find their way over. Will leave both in place for a while (a month or so) for that, then remove the "old app".

All set then I guess. If everything shows up correctly with the next sync (around 6 pm UTC), this issue can then be closed. Thanks for your help!

Nice 😄 Sure I will update the batch so that it will point to the new app! Thank you so much ❤️