System Startup Overview

Whenever a Symbian device is powered up a number of things have to happen before it is ready to be used. A number of processes and applications have to be started and certain tasks performed.

The System Starter and its related components control the startup process. This guide describes what the System Starter does and how it may be configured. Configuration is the responsibity of device manufacturers. A manufacturer may choose to enable operators, third parties and users to extend the startup configuration.

There are numerous considerations when configuring device startup. These include:

• which processes, tasks and applications are required,

• the sequence of, and inter-dependencies between, activities,

• the user experience,

• the impact on manufacturing and testing,

• operators' customisation requirements,

• users' customisation requirements,

• what to do when something goes wrong

  and

• aftermarket applications

Processes and Applications

In the interest of readability this document frequently uses the terms application and process interchangeably. Unless specifically stated otherwise you may assume that the term used refers to both.

The System Starter is automatically invoked as part of the boot process once the file system has been mounted. It works by processing a list of instructions in sequence. The list is referred to as a Static Startup Configuration, or SSC. In practical terms the SSC is defined in a resource file and is built into the ROM.

A fundamental feature of the SSC is that it allows the start up procedure to be optimised. Though the commands are processed in sequence their effect is to perform tasks not only in sequence (wait for the application or process to initialise before continuing) but also in parallel (do not wait for initialisation) and at the optimum time (wait until conditions are right).

For further information on the contents of an SSC see:

• Static Startup Configuration

Though an SSC cannot be changed, a number of SSCs may be included in a ROM. This allows a device to be started with one of a number of different configurations, i.e. to be booted into different modes.

• The mode determines which SSC the System Starter uses to start the system. Symbian has defined (and reserved) a number of Startup Modes (for test and reference purposes): Full, Emulator, Emergency, Battery charge & Test. Licencees use their own startup modes and obtain a unique range of values from Symbian by sending an email to [email protected] specifying:

  1. the licensee name

  2. the number of Start-up Mode ranges required (each range has 32 values)

SSC files are named SCCForStartupModeN.rss where N is the number of the mode. The method of selecting the mode, and therefore the SSC file, for each startup is defined by the licensee.

The degree to which an SSC can control and optimise the boot process is further enhanced by the concepts of Startup States and Staged Startup.

An SSC is divided into a series of states which follow each other sequentially. Those described here are defined by Symbian. Licencees may add or insert further states by defining them and including them in an SSC. The Symbian defined states have a certain significance:

• The Critical Static State: This is when the essential ROM based components are started. Nothing started in this state relies on anything outside the ROM.

• The Critical Dynamic State: This is when essential non-ROM based components and components which use non-ROM based files are started.

• The Non-critical State: Components started here are not essential for the basic functionality of the device. i.e. the phone will be 'up and running' before these components are started.

Further information on the System Starter may be found in the following documents

• System Starter documents.

A further level of startup control and configuration can be achieved using Staged Startup. This technique enables components to perform their initialisation procedure as separate stages - essential earlier, non-essential later. This enables further reduction of the effective boot time.

Applications must be Staged Startup Aware (SSA) to take advantage of the staged startup facilities. They must register with the Starter so that they can receive state-change notifications. An SSA application may perform a stage of its startup during each SSC state.

Staged startup subdivides each state into five ordered domains: Kernel, Base, OS Services, Application Services and UI Framework (these correspond to the Symbian OS System Model). Each SSA component associates itself with a domain according to its location in the System Model. Within each state the domains are processed sequentially. This allows application dependency to be accommodated without individual applications having to manage these dependencies.

Details on how to write an SSA component, or adapt a component to be SSA, may be found in the following document:

• How to write SSA applications.

All of the components included in the Static Startup Configuration are present for the life of the device. Components installed after the ROM has been built, or after the device has been shipped, may also be started during boot by being added to a Dynamic Startup Configuration (DSC).

One or more DSCs may be included at various points in an SSC.

A run-time API allows entries to be added to and deleted from a DSC. This means that aftermarket applications, updates and patches can be inserted automatically on installation, over the air by a Network Operator, or by the user.

• How to use the DSC API

Though system startup is an automatic process, things can go wrong. In some cases the device can continue to function if a component fails to start, in others it cannot. Applications can fail to start or fail after they have started for a variety of reasons. Symbian OS provides mechanisms for detecting and handling failure.

When an application is started using an SSC or a DSC several parameters must be specified in its resource. These include:

• a startup method (EFireAndForget, EWaitForStart, EDeferredWaitForStart)

• the number of retries (attempts to start the application)

• a timeout period (after which an EWaitForStart startup will be considered to have failed)

• a restart action (EIgnoreProcessFailure, ERestartOS, ERestartOSWithMode - the action to be taken in the event of failure to rendezvous or failure while running normally.)

• a restart mode (the phone might restart in a 'Safe Mode', for instance)

• whether to initiate monitoring after the component has made its rendezvous.

If, after the timeout period the application has not made its rendezvous, the OS can make further attempts to start it. If, after the number of retries specified, it has not succeeded it will take the specified restart action. If the restart action is ERestartOS or ERestartOSWithMode it will shut down the device and restart it (in the second case in the restart mode specified). If monitoring is enabled the System Monitor will continue to monitor the process after a successful rendezvous and, if it stops unexpectedly at any time, will re-use the same configuration information and act accordingly.

• How to use the System Monitor

Note that processes or threads declared 'System Critical' use an aternative monitoring mechanism, which pre-dates the System Monitor, to restart the OS when they fail (see RThread::SetCritical()). The System Monitor offers two significant advantages: the ability to restart the process without restarting the OS and the option of restarting in a specified mode.