[FEATURE] Reproducible builds

[IzzySoft]

At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Trying for yours, I was able to successfully generate the APK for v0.7.1 using ./gradlew assembleRelease, but the resulting APKs were not identical, having differences in classes.dex:

 |: sput-boolean v0, LDe;.d:Z
-|: const-wide v0, #double 8.51203e-312 // #00000191221fd159
+|: const-wide v0, #double 8.52281e-312 // #00000191a4271611
 |: invoke-static {v0, v1}, Ljava/lang/Long;.valueOf:(J)Ljava/lang/Long;
 |: move-result-object v0
 |: goto 0019 // +0008
@@ -96936,7 +96936,7 @@
       outs          : 0
       insns size    : 6 16-bit code units
 | com.highcapable.yukihookapi.hook.xposed.bridge.status.YukiXposedModuleStatus_Impl_Impl_io_mesalabs_knoxpatch.-_-_:()Ljava/lang/String;
-|: invoke-static {}, Lcom/highcapable/yukihookapi/hook/xposed/bridge/status/YukiXposedModuleStatus_Impl_Impl_io_mesalabs_knoxpatch;._25486:()V
+|: invoke-static {}, Lcom/highcapable/yukihookapi/hook/xposed/bridge/status/YukiXposedModuleStatus_Impl_Impl_io_mesalabs_knoxpatch;._65334:()V
 |: const-string v0, "unknown"
 |: return-object v0
       catches       : (none)
@@ -96953,7 +96953,7 @@
       outs          : 0
       insns size    : 5 16-bit code units
 | com.highcapable.yukihookapi.hook.xposed.bridge.status.YukiXposedModuleStatus_Impl_Impl_io_mesalabs_knoxpatch.-__-:()I
-|: invoke-static {}, Lcom/highcapable/yukihookapi/hook/xposed/bridge/status/YukiXposedModuleStatus_Impl_Impl_io_mesalabs_knoxpatch;._25486:()V
+|: invoke-static {}, Lcom/highcapable/yukihookapi/hook/xposed/bridge/status/YukiXposedModuleStatus_Impl_Impl_io_mesalabs_knoxpatch;._65334:()V
 |: const/4 v0, #int -1 // #ff

(plus some more like those). Since v0.7.3, we cannot even build anymore due to this: Github's maven requires credentials, which our "anonymous builder" don't have. We could try again if those two libraries were included by other means (e.g. as git submodules) – though I'd expect the above issue to still be present then (and have no idea yet how to solve that).

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

Looking forward to your reply!

[salvogiangri]

I can try adding the newer Sesl libraries fork as a prebuilt aar inside the repository itself (a850d38), I don't know how to handle the different smali code tho since afaict it's automatically generated by the YukiHookAPI lib. @HighCapable any hint?

[IzzySoft]

While using prebuilt AARs are one way to avoid the credential issue for the mavens, a better way might be if a) those libraries were available via a public maven or b) the source repos included here e.g. as git submodule, so they could be built in a first step using publishToMavenLocal (which would even be possible via a git clone in the build recipe if they were not git submodules; but submodules have the pro of pointing to the commit to use, so that would be in sync then). FOSS should be built from source when possible 😉

With that part tackled, I'll gladly try another build. If you can provide me an APK you've build then, with the commit it was built from, we could also see how close we came – in case that other diff was just a "fluke".

And thanks for calling in help: hopefully @HighCapable can shed some light on that diff.

[IzzySoft]

Looks like no response from @HighCapable 😢 So how do we proceed here?