• Development

  • Adding connection sharing to a second profile

Hello,

I don't know if it's an oversight or me not finding the option, but would it be possible to add the option to share a connection from another profile?

On my phone, I have a second profile exclusively for work and I find it "strange" that I have to go back to my main profile to activate this option and then come back to my work profile, it's absurd.

Is it possible to activate this option from other profiles?

Thank you in advance to the GOS team.

    Stewart
    Important system-wide settings are limited to the Owner profile due to the unique access/permissions that only the Owner has. The only changeable network settings in secondary profiles are what WiFi network the phone is connected to (or turn off WiFi completely) and the VPN option (which is per-profile and not system-wide).

        Dumdum But technically, is it possible to implement the connection sharing option in a second profile? Aren't there any restrictions on that ?

        Juggling profiles is pretty annoying.

          Stewart GrapheneOS is an AOSP fork. That means that most of the GrapheneOS code and most of the GrapheneOS behavior match AOSP as shipped by Google. Many many things that could "technically" be done are not done because Google didn't want to, or didn't think it was important enough to get around to yet.

          Obviously GrapheneOS does make changes to AOSP. But the project focus is on security and privacy. Adding connection sharing to secondary user profiles is a convenience issue, not a security issue or a privacy issue. That does not mean it would never happen in GrapheneOS, but it does mean it is probably not a high priority.

          One thing that might elevate the priority would be a community member contributing code. Perhaps that might be you.

          However, because GrapheneOS ships upstream patches quickly (this is not true of all other AOSP forks), every GrapheneOS change adds to the developer load when processing each new AOSP release from upstream. This means that even if code were provided by a community member for a feature, and the code were of high quality, it might not be accepted.

          So...

          1. Connection sharing is probably the way it is because of Google. It is possible to file an enhancement request in the AOSP issue tracker, but not likely to go anywhere.
          2. Even though some users might find the feature convenient, if it is not a security or privacy issue the GrapheneOS developer team may not work on it.
          3. Even though some users might find the feature convenient, if it is not a security or privacy issue a community code submission is not guaranteed to be accepted.

          There are many other AOSP forks. Some of them have various convenience features that GrapheneOS does not. The GrapheneOS project ships Google security and privacy fixes faster than the vast majority of AOSP forks and faster than most OEMs. Also, the GrapheneOS project with some frequency finds major security issues and helps Google fix them. Users who want that level of security and privacy may be well off running GrapheneOS, but other users might legitimately choose to prioritize various other features and might choose to run other AOSP variants.

          Please note that I do not speak for the GrapheneOS project.