with huge differences in e.g. DEX classes. Was 2-APlayer-v2.1.1.0-foss-release.apk really built from the tagged commit (that part the app's embedded vcsInfo confirms, but that doesn't say if the tree was "clean") using ./gradlew assembleFossRelease? It is ~300 KB larger than our corresponding build.
Such a big diff suggests something must be wrong, so for security reasons, we'll hold back this release until clarified.
To make sure: this is no accusation, offense, or assuming bad intent. It might be something trivial having gone wrong without your notice – or something we'd need to update in our recipe (speaking of which: the build now seems to require cmake 4.1.2 – would be good if your gradle setup took care for that (it currently installs cmake 3.22.1 – but only much later, when the part needing 4.1.2 has been completed). Maybe it needs something else, too? I could not spot that in our build logs).
-rw-r--r-- 0.0 unx 120 b- 116 defN 1981-01-01 01:01:02 457553c2 META-INF/version-control-info.textproto
- -rw-r--r-- 0.0 unx 14740 b- 14740 stor 1981-01-01 01:01:02 52c96f6a assets/dexopt/baseline.prof
- -rw-r--r-- 0.0 unx 666 b- 666 stor 1981-01-01 01:01:02 5ec0c7a2 assets/dexopt/baseline.profm
- -rw-r--r-- 0.0 unx 4376064 b- 2089937 defN 1981-01-01 01:01:02 486e6c4c classes.dex
- -rw-r--r-- 0.0 unx 6467136 b- 2767723 defN 1981-01-01 01:01:02 3a72dbd3 classes2.dex
+ -rw-r--r-- 0.0 unx 9168 b- 9168 stor 1981-01-01 01:01:02 2becfbf1 assets/dexopt/baseline.prof
+ -rw-r--r-- 0.0 unx 1067 b- 1067 stor 1981-01-01 01:01:02 96bf5c93 assets/dexopt/baseline.profm
+ -rw-r--r-- 0.0 unx 9458612 b- 4209416 defN 1981-01-01 01:01:02 dfbc7ac0 classes.dex
+ -rw-r--r-- 0.0 unx 1007284 b- 434726 defN 1981-01-01 01:01:02 5a714006 classes2.dex
-rw-r--r-- 0.0 unx 10096 b- 4386 defN 1981-01-01 01:01:02 9734baa0 lib/arm64-v8a/libandroidx.graphics.path.so
-rw-r--r-- 0.0 unx 7272 b- 3466 defN 1981-01-01 01:01:02 74f6d3f1 lib/arm64-v8a/libblur.so
-rw-r--r-- 0.0 unx 1367632 b- 649250 defN 1981-01-01 01:01:02 bb1897c9 lib/arm64-v8a/libffmpegJNI.so
@@ -13,7 +13,7 @@
-rw-r--r-- 0.0 unx 7252 b- 4064 defN 1981-01-01 01:01:02 9a714d3a lib/armeabi-v7a/libandroidx.graphics.path.so
-rw-r--r-- 0.0 unx 6520 b- 3709 defN 1981-01-01 01:01:02 6751f68e lib/armeabi-v7a/libblur.so
-rw-r--r-- 0.0 unx 1179756 b- 618830 defN 1981-01-01 01:01:02 d92bfb44 lib/armeabi-v7a/libffmpegJNI.so
- -rw-r--r-- 0.0 unx 805420 b- 382441 defN 1981-01-01 01:01:02 8244aab2 lib/armeabi-v7a/libtaglib.so
+ -rw-r--r-- 0.0 unx 805404 b- 382459 defN 1981-01-01 01:01:02 beb80e8e lib/armeabi-v7a/libtaglib.so
-rw-r--r-- 0.0 unx 10760 b- 4614 defN 1981-01-01 01:01:02 81bd88ae lib/x86_64/libandroidx.graphics.path.so
-rw-r--r-- 0.0 unx 7960 b- 3815 defN 1981-01-01 01:01:02 5c196f9e lib/x86_64/libblur.so
-rw-r--r-- 0.0 unx 1445416 b- 663972 defN 1981-01-01 01:01:02 318cb968 lib/x86_64/libffmpegJNI.so
@@ -121,7 +121,7 @@
-rw---- 2.0 fat 5 b- 7 defN 1981-01-01 01:01:02 6a2f0318 META-INF/kotlinx_coroutines_android.version
-rw---- 2.0 fat 5 b- 7 defN 1981-01-01 01:01:02 6a2f0318 META-INF/kotlinx_coroutines_core.version
-rw---- 2.0 fat 29 b- 31 defN 1981-01-01 01:01:02 423b4557 META-INF/services/kotlinx.coroutines.android.a
- -rw---- 2.0 fat 29 b- 31 defN 1981-01-01 01:01:02 69161694 META-INF/services/kotlinx.coroutines.x
+ -rw---- 2.0 fat 29 b- 31 defN 1981-01-01 01:01:02 69161694 META-INF/services/kotlinx.coroutines.v
-rw---- 2.0 fat 145 b- 129 defN 1981-01-01 01:01:02 86d9ab41 META-INF/versions/9/OSGI-INF/MANIFEST.MF
with huge differences in e.g. DEX classes. Was
2-APlayer-v2.1.1.0-foss-release.apkreally built from the tagged commit (that part the app's embeddedvcsInfoconfirms, but that doesn't say if the tree was "clean") using./gradlew assembleFossRelease? It is ~300 KB larger than our corresponding build.Such a big diff suggests something must be wrong, so for security reasons, we'll hold back this release until clarified.
To make sure: this is no accusation, offense, or assuming bad intent. It might be something trivial having gone wrong without your notice – or something we'd need to update in our recipe (speaking of which: the build now seems to require
cmake 4.1.2– would be good if your gradle setup took care for that (it currently installscmake 3.22.1– but only much later, when the part needing 4.1.2 has been completed). Maybe it needs something else, too? I could not spot that in our build logs).