14.4. Android Application-Level Modularity and Telephony

Getting modularity right is difficult. In the case of Android, the problem is especially difficult: mobile phones were not designed to have replaceable software components, but Android is all about replaceable, modular parts. Every part of the Android application environment, even core components that handle phone calls and talk to the mobile radio, can be replaced by code you can write.

How do you avoid perplexing program authors with too much complexity managing the interfaces and the versions of the interfaces between modules? The mobile radio in a handset has a particularly complex interface. In addition to the obvious functionality for starting and ending phone calls and reporting state and error conditions, it also encompasses critical functions such as emergency calls, and obscure functions such as "MMI codes" that enable users to access features of the phone and mobile network through special dialing strings.

Android provides a practical, usable, and flexible system for modularity for telephony applications. It uses the Android system of Intent objects and activities that listen for Intent objects that indicate they should handle a particular request. In this case, we see that the Intent class and the activities and data you need to specify when making a phone call are easy to use. We also see that application-level modularity is a boon to practicality: because you don't need to track the inner workings of a phone call—PhoneApp does it for you.

Android does all of this without replacing, modifying, or adding requirements to the modularity tools provided by Java. You still have class libraries, reflection, and other tools for making and using existing Java software modules.

In the next chapter, you will see what happens inside of Android's telephony software, all the way down to how the mobile radio is commanded to start a phone call.