System Startup Extension Plug-in API SpecificationChanges in System Startup Extension Plug-in API documentation
PurposeThe purpose of System Startup Extension Plug-in API is to allow extending the startup process without having to modify the Starter Server. The system startup process and the Starter Server are described in more detail in reference documents [1] and [2]. The system startup can be customized by configuring the system startup configuration resource. Basically, the system startup configuration resource contains lists of the executables to be started in each phase of the startup process. Other custom actions besides starting executables can be added to the system startup configurations by implementing them in DLLs. The DLLs must implement System Startup Extension Plug-in API. System startup extension plug-ins can be used to add small tasks to the startup process without the need to start a process to handle the tasks. For example, DB recovery is a task that does not necessarily require starting a process to handle the task, but it can be executed by a plug-in DLL. Restore factory settings operation is also such a task. Another use of system startup extension plug-ins is starting those processes that cannot be started by simply creating the process by executable name and giving command line arguments. They may require connecting to some server or performing some other special processing to start. The code required for starting this kind of servers can be implemented in a system startup extension plug-in, which can then be added to the system startup configuration. API descriptionSystem Startup Extension Plug-in API is an ECOM API defining a virtual base class from which all system startup extension plug-in implementations must be derived. System startup extension plug-ins are optional - it is allowed to have zero system startup extension plug-in implementations in a system. To add a system startup extension plug-in implementation as part of the system startup, it should be added to the system startup configuration resource using Startup List API (see reference document [3]). If a system startup extension plug-in implementation has not been included in the system startup configuration resource, it is not loaded or executed during the system startup. System startup extension plug-ins should not be used to execute very time-consuming tasks, because that makes the overall startup time longer. The plug-ins are loaded into the Starter Server's thread, so they also consume the Starter Server's heap and stack space. Thus, when writing system startup extension plug-ins, performance and memory consumption issues should be considered carefully. Because system startup extension plug-ins run in the Starter Server's thread,
they need to have enough capabilities, specifically the capability set of
Use casesUsing System Startup Extension Plug-in API means implementing a system startup extension plug-in. API class structureThe class structure of System Startup Extension Plug-in API is shown in Figure 1.
All system startup extension plug-in implementations should be derived
from the
Related APIs
Related APIs
Using System Startup Extension Plug-in APIImplementing a system startup extension plug-inTo implement a system startup extension plug-in, derive a class from the
Example: A DLL implementing a system startup extension plug-in should contain an
ECOM
factory method for creating an instance of the plug-in class. In the example
below, the factory method is named Example:
Example: A class derived from
Time-consuming synchronous function calls in
Example: A class derived from
Example: The sequence diagram in Figure 2 shows the sequence of actions in a successful scenario of loading and executing a system startup extension plug-in.
If the class derived from
Related APIs
Plug-in configurationSystem Startup Extension Plug-in API is implemented as an ECOM plug-in. For more information about ECOM plug-ins, refer to Symbian Foundation documentation. With the ECOM architecture, special care must be taken when writing the registration resource files.
If these conditions are not fulfilled, the plug-in implementation will not load correctly. Below is an example resource file demonstrating the correct values:
Related APIs
Error handlingPossible error conditions common for all system startup extension plug-ins are:
How the error is handled depends on whether the plug-in is a part of the critical or non-critical phase of startup. System startup extension plug-in failures during the critical phase are considered as fatal errors, and the general error handling policy of Starter Server applies. System startup extension plug-in failures during the non-critical phase are ignored. Errors caused by badly implemented or misbehaving plug-in DLLs (such as a plug-in implementation panicking or crashing) can not be detected by Starter Server, and they effectively cause an uncontrolled reset.
Related APIs
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. License: EPL
|