public enum CallAvailability
- Object
- Enum<CallAvailability>
- CallAvailability
ImplementsComparable<CallAvailability>
Whether the app may ring a call right now. Distinct from
Calls.isSupported(), which asks whether the platform has the machinery
at all: an app can be perfectly supported and still be unable to ring,
because the user is on an emergency call or another app holds one.
Check this before reporting an incoming call so the far end can be told to stop trying, rather than discovering the refusal from a failed report.
The ordinals cross the SPI boundary, so existing constants must not be reordered.
Enum constants
AVAILABLE | A call can be reported now. |
EMERGENCY_CALL_IN_PROGRESS | An emergency call is in progress. |
OTHER_APP_IN_CALL | Another application holds a call the system will not interrupt. |
NOT_PERMITTED | A permission the port needs to ring a call is missing. |
UNSUPPORTED | The platform has no system call integration at all. |
NOT_CONFIGURED | Calls.configure has not completed successfully, so a report would be refused. |
THIS_APP_IN_CALL | This application already holds a call the platform will not let it stack another on. |
Methods
public static CallAvailability[] values() | |
public static CallAvailability valueOf(String name) |
Inherited methods
Enum constant details
AVAILABLE
AVAILABLEEMERGENCY_CALL_IN_PROGRESS
EMERGENCY_CALL_IN_PROGRESSOTHER_APP_IN_CALL
OTHER_APP_IN_CALLNOT_PERMITTED
NOT_PERMITTEDA permission the port needs to ring a call is missing.
Android only; iOS never answers this. Three causes, and only one of
them is answered by a prompt: MANAGE_OWN_CALLS missing is a normal
permission granted at install, so there is nothing to ask for and the
manifest is what has to change; POST_NOTIFICATIONS ungranted on API
33+ is a runtime permission and is requestable; notifications switched
off or the incoming-call channel below high importance is a setting,
which only the user can change in the system’s own screens.
A disabled PhoneAccount is NOT one of them – nothing queries that,
and it surfaces later as a CallError.CALL_REFUSED on the report –
so a handler for this value must not send the user to the calling
switch.
UNSUPPORTED
UNSUPPORTEDNOT_CONFIGURED
NOT_CONFIGUREDCalls.configure has not completed successfully, so a report would
be refused.
Not proof that it never ran: Android’s configure answers
CallError.UNAUTHORIZED when registering the account throws, and
leaves the port unconfigured, so this value is what a caller sees
afterwards. Calling configure again changes nothing until the reason
it failed is fixed.
Appended rather than inserted: the ordinals cross the SPI boundary.
Android registers a Telecom PhoneAccount from the configuration and
ignores calls from an account it does not know, so a report made
before configuring is refused whatever the permissions say. This
exists because answering AVAILABLE and then refusing the very next
report is precisely what the check above is documented to prevent.
THIS_APP_IN_CALL
THIS_APP_IN_CALLThis application already holds a call the platform will not let it stack another on.
Appended rather than inserted: the ordinals cross the SPI boundary.
iOS only, and not an oversight elsewhere. The provider is configured for one call group of one call, so CallKit refuses a second report while this app owns a live call – and answering AVAILABLE there would be the same broken promise as answering it before configure(). Android Telecom accepts a second self-managed call from the same account, so its bridge deliberately does NOT report this; see the note in AndroidCallBridge about isInCall() being true for our own call too.
Method details
values
public static CallAvailability[] values()valueOf
public static CallAvailability valueOf(String name)