What (security) concerns exist regarding a more public/more precise Telephony API?

[Michael Zehender]

Hello,

my company is in the business of automating Acceptance Tests for telephony network integration (mainly GSM and now VoLTE), and we've been automating android phones for about 3 years now.

One target of our tests is to verify that model XYZ from vendor ABC  works with the network infrastructure i.e. intra-bss handovers, bss handovers between different bss vendors, fallback scenarios (with 2G, 3G, 4G), fast-return-to-LTE (from 2G, 3G) etc. and all that in combination with active services (e.g. active (MOC, MTC) voice call, data download, data upload, sending & receiving SMS, sending & receiving MMS). It's an enormous amount of tests that the phone vendor can't possibly do. The network operators have to do these tests in order to verify that the devices will work in their network correctly (although they currently do it for just the most popular phones). I've been working in a couple of environments and everyone tries to build some sort of (semi-)automated system and is struggling with it. My company's automation is pretty successful, but the maintenance costs are huge. Every version update breaks some part of our automation.

I'm not here to complain about the current state of the API, I'd like to understand your concerns in order to find a solution that is acceptable and which I will contribute to the project.

I'll just list the issues we have with automation, starting with easier tasks (in my opinion) and continuing to more invasive changes:

1. Precise Call State Listener: we have to measure the time from entering the DIALLING state to being CONNECTED and then the overall call duration. Unfortunately it doesn't suffice for us to receive the information about these events after the call because we need to do audio signal testing (i.e. if the audio channel is correctly established and measure the latency of sending to receiving an audio signal, etc.).
   
   This is basically just retrieving information and just this topic would ease our lives, for some models we have workarounds that don't loose much time information, but for others the precision is less than optimal.
   
   
2. Basic Call Control: this means making a call (which is possible), answering a call and ending a call - I guess the purpose is obvious. There are workable workarounds, however, I'm interested why making a call is allowed (which can cost - a lot of - money) while answering and ending a call isn't.
   
   
3. Advanced Call Control: hold a call, switch holding and active call, call transfer, conferencing - these are the things where we exclusively have to automate the UI.
   
   
4. Add/Activate APN: to integrate with different vendors without having to reconfigure the network but just activate a different APN on the phone. This is probably the most error prone procedure for us.
   
   
5. USSD: is mostly used to query the balance of a prepaid subscriber, some operators support self-service with interactive USSD. This means sending a USSD and receiving the response. There was a patch contributed, but it was never accepted - and I guess is now completely out of date.
   
   
6. Play a sound file as voice input for a call (it was possible for Nexus One and Galaxy Nexus - but isn't for almost every other model)

I'm not proposing that these API's should be available for every app developer. I'm completely happy with a solution that works entirely over adb or where we have to start a daemon process via adb to make it work. It should however be possible without rooting a device.

As I said in the beginning, I'll try to find a solution that is acceptable for all concerned parties. For that, however, I'd need to understand the constraints I am working in. Therefore I ask for your assistance.

Thank you for your time,

Michael

PS: if this is the wrong audience please guide me to the correct communication channel, thank you.