Maemo is based on Debian GNU/Linux operating system which itself inherits its architecture from the Unix operating system. Linux, GNU and Debian are open source projects (or project umbrellas for multiple separate projects) which embrace sharing of source code, collaboration and open development model. Maemo promotes these values as well by providing an integrated open source based platform for mobile devices, by sharing source code, and by contributing code directly to the upstream projects.

This document assumes that the reader knows the basic architecture of a Linux system. There exists a lot of other documentation regarding Linux kernel, the design philosophy of Unix, the GNU project, Debian etc. so we do not repeat that information in this document. In addition, we expect the reader to understand the basic GNU/Linux/Unix terminology like what is a shared library, daemon process, file system, or shell, for instance.

Key Technology Selections

Key Components

Maemo is based on the Linux operating system kernel. Linux is a monolithic kernel that supports multiple hardware platforms and is scalable to be able to support wide range of different kinds of devices from wrist watches to large server systems. Currently all maemo based devices have OMAP chipsets which contain a general-purpose ARM processor and a DSP unit. Maemo devices run recent 2.6 kernels.

The user space software links with the standard GNU C library interface. The GNU C library comes with all major Linux distributions except some minimalistic embedded systems which use some other size optimized C library (like uClibc). The GNU C library aims at POSIX compatibility and maemo aims at being compatible with mainstream Linux systems as much as possible to minimize the effort of porting applications and application engines and to bring in the best open source solutions for mobile computers.

The package management framework, the file system hierarchy, and general design policies come from the Debian distribution. Maemo aims at following Debian policies as much as possible. Debian distribution has by far the largest development community; in September 2007 Debian supports about a dozen different hardware architectures and it has more than 18,000 software components available.

The user interface architecture is based on GNOME framework, GTK+ widget set especially. GNOME is a leading application framework for desktop Linux systems. Unlike its competitor KDE, GNOME allows building proprietary software on top of its core libraries without any license payments. From GNOME project maemo has inherited many central components including GTK+, GStreamer multimedia framework, GConf configuration management, and XML library, for instance. Maemo extends GTK+/GNOME by providing the Hildon extensions for a mobile desktop.

Development Environment

The cross-compilation environment of maemo is based on Scratchbox. Cross-compilation is a problematic issue in Linux systems, since build scripts typically utilize Autotools which have not been designed well for cross-compilation in mind. Thus, many Linux distributors solve the cross-compilation problem by avoiding it, and use dedicated hardware to run native compilations. This is a big limitation since sometimes native hardware build environment is difficult to arrange. And even if it were available builds run typically multiple times slower than in cross-compilation. Scratchbox solves this problem problem by totally isolating the target and host environments. Autotools based build scripts can be run on Scratchbox without modifications to build target platform binaries on a host system having a hardware platform other than the target.

Official maemo APIs are provided for the C language. Maemo also has C++ and Python bindings for its core APIs. Other unofficial bindings for other languages and environments exists.

Software Layers

In this chapter we shortly describe the software layers. The more detailed picture is given in the next chapter (The Software Decomposition View).

Operating System Layer and Bootup

The bootloader takes care of some hardware specific initializations and then loads the operating system kernel during the early stages of the boot up process. Maemo systems are based on Linux 2.6 operating system. At the last state of the kernel boot process the InitFS is mounted (a small JFFS2 file system image). It is used during the boot time as the root file system and in the normal device operation it is mounted into /mnt/initfs. The final root file system is on a JFFS2 image which is mounted after the InitFS boot scripts are done.

Applications on the InitFS are linked with uClibc, a minimal version of the C library in order to reduce space. The Device State Management Entity (dsme) is also located in the InitFS. The existance of the dsme daemon is vital so it is used to ping the hardware watchdog as well.

The Linux kernel is the central software component of the system. It provides the hardware abstraction layer for the system devices, memory management, process management, networking services including link and transport layer protocols like TCP/IP, file managment including file systems and various other services.

Parts of the kernel functionality can be implemented into dynamically loadable kernel modules. A kernel module can be loaded or removed during runtime. Kernel functionality like device drivers, network protocols, or file systems can be implemented into kernel modules.

The ARM/OMAP based Linux kernel on maemo devices implement hardware specific several device drivers and bus drivers on top of the core kernel's virtual services. The device drivers include USB, LCD, WLAN, Camera, and Audio, for instance. The bus drivers include Flash bus, SPI, I2C, and serial bus, for instance.

System Libraries

Maemo is based on the standard GNU C library. There exists the Standard C++ library as well. For networking there exists OpenSSL library that provides network security and libcurl that provides the HTTP access for applications.

For hardware abstraction, maemo provides HAL Hardware Abstraction Layer. It provides a shared library that has an API for device objects. A device object has properties and it is up to an actual device driver which properties it supports. HAL is thus capable of loading the right device driver when a new device is detected, creating and maintaining /dev files, tracking the status of devices and providing a means to uses each device.

System Services

The primary communication channel between applications is DBUS. DBUS also provides a channel for interaction between system and applications. DBUS is also used to invoke all the applications by sending messages.

The system provides an SQL database, SQLite 3, that can be used to store user application data. SQLite database is accessed through a library interface; there is no centralized server process to connect into.

Hildon Framework

The user interface is based on X Window System having Matchbox window manager. The application programming API on top of X is GTK+ widget toolkit with Hildon extensions. GTK+ is the UI framework of GNOME project as well. Other GNOME components have also been included in maemo, like GConf application configuration management, XML library, GnomeVFS, Evolution Data Server for address book and calendar management, GSF structured file streaming, and SVG (Scalable Vector Graphics). The multimedia framework is also the same, GStreamer based.

Hildon framework provides components on top of the GNOME components to support control panel, status bar, task navigator, and home applets. Hildon framework also provides backups / restore service, help framework, and an application installer.

Applications

The applications are build on top of the Hildon framework. Simple applications link just with Hildon libraries, GTK+, Glib, and libosso in order to use the graphical user interface elements. More complex applications use other services according to their needs, for example, they link with GStreamer for multimedia access and libcurl for HTTP access.

Software Decomposition View

Software Components

The main components of maemo are presented in the table below. Just click on any component to read more details. The component division does not map one to one on the actual package division since some abstraction has been added. In addition, the layers in the picture do not mean actual package dependencies from an upper layer to a lower layer although some correlation to the actual dependencies do exist (like none of the components below GTK+ depend on it).

Applications
Fonts		Sounds			Icons
Connectivity		System UI	Search	Text Input		MIME Types
Home Applets		Control Panel		Task Navigator		Status Bar
Backup		Installer	Alarm	Help		Launcher
XML	E-D-S		Telepathy		GConf
GStreamer		GnomeVFS				GSF
Sapwood		Hildon Widgets		Hildon File UI		HTML Widget
GTK+
GDK				GdkPixbuf
Pango		Cairo			Atk
GLib				GObject
Samba	GPS	Obex	ConIC	UPnP	JPEG PNG TIFF SVG	Matchbox
D-BUS		HAL	SQLite	curl HTTP	Clipboard
SSL	System SW		Cert. mgnt	libosso	X
Libstd C++		Compression	dpkg	apt	Freetype	Fontconfig
Sysvinit	Base Files	Busybox	GNU C Library	Core Libs	Core Utils	Core Daemons
BlueZ		Power Management		WLAN security	ALSA	Video4Linux
Bootloader		Linux kernel including JFFS2 , TCP/IP				InitFS including uClibc dsme

The components marked with yellow color are provided as binary only in general (some subcomponents in them may be provided with source code though), others come with source code as well. Some specific applications, however, are provided with source code. Some maemo specific components are described in more detail below.

Maemo Connectivity Subsystem

The maemo Connectivity subsystem is implemented by using known Linux conventions. It resides in the user mode area of Linux and relies on Linux kernel through standard C libraries. Wireless LAN is the main channel to the Internet but dial-up connections through cellular networks are also supported. The only medium to the phone is Bluetooth. The Bluetooth software of maemo is based on BlueZ, which is known as the de-facto implementation of Bluetooth for Linux. D-Bus is used for internal application level message exchange.

Components of the maemo Connectivity Architecture include:

Maemo connectivity UI - User Interfaces parts of the connectivity. This includes Connection manager, Control panel applets and several different dialogs.
Maemo connectivity daemon (ICd) - LibConIC API works together with ICd which handles all Internet Access Points (IAPs). IC daemon handles both WLAN and Bluetooth connections.
OBEX wrapper - Interface to OBEX services. The primary target user of this library is the OBEX gnome-vfs module.
OpenOBEX - Open source implementation of the Object Exchange (OBEX) protocol. See more information about OpenOBEX from: http://triq.net/obex/
BlueZ Bluetooth stack - The de-facto implementation of Bluetooth for Linux. See more information about BlueZ from: http://www.bluez.org
BlueZ D-Bus API - BlueZ accepts commands via D-Bus.
WLAN connectivity daemon - The daemon which controls WLAN connections.
WLAN device driver - Device driver for Wireless LAN (IEEE 802.11g). Kernel driver is composed of two parts, a binary part (closed source) and an open source wrapper, which binds the binary to current Linux kernel.

Maemo System User Interface

System UI contains two parts. One is the System UI itself and the other one is System UI plugins.

System UI provides main application for system UI plugins including responsibility of plugin loading and unloading.
System UI plugins provide user interface to power key menu, splash screen, alarm, device lock, touch screen, keypad lock and mode change.

Maemo Global Search

Maemo Global Search component provides the search framework for maemo.

Maemo Text Input Methods

Embedded devices have special needs for text input. This framework provides the text input methods.

Hildon Home Applets

Home applets (also called as plugins) are small applications on the main window. They can provide online wether information, for instance, or a view to latest news titles.

Hildon Control Panel

Hildon control panel is the standardized place for put settings changeable by the end users for applications, servers etc. in the system.

Hildon Task Navigator

Hildon Task Navigator provides the menu for switching between applications. To make application visible in Hildon Task Navigator it needs a Desktop file for the application. This file contains all the essential information needed to show the application entry in the menu, like name, binary and D-BUS service name. Name of the file should be [application].desktop and location in filesystem “/usr/share/applications/hildon/”.

Hildon Status Bar

Status bar is a UI component that displays the status of various system tasks with a small icon image on the main window. The maemo status bar can contain user defined items as well. Normally there's places for two of these additional items. These two slots are used by usb connection indicator and alarm indicator, but can be used by any plugin. Although plugins can specify a priority the current version of status bar doesn't handle the plugin priorities, so only the two newest plugins are visible.

MIME Type Registery

This component provides the MIME type registery.

Maemo Backup

The maemo backup application saves and restores user data stored in ~/MyDocs (by default) and setting directories/files /etc/osso-af-init/gconf-dir (a link to GConf database /var/lib/gconf), /etc/osso-af-init/locale, and /etc/bluetooth/name. It can be configured to back up other locations and/or files as well by custom configuration files.

The backup application must not to be distrupted by other applications writing or reading during a backup or restore operation. For restore process, Backup therefore will, if the user approves, ask the application killer to close all application, and then wait until it has been done. For backing up, the backup_start and backup_finish D-BUS signals will be emitted on the session bus, which will indicate to applications that they should not write to disk.

Maemo Installer

Maemo installer is an application that is capable of managing application installations and upgrading. The architecture underneath is based on dpkg and apt.

Maemo Alarm Framework

The alarm framework provides mechanism to manage timed events. Timed event functionality is provided by the alarmd daemon. It makes possible for applications to get D-Bus messages or exec calls at certain times.

Packages included in the subsystem are:

libalarm
alarmd

Maemo Help Framework

The Help Framework is a centralized way to offer the user help services for your program. Maemo platform has inbuilt help system that handles all help documentation for the programs using the Help Framework. You only make use of the libraries that register your program to the Help Framework, and write the content of the actual help documentation. An ID tag will be given to the help file, which will be in XML format. This way you can control which help file will be loaded, when user asks for help, just by calling the right help content ID. When using the Help Framework, the help documentation for your program will also be available when using maemo Platform Help application.

Maemo Launcher

Maemo launcher launches all applications on the maemo platform. It is there to speed up application startup by sharing some of the initialization data of an application startup. Maemo Launcher is composed of two parts: (i) the maemo-invoker, which is executed by D-BUS daemon or scripts to start the given (application) service, and (ii) maemo-launcher, a server that has initialized most of the data used by the applications.

The maemo-invoker asks maemo-launcher to start the actual application. Use of maemo launcher requires that application is compiled as a shared library. There's a set of helper Debian package rules which make an application to “automatically” use maemo-invoker when given suitable build options. As a result, the application binary name is linked to maemo-invoker and application (library) binary name has .launch extension. By default the invoker will wait until the maemo-launcher tells it that the application has exited so that it can return the correct return value for the caller.

The maemo-launcher is a server process that has initialized most of the data used by the applications, such as Glib types, Gtk theme and some Gtk widget classes. When it's asked by maemo-invoker to start an application, instead of executing the application binary, it will dl-load that as a shared library, fork and call main(). With fork, the initialized data is handled as copy-on-write, i.e. shared until it's modified. If the application exits abnormally, maemo-launcher notifies Desktop so that Desktop can inform user about it.

Because prelinking doesn't work with dl-loaded libraries, maemo Launcher cannot speed up starting of applications where library linking has larger effect on the startup time than AF library initializations. It can still save memory though.

Sapwood

Sapwood provides a server and client library to accessing theme images. The server is responsible of loading the theme related images and distributing them to clients. Sapwood saves memory compared to Pixbuf engine which does not share the bitmaps between applications. Sapwood is also much faster because it tiles the 16-bit images using X server whereas pixbuf engine scale the 24/32-bit on the client side and then converts them to 16-bit for X server for blitting. This means that Sapwood is several times faster:

Bilinear scaling -> tiling = much faster
Scale+blit -> tile = 2x faster
24/32-bit -> 16-bit = 1.5/2x faster
24/32 to 16-bit conversion on blit -> doing it only first time = ~2x faster

Hildon Widgets

Hildon widgets provide many GUI extensions over GTK+ standard widget set. These include application widgets (like HildonApp, HildonWindow, and HildonProgram), selectors (like HildonCalenderPopup), editors (like HildonRange), notifications (like HildonBanner) etc.

Hildon File UI

This package provides the graphical user interface widget for accessing file system.

LibOSSO

LibOSSO is a shared library containing required and helpful services for maemo applications to integrate them better with the platform.

System Software

System Software subsystem provides system wide services to applications and users. The services include device state management (dsm), mode control (mce), battery management (bme) and few graphical user interface elements to manage the behaviour of the services.

More detailed description of the components:

Device State Management: Responsible for managing the states of the device including shutdown and startup. In addition, dsm is responsible for keeping the device running and operational. This is achieved by monitoring the status of critical processes such as D-Bus, X11 and Window Manager. Finally, dsm is responsible for tracking inactivity and based on that initiating power saving operations (turn off screen).
Mode Control: Provides interfaces for controlling of device modes, such as offline mode (disabling of Bluetooth and/or WLAN), and various system level user interfaces, such as device lock, touch screen and keypad lock, LEDs, etc.
Battery Management: Responsible for battery voltage monitoring and recognition, battery charging, and charger recognition.

Power Management

The Power Management (PM) framework revolves around the concepts of dynamic tick, OS idle, clock framework and DVFS. PM framework can be divided into two independent mechanisms - OS idle and DVFS.

OS idle is based on the operating system scheduler. Whenever the scheduler has no tasks to perform it calls the idle function. The idle function can then choose to shutdown all or parts of the hardware and thus save power. The level of power savings dependes on the clock and voltage resources in use.
DVFS allows to scale down the SoC’s frequency and voltage at runtime to reduce leakage currents and hence save power. The decision to scale the frequency (and consequently voltage) of the ARM and DSP processors is based on the load on them.

OS-idle and DVFS are triggered independently of each other. DVFS is triggered based on increase or decrease of required processing power while OS-idle it triggered by the Linux scheduler.

Currently the suspend and resume functionality provided by Linux Driver Model is not used. Also, the kernel level power management does not get any guidance from the user space.

Clipboard

In maemo there are number of clipboard enhanchements to the X clipboard and Gtk+, in order to able to

Support retaining the clipboard data when applications that own the clipboard exit.
Be able to copy and paste rich text data between Gtk+ text views in different applications.
Provide a generally more pleasant user experience; make it easy for application developers to gray out "Paste" menu items when the clipboard data format is not supported by the application.

Compression

This subsystem provides various libraries and utilities for general purpose data compression and uncompression. The supported compression algorithms include the Lempel-Ziv (gzip) used in zip and PKZIP as well. Supported compression formats include:

ConIC

ConIC provides an interface for manipulating and using Internet access points (IAPs) and IAP connections.

Certificate Manager

The maemo platform offers an API to deal with certificate manager storage and handling. This enables every piece of software to have access to all certificates, so that, for example, installing a new CA certificate takes immediate effect in all relevant programs (such as Web browser, e-mail, VPN and wireless connection). This saves effort and disk space.

Core Libraries (other than listed explicitly)

This subsystem provides various shared libraries.

Packages include

acl (access control lists)
expat (XML library)
gettext (internationalization management)
libart (vector based graphics API)
libelf (ELF format)
libfontenc
libgcrypt11
libusb (Universal serial bus)
popt (command line argument parsing)
ncurses (included to improve SW compatibility)
readline (included to improve SW compatibility)

Core Utilities (other than listed explicitly or in Busybox)

Command line tools include the following packages

debconf
defoma
dnsmasq
dosfstools
e2fsprogs
ifupdown
netbase
net-tools
tar
util-linux

Core Daemons (other than listed explicitly)

Daemons are server processes to perform specific tasks. Most of the daemons like dbus-daemon are described separately so this subsystem presents the misc. daemons.

Packages include

sysklogd (system message log)

Base Files

This subsystem delivers the basic filesystem hierarchy of a Debian system as well as the master copies of user database files (/etc/passwd and /etc/group) containing the user and group IDs.

Packages include

base-files
base-passwd

The Flash Partitioning

There exist four separate flash partitions on a maemo based device. The partitions are

Bootloader partition
Kernel partition
Init file system (on a small JFFS2 partition)
Root file system (on a JFFS2 partition)

The root file system thus contains all the components of the component decomposition table other than the lowest layer.

Essential Packages and the Delta to Standard Debian Systems

The core distribution is Debian based having tools like dpkg and apt for installation package management. Also sysvinit, base-files and base-passwd are included from the list of Debian Etch essential packages. A couple of differences to standard Debian exists, however. One is the replacement of Bash and coreutils with Busybox, an optimized command line tool set and shell for embedded devices. There is no bsdutils package as such but Busybox provides logger and renice utilities (script, wall and scriptreplay are missing). Diff has also been left out as well as e2fsprogs and ncurses packages. The size reduction just from the utilities and libraries is about 2.5MB and an additional 1.5MB from replacing Bash.

Secondly, there is no Perl in the system. It has been left out from the standard maemo environment to save space but can be installed separately by the user. In addition, note that there is no cron daemon. With Perl and Bash also removed the size reduction is about 6MB. The following table summarizes the the differences. Package Maemo Debian base-files included included base-passwd included included dpkg included included sysvinit included included awk in Busybox included bash in Busybox included coreutils in Busybox included debianutils in Busybox included findutils in Busybox included grep in Busybox included gzip in Busybox included hostname in Busybox included ifupdown in Busybox included login in Busybox included module-init-tools in Busybox included mount in Busybox included net-tools in Busybox included procps in Busybox included sed in Busybox included tar in Busybox included util-linux in Busybox included vi in Busybox included bsdutils logger and renice in Busybox, script, wall, scriptreplay missing included diff -- included e2fsprogs -- included mktemp in Busybox included ncurses-base -- included ncurses-bin -- included perl-base -- included sysvinit-utils last, mesg, pidof in Busybox, lastb, killall5, sulogin missing included Also note that Busybox may not support all command line options of the standard tool even though the tool is included. Check out Busybox manual for more details.

Run Time View

Overview

User starts applications primarily from the Task Navigator, but they can be started also from the Status Bar (e.g. connection manager), from File Manager to view a file, or from other applications (e.g. for “Send as E-mail” functionality).

To conserve memory, only single instance of an application can be running at the same time. If application is already running, it will only receive a message about the new invocation, such as “open file 'foo'” and top itself. User can switch to another, already running application either by using the Task Navigator UI, or by closing the topmost application.

Because device doesn't have enough memory to run all the applications at the same time, system may kill an application in the background that has indicated itself to be killable. Applications exit when users closes them from the application UI, or when system requests that.

Components

Components involved in the application life cycle management and switching are following.

Task Navigator

Task Navigator (TN) is used to:

List all the device applications in the Others menu so that user can launch them
Launch applications. See the section on launching applications
To background kill applications that have set themselves as killable, when system indicates that it's in the low memory state.
List all the running and background killed applications. Latter appear to user as they were still running
Switch between already running applications or to a background-killed application. This is done either by:
- requesting window manager to top the application window, or
- sending the application a message requesting it to top a particular window view, or
- re-starting the application in case it was background killed

D-BUS Session Bus

Each application in the device has a well-known name. E.g.: “Browser” or “Email”. The application name uniquely identifies the application. There’s a D-BUS service for each application, derived from the application name.

Applications are executed (activated) by the D-BUS session-bus daemon. If not running, an application is implicitly activated when a message with auto-activation flag is sent to the corresponding service. D-BUS gets the binary name to execute from the corresponding D-BUS .service file. The (activation) message may also contain parameters for the application, e.g. the name of a file to open in the application. D-Bus activation guarantees that at most one instance of the application is running at a time.

If the service doesn't register within given timeout, D-BUS assumes that the service (application) process startup failed and it will kill the started process.

Maemo Launcher

Maemo launcher exists to speed up application startup and to be able to share some of the data initialized at application startup. Maemo Launcher is composed of two parts: maemo-invoker: executed by D-BUS daemon or scripts to start the given (application) service. This asks maemo-launcher to start the actual application. Use of maemo launcher requires that application is compiled as a shared library. There's a set of helper Debian package rules which make an application to “automatically” use maemo-invoker when given suitable build options. As a result, the application binary name is linked to maemo-invoker and application (library) binary name has .launch extension. By default the invoker will wait until the maemo-launcher tells it that the application has exited so that it can return the correct return value for the caller.

maemo-launcher: a server that has initialized most of the data used by the applications, such as Glib types, Gtk theme and some Gtk widget classes. When it's asked by maemo-invoker to start an application, instead of executing the application binary, it will dl-load that as a shared library, fork and call main(). With fork, the initialized data is handled as copy-on-write, i.e. shared until it's modified. If the application exits abnormally, maemo-launcher notifies Desktop so that Desktop can inform user about it.

Window Manager

Matchbox window manager takes care of handling the window switching and window stacking. See window management section for more information.

Application activation

User starts applications from the Task Navigator. Task Navigator starts the applications by sending a D-BUS message to the application service with the D-BUS auto-activation flag set.

Applications can also be started implicitly when other applications send them D-BUS messages, e.g. to open a mime-type that application has registered to the MIME database.

Places where different applications get the (application) D-BUS service names:

Task Navigator: Service name is specified in the application .desktop file along with the(localized) application name and its icon
File Manager and Browser: service name is retrieved from the gnome-vfs mime-type-handler application registry through libosso-mime library
Other applications use the service application API libraries. The libraries know which service the service application implements/registers to D-BUS

D-BUS daemon looks into application .service file to know how to execute the application before delivering the message. Applications launched by the D-BUS daemon will only have one instance of them running, because D-BUS does not allow the same service name to be registered by more than one process. Applications should not care whether the recipient of their message on D-BUS is running or not, they should just send all messages with the auto-activation flag to cause automatic activation of the recipient when it is not running.

Note that using the auto-activation flag is not always desirable, e.g. when asking the application to shut down; thus the application framework does not force using the flag. An activated application will automatically appear on the foreground.

Task Navigator supports also executing the application directly if the application D-BUS service name is missing from its .desktop file. This way the launched application does not need to know about D-BUS or Libosso at all, so any unmodified Open Source program that has a .desktop file can be launched this way. Single instance is not guaranteed for applications started like this.

Application can use maemo Launcher to speed up it's startup. Figure 2 shows how this happens in practice. Figure 2: The processes involved with different application invocation methods.

Passing Environment Variables

Application launched by the D-BUS daemon will inherit environment variables that were defined at the time when the D-BUS session bus was started. D-BUS does not provide a way to change the environment variables passed to an application to be activated.

Application launched by Task Navigator could inherit any environment variables if we implement such a feature to it. But when Task Navigator uses D-BUS to launch the application, the situation is the same as directly launching the application using D-BUS.

Application launched by the maemo-launcher will inherit environment variables that were defined at the time when the maemo-launcher was started. To be able to give the applications correct (pre-loaded) theme, maemo-launcher will listen on the theme changes.

Environment variable should not be used for dynamic configuration changes, since they require program restart and D-BUS does not support that.

Locale and language change is communicated through environment variables. As applications and their libraries also cache locale state (messages etc), changing this to use e.g. Gconf wouldn't help. Therefore changing the device locale or language requires restarting all applications and processes involved in application invocation.

Application termination

Applications exit when user closes them from the application UI, or when system requests that. System will request and force applications to exit for example when:

The device battery charge drops low enough
User switches off the device
User changes the device language
User resets the device back to factory settings
User tries close or to switch to an application that doesn't respond and user accepts system request about whether the application should be forcefully closed

In case a use-case gets system into low memory situation, system can request applications to background killed, see below. If there's not enough memory in the system to satisfy application request, that application requesting more memory will be out-of-memory (OOM) killed by the kernel.

State Saving and Background Killing

Application state saving is needed so that the application UI state and user data can be restored in the in case application crashes, or application is background killed. Applications are required to save their changed state when they go to background.

Background Killing

Application framework has a mechanism for shutting down GUI applications on the background to save memory so that other application can be run. This is called background killing.

Background killing is implemented by Task Navigator to (ideally) transparently close an application when the user does not see it and to restart the application when user needs it again. This is possible because applications are required to be able to save their user interface (UI) states and Task Navigator knows all running UI applications. Application is required to save its UI state when goes to background, i.e. behind some other application's window.

Unfortunately saving the UI state may not be feasible for the application in every situation (there's e.g. a download in progress), that is why the application notifies Task Navigator when it has saved the state and can be killed. Task Navigator will kill all the killable applications when system notifies that it's in low memory situation. When the application is started again, it is required to rebuild the UI according to the (possibly existing) saved state. Task Navigator won't try to (re-)start an application if there's not enough memory in the system for that. Problems with background killing in maemo:

The killed application could be immediately below the top application in the window stack and in case the user closes the top application (from the application’s own menu), the user should see the application that was just closed, but won't, until it has restarted and initialized itself.
Currently Task Navigator checks whether a new application can be started by comparing the amount of system free memory with a build-time configured value. This might be less than a specific application would require or in some cases more than would be required. Application specific minimum required free memory value would be more optimal.

UI State Saving

The following picture describes a scenario where application A saves its state, exits, restarts and reads the saved state. The libosso library only creates the state file and provides the file descriptor to the application. Libosso will make sure that the real state file will not be updated until the state file write has completed and file closed. The application uses the standard POSIX file system API for writing and reading to the file descriptor.

If device is restarted, the UI states will be discarded, so that applications start from their default state. Each application with different version number will have it's own UI state file. This means that if application is updated (it's version number given in libosso initialization is changed), it will start from the default state.

Autosaving User data

Some applications are required to save unsaved user data periodically when on the foreground (top), so that as little as possible is lost on battery failure. Applications should register a libosso callback function for this operation and tell libosso when they have "dirty state" (user data has changed), libosso will then tell applications when they should do the autosave. (In current implementation this is just a timer in libosso, but reason for this API is that later on the saves can be synchronized with device power management.)

Note that applications should call "forced autosave" libosso function when they go to background (libosso doesn't know when this happens).

Window Management

There are several components participating in window management. X server does all the graphics and window handling operations. Matchbox window manager implements the window management policy, it takes care of:

Themed drawing of titlebars and dialog borders.
That dialogs being transient to an application window (or another dialog) are moved in the window stack together. For example when application is topped, it's dialogs are also topped.
When application switches to fullscreen mode, titlebar and panels (like Task Navigator and Statusbar) are hidden.
System dialogs and windows always keep above any application windows.
When input method opens, application window is resized and dialog is moved so that it doesn't overlap with the input method. If dialogs would go out of screen they are resized so that they are fully visible.
When window is opened, giving focus to new window and when a window is closed, giving focus to next window.

Third component of window management is Task Navigator. It keeps a list of all windows and views that applications have open from which user can switch to them. If application is closed through state saving and background killing, Task Navigator will still show it in this list so that it seems to user as the application were still running.

Application Views

In maemo applications implement views using HildonWindow widgets which each have their own X window which all belong to the same HildonProgram window group. In our UI style all dialogs are modal and earlier the dialog blocking an application could not have been raised above the window(s) that it was blocking. The HildonWindow supports standard window properties like window specific icons etc.

Application Topping

Application can top itself or Task Navigator can top the application. When an application is topped by the Task Navigator and it is already running, the topping is done by sending a standard X message.

When another application sends a message to the application requesting some functionality (e.g. File Manager tells image viewer to show a file), it is automatically started (but not yet topped) by the D-BUS daemon (if it is not already running and auto-activation is desired). When the application receives the message, it can raise its window if the operation requires user interaction.

Registering Windows to Task Navigator

For Task Navigator to be able to top application windows, it needs information that tells which window(s) belong to which application. This mapping is done with the application .desktop file StartupWMClass field.

When an application is launched by the D-BUS daemon, Task Navigator compares the WM_CLASS property of the opened application window to the StartupWMClass field in the application .desktop files to see for which application it belongs to. WM_CLASS window property is automatically set to the application binary name by Gtk. Application icons in the Task Navigator application launcher and switcher menus are also taken from the .desktop file.

If application WM_CLASS doesn't match StartupWMClass of any .desktop file, there will be no icon for the application in the Task Navigator application switcher and user cannot switch back to the application. This is a limitation of the current Task Navigator and hopefully fixed in later products.

Closing Application Windows

Application windows are in a stack. When you top an application, it comes on top of the stack. When window is closed, previously shown window is shown. Application window stack is separate from system (dialog) window stack.

System-UI Window Layer

All System-UI windows are on the prioritized system modal "dialogs" layer i.e. windows with the KEEP_ABOVE property. Matchbox window manager keeps them on top of all other system and application windows and dialogs.

0-N System-UI windows are visible at the same time.

The topmost (active) window always does pointer and keyboard grabs. Normal application menus do also these grabs, in OSSO they are required (modified) to close and release grabs when another window comes above them.

All of the System-UI windows are taken care of by the same process and it has a certain internal stacking order for them. I.e. same window comes always in the same position, but all of them might not be visible or even exist at the same time.

There's also a 1x1 window outside the screen which is always mapped to catch Gtk theme change messages.

Misbehaved Applications

The application framework assumes that applications are well behaved. However, in a few situation it checks that application has not jammed by sending a standard [EWMH] _NET_WM_PING message to it and expecting an answer. Gtk will automatically answer the ping in the Gtk event/main loop if application runs it.

This pinging is done by the Matchbox window manager when:

The application window close button is tapped i.e. user tries to close the application
Task Navigator asks it top an application window i.e. user tries to switch back to the application by selecting it from the Task Navigator application switcher. This is needed because window close button is not visible for fullscreen applications (in fullscreen mode user can use the Home key to switch between applications).

If the application doesn't answer timely, window manager informs Task Navigator and that will show user an dialog requesting whether the application should be terminated. If user accepts this, first a TERM and then KILL signal is sent to the application process (process ID is taken from the window _NET_WM_PID property) and the killing is logged. The dialog will go away automatically if application answers the ping while dialog is open.

If a maemo-launched application terminates abnormally, maemo-launcher will send a message to Desktop which will inform user about it. For more information on how applications could misbehave.

Major APIs

Major APIs are listed in the table bellow. APIs like the X APIs are not listed here since they are intended to be internal use only and not for application programmers.

glibc	The core C library API
Glib	Utility library, basic types, memory managment, dynamic strings, linked lists, etc.
GObject	The object model API of GTK+ & GNOME.
GTK+	GTK+ graphical user interface widget set library.
gdk-pixbuf	GTK+ Bitmap image handling.
libosso	maemo base library, application initialization etc.
Hildon APIs	Maemo Hildon APIs.
GStreamer	GStreamer multimedia framework.
libxml2	XML and HTML parser and tools.
libpango	Text rendering framework.
libatk	Accessibility framework.
D-BUS	Inter-process communication framework.
GConf	Configration management framework.
libcurl	HTTP access library.
SQLite	SQL database library.
LibC++	Standard library for C++ language.

References & Further Reading

"Understanding Linux Kernel: 3rd edition", Daniel P. Bovet & Marco Cesati. O'Reilly 2003. "Linux Device Drivers: 3rd edition", Jonathan Corbet & Alessandro Rubini. O'Reilly 2005. "The GNU C Library Reference Manual", Free Software Foundation. "Cross-compiling Tutorial with Scratchbox" "Introduction to Cross-development for Embedded Linux" "GTK+ 2.0 Tutorial", Tony Gale & Ian Main. "Busybox Manual" "GTK+/GNOME Application Development", Havoc Pennington. New Riders Publishing. "GObject Reference Manual". "D-BUS Tutorial", Havoc Pennington, David Wheeler, John Palmieri & Colin Walters. "Reference Manual for libxml2" "Introduction to GConf Library", Havoc Pennington. "GStreamer Application Development Manual", Wim Taymans, Steve Baker, Andy Wingo, Ronald S. Bultje & Stefan Kost. "GStreamer Core Reference Manual" "HAL Specification", David Zeuthen. "Cairo Tutorial", Michael Urman "Pango Reference Manual" "Telepathy D-BUS Interface Specification", Collabora, Nokia & INdt 2007. "File System Hierarchy Standard".

Relevant Standards

ANSI X3.159-1989 C language standard ISO POSIX ISO/IEC 9945 (also published as ANSI/IEEE std. 1003) ISO/IEC 9945-1:1996, the POSIX System Application Program Interface (aka POSIX.1). ISO/IEC 9945-2:1993, the POSIX Shell and Utilities standard (aka POSIX.2) X/Open Portability Guide (XPG), Issue 4.2 ISO C: The international standard for the C programming language. ISO 14882 Standard C++ library Filesystem Hierarchy Standard 2.2 and 2.3 JPEG (lossy and lossless): ITU-T T.81, ISO/IEC IS 10918-1 JPEG (extensions): ITU-T T.84 PNG Specification, second edition RFC 4346: The Transport layer security (TLS) protocol version 1.1 TIFF Revision 6.0 The XML Standard 1.0, W3C Namespaces in XML 1.0, W3C XML Base, W3C RFC 2396 : Uniform Resource Identifiers XML Path Language (XPath) 1.0 HTML4 Parser, W3C XML Pointer Language (XPointer) Version 1.0, W3C XML Inclusions (XInclude) Version 1.0, W3C ISO-8859-x encodings, RFC 2044 [UTF-8] and RFC2781 [UTF-16] Unicode encodings SGML Open Technical Resolution TR9401:1997 XML Catalogs Working Draft 06 August 2001 Canonical XML Version 1.0 Exclusive XML Canonicalization CR draft Relax NG, ISO/IEC 19757-2:2003 W3C XML Schemas Part 2: Datatypes REC 02 May 2001 W3C xml:id Working Draft 7 April 2004 UPnP Device Architecture Specification version 1.0 ISO/IEC 9075:1992, Database Language SQL- July 30, 1992 (SQL92)

Improve this page