Simple binary repos: can't see new package version

1

Hello everyone.

Few monthes ago, I set up a F-Droid App Repo for Umami Wallet app with version 1.0.9. It worked well, and I have been able to add it in the Repositories Setting page, found the app, installed it.

But now, I added the 1.2.0 version of the apk, ran fdroid update, and publish the updated files. The new index is (see https://fdroid.umamiwallet.com/repo/index-v1.json)

{
  "repo":{
    "timestamp":1674738647000,
    "version":20001,
    "name":"Umami Wallet official releases",
    "icon":"umami-logo.png",
    "address":"https://fdroid.umamiwallet.com/repo",
    "description":"\nF-Droid App Repo for the Umami Tezos wallet.\n"
  },
  "requests":{
    "install":[],
    "uninstall":[]
  },
  "apps":[
    {
      "authorEmail":"umami-support@nomadic-labs.com",
      "authorName":"Nomadic Labs",
      "categories":["Money"],
      "suggestedVersionCode":"16",
      "issueTracker":"https://gitlab.com/nomadic-labs/umami-wallet/umami-mobile/-/issues",
      "license":"Unknown",
      "name":"Umami Wallet",
      "sourceCode":"https://gitlab.com/nomadic-labs/umami-wallet/umami-mobile",
      "summary":"The mobile version of the Umami Tezos Wallet.",
      "webSite":"https://umamiwallet.com/",
      "added":1674738645000,
      "packageName":"com.umamimobile",
      "lastUpdated":1674738646000,
      "localized":{...}
    }
  ],
  "packages":{
    "com.umamimobile":[
      {
        "added":1674738645000,
        "apkName":"umami-1.0.9.apk",
        "hash":"38ec8d68537ab9d234a80aef93f47755d98681184b9b2be836461ffe39870e95",
        "hashType":"sha256",
        "minSdkVersion":21,
        "nativecode":["arm64-v8a", "armeabi-v7a", "x86", "x86_64"],
        "packageName":"com.umamimobile",
        "sig":"c818a7299bd4e2a7ecaa2991f294d105",
        "signer":"c3226488eee55660ebcee88e16dae08651f4d74770a11e7f1c2c0df686ea61a0",
        "size":42035490,
        "targetSdkVersion":31,
        "uses-permission":[...],
        "versionCode":9,
        "versionName":"1.0.9"
      },
      {
        "added":1674738646000,
        "apkName":"umami-1.2.0.apk",
        "hash":"e7276778b75b7dbddba0a132f4d72555e395163d1cdc5589ef3f650044e6da1a",
        "hashType":"sha256",
        "minSdkVersion":21,
        "nativecode":["arm64-v8a","armeabi", "armeabi-v7a", "x86", "x86_64"],
        "packageName":"com.umamimobile",
        "sig":"1e0905faf1c39af8b9d0be4e8b87d42b",
        "signer":"f478bc1ded7063329464cf172078e17235626bc21ce2ce6ab5bb29e00a73ac4b",
        "size":43113701,
        "targetSdkVersion":31,
        "uses-permission":[...],
        "versionCode":16,
        "versionName":"1.2.0"
      }
    ]
  }
}

But the app on f-droid only showed version 1.0.9.

I uninstalled the app and installed it from Play Store, get back on the app page on f-droid and it stated:

No version with compatible signature

Uninstalled it again, back on the f-droid page, and I can see 1.0.9 and 1.2.0 (note: 1.2.0 is not marked as suggested even if I have "suggestedVersionCode":"16" and "versionCode":16 in the json).

If I install a version, the other disappear from the page and the one installed has the Suggested tag.

I guess that the problem comes from the "signer", which is different?

Is this signature problem something related to the .apk file itself, or is it something happening when doing fdroid update. Because when I fdroid update, both apk files are processed with the same informations, so I suspect that this is linked to the apk itself? Is there something I can do if I can’t change the apk files?

1 Like
2

@Izzy thoughts?

3

I confirm that the app certificate has changed.
The new version (1.2.0) is signed with a new keystore.jks file.
How can we integrate the change seamlessly in fdroid?

4

F-Droid already seamlessly announces you that you can’t update from your Play APK signed with one cert to this new APK signed with another :slight_smile:

You wanna update? Well… then put the SAME key so it signs with the same key… OR put the SAME signed APK directly and it will publish that one.

5

I don’t understand.
We lost the signing key and now a new one is being used.
You are saying that you can’t change the key on an fdroid repo.
Therefore we need to create a new repo with the new key, is that correct?

6

Note: I just realised that the key used to sign by fdroid is not used on the apk files at all but only for .jar files.

So ok, what if we lost the signing key of the app? Can f-droid do something for us? (i.e. force to warn the user about an upgrade available)

7

I’ve never had that case and thus have no idea how it would be handled internally (if at all; maybe the app is bound to its initial signing key/signature), but maybe removing the old version (1.0.9) would help? Otherwise, as changing the signing key anyway implies one has to uninstall and re-install, establish the app with a new applicationId (so it’s essentially a different/new app, not just a newer incompatible version). That should always work. Optionally then also add a note to the description of the original app saying one should follow up to the new one, so existing users find it more easily.

8

Ok. Good to know: we need to keep the signing key the same in order to avoid the app to be stucked.

I am glad we learn this now. The app has probably only be installed internally for now, so I can just remove 1.0.9 from the repo (or rebuild and sign with the new key), I don’t think we need a new applicationId. It will reproduce the situation about the “No version with compatible signature” as if the app came from the Google Play version.

I guess that editing the description in metadata would be the best we can do in order to let the user know that you can have upgrades if you first uninstall the app.

2 Likes
9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.