Upgrading rules

An install package can only overwrite or remove files if it is a valid upgrade of the package that originally installed the files.

Files that were not installed by an install package (known as orphaned files), can only be overwritten if the phone's installation policy has been configured by the phone manufacturer to allow orphaned files to be overwritten. If the policy is enabled, the user will be asked to permit the file to be overwritten.

Upgrading rules

• SA

  When upgrading using a package of type SA, the original package is entirely replaced by the new one. Any files not re-delivered by the new package are removed from the device. After the upgrade has completed, the new package cannot be removed separately from the original; to remove the upgrade, the entire package must be removed.

  If the upgrade causes an executable to be removed, the corresponding private directory is deleted. Any directories and files that were created by the application outside of its private directory are not removed. It is the responsibility of the application to clean these up. It is therefore recommended that files created by an application should be located in the application's private directory.

  If the upgrade causes an executable to be replaced, the private directory is untouched.

  The version number of the upgrading package should be higher than that of the original. To be identified as an upgrade, the upgrading package file must have the same package UID, unique vendor name, and package name as the original. If the package UID differs, then it will be considered to be an unrelated package, not an upgrade. If the package UID is the same but the vendor name or package name differs, then the installation will report an error.

  When upgrading a package of type SA by another SA and the package being upgraded has been patched (see next bullet point), the patch will not be uninstalled by the upgrade.

  An upgrading package of type SA cannot overwrite files installed by a patch. For such a package to install, the patch would first need to be uninstalled.

• SP

  A patch, specified using the SP package type, is an augmentation to an existing package (the "base package"), for instance additional levels for a game.

  A patch differs from a partial upgrade (see the next bullet point) in that it can only add files to a base package; it cannot overwrite files, and it can be uninstalled separately from the base package. If a patch tries to modify or replace an existing file in the base package, the installation will fail.

  If two patches with the same package name and UID are installed, the second patch is treated as an upgrade of the first patch and will replace it entirely.

  The patch's package UID should be the same as the base package's UID, but it should have a different package name. The patch can have its own version number.

• PU

  A partial upgrade, indicated by the PU package-type, is a variation of SA in that any files present in the base package that are missing from the upgrading package are not removed. A partial upgrade can only add or overwrite files. This allows an upgrade SIS to replace just the parts of a base package which require replacement, and not re-deliver the whole package.

  Unlike packages installed using the SA or SP options, a partial upgrade package is not listed as a removable component after installation, so the user needs to remove and reinstall the base package to remove the changes.

  When creating a PU package, the drive selection dialog should be suppressed, so that the upgrade will be installed to the same drive as the existing package and not one arbitrarily chosen by the user. Clearly, if space is limited on this drive, the upgrade cannot continue.

  The package UID for a partial upgrade should be the same as the base package's, but the package names do not need to match. The version number should increment.

  A partial upgrade cannot overwrite files installed by a patch.