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

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix