Introduction to the software installer

The software installer is a component of Symbian OS that allows software to be installed onto a phone by end users.

Native software (that is, not Java MIDlets, which are installed by an entirely separate component called the Java MIDlet installer) can only be installed onto a phone if it has first been packaged into an installation ('SIS') file. Note that the SIS file format changed significantly in v9.1, so that pre-9.1 SIS files will no longer install, and v9.x files will not install on pre-9.x devices.

The installer’s responsibilities are to:-

• validate and install installation packages (SIS files),

• validate software that is pre-installed on media cards,

• handle software upgrades, patching and removals.

Platform security rules

The introduction of platform security in Symbian OS version 9.1 means that the software installer enforces some new rules. This is a brief summary.

• Before v9.1, files could be installed anywhere in the file system. In v9.1, data caging was introduced, meaning that for instance, binaries can only be installed to a single designated location, and files cannot be written to another program’s private directory area.

• If an executable being installed requests any system capabilities (which are needed in order to be able to use certain sensitive APIs), the package must be signed appropriately by a signing authority, ('user capabilities' may be grantable by the user at install time).

• Overwriting and eclipsing of files are now restricted. Eclipsing is where a file is installed with the same name and path as an existing file, but to a different drive, so that the replacement will be loaded instead of the original. A package cannot overwrite files previously installed by another package, or eclipse files on the ROM drive, unless as part of a valid upgrade.

If any of the rules are broken, the installation will fail, and the entire install package will be rejected.

Configuring the installer

Note that the installation engine is configurable by the phone manufacturer via a ROM-based policy file. This allows much of its behaviour to be customised, including the following:

• whether all packages, even those that require no capabilities must be signed

• whether users can grant user capabilities, or whether they must be granted by a signing authority

• whether the user can be asked to allow overwriting of orphaned files during an installation ('orphaned' means not owned by an installed package, for example, files that were created on the device rather than installed, or that are in ROM but are not mentioned in any ROM stub file)

• the amount of time the installer will wait for a RUNWAITEND executable to complete before continuing with the install/uninstall.

Note also that the user interface implemented on top of the installation engine is written by the phone manufacturer, so the dialogs and messages displayed during the installation may vary from phone to phone.