[Feature Proposal] Automatic Update Integration from GitHub Releases

[CodeWithTamim]

Hi
I hope you're doing well. I’m considering adding a feature to the app that would allow it to show an update dialog when a new release is available on GitHub. The feature would also handle downloading and installing the update directly from within the app.

Would you be open to this enhancement? Please let me know if this is something you'd like to include.

Thank you!

Best regards,
Tamim Hossain

[samolego]

Hi there, that would be awesome, especially since fdroid cannot reproduce builds (#49)

[CodeWithTamim]

Hi there, that would be awesome, especially since fdroid cannot reproduce builds (#49)

Okay bro pr coming soon

[shuvashish76]

Requested at IzzyOnDroid : https://gitlab.com/IzzyOnDroid/repo/-/issues/636
BTW the app can co-exist on both the repos ;)

[IzzySoft]

Scanner results:

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Easily avoided with a minor addition to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Integrating your app now, will report back when done.

[IzzySoft]

I can confirm the APK is NOT reproducible: classes.dex differs slightly in what looks like it could have been built by a JDK which slightly differs (assuming you've used your Github workflow to produce the APK attached to the release, we can rule out a build from a "dirty tree" with local changes). And looking at your workflow it seems you use JDK-19 – could that be? If so: could you switch to either 17 or 21 there? 19 is no LTS release and thus not even suitable for RB.

If you'd switch to JDK 21, make a test build (from a clean tree, i.e. all changes committed – can be inside a "test branch" but must be available here at Github), then attach the APK here (rename it to *.zip so you can attach it, please do NOT put it inside another ZIP) and name the commit you built it from, I can give it another try to see if that solves the issue.

Current APK diff:

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 e9680e28 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     3885 b-     3885 stor 1981-01-01 01:01:02 0b393429 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     3885 b-     3885 stor 1981-01-01 01:01:02 8f7598cf assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      498 b-      498 stor 1981-01-01 01:01:02 4012471a assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  2208040 b-  2208040 stor 1981-01-01 01:01:02 f484b8be classes.dex
+ -rw-r--r--  0.0 unx  2208048 b-  2208048 stor 1981-01-01 01:01:02 8900aa05 classes.dex
  -rw----     2.0 fat     1738 b-      782 defN 1981-01-01 01:01:02 2d73be70 DebugProbesKt.bin

(baseline.prof differs because classes.dex differs). The dex diff:

       name          : '<init>'
-      type          : '(LO1/a;ZLY/e;LY/k;)V'
+      type          : '(LA/h;ZLY/e;LY/k;)V'
       access        : 0x10001 (PUBLIC CONSTRUCTOR)
       code          -
       registers     : 5
       ins           : 5
       outs          : 2
       insns size    : 13 16-bit code units
-| B.g.<init>:(LO1/a;ZLY/e;LY/k;)V
+| B.g.<init>:(LA/h;ZLY/e;LY/k;)V
 |: iput-object v1, v0, LB/g;.j:LO1/a;
 |: iput-boolean v2, v0, LB/g;.k:Z
 |: iput-object v3, v0, LB/g;.l:LY/e;
@@ -450983,14 +450983,14 @@
   Direct methods    -
     #0              : (in LB/h;)
       name          : '<init>'
-      type          : '(JLO1/a;Z)V'
+      type          : '(JLA/h;Z)V'
       access        : 0x10001 (PUBLIC CONSTRUCTOR)
       code          -
       registers     : 5
       ins           : 5
       outs          : 2
       insns size    : 11 16-bit code units
-| B.h.<init>:(JLO1/a;Z)V
+| B.h.<init>:(JLA/h;Z)V
 |: iput-wide v1, v0, LB/h;.j:J
 |: iput-object v3, v0, LB/h;.k:LO1/a;
 |: iput-boolean v4, v0, LB/h;.l:Z
@@ -451010,7 +451010,7 @@
       registers     : 10
       ins           : 2
       outs          : 5
-      insns size    : 67 16-bit code units
+      insns size    : 69 16-bit code units
 | B.h.k:(Ljava/lang/Object;)Ljava/lang/Object;
 |: check-cast v9, LV/c;
 |: iget-object v0, v9, LV/c;.i:LV/a;
@@ -451040,9 +451040,10 @@
 |: invoke-direct {v2, v4, v7}, Landroid/graphics/PorterDuffColorFilter;.<init>:(ILandroid/graphics/PorterDuff$Mode;)V
 |: invoke-direct {v1, v5, v6, v3, v2}, LY/k;.<init>:(JILandroid/graphics/ColorFilter;)V
 |: new-instance v2, LB/g;
-|: iget-object v3, v8, LB/h;.k:LO1/a;
-|: iget-boolean v4, v8, LB/h;.l:Z
-|: invoke-direct {v2, v3, v4, v0, v1}, LB/g;.<init>:(LO1/a;ZLY/e;LY/k;)V
+|: iget-boolean v3, v8, LB/h;.l:Z
+|: iget-object v4, v8, LB/h;.k:LO1/a;
+|: check-cast v4, LA/h;
+|: invoke-direct {v2, v4, v3, v0, v1}, LB/g;.<init>:(LA/h;ZLY/e;LY/k;)V
 |: invoke-virtual {v9, v2}, LV/c;.b:(LO1/c;)LV/f;
 |: move-result-object v9
 |: return-object v9
@@ -451101,7 +451102,7 @@
       registers     : 9
       ins           : 4
       outs          : 5
-      insns size    : 81 16-bit code units
+      insns size    : 83 16-bit code units
 | B.i.h:(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
 |: check-cast v6, LS/o;
 |: check-cast v7, LG/q;
@@ -451130,9 +451131,10 @@
 |: move-result-object v4
 |: if-nez v8, 003b // +0006
 |: sget-object v8, LG/l;.a:LG/Y;
-|: if-ne v4, v8, 0043 // +000a
+|: if-ne v4, v8, 0045 // +000c
 |: new-instance v4, LB/h;
-|: invoke-direct {v4, v0, v1, v2, v3}, LB/h;.<init>:(JLO1/a;Z)V
+|: check-cast v2, LA/h;
+|: invoke-direct {v4, v0, v1, v2, v3}, LB/h;.<init>:(JLA/h;Z)V
 |: invoke-virtual {v7, v4}, LG/q;.g0:(Ljava/lang/Object;)V

[IzzySoft]

Update: Integration completed, Canta going live at IzzyOnDroid with the next sync around 6 pm UTC:

Be welcome to pick a badge to link there e.g. from your Readme 😃

We will establish RB as soon as we can rebuild, see previous comment.

[shuvashish76]

Added IzzyOnDroid badge with #107. Removed the "Fdroid has old versions only" warning as the version can be viewed from the Readme itself and the specific is already pinned at issue tracker anyway.

The IzzyOnDroid query color looks orange even though I explicitly mentioned it as blue &color=blue. Probably it's orange because currently resource not found, I hope it'll change back to blue with live on IzzyOnDroid.

[IzzySoft]

@shuvashish76 check again, it's blue now that the sync is through. And thanks! Any idea why F-Droid and Github badges have a V in front of the version? Ah, you've explicitly specified that with the API call. Looks a bit weird. Not my decision, but maybe skip the /v/ for the other two badges so it is more "streamlined"?

And @samolego, any word on the RB proposal? No pressure, just for orientation on my end? Thanks in advance!

[shuvashish76]

maybe skip the /v/ for the other two badges so it is more "streamlined"?

For some reason it doesn't work for F-Droid if I remove that...but works for GitHub.
I think Better to keep them that way as that's what it auto-generate from official https://shields.io/badges/f-droid-version and https://shields.io/badges/git-hub-release

[IzzySoft]

that's a bit stupid IMHO as it falsifies the versionName – but if that's the only way it works 🤷‍♂️

PS: Wonder how that looks like for e.g. versionName: "v1.2.3". Would it then be "vv1.2.3"?

[samolego]

Hi, I'll take a look tomorrow, thanks for all the info but it's quite late here.
:)