Telephony API contribution
Gergely Kis
We (MattaKis Consulting) would like to contribute 3 improvements to
the Telephony API:
1. Allow sending DTMF codes during an active call programmatically.
This functionality is required to create applications, which interact
with phone based systems like IVRs, voicemails ... etc.
There is already a ticket for this:
http://code.google.com/p/android/issues/detail?id=1428
2. Provide access to the more detailed "PreciseCallState" for the
applications. This is required for an application to detect when a
call is actually connected to the other party (end the sending of the
DTMF codes can be started).
http://code.google.com/p/android/issues/detail?id=1429
3. Provide means to end a call programmatically (Currently one has to
access the private ITelephony interface and call endCall() on it.)
http://code.google.com/p/android/issues/detail?id=675
We already have a working prototype, which only changes the phone application:
- It adds a DTMFSender IntentService which allows an application to
send DTMF strings using an appropriate Intent. The intent includes
extra parameters like the length of the DTMF codes, the length of the
pause between the codes and also whether the DTMF codes should be
audible for the user or not.
- It defines a new broadcast intent which is sent by the CallNotifier
when the PreciseCallState changes.
We used this intent based approach for the prototype, because this way
only the Phone application had to be changed, so it is easier to patch
a phone, no need to flash ... etc.
For the platform it would probably make more sense to add the
appropriate sendDtmf, startDtmf, stopDtmf, endCall ... etc. methods to
the TelephonyManager interface.
Regarding the PreciseCallState, I think a separate broadcast intent
from the current PHONE_STATE_CHANGED intent would be the easiest
route.
What do you think? We are of course open to suggestions. There are
many things that could be / should be done around the Telephony API,
but first we wanted to concentrate on a specific, localized issue,
which affects many developers.
Do we have a chance that this contribution will get picked up for
Gingerbread? We are of course prepared to submit the code + CTS test
cases + any other necessary additions that are required for this
change to get into Gingerbread.
Does Google work on improvements for the Telephony API?
Best Regards,
Gergely Kis
MattaKis Consulting
Dave Sparks
comment on your proposal. That said, I think it's reasonable to expose
these APIs to app programmers as long as they are behind the
appropriate permissions. I'll see if I can get someone from Android to
respond to your proposal.
Regarding phone state change, I wonder if would be make sense to use
the existing intent and just add an extra to indicate the progression
from dialing to connected.
On Jun 25, 1:25 pm, Gergely Kis <gergely....@gmail.com> wrote:
> Dear Android Contributors,
>
> We (MattaKis Consulting) would like to contribute 3 improvements to
> the Telephony API:
> 1. Allow sending DTMF codes during an active call programmatically.
> This functionality is required to create applications, which interact
> with phone based systems like IVRs, voicemails ... etc.
> There is already a ticket for this:http://code.google.com/p/android/issues/detail?id=1428
>
> 2. Provide access to the more detailed "PreciseCallState" for the
> applications. This is required for an application to detect when a
> call is actually connected to the other party (end the sending of the
> 3. Provide means to end a call programmatically (Currently one has to
Gergely Kis
Thank you for your help.
Regarding reusing the current broadcast: this is valid an option,
however I don't know if it violates the current interface contract if
the OFFHOOK intent is sent multiple times with different extra values.
If this is not a problem, then it certainly makes sense to just reuse
the existing intent.
Best Regards,
Gergely
Herb Jellinek
I'd like to have sendDtmf, startDtmf, stopDtmf, endCall, etc. methods
in some public API, but TelephonyManager seems like the wrong home for
them - the abstraction level is too high. Remember, you can have
several phone calls in progress at one time.
I'd been imagining having a mechanism to obtain a hypothetical
PhoneCall object for a given call, perhaps via PhoneStateListener or
other notification mechanism. The PhoneCall class would define the
sendDtmf, startDtmf, etc. methods.
Your thoughts?
Herb
>
> We (MattaKis Consulting) would like to contribute 3 improvements to
> the Telephony API:
> 1. Allow sending DTMF codes during an active call programmatically.
> This functionality is required to create applications, which interact
> with phone based systems like IVRs, voicemails ... etc.
> There is already a ticket for this:http://code.google.com/p/android/issues/detail?id=1428
>
> 2. Provide access to the more detailed "PreciseCallState" for the
> applications. This is required for an application to detect when a
> call is actually connected to the other party (end the sending of the
> 3. Provide means to end a call programmatically (Currently one has to
Gergely Kis
Finally, I uploaded the first version of our patch to Android,
hopefully not too late.
It consists of 3 changes:
1. Add new interfaces to TelephonyManager:
https://review.source.android.com/#change,18745
2. Implement the new interfaces in the Phone application:
https://review.source.android.com/#change,18746
3. Add a DtmfTester sample to make it easy to try it out:
https://review.source.android.com/#change,18747
It looks like I left a few whitespace errors in there, I will address
those together with any other concerns you may have.
I am looking forward to your comments.
Best Regards,
Gergely Kis
MattaKis Consulting
Gergely Kis
I just saw your email. You are of course right, it would be very nice
to redesign the whole Telephony subsystem of Android.
Right now, I decided to keep the change localized in order to increase
the chance of getting it accepted into the official tree.
If we succeed with this, we could try to work on a redesign of the
Telephony subsystem as a whole. However, as any large scale change in
the core Android platform, such efforts have to be driven by Google
engineers, because they are in the position to make such decisions,
and synchronize the changes with other platform improvements.
Best Regards,
Gergely