The Java API to Android's Telephony Stack

Start writing your own Android telephony applications using the Android Java API, and discover the under-the-hood workings of a cellular telephony software stack.

Going back to the internal telephony API of the com.android.internal.telephony package that platform applications such as Phone use, you will find that the most important methods are in the Phone and SimCard interfaces as well as the Call and Connection abstract classes. The source code below shows some of the most important methods.

The Phone interface has methods that are used to place, accept or reject a call:

public interface Phone {
  Connection dial(String dialString) throws CallStateException;
  void acceptCall() throws CallStateException;
  void rejectCall() throws CallStateException;
  void setMute(boolean muted);
  void startDtmf(char c);
  void sendDtmf(char c);
  void stopDtmf();
  ...
}

A Call object is created when you answer a call, and the Call class methods implement call-related functionality allowing you to, among other things, hang up:

public abstract class Call {
  public abstract void hangup() throws CallStateException;
  public boolean isRinging()
  public abstract boolean isIncoming();
  ...
}

The Connection class is related to the Call class shown above. A Call can have a number of associated Connection classes accessible via the getConnections() method, while the Connection class has a reference to the corresponding Call, returned by the getCall() method). To be honest, I didn't manage to understand from the Android source code when and why there would be multiple connections in one call. Some telephony routines work with the Call class—for instance, those used to answer the call. Others work with the Connection class—for instance, it is returned by the dial() method of the Phone class. As you can see from the list of important Connection methods, their functionality is similar:

public abstract class Connection {
  public abstract void hangup() throws CallStateException;
  public boolean isRinging()
  public abstract boolean isIncoming();
  ...
}

Finally, the SimCard interface provides an access to a SIM card via methods that allow users to supply a PIN (Personal Identification Number) and a PUK (Personal Unblocking Key), which is used to unblock the PIN:

public interface SimCard {
  void supplyPin(String pin, Message onComplete);
  void supplyPuk(String puk, String newPin, Message onComplete);
  void supplyPin2(String pin2, Message onComplete);
  void supplyPuk2(String puk2, String newPin2, Message onComplete);
  State getState();
  ...
}

The SIM state, returned by the getState() method, can be either ready, PIN/PUK required or network locked.

If you are interested in the Phone interface implementation, you should check the PhoneBase class that implements some of its methods. The rest, which are RAT-dependent, can be found in GSMPhone, which extends the PhoneBase class and is part of the com.android.internal.telephony.gsm package. The SimCard interface and the GsmSimCard class, as well as Call and GSMCall, follow the same approach. GSM currently is the only RAT supported by the Android platform, but Qualcomm has announced that it is working on CDMA2000 support. More technologies, such as LTE (Long Term Evolution), may be supported in the future.

Another important class is TelephonyIntents, which defines intents—that is, events (in Android parlance) that the telephony framework can produce:

  • ACTION_SERVICE_STATE_CHANGED: the phone service state has changed.

  • ACTION_SIGNAL_STRENGTH_CHANGED: the phone's signal strength has changed.

  • ACTION_ANY_DATA_CONNECTION_STATE_CHANGED: the data connection state has changed for any one of the phone's mobile data connections.

  • ACTION_DATA_CONNECTION_FAILED: an attempt to establish a data connection has failed.

  • ACTION_SIM_STATE_CHANGED: the SIM card state has changed.

The Phone application (in the PhoneUtils class of the com.android.phone package) uses these methods to place or answer a call in the following way:

public class PhoneUtils {
  ...
  static boolean answerCall(Phone phone) {
    ...
    Call call = phone.getRingingCall();
    phone.acceptCall();
    ...
  }
  ...
}
static int placeCall(Phone phone, String number, Uri contactRef) {
  ...
  Connection cn = phone.dial(number);
  ...
}

The above code sample demonstrates only the most basic telephony functionality; however, along with the API outlined above, it should give you a good starting point for writing Android telephony applications. If you decide to do so, you probably won't be able to avoid having to dig in to the Android sources for more details. I hope having a bit more of an in-depth understanding of how cellular telephony works under the hood of the high-level Java API will help you in this endeavour.

Note that this article is based on the Android 1.1 SDK r1 and the Android main git branch snapshot taken on March 24, 2009. Because Android is being developed constantly, some of the APIs mentioned in this article may have changed since that date.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I want to call from PC using

Anonymous's picture

I want to call from PC using my GSM mobile phone blutooth between them,i want to use AT Commands for call control through PC to Mobile via blutooth, pls give some smple code or guidance

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions