Symbian Platform+overview

Introduction to Symbian Operating System

Introduction Symbian OS was designed from its inception with smartphones as the target platform. It is not a generic operating system shoehorned into a smartphone nor is it an adaptation of a larger operating system for a smaller platform. It is a multitasking and multithreaded operating system. Many processes can run concurrently, they can communicate with each other and utilize multiple threads that run internal to each process. The operating system has a file system compatible with Microsoft Windows (technically, a FAT32 file system); it supports other file-system implementations through a plug-in interface. It uses TCP/IP networking as well as several other communication interfaces, such as serial, infrared and Bluetooth Because of limited disk storage, no virtual memory is implemented. Symbian OS has a pluggable messaging architecture – one where new message types can be invented and implemented by developing modules that are dynamically loaded by the messaging server. Consider the way system calls work in Symbian OS. There are two types of system call. An executive call makes a request for the kernel to execute an operation in privileged mode on behalf of the user-space requestor. An executive call causes a software interrupt, which is serviced by branching the operation into kernel code. The interrupt is serviced and control is passed back to the user. There is a server that protects kernel resources and requests to manipulate those resources need to go through that server. Server requests are themselves executive calls.

•

•

•

•

The kernel structure of Symbian OS has a microkernel design. Minimal system functions and data are in the kernel with many system functions spread out into user-space servers. The servers get their jobs done by making executive calls into the kernel when necessary. Symbian OS supports the use of virtual machines: the implementation of a ‘computer within a computer’. The implementation of the Java programming language and the run-time environment needed to run Java is done through this mechanism. Communication structures in Symbian OS are easily extended. Modules can be written to implement anything from user-level interfaces to new protocol implementations to new device drivers. Because of the microkernel design, these new modules can be introduced and loaded into the operation of the system dynamically. Symbian OS has been designed at its core with APIs specialized for multimedia. Multimedia devices and content are handled by special servers and by a framework that lets the user implement modules that describe new and existing content and what to do with it.

S60

UIQ

UI Framework Layer Uikon

Java ME

FEP Base

CONE

Application Services Layer Messaging, Browsing, Data Synchronization etc. OS Services Layer Generic OS Services

Communication Services Telephony Services

Short Link Services

Networkin g

Multimedi a & Graphics

Base Services Layer Kernel Services and Hardware Interface

Connectivit y Services

Symbian OS Layer by Layer Symbian operating system can be decomposed into layers, and layers as further decomposed into blocks and sub-blocks and finally blocks are decomposed into collections of individual components. Layers are the highest level abstraction in the model; components are the lowest level abstraction, the fundamental units of the model; blocks and sub-blocks decompose layers by functionality – roughly speaking, by broad technology area. The key concepts used by the system model are layers, blocks and sub-blocks, component collections and components. Components provide the essential mapping from the logical model to the concrete system. While layers, blocks and sub-blocks are essentially logical concepts, components are physically realized in software, typically consisting of multiple files in the operating system delivery (e.g. source code files including test code; built executables including libraries; data and configuration files; build files; and documentation). However, from the perspective of the model, components are treated atomically and constitute the smallest units of architectural interest.

UI Framework Layer The topmost layer of Symbian OS, the UI Framework layer provides the frameworks and libraries for constructing a user interface, including the basic class hierarchies for user interface controls and other frameworks and utilities used by user interface components. The UI Framework layer also includes a number of specialists, graphics based frameworks which are used by the user interface but which are also available to applications, including the Animation framework and the Front End Processor (FEP) base framework. The user interface architecture in Symbian OS is based on a core framework called Uikon and a class hierarchy for user interface controls called the control environment. Together, they provide the framework which defines basic GUI behavior, which is specialized by a concrete GUI implementation (for example, S60, UIQ or MOAP), and the internal plumbing which integrates the GUI with the underlying graphics architecture. Uikon was created to support easier user interface customization, including ‘pluggable’ look-and-feel modules.

The Application Services Layer The Application Services layer provides support independent of the user interface for applications on Symbian OS. These services are divided into three broad groupings:

1. System-level services used by all applications, for example the Application 2. 3.

Architecture. Services that support generic types of application and application-like services, for example personal productivity applications (vCard and vCal, Alarm Server) and data synchronization services Services based on generic but application-centric technologies, for example mail, messaging and browsing (Messaging Store, MIME, HTTP Transport Framework).

Applications in Symbian OS broadly follow the classic object-oriented Model–Viewer– Controller (MVC) pattern. The framework level support encapsulates the essential relationships between the main application classes (representing the application data model, the views onto it, and the document and document user interface that allow it to be manipulated and persisted) and abstracts all of the necessary underlying system-level behavior.

The OS Services Layer The OS Services layer is, in effect, the ‘middleware’ layer of Symbian OS, providing the servers, frameworks, and libraries that extend the bare system below it into a complete operating system. The services are divided into four major blocks, by broad functional area: 1. Generic operating system services o Example: Task Scheduler 2. Communications services o Telephony Services o

 Examples: GSM, CDMA, EDGE etc. Networking Services

o

 Examples: TCP/IP Stack Implementation, HTTP, SSL Short Link Services

 Examples: Bluetooth, Infrared, USB, OBEX 3. Multimedia and graphics services o Examples: Window Server which provides Access to screen hardware 4. Connectivity services o Supports Interaction with Desktop Host to:  Perform Data Backup  File Browsing and Transfer  Software Installation from Desktop to Device o Together, these provide technology-specific but application independent services in the operating system. The Base Services Layer The foundational layer of Symbian OS, the Base Services layer provides the lowest level of user-side services. In particular, the Base Services layer includes the File Server and the User Library. The microkernel architecture of Symbian OS places them outside the kernel in user space. (This is in contrast to monolithic system

architectures, such as both Linux and Microsoft Windows, in which file system services and User Library equivalents are provided as kernel services.) Other important system frameworks provided by this layer include the ECom Plug-in Framework, which implements the standard management interface used by all Symbian OS framework plug-ins; Store, which provides the persistence model; and the Cryptography Library.

The Kernel Services and Hardware Interface Layer The lowest layer of Symbian OS, the Kernel Services and Hardware Interface layer contains the operating system kernel itself, and the supporting components which abstract the interfaces to the underlying hardware, including logical and physical device drivers ‘variant support’, which implements pre-packaged support for the standard, supported platforms (including the Emulator and reference hardware boards). In releases up to Symbian OS v8, the kernel was the EKA1 (Kernel Architecture 1) kernel, the original Symbian OS kernel. In Symbian OS v8, the EKA2 (Kernel Architecture 2) real-time kernel shipped for the first time as an option. From Symbian OS v9, EKA1 no longer ships and all systems are based on the real-time EKA2 kernel

Java ME In some sense, Java does not fit neatly into the layered operating system model. Symbian’s Java implementation is based around: • • • •

a virtual machine (VM) and layered support for the Java system which complements it, based on the MIDP 2.0 Profile a set of standard MIDP 2.0 Packages an implementation of the CLDC 1.1 language, I/O, and utilities services a number of low-level plug-ins which implement the interface between CLDC, the supported packages, and the native system.

Key Design Patterns of Symbian Operating System Like any good architecture, the patterns repeat at multiple levels of abstraction and in all corners of the system.

The Client–Server Model Probably the most pervasive architectural pattern in Symbian OS is the structuring client–server relationship between collaborating parts of the system. Clients wanting services request them from servers, which own and share all system resources between their clients. In Symbian OS, all system resources are managed by servers. The kernel itself is a server whose task is to manage the lowest level machine resources, CPU cycles and memory. From the kernel up, this pattern is ubiquitous. For example, the display is a resource managed by the Window Server; display fonts and bitmaps are managed by the Font and Bitmap Server; the data communications hardware is managed by the Serial Server; the telephony stack and associated hardware by the Telephony Server; and so on all the way to the user-interface level, where the generic Uikon server (as specialized by the production GUI running on the final system) manages the GUI abstractions on behalf of application clients.

Asynchronous Services Another widely used pattern is the use of asynchronous methods in client–server communications. Typically, client–server interactions on Symbian platform are asynchronous. System responsiveness in a multitasking system (the impression that applications respond instantly and switch instantly) depends on asynchronous behavior; applications don’t wait to finish processing one action before they are able to handle another. The alternatives are blocking, or polling, or a combination of both. In a blocking request (the classic Unix pattern), the calling program makes a system call and waits for the call to return before continuing its processing. Polling executes a tight loop in which the caller checks to see if the event it wants is available and handles it when it is. (Polling is used by MS-DOS, for example, to fetch keystrokes from the keyboard.) Blocking is unsatisfactory because it blocks others from accessing the system call which is being waited on, while it is waiting. Polling is unsatisfactory because code which is functionally idle, waiting for an event, is in reality not idle at all, but continuously executing its tight polling loop. Blocking reduces responsiveness. Polling wastes clock cycles, which on a small system like mobile phones translates directly to power consumption and battery life.

The Plug-in Framework Model

The plug-in framework model is used pervasively in Symbian OS, at all levels of the system from the UI Framework at the top to the lowest levels of hardware abstraction at the bottom. A framework is an enclosing structure. A plug-in is an independent component that fits into the framework. The framework has no dependency on the plug-in, which implements an interface defined by the framework; the plug-in has a direct, but dynamic, dependency on the framework. On a small scale, this is what designing with classes achieves: a class abstracts an interface and its expected behavior encapsulates its implementation. Frameworks provide a mechanism for this kind of abstraction and encapsulation at a higher level.

A framework in Symbian OS defines an external interface to some part of the system (a complete and bounded logical or functional part) and an internal plug-in interface to which implementers of the framework functionality (the plug-ins) conform. In effect, the framework is a layer between a calling client and an implementation. In the extreme case, a ‘thin’ framework does little more than translate between the two interfaces and provide the mechanism for the framework to find and load its plug-ins. A ‘thicker’ framework may do much more, providing plug-in interfaces which are highly abstracted from the external visible client interface. Symbian OS contains frameworks at both extremes and most points in between. Because in Symbian OS a framework exposes an external interface to a complete, logical piece of the system, most frameworks are also implemented as servers. The plug-in model is used to structure the internal relationships within complex parts of the system, to enable flexibility and extensibility. Flexibility in this context means runtime flexibility and is particularly important when resources are constrained. The ability to load the requested functionality on demand enables more efficient use of constrained resources (objects which are not used are not created and loaded). Extensibility is important too in a broader sense. The use of plug-ins enables the addition of behavior over a longer timescale without re-architecting or re-engineering the basic design.

As well as providing interface abstraction and separation from implementation, and flexibility through decoupling, frameworks also provide a natural model for functional extension. This approach is used for example by the telephony-server framework to provide an open-ended design. The core framework supports generic telephony functionality based around a small number of generic concepts. Framework extensions implement the specialized behaviors which differentiate landline from mobile telephony, data from voice, circuit- from packet-switched, GSM from CDMA, and so on.

Symbian OS Kernel The real-time architecture is essential for a system implementing a telephony stack, which depends on critical timing issues, and is also becoming increasingly important for fast, complex multimedia functionality. Together, phone and multimedia are

arguably the most fundamental drivers for any contemporary operating system. As mobile phones, in particular, reach new levels of multimedia capability, to become fully functional converged multimedia devices (supporting streamed and broadcast images and sound, e.g. two-way streaming for video phone conferencing and interactive broadcast TV), achieving true real-time performance has become an essential requirement for a phone operating system. The real-time kernel allows Symbian OS to meet that requirement. The real-time kernel architecture also introduces important changes (in particular to mechanisms such as interprocess communication) to support the new platform security model introduced from Symbian OS v9.

UI Platforms Symbian OS is an inherently GUI-centric operating system which ships without a GUI of its own. Moreover it targets a market (wireless devices generally and mobile phones in particular) in which the user interface is a critical competitive element. User interface issues are particularly interesting because they highlight many of the unique problems of the mobile phone market Symbian supports (but does not provide itself) multiple UIs. Licensees either buy in the platform pre-integrated and tested from a Symbian OS UI vendor such as S60 or UIQ or they buy in the operating system ‘headless’ and develop their own GUI. The Symbian operating system does not provide the UI layer; instead it provides the infrastructure (frameworks and primitives) for UI creation. Beneath the UI, the common frameworks and the underlying services of the operating system itself ensure substantial platform compatibility at the application-engine (i.e. applicationlogic) level. Indeed applications can be targeted at the different available user interfaces by customizing the application UI without changing the application engine. A Symbian licensee either creates a bespoke user interface from the frameworks (although this is not a trivial engineering effort, it is the option chosen by DoCoMo in Japan for its FOMA platform, for example) or buys in a UI from a specialist vendor (UIQ and S60). Symbian OS on a Sony Ericsson phone or a Motorola phone with the UIQ GUI – the P910 or P990, say, or the Motorola A1000 – looks and feels very different to Symbian OS on a Fujitsu or Mitsubishi FOMA phone or to Symbian OS on a Nokia, Samsung or LG phone with an S60 GUI. And yet the underlying operating system is the same and the very same applications can run on all of these different phones, sharing identical source code at the application-logic and data-model levels. While Symbian OS is tightly integrated to the GUI which runs on top of it, by way of the UI and application frameworks, it is designed to be GUI-neutral. For application developers and from the application perspective, although Symbian OS applications are intrinsically GUI in nature, applications are only loosely coupled to a particular GUI variant, since the application model and the application-event loop are enshrined in the operating system itself and in the UI Framework support, and not in the variant user interface.

References • •

The Symbian OS Architecture Sourcebook by Ben Morris Smartphone Operating System Concepts with Symbian OS by Michael J. Jipping