I was poking around the settings & found System | Multiple users. While playing I found that the warning message “Call & SMS history will be shared with this user” was accurate, and I’m a bit befuddled why that is. I’m hoping someone can explain why it was coded to work that way. (The user cannot make non-emergent calls, or send SMS, without history also being shared.)
When I create different users on my laptop, we don’t share emails, IMs, etc. So why does /e/OS require sharing?
Use case: daughter can’t find phone before heading off to the ski slope, & wants to borrow mine for a few hours so she can contact us with a meeting place/time. I want her to be able to call/text, but I don’t want her looking at my chat history.
I hope this doesn’t come across as a gripe - I’m appreciative with all the work you’ve done. I just can’t wrap my head around a use case where a temporary user should have access to the permanent user’s chat history.
you point out a shortcoming of the implementation in AOSP. (For others, here are the official help docs)
You don’t share mails/IMs because you have different accounts, but you share the same number on a device across all users. So for inbound calls/texts it is hard to determine the recipient. But ofc for outbound you could make that distinction and create separate histories. I guess there just isn’t the code to do what would be sensible from a end user perspective.
One way to circumvent this is to use any “OTT” messenger for calls+text that are account-bound and separate. Of course for emergency purposes you’d always want your kids to use all methods of communication possible.
“You don’t share mails/IMs because you have different accounts, but you share the same number on a device across all users. So for inbound calls/texts it is hard to determine the recipient.” Excellent point. Texts/calls from my friends may be arriving while my kid has the phone. An argument could be made for the active user receiving texts/calls, with the admin user also getting a copy of those texts (and the outbound call log). But that’s a stretch, and an AOSP change I’d peg as highly unlikely.
