The Java API to Android's Telephony Stack
As a Linux Journal reader, you've probably stumbled across Google Android here and there. You've probably read an introductory article or maybe you even downloaded an SDK and coded an application or two. If you haven't, I encourage you to do so, as this article is not an Android overview. I'm not going to talk about the Android architecture and application development; plenty of good articles already exist on those subjects. See this article's Resources for some links to Google video lectures about the Android architecture and Android application basics. However, if you have some basic knowledge of Android and would like to learn a bit about cellular telephony and how it is implemented in Android, this article is for you.
Android is all about applications. Almost every article and discussion on this subject revolves around the SDK, the Dalvik Java VM and the Android Market. In fact, it is quite difficult to find an Android article that doesn't mention applications. With all this hype, it's easy to forget that the Google phone is, after all, a phone, which (surprise, surprise) is supposed to make phone calls. So, this article takes a different route and instead of focusing on applications, it focuses on Android telephony—from the application API down to the cellular baseband hardware. This part of Android is not very well documented, but fortunately, Google has released most of the code under the Apache open-source license.
Before I start talking about APIs, dæmons and all the really interesting stuff, it's worth mentioning that although it seems like Android has all the hype, at least as far as Linux-based mobile phones are concerned, when you look at the facts, you will discover that actual Android adoption is far more modest than what Google would like you to believe. Currently, only one company (HTC) manufactures Android-based phones, and it has two variants sold by T-Mobile. A few other companies (Samsung, for instance) have announced that they are going to launch an Android-based phone some time during 2009. There are actually a few dozen other Linux-based mobile phone models on the market that are based on a competing platform, described in more detail below.
Before going into software, it is important to understand the underlying cellular telephony hardware architecture. Unfortunately, there are no standards in this area, and every model from every company may look completely different. Still, there are some common ideas and industry trends in cellular reference designs; a block diagram of cellular phone basics is shown in Figure 1.
Figure 1 omits many crucial hardware components that have nothing to do with software architecture and, therefore, are not very relevant in the context of this article—after all, the goal here is to understand the telephony software stack.
Sometimes the application and communication (or baseband) processors are, indeed, different chips. However, more often than not, both CPUs reside on the same die or at least the same package. This is the case with the HTC/T-Mobile G1, which is based on a Qualcomm MSM7201A multicore CPU and includes an application processor (ARM11), a communication processor (ARM9) and some other cores, including a GPS. Sometimes a single CPU is used for both application and baseband tasks, usually in simple low-end phones. The distinction between application and communication processors is especially important in the context of software: when there is only one core used for both application and communication processing, the software stacks are quite different.
The application processor usually controls the screen and keyboard and runs the software stack that interacts with the user, including various applications. It usually runs some generic operating system, such as Linux, Windows Mobile or Symbian. The communication processor runs a cellular protocol stack on top of some RTOS, such as Nucleos or Thredx. Although the application software can be open source in some cases, the cellular protocol stack always is distributed as binary only. The PM chip is responsible for power management, and the RF for conversion of baseband to radio frequencies. Other peripherals, such as the LCD, keypad, speaker and microphone do not need further explanation.
It is important to note that the communication processor is responsible for cellular communications only (both voice and data). Wi-Fi, Bluetooth and other communication protocols are beyond the scope of this article, as they are conceptually different and often better documented.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
2 hours 12 min ago
5 hours 48 min ago
- Reply to comment | Linux Journal
6 hours 20 min ago
- All the articles you talked
8 hours 44 min ago
- All the articles you talked
8 hours 47 min ago
- All the articles you talked
8 hours 48 min ago
13 hours 13 min ago
- Keeping track of IP address
15 hours 4 min ago
- Roll your own dynamic dns
20 hours 17 min ago
- Please correct the URL for Salt Stack's web site
23 hours 29 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
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.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?