|
||
Phone manufacturers may want to provide installable upgrades to plug-ins that have been delivered in a phone's ROM, to fix defects or to add functionality. This can be done, but only if certain conditions are met for both the original ROM plug-in and for the upgrade. This page describes these conditions.
Note that ECom finds and uses installed plug-in upgrades even if:
client code uses the ROM-only plug-in resolver, as described in Using the ROM-only resolver
the plug-in location is specified at ROM build time using a SPI file.
Only plug-ins made upgradable when the ROM is originally built can be upgraded. To do this:
Provide a SIS stub package for the plug-in DLL on the same drive as the plug-in.
This step is part of the general mechanism that allows ROM-based files to be upgraded. The SIS file provides information that the Software Installer program uses to identify the replacement file as a valid upgrade of the original file. For more details of how to do this, see Installing language independent files.
In the plug-in's registration file, set the rom_only
setting to 0.
If rom_only
is set to 1, then upgrades are ignored. For
details of this flag, see Preventing a ROM-based implementation from being overridden.
When you create the plug-in upgrade, ensure that the following conditions are met:
The upgrade supplies both the plug-in DLL and the built resource file, with the same file names as the original ROM plug-in.
The interface UID and the implementation UID are the same in the upgrade and the original.
If the values are different, ECom treats the upgrade plug-in as a new implementation.
The DLL's Vendor ID is the same in the upgrade and the original.
Software Install will check the Vendor ID of the upgrade DLL matches the original DLL’s Vendor ID.
The version number (version_no
setting) of the
implementation, as specified in the registration resource file, is higher in
the upgrade than in the original. See How to provide registry information for more information.