Infeasible
Status Update
No update yet.
Comments
am...@google.com
Thank you for the feedback. We’ve shared this with our product and engineering teams for the possible consideration.
am...@google.com
The NEW_OUTGOING_CALL broadcast is deprecated and is expected to be removed in a future release. In Android O initiatives were begun to start reducing the number of apps which run in the background (https://developer.android.com/about/versions/oreo/background ); the NEW_OUTGOING_CALL and PHONE_STATE broadcasts are currently retained as background-check exempt broadcasts. This means they can wake up background apps for handling. Our goal is to ensure that less apps wake up when background events take place (see the developer site article for more reason as to why). As such there is not planned to be any new call state related broadcasts, with the existing ones being turned down over time.
Apps which perform caller ID should use the CallScreeningService API (https://developer.android.com/reference/android/telecom/CallScreeningService ) which provides them with the information they require to operate. The API is ideally suited to these kinds of apps as it is guaranteed to be invoked prior to a call ringing, while limiting the number of apps competing to perform this operation.
Likewise, apps which want to provide outgoing call assistance (re-writing numbers for calling cards, etc) can use the CallRedirectionService API (https://developer.android.com/reference/android/telecom/CallRedirectionService ) to have control over the placing of outgoing calls. Again, this API limits the number of apps which can perform this operation to ensure an overall better user experience and to align the Telecom APIs with background execution goals.
Apps which perform caller ID should use the CallScreeningService API (
Likewise, apps which want to provide outgoing call assistance (re-writing numbers for calling cards, etc) can use the CallRedirectionService API (
lb...@gmail.com
@3 CallScreeningService cannot be used by multiple apps. Intents can.
Also, we have handling of incoming phone calls, when they are answered, so why not outgoing calls too?
I really wish there would be a good API, but none of what's offered can suffice.
Why not offer CallScreeningService to be handled by multiple apps? The user could set a priority of which to use, and also have auto-priority, to let the first that has an answer who the other person is - to show it.
Why do you want to limit the power of the API, instead of enhancing it?
Also, we have handling of incoming phone calls, when they are answered, so why not outgoing calls too?
I really wish there would be a good API, but none of what's offered can suffice.
Why not offer CallScreeningService to be handled by multiple apps? The user could set a priority of which to use, and also have auto-priority, to let the first that has an answer who the other person is - to show it.
Why do you want to limit the power of the API, instead of enhancing it?
Description
Using InCallService isn't always an option, and it can be a very bad choice in some cases, as I wrote here:
Currently, after getting the intent that an outgoing call has started ringing, when the call is answered (the other side has picked up the phone), there is no new Intent.
That's as opposed to incoming call, where the state changes to EXTRA_STATE_OFFHOOK .
Please add a new Intent or a way to detect the state after this Intent, that will let apps detect that an outgoing phone call was answered.
This can help a lot of caller ID apps out there that have a very good reason not to use InCallService