Essentially the apps have same package name but different signatures and the app store that installed it should be the only one to recognize and update it.

But Google is likely trying this dark pattern to sway people away from F-Droid or alt stores by making users uninstall these apps and install it from the Google Play Store.

It’s been going on for a while and is annoying af.

https://android.stackexchange.com/questions/253727/why-is-googles-play-store-suddenly-trying-to-update-apps-installed-via-f-droid

  • NeatNit@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    7
    ·
    8 months ago

    It’s relatively new behaviour so they introduced it recently. And they need to fix it, but ignore it entirely…

    • Martin
      link
      fedilink
      English
      arrow-up
      27
      arrow-down
      4
      ·
      8 months ago

      Mismatched signatures have been discouraged since day one of Android. A mismatched signature is a sign that some one other than the original publisher built this package, and the user needs to be aware that it might be malicious.

      That F-Droid went with this setup with mismatched signatures was always going to make their apks look suspicious.

      • NeatNit@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        10
        ·
        8 months ago

        You misunderstood the whole situation. The signatures are all fine. Google Play Store is trying to override an app installed from F-Droid. If the two stores had the same signature, the play store would be able to do this which would go completely counter to the user’s choice (they installed from F-Droid for a reason). It’s a good thing the signatures don’t match, there’s nothing suspicious about it.

        It used to be that the play store just wouldn’t show updates to apps that it wasn’t actually able to update. They broke this behaviour.

        • Norgur@fedia.io
          link
          fedilink
          arrow-up
          17
          arrow-down
          2
          ·
          8 months ago

          No, it’s not a good thing. The solution would be to use a different package name for the f droid version. That’s what’s supposed to be done. It’s not the signature or Google that’s causing the problem. It’s that there are two packages with identical names that should not be identical.

        • Martin
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          8 months ago

          The package name is the unique id. If you want to distribute multiple variants (like two versions with differing signatures) they should not have the same identifier. If they are not the same the id/package name should not be the same.

          Having different package names would also prevent the Google play store from trying to update it.

    • Norgur@fedia.io
      link
      fedilink
      arrow-up
      17
      arrow-down
      2
      ·
      8 months ago

      Even if it’s new behavior, there is really no reason to assume that this was done to evoke some dark pattern or other. It just shows that Google will not think about 3rd party stores when they do anything with their services and that is hardly news, is it? Besides: I kinda get it honestly. If they’d take all the stuff out there for android into account before they did anything, nothing would be done at all.

      So the question becomes less why that’s there, but more what stores like Samsung do to prevent this issue and if F-Droid can adapt the same behavior.

      • joewilliams007@kbin.melroy.org
        link
        fedilink
        arrow-up
        4
        ·
        8 months ago

        Samsung just says:

        Can’t auto update Installed from Google play store. And Can’t auto update Installed from Aurora store.

        You can easily see from what store an app has been installed in android.

      • NeatNit@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        3
        ·
        8 months ago

        Maybe that’s true, but then:

        • They previously had code to prevent this, why did they remove it?
        • Why won’t they fix it now? I’ve reported this twice already and I’m not the only one, this is affecting a huge number of users, why are they ignoring it? I refuse to believe they’re not aware of it. And if they aren’t aware of it that points to an even bigger issue of having absolutely no idea the repercussions of that they do even when thousands/millions of users reach out to tell them.
        • Norgur@fedia.io
          link
          fedilink
          arrow-up
          7
          arrow-down
          1
          ·
          8 months ago

          I think you massively overestimate the amount of users that are a) affected by this b) reporting it When seeing the overall picture, this might mlbe a rather fringe issue in Google’s eyes.

          Furthermore, you might be exaggerating the impact as well. The “impact” is that an app update fails. That’s it. That might be annoying, but isn’t the grave and evil thing you make it out to be.

          Besides, have you ever thought about that this stems from a rather bad practice on F-Droid/app developer side? They use the same package name for a software with a different signature. That’s just not ideal to begin with. All packages with the same name should have the same signature for any given version of the package. That’s how security works. If they don’t follow that, how is a user/security software supposed to check if the signature is authentic or of the package was tampered with?

          • NeatNit@discuss.tchncs.de
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            2
            ·
            edit-2
            8 months ago

            AFAIK F-Droid allows using the same signing key as in PS. The choice is up to the developer. But as I said, if they use the same key then PS will overwrite the app, which is 100% unwanted behaviour.

            What do you suggest about package names? Do you think there should be org.wikipedia.playstore, org.wikipedia.fdroid, org.wikipedia.galaxystore to use a different package name per store? Or should just F-Droid get the special name?

            Do you think it’s okay when e.g. play store and galaxy store update apps installed by the other store? This happens with various apps, especially some Samsung and Microsoft apps. (Obviously only when using the same keys, but I think this is common practice)

            And specifically do you think that’s okay when F-Droid is thrown into the mix? I think absolutely not, especially since F-Droid often removes proprietary libraries, ads and tracking that are present in the other sources.

            Honestly I can warm up to the idea that F-Droid builds should have a unique package name (call it a flavour, even if it’s 1:1 with the play store release). But the Play Store and Galaxy Store overwriting each others’ apps already reeks of idiocy and bad design to me, and F-Droid has nothing to do with it.

      • NeatNit@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        8 months ago

        I’ve only been seeing it in the past few months, definitely less than one year. Before that this never happened even when I had affected apps installed. Notably the Wikipedia app.

        • wreckedcarzz@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          edit-2
          8 months ago

          I have experienced it for at least 5y or so, back when I ran CalyxOS. It would try to override the sim tool at every opportunity when calyx used a custom version. With GrapheneOS, I have always (3y) had a stub apk to give me the preview picture in gCam without requiring gPhotos, and it bitches and errors constantly if you don’t turn off auto-updating. Tasks.org joined it recently since I use Obtainium (not f-d); it’s been happening with quite a few apps, just Tasks has been out of sync for the Github release vs play store release a while now.

          Android knows if an apk is installed from the ps or not, this would be a two-line if-statent fix. But there’s no incentive for them to make using alternative stores/methods work better than the bare minimum, so they don’t :(