- Edited
The purpose of Android's Phone permission is to give apps the ability to make and manage carrier-based calls. It also provides access to related information on the phone number and carrier. This information can also be obtained through the ability to place a call providing by the permission. This permission also isn't required by apps implementing their own calling system. Signal/Molly is a very widely used example of an app implementing non-carrier-based calls and doesn't require this. It's not required to properly avoid conflicts between calls and other apps playing audio. Android has a solid audio focus system and nearly every app integrates well into it. No permissions are required to properly implement this kind of user experience. Phone permission is for apps making/managing carrier-based calls, not VoIP calls. Some apps request it simply to autofill the user's phone number if they use it as their account identifier such as Signal and WhatsApp, but those apps almost always work without it particularly since they want to support using a different phone number than one assigned by a carrier to the device.
GrapheneOS provides Contact Scopes and Storage Scopes for working around privacy invasive apps unnecessarily insisting on access to the contacts and storage/media permissions. It would still be better if these apps simply used the standard Android contact picker, file picker and photo picker on their own, and that's something users already should have been expecting from apps. These scope features are a way of working around many apps insisting on having access they don't require. This is far less common with other permissions, so it hasn't been prioritized to the same extent. However, we plan to provide similar features for other permissions including the Phone and SMS permissions along with Camera, Microphone and others.
We have limited development resources and a lot of them need to be spent on maintaining what we already provide and porting to new Android releases. Since we continue to add more features and raise the bar for quality, we have increasingly reduced time for adding new features. We have to carefully choose what to prioritize and can only gradually implement a small fraction of the features we want to add. Adding alternatives to granting the Phone and SMS permissions for apps insisting on having them is not at the top of our priorities. One of our top priorities for privacy is providing control over which apps can read clipboard contents set by other apps when they focused, etc. Providing a per-app replacement for the standard mock location feature is also likely a higher priority than the Phone and SMS permissions.
If you don't want apps having access to this, then simply reject their request for it. If an app insists on having it and won't work without it, use a different app. There are lots of VoIP options without the unreasonable expectation that you share your carrier-based numbers with them. Apps insisting on having access to this permission are doing it for data mining and you don't have to tolerate it. You do not have to use those apps. Permission requests do not have to be granted. The whole point of having a permission system is the option to reject it. You do not need features like Storage Scopes and Contact Scopes to benefit from the permission model. Those features are nice to have to work around invasive apps and use them despite their intention to coerce you into giving access to your data. However, you already had the option to say no and avoid using apps insisting on saying yes before we provided these features. You currently have that option for permissions like Microphone and Phone prior to us adding similar features offering an alternative to granting them. It's up to you if you want to use a privacy invasive app demanding access it shouldn't need.
MySudo unnecessarily demands access to this permission, has an unnecessary hard dependency on Google Play and bans using an alternate OS for registering an account. Leave a 1 star review for their app on the Play Store explaining this is why and use a better option like jmp.chat. Send app developers a link to https://grapheneos.org/articles/attestation-compatibility-guide if they're banning using alternate operating systems to show them how they can permit GrapheneOS without losing any of what they're trying to do.
Storage Scopes and Contact Scopes didn't exist for most of the lifetime of GrapheneOS. No one should feel entitled to having more features like this from us covering more permissions. We implement what we can based on our available resources and our priorities. No one should be attacking the project and our team based on this. We're aware everyone has their own ideas on what should be prioritized, but most of the community seems quite happy with how we choose our priorities. We're currently working on 2-factor fingerprint unlock, per-app clipboard control, preventing other kinds of leaks with third party VPN apps, control over communication between apps and other features. Some people would prefer if we'd prioritize other things, but it's up to us and it's not open to negotiation. Contacting developers trying to influence our prioritization or publicly attacking our project members based on it is highly inappropriate and isn't going to be tolerated. We aren't going to provide a platform for it and it's not going to influence our priorities. It's taking resources away from development and is in fact delaying the implementation of features.
