• winterpeacock
      link
      fedilink
      English
      arrow-up
      5
      ·
      1 year ago

      I don’t know the exact reason why Android requires the primary user to enter their PIN/password before any other user can log in, but it may be due to the fact that the primary user is also the “system” user which is “always running even when other users are in the foreground.

      Full disk encryption?

      • MishaalRahman@lemdro.idOP
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        Android hasn’t used FDE for a couple of years now. File Based Encryption (FBE) has been required instead since Android 10. With FBE, each user has their own credential encrypted storage location for apps, which are encrypted with the credential from that particular user. (I verified this while testing. When you boot and unlock the primary user, other users data at /data/user/{id} is still encrypted until you unlock them.)

        • winterpeacock
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          Maybe there are other system files required that are encrypted with the primary user credentials

          • MishaalRahman@lemdro.idOP
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            There might be, though I couldn’t find any. I poked around /data on a rooted Pixel that had just booted but hadn’t had its primary user unlocked yet, and I was able to access most files in /data/system still.

      • someone_secret@burggit.moe
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Pretty much my thoughts, yes.

        In order for the FDE to have any usefulness, the key has to be derived from a secret that only the user of phone knows (I.e. a secret PIN, password or pattern)

  • Zectivi@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    ·
    1 year ago

    I didn’t know that Samsung had that feature, but it does sound nice - so long as you have the ability to enable maintenance mode.

    I recently took my pixel 7 in to ubreakifix for a screen replacement. The screen was 100% dead, but I could still hear the notifications coming in. I couldn’t put it into maintenance mode if it had one, so I think I’d still stress a bit about whether or not the phone would be wiped, such as in the case I was unable to verify the upload of a recent Aegis backup. It would be nice if the maintenance mode was able to be triggered via a web interface in cases such as mine. Or maybe even a specific button combo that would be difficult to accidentally do.

    • MishaalRahman@lemdro.idOP
      link
      fedilink
      English
      arrow-up
      9
      ·
      1 year ago

      That’s a good point, and I agree: There should be a way to trigger Maintenance Mode remotely, like through Find My Device, should Google implement this.

  • TrenchcoatFullOfBats@belfry.rip
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    Good article, thanks for writing and sharing here!

    I’m not an Android developer, but I do know Linux, and it sounds like Samsung’s maintenance mode could just be another user with different permissions, with access to system directories but not user home directories.

    If, as you say, Google gives the primary user full rights (like having admin rights in Windows), that would mean that Samsung might be creating “regular” users without those rights, and “maintenance mode” could simply be another regular user - by default, regular users don’t have access to other regular user’s home directories.

  • Moonrise2473@feddit.it
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 year ago

    Theoretically, isn’t maintenance mode completely useless?

    If they’re the manufacturer, they could upload and boot via fastboot a signed image that allows all tests to be done, all automatically

    When I broke the screen of my Xiaomi mix 3, it was completely black, I sent it back to repair and they had no problem at all repairing it even if I didn’t unlock it before sending it. (Maybe it’s because Xiaomi has hw tests shortcuts in the bootloader?)

    • MishaalRahman@lemdro.idOP
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      Sure, the manufacturer could, but they might not provide those kinds of images to their official repair centers, certainly not third-party ones.

      • Moonrise2473@feddit.it
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        They should provide it, easier to do compared to a mode that can’t be activated if the screen is broken or simply the user has no idea how to do it.

        For example Epson gives watermarked service programs to authorized service centers (splash screen says “licensed to Mr xxx of yyy inc.” so they know exactly who leaked it)

        Apple also has such secret software

        This will also give a competitive advantage to official service centers (why pay $$$ for certification and training if can get the same tools of a generic store that opened yesterday?)

  • ScOULaris@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    One UI has been crammed with features for years now, many of which would be very nice to have in Pixel phones. Maintenance Mode would be good, I guess, but I can think of several others that would be far more beneficial to have merged into AOSP in some form.

    For example, One Hand Operation + is the best implementation of gesture navigation in all of Android IMO. It’s quicker and more efficient than traditional gestures, more customizable, and plays well with third-party launchers. It’s one of the killer apps that makes it hard for me to consider anything other than a Samsung phone these days, especially since Google has made no attempts at fixing the wonky behavior of the native gesture navigation and third-party launchers.