vvf69107
when Ive messed about with the (possibly?) upcoming cloned app/clone profile feature (on a Pixel 3XL running Graphene / Android 12) I could only create a cloned profile nested under the owner user. As with work profiles it wasnt possible to have a clone profile nested under secondary user profiles.

Guess it may be different in A13 or A14 - particularly because the new Pixel tablet will likely be pushing better secondary user usability/functionality as they are aimed at a multi-user use case.

Theres also the chance this feature wont be released in Android 14. I dont think theyve talked about it publicly yet. They might cancel or delay

Was interesting to see the cloned profile apps show up in the work profile app draw without the little briefcase icon in their corner. Cloned apps has usability issues - shared storage wasnt wired up, didnt show up in recent apps screen.

    a month later
    2 years later

    matchboxbananasynergy

    There is at least one Google Pixel focused open-source OS/ROM that has "work profiles on secondary accounts" as semi-official feature.
    They're somewhat controversial (Yes, I am talking about the C*lyx guys) and I would very much love Graphene to leverage open-source nature of the affair to re-implement this feature on, well, Graphene so I can switch to Graphene for both my phones instead of just one.

    I am positively addicted to having "DeviceOwner+Work_DeviceOwner" AS WELL AS "Secondary+Work_Secondary" (four concurrently running accounts in total, with very comfy separation.

    I understand it's like, a super niche ask/feature but it is doable and has been done, so maybe Graphene will kindly consider it ;-)

      simple-fella generally the answer from graphene is to use private space instead of work profile. Not sure if there is private space in secondary profile. I wish the private space had a schedule to lock unlock at given time..

      simple-fella
      https://grapheneos.social/@GrapheneOS/114146787766360796

      Work profiles are not meant for personal use and most people are not meant to know about them. The Android community used them as a poor's man Private Space before they made that feature. Private Space and OEM features similar to it were likely at least partially inspired by how people were using work profiles via local management app.

      Private Space is essentially just meant to be a nested user owned by another user.

      In the future, support for having multiple Private Spaces would largely replace 1 person using multiple secondary users.

      Android intended secondary users to be for actual separate people using the same device and work profiles to only be for Bring Your Own Device enterprise deployments where your work phone is nested inside your current phone and managed/owned by your work's device management system rather than by you.

      Generally the idea is that it would be better to use Private Spaces (and potentially even the new terminal VM feature) instead. At the moment, further development would be needed to allow more extensive usage beyond the current single, Owner-only Private Space limit.

      As for the other ROM, I imagine their feature is likely insecure and GOS devs would prefer their own secure implementations.

        Dumdum I wonder if I can achieve what I want to achieve via "full VM"
        very interesting and thought provoking

        Dumdum Work profiles are not meant for personal use and most people are not meant to know about them.
        Android intended secondary users to be for actual separate people using the same device and work profiles to only be for Bring Your Own Device enterprise deployments where your work phone is nested inside your current phone and managed/owned by your work's device management system rather than by you.

        Okay but just because that's what Google "intended" does not mean work profiles are inferior to the private space feature? The best argument against work profiles is that they require a management app (e.g. Shelter) so there's one more developer you need to trust. But let's say GrapheneOS were to fork Shelter and include it in the OS, then what's the downside compared to a private space? I only see upsides with the work profile such as the ability to add an app to the homescreen or biometric authentication actually working as expected.

          Viewpoint0232 Okay but just because that's what Google "intended" does not mean work profiles are inferior to the private space feature? The best argument against work profiles is that they require a management app

          Except work profiles actually are inferior (and not because of "what Google intended"). Personally I'd say the best argument against is actually the lack of separate encryption like you get with Private Spaces.
          https://grapheneos.social/@GrapheneOS/114146765620652881

          Private Space is closer to being a secondary user due to better UI integration, no need for a management app and full support for a separate lock method / encryption keys similar to a secondary user instead of the weird way it works with work profiles. We look forward to simply being able to tell people not to use work profiles for personal use but we can't yet because it's useful having 2 nested profiles rather than 1.


          But let's say GrapheneOS were to fork Shelter and include it in the OS, then what's the downside compared to a private space? I only see upsides with the work profile such as the ability to add an app to the homescreen or biometric authentication actually working as expected.

          They've stated a few times (including the above quote) that Private Spaces are the preferred option, so forking of Shelter would be unlikely especially when so much is already being done elsewhere (including overhauling the default apps and eventually Seedvault). They also intend to develop and expand Private Spaces to allow multiple in one profile and/or Private Spaces in secondary profiles. I imagine such development would also include useful features missing from Private Spaces (unless they get added upstream before GOS).