Click on the following link to download the example: SysStart.zip
Click: browse to view the example code.
This example demonstrates the use of resource files at the time of System Start-up. System starter is an architecture designed to provide a consistent, transparent, easily customisable method of starting components (i.e. servers and applications) at device boot. It allows an ordering of components according to criticality and dependency by means of a Static Start-up Configuration (SSC).
In this example a resource file SSCForStartupMode0.rss is used at Start-up.
On a target device booting normally, the SSC SSCForStartupMode0.rss is always used for start-up. This SSC is associated with startup mode zero, which is defined as EStartupModeUndefined in e32modes.h. The System Starter architecture provides an ability to select between a number of static Start-up configurations (rss files) depending on the desired Start-up Mode, for example: Full, Emergency, Charging, or Test. Each of these modes may require different sets of components and order of execution.
The start-up process in the resource file is staged via an ordering of Start-up States or phases. These states cannot be removed or their values altered. They appear in the following order:
EStartupStateUndefined – Value before the system enters its first state/ undefined state.
EStartupStateCriticalStatic – Within this Start-up State all ROM based (static) components or resources that are critical to the operation of the phone function are started.
EStartupStateCriticalDynamic – Within this Start-up State all non-ROM based (dynamic) components or resources that are critical to the operation of the phone function are started.
EStartupStateNonCritical – Within this Start-up State all ROM based (static) or non-ROM based (dynamic) components or resources that are non-critical to the operation of the phone function are started. All components that have not already been started and are required at device boot are started in this Start-up State.
This allows start-up to be split into separate, distinct states with a defined order. Within each state, a STATE_INFO structure containing information regarding that state is located. This contains the following information:
Id |
The id of the state as defined in the custom header file |
Name |
A text string describing the state |
Command_list |
The name of the Command array in the SSC which contains the list of Commands to invoke in that state |
Next |
The name of the Command array corresponding to the next state |
Following the STATE_INFO structure in the SSC is a COMMAND_ARRAY structure. This contains details of all commands to be executed within that list. Its name matches the command_list identifier in the STATE_INFO struct and contains one array entry: Commands. The Command entry contains a list of all commands to be executed. Each instance in the rss file is headed with the START_PROCESS_INFO identifier and contains any value needed to override the defaults specified in startup.rh.
Type |
Set by default. Should not be specified in the SSC. |
Path |
The location of the binary e.g. path = "Z:\sys\bin\fbserv.exe" |
Args |
Arguments passed to the process. |
start_method |
The enum TStartupCommandType is defined in startup.hrh. Currently it takes one of three values:
Use EFireAndForget if there is no need for the process to be started serially in other words as soon as the process has been invoked, the System Starter can continue with starting the next process without waiting for the process to rendezvous. Use EWaitForStart if the process needs to get to a certain stage before starting the next process. The starter cannot continue with the next Command until a rendezvous has been made with the first process. Note that the apparc component must be started with mode EWaitForStart to allow connection with the server to take place. Use EDeferredWaitForStart if there is no need to start the process serially, but at a later stage there is a command which cannot be invoked until this process has initialized. Using this value allows a number of commands to be started and the System Starter to wait for them all at a later point in the SSC. This ensures later on that the initializations of all EDeferredWaitForStart commands have completed. EWaitForStart and EDeferredWaitForStart depend upon receiving a rendezvous from the started process. By default this is performed automatically by EikonEnv. If however, you wish your component to perform its own rendezvous, then the following function should be overridden in your AppUi class and return EFalse. TBool CCoeAppUi::FrameworkCallsRendezvous(); |
timeout |
This field is for use with start_method EWaitForStart only. Indicate if a timer should be started when attempting to start the process by filling in this timeout value in milliseconds. The value is 0 by default indicating that no timer will be started. Note that if the timer expires before a rendezvous with the component is made, the component will be killed. If the component is a critical process this will result in a Kern:4 Panic (which on licensee phones usually initiates in a system restart). |
retry_failure_recovery_method |
This specifies the action to take if an error is returned from an attempt to start the process. It is set to ERestartOS by default. This means if the process fails to start the system will restart in the default start-up mode. If it is set to EIgnoreOnFailure then the starter will continue with the next Command. This option is intended for non-critical components on which nothing critical is dependent. If it is set to ERestartOSWithMode the system will be restarted in a specific start-up mode. Note: this field has a slightly different use depending on the start mode: in modes EFireAndForget and EDeferredWaitForStart a failure will be indicated only if there is an immediate error for example the initial process creation/invocation fails. In EWaitForStart a failure will also be indicated if there is no successful rendezvous. |
no_of_retries_on_failure |
For use with start_method EWaitForStart only. Set to 0 by default. This specifies the maximum number of times the starter should try to start a failed process. After the process has been retried the specified number of times, the starter will act according to the value in the retry_failure_recovery_method field. This is used in conjunction with the timeout value. |
monitor |
Indicates whether the started process should be monitored for failure by the System Monitor component. The value is 0 by default indicating that no monitoring will be done. A value of 1 indicates monitoring should be performed. The recovery policy set by retry_failure_recovery_method (and if applicable retry_failure_recovery_startup_mode) will be used by the System Monitor if a failure occurs to this process during the lifetime of the system. Note: if the component being started is a System Critical process, monitoring must not be enabled. |
retry_failure_recovery_startup_mode |
For use with retry_failure_recovery_method ERestartOSWithMode only. Used to specify the start-up mode the system should restart with. This is set to EStartupModeUndefined by default. |