Reproducible Builds

[IzzySoft]

I've checked your app if its build is reproducible (see: Reproducible bulds, special client support and more in our repo), but while I was able to successfully generate the APK using ./gradlew assembleRelease, the differences to the one provided at your latest release were huge. Was that APK really built from the commit the tag points to? If so, did I miss some build options? And if not, which commit was it?

APK Diff:

-------------------------------
--- /dev/fd/63  2024-07-19 20:30:39.369086406 +0200
+++ /dev/fd/62  2024-07-19 20:30:39.369086406 +0200
@@ -3,11 +3,11 @@
   META-INF/version-control-info.textproto
   32-bit CRC value (hex):                         3c8ae285
   assets/dexopt/baseline.prof
-  32-bit CRC value (hex):                         29abf12e
+  32-bit CRC value (hex):                         9a7a4c49
   assets/dexopt/baseline.profm
-  32-bit CRC value (hex):                         316a3302
+  32-bit CRC value (hex):                         c9a258cb
   classes.dex
-  32-bit CRC value (hex):                         c75fc7cb
+  32-bit CRC value (hex):                         8dd44524
   lib/arm64-v8a/libaria2c.so
   32-bit CRC value (hex):                         2a243272
   lib/arm64-v8a/libaria2c.zip.so
@@ -227,13 +227,13 @@
   META-INF/native-image/okhttp/okhttp/resource-config.json
   32-bit CRC value (hex):                         f5dec0e8
   META-INF/services/com.fasterxml.jackson.core.JsonFactory
-  32-bit CRC value (hex):                         a99eb9c4
+  32-bit CRC value (hex):                         b3197263
   META-INF/services/com.fasterxml.jackson.core.ObjectCodec
-  32-bit CRC value (hex):                         20f7617d
+  32-bit CRC value (hex):                         09ea2bfa
   META-INF/services/kotlinx.coroutines.CoroutineExceptionHandler
-  32-bit CRC value (hex):                         167298eb
+  32-bit CRC value (hex):                         8f594b50
   META-INF/services/kotlinx.coroutines.android.AndroidDispatcherFactory
-  32-bit CRC value (hex):                         bd6769a0
+  32-bit CRC value (hex):                         4b95597f
   javax/annotation/CheckForNull.java
   32-bit CRC value (hex):                         266f00ba
   javax/annotation/CheckForSigned.java
@@ -329,7 +329,7 @@
   res/-51.xml
   32-bit CRC value (hex):                         c51a4f37
   res/-7.xml
-  32-bit CRC value (hex):                         097e63c0
+  32-bit CRC value (hex):                         34a4cac3
   res/-9.xml
   32-bit CRC value (hex):                         a21466a8
   res/-A.png
@@ -339,9 +339,9 @@
   res/-B.xml
   32-bit CRC value (hex):                         5dcbf80d
   res/-D.xml
-  32-bit CRC value (hex):                         bde9b38c
+  32-bit CRC value (hex):                         3c7adcc7
   res/-E.xml
-  32-bit CRC value (hex):                         53db60ba
+  32-bit CRC value (hex):                         546b7ed5
...

We'd appreciate if you could help making your build reproducible. We've prepared some hints on reproducible builds for that.

Looking forward to your reply!

[zaednasr]

I believe i built the apk before posting the commit. So that could be the case. I have some changes pending. I'll commit those and build an apk for you to compare.

[IzzySoft]

I believe i built the apk before posting the commit.

Which is one way to guarantee it's not RB, yeah – see the linked hints, §1 :stuck_out_tongue_winking_eye:

I have some changes pending. I'll commit those and build an apk for you to compare.

Will that be a new release then? Because only releases are relevant. I could of course test-run it first to see if it is RB – just in case there are other culprits, to ensure we cover them all and have a fine RB release then. For that just ping me with an APK and the information which commit it was built from. Thanks!

[zaednasr]

Alright, next release it is. Will let you know

[zaednasr]

Try this apk using the latest commit https://we.tl/t-KWOsKfVlOs

[IzzySoft]

Could you please attach the APK here (simply rename it to *.zip, do not put it inside another zip) and name the commit? "latest" is a "moving target" (and I cannot download from the link you provided, sorry).

[zaednasr]

Cant send it here because the max limit is 25mb. What other method do you prefer

[IzzySoft]

Maybe temporarily attach it to the release (with a "test name"), I'll let you know once I've grabbed it so you can remove it again? Don't forget to name the commit hash I should check against.

[zaednasr]

ok

[zaednasr]

https://github.com/deniscerri/ytdlnis/releases/tag/v1.7.9.1

[IzzySoft]

Build failed:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:dataBindingMergeDependencyArtifactsRelease'.
> Could not resolve all files for configuration ':app:releaseCompileClasspath'.
   > Could not find com.devbrackets.android:exomedia:4.3.0.
     Required by:
         project :app
   > Could not find com.github.TeamNewPipe:NewPipeExtractor:0.24.2.
     Required by:
         project :app

Are those dependencies in some private repo(s)?

[zaednasr]

No

[IzzySoft]

Note: this artifact is located at JCenter repository (https://jcenter.bintray.com/)

Well, JCenter closed a couple of weeks ago – and that's where com.devbrackets.android:exomedia:4.3.0 was located. If you'd switch to a newer version: 5.x is available at Maven Central.

NewPipeExtractor seems to be available at Jitpack, which you have enabled, so I wonder why that is not found. Can you check, please – and fix those dependencies which no longer resolve?

[zaednasr]

I'll have a look at it later today

[zaednasr]

I switched to exomedia 5.1.0 and that built fine but cant reproduce the newpipextractor issue.

What error is popping up?

[IzzySoft]

The one shown above. If you give me a commit hash and its matching APK, I can re-check if you want.

[zaednasr]

@IzzySoft the test release was somewhat of a disaster. People still downloaded it and threw me errors 😁. Need to find another way to give you the apk. Like there isnt any other file hosting service i can use?

[IzzySoft]

Guess if you name the release "THIS WILL EAT YOUR CAT!!!" they'd still try it out, huh? :see_no_evil: Are you using Github Actions to build? I see there's a workflow defined. If so, you could link me to the artifact maybe.

As for file hosting services: haven't use any in ages, so I cannot tell. The one you used last time wanted me to agree to their TOS and all, and that's a bit much for just downloading a test file…

[jeyjai]

Ppl use obtainium and that will grab new releases no matter what he writes in the release or filename

[IzzySoft]

that cannot be helped then. Can Obtainium not be told to ignore pre-releases? Oof…

[zaednasr]

@IzzySoft i managed to get the github action build to succeed. I just now need to find a way to create apks right in github. I guess that would be the best course of action.

[IzzySoft]

Sounds good! :crossed_fingers: Doing it via Github CI ensures builds from a clean tree. Dirty trees are the main reason of RB fails, so this sounds good :smiley:

[zaednasr]

@IzzySoft the latest action build generated the apks you can check out and see. I guess in the following releases, ill just grab the generated apks from github and use them in the release so we can have transparency.

Also about that newpipe error, somehow gradle wanted the company name to be in lowercase to work. 😁

[IzzySoft]

the latest action build generated the apks you can check out and see.

Now I'll need to figure how to find that artifact and how to match it to which commit it was built from… OK, the latter is clear. The former not: there's only a 250+ MB ZIP file… Eek, and not even downloadable via wget or curl as the link is not direct to the zip… Guess you'll add downloading artifacts later then?

OK, managed to download the full ZIP, extract the APK, and running the RB check. But it's not RB:

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 16e72a9e META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     5125 b-     5125 stor 1981-01-01 01:01:02 e6456266 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     5125 b-     5125 stor 1981-01-01 01:01:02 0f8bf6e7 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      396 b-      396 stor 1981-01-01 01:01:02 48b4a4cc assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx 10043204 b-  4354747 defN 1981-01-01 01:01:02 f3c4df5a classes.dex
+ -rw-r--r--  0.0 unx 10042968 b-  4354666 defN 1981-01-01 01:01:02 6fd96133 classes.dex
  -rw-r--r--  0.0 unx   631400 b-   254102 defN 1981-01-01 01:01:02 52f51e23 classes2.dex
  -rw-r--r--  0.0 unx  2362568 b-   852191 defN 1981-01-01 01:01:02 2a243272 lib/arm64-v8a/libaria2c.so
  -rw-r--r--  0.0 unx  1672335 b-  1665102 defN 1981-01-01 01:01:02 648a6fac lib/arm64-v8a/libaria2c.zip.so
@@ -1667,7 +1667,7 @@
  -rw----     0.0 fat      884 b-      884 stor 1981-01-01 01:01:02 0ef1b92c res/zz.png
  -rw----     0.0 fat      532 b-      205 defN 1981-01-01 01:01:02 a50d3889 res/zz.xml
  -rw----     0.0 fat  2922860 b-  2922860 stor 1981-01-01 01:01:02 7f51ca9f resources.arsc
- -rw-r--r--  0.0 unx   150110 b-    68236 defN 1981-01-01 01:01:02 b3cdd6b7 META-INF/CERT.SF
- -rw-r--r--  0.0 unx     1375 b-     1102 defN 1981-01-01 01:01:02 e1a8e130 META-INF/CERT.RSA
- -rw-r--r--  0.0 unx   150036 b-    64662 defN 1981-01-01 01:01:02 413b0dcc META-INF/MANIFEST.MF
- 1670 files, 46855332 bytes uncompressed, 37623193 bytes compressed:  19.7%
+ -rw-r--r--  0.0 unx   150110 b-    68235 defN 1981-01-01 01:01:02 621c0082 META-INF/CERT.SF
+ -rw-r--r--  0.0 unx     1167 b-     1021 defN 1981-01-01 01:01:02 be28c0d6 META-INF/CERT.RSA
+ -rw-r--r--  0.0 unx   150036 b-    64657 defN 1981-01-01 01:01:02 0d450b76 META-INF/MANIFEST.MF

Next to the classes.dex, I wonder how comes that my local build ends up to be signed?

Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 66bddff52ca3d64700b8f0793d79efbc5634b7668740683ce3be18b48a457f7e
Signer #1 certificate SHA-1 digest: eb702217e298990e41c2cb25815f027ab0c4723f
Signer #1 certificate MD5 digest: c2e582e8e99d644d5ef7db02d7774034
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

Hmpf. Guess I'll need to update my recipe and patch out some more signing stuff from build.gradle. Looking at the dex diff it's clear what's missing:

-    #5              : (in Lcom/deniscerri/ytdl/BuildConfig;)
-      name          : 'signingConfigkeyAlias'
-      type          : 'Ljava/lang/String;'
-      access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : "S4n1t1z3D"
-    #6              : (in Lcom/deniscerri/ytdl/BuildConfig;)
-      name          : 'signingConfigkeyPassword'
-      type          : 'Ljava/lang/String;'
-      access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : "S4n1t1z3D"
-    #7              : (in Lcom/deniscerri/ytdl/BuildConfig;)
-      name          : 'signingConfigstoreFile'
-      type          : 'Ljava/lang/String;'
-      access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : "release_keystore.jks"
-    #8              : (in Lcom/deniscerri/ytdl/BuildConfig;)
-      name          : 'signingConfigstorePassword'
-      type          : 'Ljava/lang/String;'
-      access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : "S4n1t1z3D"

Your artifact's APK contains the build config's signing data? :eyes: :scream: Guess it's time for a new certificate then (in the diff, I've sanitized the values except for the keystore file). Was it that way with previous releases as well? (checking) oof, unfortunately yes – so we must consider your signing key compromised, and you need to change to a new one. You could use Signing Key Rotation, but that will only help devices running Android-9 or later (so 6-8 would need an uninstall/reinstall).

[zaednasr]

Why new certificate? How can you even figure out the signing data? Am i not supposed to sign the app?

[zaednasr]

Or does the github action configuration not build the apk properly?

[IzzySoft]

Look above in the diff: there's the keystore, the alias and the passwords. What else do I need to properly sign an APK in your name? Do I miss something? Ah, maybe the keystore is just mentioned but luckily was not checked in. (checking) OK, it's generated at build time from a secret, oof. OK, then maybe no need to change the key itself. But the passwords at least, and make sure they're not ending up in the APK anymore then. Luckily at least the keystore itself didn't end up in the APK. So if you consider its storage safe enough (and thus the risk of someone obtaining it low enough), maybe that should be sufficient.

And that com/deniscerri/ytdl/BuildConfig should not be part of the APK (else we cannot achieve RB – apart from the fact of your passwords being contained there in cleartext being a very bad idea).

[zaednasr]

The confusing part is that the passwords are also stored in secrets. But i create the local.properties file in the github actions to build the apk. Did you get the password from that? Did the file not delete after the build?

Can you guide me how to resolve this?

[zaednasr]

I think buildconfig gets data from local.properties. If i add the passwords to another .properties file ill be good. Testing that

[zaednasr]

Try this run please https://github.com/deniscerri/ytdlnis/actions/runs/10654766901

[IzzySoft]

The confusing part is that the passwords are also stored in secrets. But i create the local.properties file in the github actions to build the apk. Did you get the password from that? Did the file not delete after the build?

I get the passwords when using Apktool to unpack it and generate the Smali code from it. They are stored in a class named com/deniscerri/ytdl/BuildConfig, as shown by the above Dex diff. I've never seen such before in any of the apps I've analyzed. You can find the corresponding code references here.

I think buildconfig gets data from local.properties. If i add the passwords to another .properties file ill be good. Testing that

Not sure, but I'm no Android dev. I've seen other projects using local.properties for keystore stuff, but it didn't end up this way.

Try this run please

OK, will do… BuildConfig is still there, but the sensitive information is gone from it. Now let's see what the verification builder say: not RB. Hm. APK diff:

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 1aac3f57 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     5104 b-     5104 stor 1981-01-01 01:01:02 430965b1 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     5105 b-     5105 stor 1981-01-01 01:01:02 232ce725 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      396 b-      396 stor 1981-01-01 01:01:02 baf29ca2 assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx 10045520 b-  4355000 defN 1981-01-01 01:01:02 a4800405 classes.dex
+ -rw-r--r--  0.0 unx 10045520 b-  4354997 defN 1981-01-01 01:01:02 c16457ad classes.dex
  -rw-r--r--  0.0 unx   631400 b-   254102 defN 1981-01-01 01:01:02 52f51e23 classes2.dex
  -rw-r--r--  0.0 unx  2362568 b-   852191 defN 1981-01-01 01:01:02 2a243272 lib/arm64-v8a/libaria2c.so
  -rw-r--r--  0.0 unx  1672335 b-  1665102 defN 1981-01-01 01:01:02 648a6fac lib/arm64-v8a/libaria2c.zip.so
@@ -140,7 +140,7 @@
  -rw----     2.0 fat    25972 b-     7092 defN 1981-01-01 01:01:02 0eee32e3 org/mozilla/javascript/resources/Messages_fr.properties
  -rw----     2.0 fat     2579 b-     1042 defN 1981-01-01 01:01:02 1e1d6243 org/mozilla/javascript/tools/debugger/test.js
  -rw----     2.0 fat     8222 b-     2787 defN 1981-01-01 01:01:02 9bda5daa org/mozilla/javascript/tools/resources/Messages.properties
- -rw----     0.0 fat    42792 b-     7129 defN 1981-01-01 01:01:02 1d803ecb AndroidManifest.xml
+ -rw----     0.0 fat    42792 b-     7135 defN 1981-01-01 01:01:02 133a5067 AndroidManifest.xml
  -rw----     0.0 fat      744 b-      344 defN 1981-01-01 01:01:02 1312bbae res/-1.xml

OK, still the Dex. But also the Manifest? (Edit: removed this section as it turned out irrelevant) So let's see the dex diff:

-checksum            : 9ddf47b4
-signature           : 63dd...7072
+checksum            : ea914968
+signature           : aa7b...7cc1
 file_size           : 10045520
 header_size         : 112
 link_size           : 0
@@ -409077,7 +409077,7 @@
       name          : 'VERSION_CODE'
       type          : 'I'
       access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : 107090100
+      value         : 107090104
     #4              : (in Lcom/deniscerri/ytdl/BuildConfig;)

Much cleaner. What irritates me there… isn't that the versionCode? I've picked the arm64 APK out of your artifacts. Then I've adjusted your build.gradle to have it only build the arm64:

sed -r '/abi \{/,/}/ { s/include.*/include "arm64-v8a"/ ; s/universalApk true/universalApk false/ }' -i app/build.gradle

Why does that result in the arm64 APK getting the "base versionCode"? I mean, it would be a waste of resources to build 5 APKs if I just need 1 of them, no? Probably caused by this:

def baseAbiVersionCode = project.abiCodes.get(output.getFilter(com.android.build.OutputFile.ABI))

So no fix definition, but looking for the build output. Let me try to confirm (just disabling the UniversalApk but having it build all defined ABIs)… Ah, that looks better: just the dex diff (and hence baseline.prof) remain now. Eh, and the dex diff is just … the versionCode? Now I'm really curious. Last run, leaving the ABI definitions entirely untouched (i.e. also building the UniversalApk). If that works, maybe you can create a static mapping for the overrides, instead of relying on build output? I'm not even sure if that forEach is deterministic (if not, this would give us a chance of 4 out of 5 to be wrong when trying to confirm RB).

Oof:

    "upstream_signed_apk_sha256": "9c37a627b88d8a2c6ea62344407f826f1b0fbc7c8ecd4c6bb962ab4582e79289",
    "built_unsigned_apk_sha256": "a63e4872d64844b76b1ef9a1e1c00f6588b0a0bb91000c41cf390912a94ac4e8",
    "signature_copied_apk_sha256": "9c37a627b88d8a2c6ea62344407f826f1b0fbc7c8ecd4c6bb962ab4582e79289"

OK, that's RB now – congrats! Where do we want to go from here? Leave it as-is (building additional 4 APKs we then just throw away) – or try with the mapping?

[zaednasr]

Well i thought I'd build everything in github action and use those for release. So i never build in my local computer.

[IzzySoft]

Yeah, and you build everything in one action, so there it totally makes sense. The verification builders for IoD as well as per-ABI builds with F-Droid.org would build each ABI separately. While the recipe in my builder would just cover the ABI present at IoD, F-Droid would have 4 build blocks (one for each ABI) and thus build all 5 variants (4x ABI plus the UniversalApk) 4 times.

I'm no Android dev, so it's hard for me to tell how much overhead that might be (as long as it's not pulling additional files for each ABI, it would most likely be some additional local processing concerning the ABI specific stuff). Which is why I raised the question with you. If you say you want to stay with the process as it currently is, I'd add the (now working) recipe to my builder (just adding a note to it for this), and the green shield for confirmed RBs will be established starting with this version – once you've released it. If you say you're willing to give the "mapping" a chance, I happily try another time having the sed re-established (I'm using that with several other apps successfully, but I cannot tell how many of them, if any, use versionCode override).

[obfusk]

https://github.com/element-hq/element-x-android/pull/2911

Using BuildConfig.VERSION_CODE break the reproducible build since the value will always end with 0, and should end with a digit depending on the architecture.

[zaednasr]

@obfusk @IzzySoft is there any project i can look over and see how they implemented the build process? thanks

[obfusk]

AFAIK Element X won't build reproducibly unless you build multiple ABIs either (because the manifest will differ otherwise). So doing that might be easiest. I suspect it's fixable but the gradle DSL stuff is pretty complex. My guess is there are no ABI filters when there is only one ABI configured and thus the lookup fails. Thus I suspect simply adding a second sed to replace the ABI code in the lookup as well might work, at least for the manifest (Izzy would have to test to confirm that):

sed -r 's/abiCodes.get\(.*\)/abiCodes.get("arm64-v8a")/' -i app/build.gradle

[IzzySoft]

AFAIK Element X won't build reproducibly unless you build multiple ABIs either

Same for com.tawhid.webcapture btw.

Izzy would have to test to confirm that

v1.7.9.2 without touching the ABIs (i.e. building all of them) is RB. Now with this recipe (i.e. adding the first 2 lines):

        build:
          - sed -r '/abi \{/,/}/ { s/include.*/include "arm64-v8a"/ ; s/universalApk true/universalApk false/ }' -i app/build.gradle
          - sed -r 's/abiCodes.get\(.*\)/abiCodes.get("arm64-v8a")/' -i app/build.gradle
          - sed -r '/signingConfigs.debug/d' -i app/build.gradle
          - chmod +x gradlew
          - touch local.properties
          - ./gradlew assembleRelease

is NOT RB. APK diff:

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 73f7a028 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     5106 b-     5106 stor 1981-01-01 01:01:02 505830c3 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     5106 b-     5106 stor 1981-01-01 01:01:02 104ca8c8 assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      396 b-      396 stor 1981-01-01 01:01:02 48b4a4cc assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx 10043656 b-  4354933 defN 1981-01-01 01:01:02 54462bfd classes.dex
+ -rw-r--r--  0.0 unx 10043656 b-  4354933 defN 1981-01-01 01:01:02 d87fbd41 classes.dex
  -rw-r--r--  0.0 unx   631400 b-   254102 defN 1981-01-01 01:01:02 52f51e23 classes2.dex
  -rw-r--r--  0.0 unx  2362568 b-   852191 defN 1981-01-01 01:01:02 2a243272 lib/arm64-v8a/libaria2c.so
  -rw-r--r--  0.0 unx  1672335 b-  1665102 defN 1981-01-01 01:01:02 648a6fac lib/arm64-v8a/libaria2c.zip.so
@@ -140,7 +140,7 @@
  -rw----     2.0 fat    25972 b-     7092 defN 1981-01-01 01:01:02 0eee32e3 org/mozilla/javascript/resources/Messages_fr.properties
  -rw----     2.0 fat     2579 b-     1042 defN 1981-01-01 01:01:02 1e1d6243 org/mozilla/javascript/tools/debugger/test.js
  -rw----     2.0 fat     8222 b-     2787 defN 1981-01-01 01:01:02 9bda5daa org/mozilla/javascript/tools/resources/Messages.properties
- -rw----     0.0 fat    42792 b-     7129 defN 1981-01-01 01:01:02 11b141f1 AndroidManifest.xml
+ -rw----     0.0 fat    42792 b-     7133 defN 1981-01-01 01:01:02 1f0b2f5d AndroidManifest.xml
  -rw----     0.0 fat      744 b-      344 defN 1981-01-01 01:01:02 9d59dbe0 res/-1.xml

Manifest:

           E: activity-alias (line=68)
-            A: http://schemas.android.com/apk/res/android:icon(0x01010002)=@0x7f100000
-            A: http://schemas.android.com/apk/res/android:name(0x01010003)="com.deniscerri.ytdl.Default" (Raw: "com.deniscerri.ytdl.Default")
-            A: http://schemas.android.com/apk/res/android:enabled(0x0101000e)=true
+            A: http://schemas.android.com/apk/res/android:icon(0x01010002)=@0x7f100002
+            A: http://schemas.android.com/apk/res/android:name(0x01010003)="com.deniscerri.ytdl.LightIcon" (Raw: "com.deniscerri.ytdl.LightIcon")
+            A: http://schemas.android.com/apk/res/android:enabled(0x0101000e)=false
             A: http://schemas.android.com/apk/res/android:exported(0x01010010)=true
             A: http://schemas.android.com/apk/res/android:launchMode(0x0101001d)=2
             A: http://schemas.android.com/apk/res/android:configChanges(0x0101001f)=0x00000004
             A: http://schemas.android.com/apk/res/android:targetActivity(0x01010202)="com.deniscerri.ytdl.MainActivity" (Raw: "com.deniscerri.ytdl.MainActivity")
             A: http://schemas.android.com/apk/res/android:windowSoftInputMode(0x0101022b)=0x00000020
-            A: http://schemas.android.com/apk/res/android:roundIcon(0x0101052c)=@0x7f100003
+            A: http://schemas.android.com/apk/res/android:roundIcon(0x0101052c)=@0x7f100005
               E: meta-data (line=78)
                 A: http://schemas.android.com/apk/res/android:name(0x01010003)="android.app.shortcuts" (Raw: "android.app.shortcuts")
                 A: http://schemas.android.com/apk/res/android:resource(0x01010025)=@0x7f170008
@@ -127,15 +127,15 @@
                   E: data (line=119)
                     A: http://schemas.android.com/apk/res/android:mimeType(0x01010026)="application/txt" (Raw: "application/txt")
           E: activity-alias (line=122)
-            A: http://schemas.android.com/apk/res/android:icon(0x01010002)=@0x7f100002
-            A: http://schemas.android.com/apk/res/android:name(0x01010003)="com.deniscerri.ytdl.LightIcon" (Raw: "com.deniscerri.ytdl.LightIcon")
-            A: http://schemas.android.com/apk/res/android:enabled(0x0101000e)=false
+            A: http://schemas.android.com/apk/res/android:icon(0x01010002)=@0x7f100000
+            A: http://schemas.android.com/apk/res/android:name(0x01010003)="com.deniscerri.ytdl.Default" (Raw: "com.deniscerri.ytdl.Default")
+            A: http://schemas.android.com/apk/res/android:enabled(0x0101000e)=true
             A: http://schemas.android.com/apk/res/android:exported(0x01010010)=true
             A: http://schemas.android.com/apk/res/android:launchMode(0x0101001d)=2
             A: http://schemas.android.com/apk/res/android:configChanges(0x0101001f)=0x00000004
             A: http://schemas.android.com/apk/res/android:targetActivity(0x01010202)="com.deniscerri.ytdl.MainActivity" (Raw: "com.deniscerri.ytdl.MainActivity")
             A: http://schemas.android.com/apk/res/android:windowSoftInputMode(0x0101022b)=0x00000020
-            A: http://schemas.android.com/apk/res/android:roundIcon(0x0101052c)=@0x7f100005
+            A: http://schemas.android.com/apk/res/android:roundIcon(0x0101052c)=@0x7f100003
               E: meta-data (line=132)

Dex diff:

 magic               : 'dex\n035\0'
-checksum            : 8f9795f3
-signature           : 4d8c...e13a
+checksum            : ba619438
+signature           : 4589...800b
 file_size           : 10043656
 header_size         : 112
 link_size           : 0
@@ -409077,7 +409077,7 @@
       name          : 'VERSION_CODE'
       type          : 'I'
       access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : 107090200
+      value         : 107090204
     #4              : (in Lcom/deniscerri/ytdl/BuildConfig;)

So do we go with building everything to have RB now – or do we wait until we can find out how to properly build a single ABI with RB later?

[zaednasr]

Let's go with how it is for now

[obfusk]

That manifest diff is very odd. I'm thinking this is a bug in the toolchain then. So yeah, made sense to try a few things first, but let's just use what works for now :)

[IzzySoft]

So with all agreeing, I'll now implement it. Done:

And here comes your welcome toot:

[IzzySoft]

premature close it seems, @zaednasr: today's release is no loger RB; a load of PNGs differ. Did you maybe enable use PNG Crush/Crunch, or have your PNGs generated from vector drawables?

  -rw----     0.0 fat     6156 b-     1802 defN 1981-01-01 01:01:02 85de0b9a res/-E.xml
- -rw----     0.0 fat      194 b-      194 stor 1981-01-01 01:01:02 defee408 res/-I.png
+ -rw----     0.0 fat      175 b-      175 stor 1981-01-01 01:01:02 dd4326d5 res/-I.png
  -rw----     0.0 fat      670 b-      670 stor 1981-01-01 01:01:02 34f21c1e res/-J.png
  -rw----     0.0 fat      318 b-      318 stor 1981-01-01 01:01:02 5390d72d res/-N.png
  -rw----     0.0 fat      616 b-      299 defN 1981-01-01 01:01:02 91d1cdde res/-Q.xml
@@ -189,7 +189,7 @@
  -rw----     0.0 fat     1081 b-     1081 stor 1981-01-01 01:01:02 6b2f0b00 res/12.png
  -rw----     0.0 fat     2305 b-     2305 stor 1981-01-01 01:01:02 03217b6e res/1I.9.png
  -rw----     0.0 fat     1731 b-     1731 stor 1981-01-01 01:01:02 307aa23f res/1J.9.png
- -rw----     0.0 fat      135 b-      135 stor 1981-01-01 01:01:02 e380418d res/1J.png
+ -rw----     0.0 fat      124 b-      124 stor 1981-01-01 01:01:02 ece2c619 res/1J.png
  -rw----     0.0 fat      436 b-      436 stor 1981-01-01 01:01:02 f54db5c2 res/1K.png
  -rw----     0.0 fat      756 b-      421 defN 1981-01-01 01:01:02 b2ef4fba res/1K.xml
  -rw----     0.0 fat      509 b-      509 stor 1981-01-01 01:01:02 4593baf7 res/1K1.png
@@ -197,7 +197,7 @@
  -rw----     0.0 fat      106 b-      106 stor 1981-01-01 01:01:02 614b8e0c res/1W.png
  -rw----     0.0 fat      580 b-      317 defN 1981-01-01 01:01:02 a6b238a0 res/1Z.xml
  -rw----     0.0 fat      728 b-      401 defN 1981-01-01 01:01:02 0046ca95 res/1a.xml
- -rw----     0.0 fat      271 b-      271 stor 1981-01-01 01:01:02 966aedf4 res/1b.png
+ -rw----     0.0 fat      235 b-      235 stor 1981-01-01 01:01:02 91597e85 res/1b.png
  -rw----     0.0 fat      322 b-      322 stor 1981-01-01 01:01:02 12f96d6b res/1c.png
  -rw----     0.0 fat      139 b-      139 stor 1981-01-01 01:01:02 f2066b4c res/1d.png
  -rw----     0.0 fat      171 b-      171 stor 1981-01-01 01:01:02 19b7f846 res/1e.9.png
@@ -239,7 +239,7 @@
  -rw----     0.0 fat     1056 b-      499 defN 1981-01-01 01:01:02 06e99b59 res/3A.xml
  -rw----     0.0 fat      283 b-      283 stor 1981-01-01 01:01:02 129d616c res/3E.png
  -rw----     0.0 fat     5044 b-     1561 defN 1981-01-01 01:01:02 bdd7750a res/3G.xml
- -rw----     0.0 fat      322 b-      322 stor 1981-01-01 01:01:02 4854eebf res/3P.png
+ -rw----     0.0 fat      353 b-      353 stor 1981-01-01 01:01:02 6fbd68b3 res/3P.png
  -rw----     0.0 fat      528 b-      304 defN 1981-01-01 01:01:02 2547aaad res/3R.xml
  -rw----     0.0 fat      516 b-      246 defN 1981-01-01 01:01:02 830da9c7 res/3W.xml
  -rw----     0.0 fat      675 b-      675 stor 1981-01-01 01:01:02 6f123646 res/3Z.png
@@ -280,7 +280,7 @@
  -rw----     0.0 fat      452 b-      266 defN 1981-01-01 01:01:02 89111a78 res/4y.xml
  -rw----     0.0 fat      876 b-      417 defN 1981-01-01 01:01:02 a49bff1b res/4z.xml
  -rw----     0.0 fat     3092 b-      973 defN 1981-01-01 01:01:02 85fd0533 res/4z1.xml
- -rw----     0.0 fat      172 b-      172 stor 1981-01-01 01:01:02 fe888b42 res/5-.png
+ -rw----     0.0 fat      198 b-      198 stor 1981-01-01 01:01:02 657c8bfc res/5-.png
  -rw----     0.0 fat      673 b-      673 stor 1981-01-01 01:01:02 17078ed0 res/50.png
  -rw----     0.0 fat      812 b-      374 defN 1981-01-01 01:01:02 67a5b7e5 res/51.xml
  -rw----     0.0 fat      932 b-      392 defN 1981-01-01 01:01:02 e9c0fd30 res/57.xml
@@ -321,12 +321,12 @@
  -rw----     0.0 fat      436 b-      259 defN 1981-01-01 01:01:02 438a3149 res/6x.xml
  -rw----     0.0 fat      186 b-      186 stor 1981-01-01 01:01:02 46349333 res/6z.png
  -rw----     0.0 fat      648 b-      359 defN 1981-01-01 01:01:02 267ec63a res/70.xml
- -rw----     0.0 fat      363 b-      363 stor 1981-01-01 01:01:02 e0a65c3b res/71.png
+ -rw----     0.0 fat      386 b-      386 stor 1981-01-01 01:01:02 6a7bc9c7 res/71.png
  -rw----     0.0 fat      290 b-      290 stor 1981-01-01 01:01:02 e4259315 res/711.png
  -rw----     0.0 fat     2760 b-      938 defN 1981-01-01 01:01:02 a226f80a res/72.xml
  -rw----     0.0 fat      508 b-      258 defN 1981-01-01 01:01:02 22d03ed7 res/76.xml
  -rw----     0.0 fat      596 b-      329 defN 1981-01-01 01:01:02 c2e30e72 res/77.xml
- -rw----     0.0 fat      186 b-      186 stor 1981-01-01 01:01:02 410270c3 res/78.png
+ -rw----     0.0 fat      283 b-      283 stor 1981-01-01 01:01:02 2511a139 res/78.png
  -rw----     0.0 fat     2056 b-      835 defN 1981-01-01 01:01:02 b309e93d res/78.xml

(to be continued, there's more of that). Further it seems you're now building on Windows – which you seemingly did not do before, as this issue didn't pop up with the last release:

  -rw----     2.0 fat       92 b-       77 defN 1981-01-01 01:01:02 f5dec0e8 META-INF/native-image/okhttp/okhttp/resource-config.json
- -rw----     2.0 fat       40 b-       40 defN 1981-01-01 01:01:02 a99eb9c4 META-INF/services/com.fasterxml.jackson.core.JsonFactory
- -rw----     2.0 fat       45 b-       47 defN 1981-01-01 01:01:02 20f7617d META-INF/services/com.fasterxml.jackson.core.ObjectCodec
- -rw----     2.0 fat       55 b-       51 defN 1981-01-01 01:01:02 167298eb META-INF/services/kotlinx.coroutines.CoroutineExceptionHandler
- -rw----     2.0 fat       53 b-       50 defN 1981-01-01 01:01:02 bd6769a0 META-INF/services/kotlinx.coroutines.android.AndroidDispatcherFactory
+ -rw----     2.0 fat       39 b-       39 defN 1981-01-01 01:01:02 b3197263 META-INF/services/com.fasterxml.jackson.core.JsonFactory
+ -rw----     2.0 fat       44 b-       46 defN 1981-01-01 01:01:02 09ea2bfa META-INF/services/com.fasterxml.jackson.core.ObjectCodec
+ -rw----     2.0 fat       54 b-       50 defN 1981-01-01 01:01:02 8f594b50 META-INF/services/kotlinx.coroutines.CoroutineExceptionHandler
+ -rw----     2.0 fat       52 b-       49 defN 1981-01-01 01:01:02 4b95597f META-INF/services/kotlinx.coroutines.android.AndroidDispatcherFactory
  -rw----     2.0 fat      964 b-      964 stor 1981-01-01 01:01:02 595758b4 junit/runner/logo.gif

This one we can easily fix on our end. I just wonder if the PNG stuff might originate on the same cause (building on Windows)?

[zaednasr]

I added a few vector icons, so most likely png generated from them. Ill add that command to disable them and push the change

[zaednasr]

@IzzySoft https://github.com/deniscerri/ytdlnis/actions/runs/11428481877

[IzzySoft]

Now, that was fast – thanks! Any ETA for the next release then? Or maybe we shall confirm the solution first (for that I'd just need a commit hash and the APK built from it)?

[zaednasr]

Didnt expect to have issues right after release so might be a bit. I have to wait for people to complain on new bugs i guess. The commit hash is from the action i sent you, there is also the generated apks

[IzzySoft]

Yeah, just found them in the artifacts. Build is running here now, will take a few minutes. Thanks!

[IzzySoft]

Congrats, that one is RB right out of the box, no adjustments needed on my end, thanks!

So we let the current release be marked as "RB failed" (as we cannot fix it anymore now that the APK has been distributed), and the next release should have the green shield up again, right? I still wonder where those Windows line-breaks came from in the last release, though, and if that means they'll be back next release. Well, we'll see.

[zaednasr]

lets hope. I wonder why me adding a new vector caused an issue. I updated some dependencies. Android version to 35 and other gradle stuff

[IzzySoft]

No idea. And as long as it's just those line breaks resurfacing, that's something I can fix here without having the release being marked "RB failed" (as no changes to your APK are happening when I adjust our build). It just gets nasty when it's flipping back and forth.

So shall we leave this issue open until the next release is verified – or shall I close it, and we reopen it if needed?

[zaednasr]

lets leave it open