Symbian Operating System Architecture

The Symbian operating system is composed of a set of layers. Most prominent logical layers of the operating system include User Interface Framework, Application Services, Operating System Services, Base Services, and Kernel Services and Hardware Interface. The Figure 3.1 shows stack of Symbian operating system layers. Symbian operating system has headless configuration i.e. minimal user interface features are supported by core operating system. Therefore, third parties have developed user interface layers on top of core Symbian operating system, depicted in Figure 1 as top most layers. These third party libraries include S60developed by Nokia, UIQdeveloped by Sony Ericsson and MOAP developed by NTT DoCoMo. User applications reside typically on top of S60, UIQ or MOAP. Java Micro Edition libraries exist as separate component in the operating system. Figure 3.1: Symbian OS Layered Architecture [1] Symbian OS layers are further divided into blocks and sub-blocks. Each block and sub-block is a collection of individual components. Thus, a layer is the highest level of abstraction, while a component is a lower level of abstraction. Components are physical realization of more logical concepts such as layers and blocks. Components consist of software code including source code, executables, libraries, and documentation. Each layer abstracts the functionality of layer below it and provides services to layer above it. The level of abstraction increases as we move up from the hardware (at the lowest level) to the user interface (at the highest level). While layers provide a basic categorization of OS services, blocks and sub-blocks correspond to specific technology domains. Each block consists of a collection of components that provides a set of related services. For example, The OS Services layer contains a Communication Services block which is further decomposed into Telephony, Short Link and Networking Services sub-blocks. Localization of Mobile Platforms 14

The following sections briefly describe Symbian OS layers and their basic functionality. All Symbian OS releases from v7.0 to v9.3 have the same layer decomposition. User Interface (UI) Framework Layer The top most layer of Symbian OS provides libraries and framework for constructing a graphical user interface. This layer includes class hierarchies of user interface controls and concrete widget classes. Third party graphical user interface libraries such as S60 and UIQ have been built by extending the functionality available in user interface framework layer. User Interface Layers on Symbian OS User interface framework is the topmost layer of Symbian OS. It provides the framework support on which a production user interface is built. The three currently available custom user interfaces are S60, UIQ and MOAP. S60 S60 platform is developed and licensed by Nokia. It supports touch screen, keypad, 5-way navigator, soft keys. Lenovo, LG, Panasonic and Samsung have also shipped S60 enabled phones by licensing S60 from Nokia in the past [1]. In the past, S60 has been shipped in various versions such as 1st, 2nd, 3rd, and 5th editions. After S60 5th edition, Nokia has shipped S60 and Symbian as one open source package under the umbrella of Symbian Foundation and various versions of packages have been named Symbian^1, Symbian ^2, and, more recently, Symbian ^3. UIQ (User Interface Quartz) UIQ was developed and licensed by UIQ Technology owned by Sony Ericsson. It is most commonly used on Sony Ericsson's P series of smart phones, such as the P990. Other devices shipped with UIQ include Sony Ericsson P990, W950 and W960i. UIQ, however, has not been made part of latest breed of Symbian operating system versions i.e. Symbian ^1 and later editions. MOAP (Mobile Oriented Application Platform) MOAP has been developed by FOMA (Freedom of Mobile Access) consortium in Japan. It is a proprietary platform used only by NTTDoCoMo (i.e. not licensed to others). Application Services Layer This layer provides application support independent of user interface layer. Application services are broadly classified into three main categories: 1. System level services that provide basic application framework support to all applications, 2. Technology-specific services such as multimedia, telephony, mail, messaging, and browsing, 3. Services that support generic types of applications such as Personal Information Management (PIM) and Alarm Server. 15 Symbian Operating System Architecture

OS Services Layer This layer acts as a middle-ware between the base services layer at a lower level and the application services layer at an upper level. The services provided by this layer can be divided into four broad categories: 1. Generic operating system services such as task scheduler. 2. Communications services such as telephony, short-link services, and network services. 3. Multimedia services such as windows server, font server, and multimedia framework. 4. Connectivity services such as services for interaction with desktop for file browsing and services for software installation. Base Services Layer The base services layer serves as the user side of the two-layer Symbian OS base system. It encapsulates servers, libraries and frameworks that are built on the kernel layer in order to provide upper layers basic operating system services such as file server, basic programming library, persistence model and cryptography library. Kernel Services and Hardware Interface Layer The lowest layer of the Symbian operating system contains the operating system kernel and includes components that interface with underlying system hardware. It includes logical and physical device drivers, scheduler and interrupt handler, timers, mutexes etc. In order to port Symbian OS to a new hardware, kernel layer is customized. Java Micro Edition (Java ME) Java ME has been built into Symbian operating system as a separate component and it interacts with multiple system layers. It contains MIDP and CLDC libraries, Java Virtual Machine (JVM) and plugins for interaction with native operating system layers.

3.1 Overview of Key Design Patterns

Symbian OS architecture has been structured around a number of design patterns. Some key design patterns are described below: Microkernel The Symbian OS kernel is a microkernel; core services that are generally part of the operating system in a monolithic architecture have been moved outside the kernel. All file system services, communication services (including networking) and window services execute at the user side. Therefore, this design places minimum responsibilities on the kernel. Localization of Mobile Platforms 16

Client-Server Relationship between System Components All system resources are managed by servers in Symbian OS. The system kernel itself is a server that manages CPU cycles and memory. This pattern is observed throughout the system from lower to higher layers. For example, display is managed by the Windows server, display fonts and bitmaps are managed by the Font and Bitmap server, file services are managed by the File server, data communication hardware is managed by the Serial server, etc. Clients request services from the servers, which own and share resources among multiple clients. Clients and servers reside on same devices but run in their own separate processes in separate memory segments. Pervasive Asynchronous Methods in Client-Server Communication In asynchronous processing, a client requests the services of a server by issuing asynchronous requests, i.e. the requesting function does not block after issuing a request. The server informs the client when the service request is complete. Asynchronous services are used throughout Symbian OS, most commonly in communication between client applications and system servers. Event Based Application Model User interaction is captured as events. All events are sent to the event queue and event queue is responsible for delivering the event to target application. Plug-In Framework Model (ECOM) ECOM enables extension of the Symbian OS. Additional components such as device drivers and font rendering engines can be plugged into the system without recompiling the system code. Plug-ins are independent components that can be integrated into the system framework. The plug-in framework allows plug-ins to register their availability as accessible modules. The framework acts as an enclosing structure for plug-ins i.e. applications request for certain plug-ins and framework loads the requested plug-ins. This provides both extensibility and flexibility in Symbian OS. Flexibility allows loading functionality on-demand and extensibility allows addition of new behavior in the operating system without re-engineering it. Threads and Processes Symbian OS supports both multi-threading and multi-processing. Threads are units of execution which the kernel scheduler runs. Processes are collections of one or more threads sharing the same heap memory, but having different stacks. Servers and clients run in their own separate processes in Symbian OS.

3.2 Application Development Concepts Unique to Symbian OS

Symbian OS introduces some development idioms that are unique to Symbian applications. These are discussed in detail in the following sections. 17 Symbian Operating System Architecture

Exception Handling Exceptions are run-time errors that may be caused by conditions such as out of memory, loss of connectivity, disk full, unavailability of file system when a removable media card is removed or loss of power. These are all likely occurrences in a resource-constrained environment such as of mobile phones. In Symbian, Leave-Trap exception handing mechanism has remained most dominant and is still being used by many applications. In newer versions, Symbian operating system supports standard C/C++ exception handling mechanism (i.e. try-catch mechanism). In traditional Symbian OS, exceptions are characterized as leaves. A leave is a call to the function User::Leave(), and it causes program execution to return immediately to the trap harness within which the function was executed. By convention, all leaving functions are superseded by the letter L. When a function has such a suffix, it can return a special error state that will propagate the need for return. This error state is captured using a trap harness. For example, a leaving function can be declared as follows. void AllocateMemoryL() { //Allocate some memory here } To catch the leave, a trap harness can be setup as using the TRAP or TRAPD. TRAPD(error, AllocateMemoryL()); if (error!=KErrNone){//Do some error coding}