On cottage phone and Android "13" SmartPhone AP System

In the 9th chapter, we mentioned that a rough generalization of the smartphone is that the smartphone = = computer + mobile network card, or more accurately, the hardware structure of the smartphone is divided into the application processor AP, and the baseband processor BP two parts. There are two problems implied,

1. Integration of the BP part with the AP part.

2. The traditional function phone is only equipped with the factory preinstalled application software, but does not allow users to download and install third-party applications, and the smartphone has breached this limit, so the AP portion of the smartphone must have a corresponding open mechanism, facilitate the development and installation of third-party software, At the same time, minimize the malicious damage to the entire system, including other software, caused by third-party software. Further, the open mechanism of smart phones, not only for third-party software, but also for mobile phone manufacturers, allow mobile phone manufacturers to replace some of the mobile phone system hardware equipment, or additional peripheral hardware equipment, so that a common platform can ship multiple phone models, Help mobile phone manufacturers to minimize the cost of mobile phone research and development.

For the first question, how the BP part integrates with the AP section, the solution idea is simple. Open any of the operating system textbooks, you can see the standard hierarchy, application software >> operating system >> drive >> hardware. The integration of BP and AP may be compared with the composition of the file system in the operating system.

File systems typically include virtual file system (SYSTEM,VFS) and actual storage devices (Storage device). The actual storage device includes storage hardware such as flash or hard disk, and the appropriate drive. Virtual file system through the drive to manipulate the storage hardware, on this basis to achieve file and folder creation and deletion, file read and write functions. The virtual file system is called virtual because the application software uses standard interfaces (APIs) to invoke the functionality of files and folders implemented by the virtual file system, regardless of which vendor's hardware and drives are used by the actual storage device [1].

If the actual storage system in the file system is likened to the BP part of the smartphone, then the virtual file system corresponds to the telephony Stack in the AP section. The Telephony stack offers three functions,

1. With the BP part of the system communication (Inter-processor COMMUNICATION,IPC), the BP part of the command, set up a communication channel, send and receive voice and data information. The IPC can be implemented either by passing At-command or by using shared memory for data exchange.

2. The three basic functions provided by the BP section, namely, voice call, SMS and other data communication, as well as SIM card management, plus the closely related telephone book (Address books), provide the following services,
-Make a call: initiate or accept a voice call.
-SMS Management: Edit SMS, send text messages, receive SMS, delete, reply or forward SMS, etc.
-Call history.
-Phone book.
-Phone ringing and vibration settings.
-SIM card management.

3. Provide standard calling interface (Telephony APIs, TAPI) to facilitate application software to invoke the above services.

Figure 13-1 describes the internal structure of the Telephony stack in the AP system of WinMobile 6. The purple modules in the figure, strictly speaking, do not belong to the telephony Stack, they are application software that uses the function of the yellow part of the module by invoking the Telephony APIs. Yellow part of the module, responsible for the implementation of call, SMS management, SIM card management, call history and other functions, called Cellcore, provided by Cellcore.dll, mobile phone design manufacturers can not change the cellcore. The Blue section module, mainly Ril (Radio Interface Layer), is responsible for inter-system communication between the AP part and the BP part. RIL part is hardware-related, by mobile phone design house or BP part of the manufacturer to complete.

Figure 13-1. WinMobile Telephony Stack.
Courtesy Http://farm5.static.flickr.com/4030/4461979382_a450147727_o.png

The first problem, the integration of BP and AP, is easier to solve. The second problem, the open mechanism of the AP, provides a standard interface for invoking system resources, which facilitates the development and installation of third-party software, while minimizing the risk of opening, and this problem is not easily solved. What kind of call interface is convenient, what degree of risk control is safe, these two indicators are lack of universally accepted measurement criteria. What we can do in the current situation, perhaps, is to compare the design of the AP portion of several smartphones and analyze who is more convenient and safer.

Figure 13-2 describes the position of the Telephony stack in the entire winmobile system, defined by a red box. WinMobile provides Win32 Apis,win32 APIs for third-party software that not only provides the ability to allocate memory, control process and thread, read and write files, connect to the network, and other basic functions such as the Calling interface (APIs), also provides the open and close windows, And the GUI-related APIs that control the window controls.

Figure 13-2. WinMobile Architecture.
Courtesy Http://farm3.static.flickr.com/2756/4497998261_22aa6faf22_o.png

Win32 APIs are fully functional, but they are very difficult to use. Many APIs come with many parameters, many repetitive work is not encapsulated, resulting in the development of application software, not only the code is large, but also error-prone. In view of this, Microsoft to the pure C Win32 APIs, with VC + + re-packaging, the formation of MFC (Microsoft Foundation Classes). As a object-oriented language, VC + + has encapsulation (encapsulation), polymorphism (polymorphism), Inheritance (inheritage) and so on. Using VC + + these features, MFC greatly simplifies the invocation of WIN32 APIs, programmers can use more streamlined code to complete the development of application software.

Microsoft referred to MFC as a application Framework. The rise of the concept of the application framework stems from the difficulty of seeking to reduce GUI development. GUI development, involving graphics, layout, event capture and response, message delivery and many other technologies, not only difficult to get started, but also error-prone. The application framework simplifies the complexity of programming and reduces the risk of errors by standardizing programming by using a variety of programming environments (Ides), Toolsets, and software system stereotypes, such as MVC stereotypes [2].

Object in MFC, you can allocate memory directly, so when you clear object, you need to manually clear the memory allocation, leaving no residue. Prevention of memory leaks is not only a difficult point in the application software development process, but also prone to bugs. If you put an object in MFC, called the original Ecological object (Native object), then Jave and c#/. NET object, is a controlled object (Managed object). The so-called garbage collectors (garbage Collector), which are mainly embodied in virtual machine, are responsible for managing the memory space they occupy, without requiring the programmer to manually allocate memory and clear the memory.

Google's smartphone, os,android, encapsulates the Telephony function as a Java object,telephony Manager. And so on, the GPS function is also packaged as a Java Object,location Manager, in addition to Resource manager and so on. Through these manager Java Object, the function of peripheral hardware (peripheral) is encapsulated, providing a simple calling interface, which reduces the difficulty of application software development and increases the productivity of programmers. It also provides Activity Manager,window manager,content provider,view system,notification Manager, etc. to simplify and standardize the development of the GUI [3,4].

These Java objects run on virtual machine and their memory footprint is regulated by garbage collector, which reduces the risk of memory leaks. In addition, Android assigns individual VM entities to each application, and if an application fails, it causes the VM entities that support it to crash, but usually does not hurt the VM entities running other applications, thereby improving the overall security of the system.

Compared with MFC, Android's application Framework is more convenient and more secure. Of course there is a price, the cost is the loss of operating speed.

Figure 13-3. Android Architecture [4].
Courtesy Http://farm3.static.flickr.com/2713/4497986885_7b1f93c360_o.png

Android's open mechanism is not only reflected in the application Framework, but also in the hardware abstraction Layer (HAL). For the purpose of setting HAL, Google has a three-point description [4],

1. Develop standard drive interfaces for a variety of hardware devices.

2. Since the Android kernel is open source, it is subject to the GPL license. And some hardware device manufacturers do not want to open up their drive program, with the HAL this isolation, you can solve the open source of the kernel and the non-open source hardware drive contradictions.

3. Android has certain requirements for hardware drives.

These three points relate to three participants in the mobile manufacturing industry chain,

1. If there is a standard drive interface, the largest beneficiary is the handset manufacturer. As long as the hardware peripherals manufacturer according to the standard interface to provide the corresponding hardware drivers, handset manufacturers can freely choose a variety of accessories, greatly simplifying the integration of the phone's difficulty and time.

2. There is no need for open source drive programs, the beneficiaries are hardware device manufacturers, and not to the handset manufacturers to create trouble.

3. It's hard to understand what Android requires from a hardware drive and why Android wants to make these demands. To understand the problem, consider an example of how the Android HAL handles telephony.

Figure 13-4 describes the collaboration between the various levels associated with telephony. We care about HAL, named after libraries (User Space) in the diagram, Telephony HAL's internal structure is labeled green, containing two artifacts, Radio daemon and vendor RIL.

1. Radio Daemon, which is provided by Android, does not change with the manufacturer and model of the BP hardware. When Android starts, the Radio daemon is activated and is running until Android shuts down [4].

2. Vendor RIL (Radio Interface Layer). Vendor RIL is provided by some manufacturers of BP, different brands of BP, and different models of BP, binding different Vendor RIL. Vendor RIL The existence form is a function library file, file naming must obey the specification of the contract, Libril-<companyname>-<ril version>.so, convenient radio daemon find available Vendor RIL[5].

When running in real time, the application calls the telephony stack, while the telephony stack instructs Radio daemon to discover the currently available vendor RIL and dynamically load the corresponding. So function library. That is, let radio daemon to achieve the function of hot plug (plug-and-play). The Vendor Ril function library is responsible for the IPC between AP and BP. At this point, from the application software, to the telephony Stack, to the HAL in the Radio daemon and vendor RIL, to the BP part of the hardware and drivers, all through. After the whole line, the application software can handle the call, send SMS and so on communications business [4,5,6].

While figure 13-4 only describes the collaborative relationships between the various levels associated with telephony, the collaboration among the various levels is similar for other functions, such as audio control, power management, and so on.

The implication of Android HAL is that it allows Android phones to add other hardware devices, such as thermometers, to expand the functionality of the phone.

Figure 13-4. Android Telephony system architecture [5].
Courtesy Http://farm5.static.flickr.com/4066/4498024565_4c10a45173_o.png

To summarize, the AP portion of the smartphone is integrated with the BP section, similar to the integration of the common VFS in the file system with the storage device provided by different manufacturers. The BP section provides basic call, data communication, and SIM card functionality. and the AP section around these basic functions, to provide a wealth of services, such as call history, text messages, such as the editing of replies and forwarding and so on. These services are included in the Telephony stack function library.

To facilitate the installation and operation of third-party software, Android provides the application Framework, which, in the form of Java object, encapsulates the functions of the telephony stack function library, GUI functions, and other peripheral hardware devices. The application framework not only reduces the difficulty of developing third-party applications, but also reduces the likelihood of third-party application errors, and reduces the damage to the entire system in the event of a third-party application error.

To facilitate the integration of a wide range of hardware devices, Android provides a hardware abstraction Layer. Similar to the way VFS and storage devices collaborate in file systems, Hal refines the common features that different hardware vendors must provide, including them in generic modules, such as Radio Daemon, which are independent of the brand and model of the hardware. On the other hand, HAL requires hardware vendors to provide a library of IPC functions that conform to the Android specification, such as the vendor RIL, to establish a common module for communication with different brands and models of hardware devices.


Reference,

[1] Introduction to Virtual File System. (Http://en.wikipedia.org/wiki/Virtual_file_system)
[2] Introduction to application Framework. (http://en.wikipedia.org/wiki/Application_framework)
[3] Inside the Android application Framework.
(http://www.slideshare.net/viswanath7/inside-the-android-application-framework-google-io-2009)
[4] The anatomy and physiology of Android.
(Http://www.slideshare.net/viswanath7/anatomy-of-android-google-io)
[5] Android Telephony Porting Guide. (http://www.kandroid.org/android_pdk/telephony.html)
[6] Android Drive development key technology HAL and porting essentials. (Http://www.slideshare.net/pandodo)

On cottage phone and Android "13" SmartPhone AP System