TL;DR

  • Efforts like Graphene OS face increasing pressure from apps that refuse to run on non-standard Android.
  • The custom ROM project characterizes Google’s approach to device attestation as incomplete and flawed.
  • Graphene OS is prepared to take legal action if Google won’t let it pass Play Integrity checks.
  • Blackmist@feddit.uk
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    4
    ·
    5 months ago

    Well that’s all very well, but I’ve got a bathroom speaker I can no longer access.

    So how about instead of Daddy Google deciding what’s best for everyone, they let things run and give you a warning?

    Hell, I’ve even got games I’ve paid for that are now gone. Honestly, fuck them for even thinking that’s acceptable.

    • yamanii@lemmy.world
      link
      fedilink
      English
      arrow-up
      11
      ·
      4 months ago

      Same, it’s why I never buy a game or app nowadays, they will just stop working when the new OS version comes around, devs already got their money so they don’t have any incentive to care, and contrary to PC I can’t do shit about it myself on my phone, there’s no “androidbox” to run old apps inside my phone.

    • corsicanguppy@lemmy.ca
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      5 months ago

      You’re really arguing for a covenant around tech that companies want to orphan. The rule needs to be the code is opened and a slacker code owner is appointed for handover.

      This is gonna embarrass Google a Lot but it’s gonna embarrass azn and m$ a whole lot more.

      The forced alternative is a refund if you can bring something recognizable with a serial number to your post office or something as ubiquitous, present and staffed - have them validate in the loosest fashion and require like 10 bizdays for the cash refund.

      Whether or not the post office is there for that or charges the OEM for the notary-light service is a matter for the courts, the USPS, and these days probably the fn SCotUS.

    • TrickDacy@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      5 months ago

      So how about instead of Daddy Google deciding what’s best for everyone, they let things run and give you a warning?

      That is not what’s happening. It takes tons of work to maintain backward compatibility but you’re framing it as though it doesn’t and they’re just being a holes on purpose.

      • Blackmist@feddit.uk
        link
        fedilink
        English
        arrow-up
        8
        ·
        5 months ago

        It doesn’t allow direct connection. You have to dick about with a stupid app to put it in “speaker mode” first.

        • Gingernate@programming.dev
          link
          fedilink
          English
          arrow-up
          5
          ·
          4 months ago

          Damn that sucks!!! I wish there was a way to sandbox older apps. I’ve ran into the same issue with old apps before.

        • LinusSexTips@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          4 months ago

          Gives me Sonos vibes.

          I won a Sonos speaker years ago, thing needed (from memory) an app to switch to AUX mode. The speaker sounded great but I didn’t want to install an app just to use the thing.

          In a grand spectacle my ex’s cat kicked a potplant off a windowsill into our fish tank. That shorted a power board, we didn’t have breakers (ceramic / wire fuses) which ended up killing the speaker.

          Honestly as nice of a speaker it was, good riddance.

      • Blackmist@feddit.uk
        link
        fedilink
        English
        arrow-up
        6
        arrow-down
        3
        ·
        5 months ago

        So it’s my choice to run them?

        If I can download an APK, I should be able to run it in a “compatibility mode” and have the OS do it’s best to run it.

        • gh0stcassette@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          1
          ·
          4 months ago

          There’s a few apps that let you virtualize an older version of Android, but in my experience they’re slow, and they’re all from sketchy-looking Chinese companies that are for sure harvesting all your data. There’s also an open source project running for this, but I don’t remember what it was called and it was fairly limited.

        • conciselyverbose@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          6
          ·
          5 months ago

          It can’t.

          A compatibility mode would involve meaningful cost, massively compromise security, and not have a chance in hell of working.

          • gh0stcassette@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            2
            arrow-down
            1
            ·
            4 months ago

            They could just spin up a container of some sort. It’s still fundamentally Linux, so it should be possible to run Android inside an lxc container the same way you can run a desktop Linux distro in docker (which is based on the lxc functionality in the Linux kernel)

            • conciselyverbose@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              2
              ·
              4 months ago

              The point is that you have to emulate a fuckton of low level access to even have a chance of anything working. Either you replace the actual hardware access with junk data, making none of the apps work, or you break the whole permissions structure, and your security is completely gone.

              All of those APIs were deprecated because it’s impossible to provide them in any way that resembles security.

              • gh0stcassette@lemmy.blahaj.zone
                link
                fedilink
                English
                arrow-up
                1
                ·
                4 months ago

                I mean, as long as it’s in a pretty robust sandbox and it’s either firewalled or has no network access (if possible for the app in question), I would think security implications are minimal. Like, even if the version of Android inside the container is compromised, the app could only take over its own container, which is non-privileged and doesn’t have access to anything you didn’t explicitly give it (in terms of user data).

                • conciselyverbose@sh.itjust.works
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  4 months ago

                  But almost every app is going to crash because they’re built on needing the information those APIs return.

                  His example of not being able to control some wireless speaker? Supporting that app is going to be a mess, best case.

                  • gh0stcassette@lemmy.blahaj.zone
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    edit-2
                    4 months ago

                    You’d need some sort of translation layer to allow older versions of the Android userland drivers in the container to talk to the modern Android userspace drivers. Or you could write new userspace drivers inside the container that interact directly with the hardware, but this would likely be expensive and insecure. Definitely doable tho, especially for a company as large as Google.

                    Especially on Pixels, with the generic system image feature (allows for booting generic, non-device-specific android images), if the container is built with the same userland drivers as a generic system image, it might not even need any special effort/attention to run, though iirc GSIs are pretty recent, so you wouldn’t be able to run software for anything before like, Android 12 or 13 probably.