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.
Thanks for the response, Tcecyk.
heuristic for “active user” can prove to be difficult once the lockscreen is on. It’s an interesting problem!