Application Provisioning

Overview and Goals

This chapter describes how application suites and LIBlets are provisioned; that is, how application suites and LIBlets are deployed to client devices, and the requirements imposed upon a client device to support these deployments. Following these recommendations will help ensure interoperability between clients and servers from all manufacturers.

There MUST be only one provisioning mechanism in a concrete implementation though and it must remain unchanged. With other words, if an implementation has decided to implement a certain provisioning mechanism, there MUST NOT be any other way to install, update or delete application suites or LIBlets in this implementation.

One possible implementation of Provisioning is the OTA Provisioning as known from MIDP and IMP. The OTA Provisioning chapter describes how this kind of provisioning should look like in case an implementation decides to implement Provisioning this way.

The ability of an implementation to support provisioning is optional in MEEP 8. If an implementation decides that is does not have to support provisioning (as all application suites are already pre-installed during the manufacturing of the target device and there is no need for updates), it can decide to skip it. Also the way of provisioning - if supported - can be freely chosen as it is out of scope of the specification (see later in this section for details).

Devices MAY provide mechanisms that allow the discovery of application suites and LIBlets. Throughout this chapter, an application with this functionality will be referred to as the Discovery Application, or DA. Please be aware that a DA does not make sense for all provisioning mechanisms, so for a concrete provisioning mechanism it is possible that it will never include a DA.

The installation mechanism used during the provisioning is orthogonal to the provisioning mechanism itself. So installation can be done via the HTTP or HTTPS protocol (whatever is supported) as known from the OTA Provisioning mechanism as defined in the IMP-NG specification, but also e.g. Bluetooth^TM wireless technology, serial cable, IrDA^TM, etc.). The specification of those installation mechanisms re outside the scope of this specification, with the exception of the HTTP or HTTPS based installation variant of the OTA provisioning mechanism.

The term Application Management Software (AMS) is a generic term used to describe the software on the device that manages the transfer and lifecycle of applications. This term does not refer to any specific implementation and is used for convenience only. In some implementations, the term Java Application Manager (JAM) is used interchangeably.

This chapter describes the general functional requirements of the device and the functions supporting the application suite lifecycle and LIBlet provisioning. Descriptions are included for additional Application Attributes and mechanisms that identify the device type and characteristics to servers providing application suites and LIBlets.

Functional Requirements for Provisioning

A MEEP 8 implementation supporting provisioning:

MAY be capable of locating application suite and LIBlet Application Descriptors.
in cases where provisioning includes a transfer of an application suite or LIBlet (to the device or within the device) MUST provide a way to realize this transfer. If for the respective provisioning mechanism an Application Descriptor is associated to the Application Suite or LIBlet, there MUST also a way to transfer this descriptor.
MUST be able to install the application suite or LIBlet on the device.
MUST be able to invoke Applications.

Application Suite and LIBlet Lifecycle

The lifecycle of an application suite for an implementation supporting provisioning consists of discovery (optional), installation, update, invocation and deletion.

The lifecycle of a LIBlet for an implementation supporting provisioning consists of discovery (optional), installation, update, and deletion.

Discovery

Application suite and LIBlet discovery is the process by which an application suite or LIBlet is discovered using the device. The ability of Discovery itself is optional, as the Provisioning can take place in a way that does not require that the device discovers the application suite or LIBlet itself. Discovery and installation of application suites and LIBlets, if supported, MUST follow the following high-level scheme:

The mechanisms of the discovery itself (if supported), done by an application or by a user, is out of scope of this specification.
Once discovered (or otherwise made known to the device), the Application Descriptor, if available, is transferred to the device first. This descriptor contains information about the application suite or LIBlet and can be used by the device's AMS to start installation.
The source of the application suite or LIBlet to be discovered MAY require that a full client device profile has to be transferred there (in a provisioning mechanism specific manner) together with the request for the Application Descriptor (if those are supported by the mechanism) or the provisioning of the suite or LIBlet itself.
If Application Descriptors are supported, then the transfer (if necessary) of the suite or LIBlet begins if the Application Descriptor is not available, or after the AMS has transferred the Application Descriptor and determined that installation should continue, otherwise (if no Application Descriptors are supported), the transfer (if needed) starts immediately.
If Application Descriptors are supported, and an application suite or LIBlet depends on one or more LIBlets, the Application Descriptors for all dependency LIBlets are transferred prior to the dependent application suite or LIBlet transfer. The decision on whether to proceed with the application suite or requiring LIBlet transfer (and subsequent installation) depends on the verification of the JAD and JAR of both the application suite or LIBlet and dependency LIBlets for those implementations. If it is detected during this process that the transfer and installation of an application suite or LIBlet won't take place due to dependency LIBlets being not suitable for some reason, the subsequent transfer and installation of LIBlets for this applications suite or LIBlet SHOULD also be stopped.

Provisioning

When an application suite or LIBlet is provisioned, all files that comprise the applications or LIBlet are transferred to the device for installation. In addition to the application suite or LIBlet JAR file, one or more dependency LIBlet JAR files could be transferred.

This section describes how the Discovery Application (DA, if any) and the Application Management System (AMS) handle the various components of an application suite or LIBlet and its dependencies.

Application Suite Provisioning

As mentioned before, the mechanism of discovery (if supported) is out of scope of this specification. As a result of a discovery or from another source, an information is available pointing to an Application Descriptor (if supported) or to the application suite itself. Once the information is available, the following steps should be performed:

The Application Descriptor (if supported) or the application suite itself the information points to is checked to have the correct structure to enable retrieval of information about the application suite (in case of an Application Descriptor) or the direct installation (otherwise), and a transfer (if necessary) is initiated.
After completing the transfer (if any), the necessary information is passed to the AMS on the device to start the installation process. If an Application Descriptor is supported, it is used by the AMS to determine if the associated application suite can be successfully installed and executed on the device. This may involve transfer (if necessary) and check of Application Descriptors of any LIBlets the application suite depends on, if any LIBlet dependencies are specified by the application suite.
If Application Descriptor (if supported) or the application suite itself is delivered in a transport format that is not the Unicode encoding that is specified by the specification it MUST be converted before it can be used. The default character set it has to be converted into is UTF-8. It is expected that an implementation is able to recognize and convert the transport format used, otherwise the installation MUST fail.

If Application Descriptors are supported, the Application Suite JAD file lists its LIBlet dependencies. In this case, and if a transfer of installation files is necessary for the respective provisioning mechanism, the JAD files involved, for both the application suite and dependency LIBlets, MUST be transferred first before any of the application suite or dependency LIBlet JAR files can be transferred. Based on those JAD files, the device SHOULD calculate the total static size required for installation. Also, any JAD only validation steps MAY be undertaken before the actual installation data transfer (if required) is started.

The attributes in the Application Descriptor (if supported) MUST be formatted according to the syntax defined in Application Attributes; otherwise the provisioning MUST fail. All of the application attributes designated as mandatory by Appendix A MUST be present in the Application Descriptor (if supported); otherwise the provisioning MUST fail. If Application Descriptors are supported, and an Application Descriptor contains any application attributes that are allowed only in the Jar manifest (see Appendix A), then the provisioning MUST fail.

LIBlet Provisioning

LIBlet provisioning can be performed as part of application provisioning (for LIBlets an application suites is depending on), or as a standalone provisioning.

For provisioning of a LIBlet during the provisioning of an application suite, if the required version of a LIBlet is already installed on the device, i.e. if a LIBlet with the same name, vendor and version is already available, then the LIBlet MUST NOT be provisioned (and later installed) again, replacing the exiting one.

For a standalone installation of a LIBlet though, if the same version of the LIBlet is already installed on the device, i.e. if a LIBlet with the same name, vendor and version is already available, then the provisioning is interpreted as part of a LIBlet Update, so it will be provisioned and later replace the existing one.

If Application Descriptors are supported, the LIBlet JAD file lists its LIBlet dependencies. In this case, and if a transfer of installation files is necessary for the respective provisioning mechanism, the JAD files involved, for both dependent LIBlet and dependency LIBlets, MUST be transferred first before any of the LIBlets can be transferred. Based on those JAD files, the device SHOULD calculate the total static size required for installation. Also, any JAD only validation steps MAY be undertaken before the actual installation data transfer (if required) is started. This is true independent on whether the dependent LIBlet is provisioned as part of an application suite provisioning or standalone.

Installation

Installation of Application Suites

Application installation is the process by which any transfer of an application suite as far as required by the provisioning mechanism is performed and applications are made available for running. Application installation is optional in MEEP 8, but MUST be supported if Provisioning is supported.

If the application suite depends on one or more LIBlets, implementation MAY make the user aware of all LIBlets the application suite depends on. The means by which application dependencies are presented to the user are implementation specific.

Installation of LIBlets the application suite is depending on is done as part of the application suite installation process. It only takes place, if the LIBlet of the required version is not yet installed on the device. In this case, since other applications could depend on other versions of a LIBlet already installed in the device, a LIBlet is not simply replaced with a newer version. Instead, another (but typically newer) version of the LIBlet is installed. Any existing version of the LIBlet MUST NOT be deleted if there are other applications or LIBlets depending on it. It follows that multiple versions of the same LIBlet MAY reside on the device at the same time.

At installation of a trusted application suite, the implementation MAY present to the user security information related to the application suite.

During installation, the user MAY be informed of progress. The way this happens is implementation-dependent. If the installation is interrupted by any reason, the device MUST be left in the state it was in before installation began.

If the application suite is already installed on the device, it SHOULD be treated as an update. See the Application Suite Update section for additional information on how to handle an update.

To install an application suite, the AMS performs the following series of steps and checks and MAY provide the user with feedback about the progress (in an implementation-dependent manner):

The device initiates the transfer of the application suite (in case the provisioning mechanism includes any transfer operations).
The application suite MUST be checked to verify that the retrieved application suite is valid and can be installed on the device. The following problems may occur:
1. If there is insufficient memory to store the application suite on the device, the installation MUST fail. In case a LIBlet dependency is specified, the device MUST first verify there is sufficient persistent storage space by summing the JAR size specified in the JADs of the application suite and all of the LIBlets that the application suite declares dependency on, directly or indirectly, using the following formula:
  MIDlet-Jar-Size + Σ(LIBlet-Jar-Size for distinct LIBlets)
  The associated JARs will only be transferred if there is sufficient persistent storage space. If the required version of a LIBlet already exists on the device, its size will be omitted from this total size.
2. If the application suite code is not available at the place the provisioning parameters specify it should, the installation MUST fail. Similarly, if a dependency LIBlet is not already installed on the device in the required version and cannot be found at the place the provisioning parameters specify it should, the installation of the application suite MUST fail.
3. If Application Descriptors are supported, and the size of the application suite to be installed does not match the size specified in the Application Descriptor, the installation MUST fail.
4. If the manifest or any other file cannot be extracted from the piece of software containing the application suite, like a JAR, the installation MUST fail.
5. If the manifest is not in the correct syntax, or if any of the required application attributes are missing in the manifest, or if the manifest contains any application attributes that are allowed only in the JAD (see Appendix A), then the installation MUST fail.
6. If Application Descriptors are supported, and the mandatory attributes in the descriptor MIDlet-Name, MIDlet-Version, and MIDlet-Vendor do not match those in the manifest of the application suite, the installation MUST fail. Similarly, if the mandatory attributes in one of the dependency LIBlet descriptors LIBlet-Name, LIBlet-Version, and LIBlet-Vendor do not match those in the respective LIBlet manifest, the installation of the application suite MUST fail as well.
7. If Application Descriptors are supported, the value of each attribute that appears in both, the manifest and Application Descriptor MUST have the identical value (with the exception of application suites with the MicroEdition-Profile attribute equal to "IMP-1.0", or "IMP-NG"). If not identical, the installation MUST fail. For IMP 1.0, and IMP-NG application suites, refer to Attribute Overrides in Application Descriptor.
8. If an Application Descriptor (if supported) or Manifest of an Application Suite contains any instances of LIBlet-Dependency-<n> attributes, or if any LIBlet Application Descriptor (if supported) or Manifest of a LIBlet associated with the application suite contains any instances of MIDlet-Dependency-<n> attributes, then the installation of the application suite MUST fail.
9. If an Application Descriptor (if supported) or Manifest of an Application Suite contains a LIBlet-Name attribute, then the installation of the application suite MUST fail.
10. If the version of a LIBlet, as required by an application using the MIDlet-Dependency-<n> attribute, or as required by another LIBlet using the LIBlet-Dependency-<n> attribute, is not already installed on the device, it MUST be downloaded from the URL as specified in the MIDlet-Dependency-JAD-URL-<n> or LIBlet-Dependency-JAD-URL-<n> attribute. If the LIBlet cannot be found there or if it has not the required version, then the installation of the application suite or dependent LIBlet MUST fail.
11. At installation time, the device MUST first verify there is sufficient disk space for persistent data using the data size specified in the JADs (if supported) of the application suite and the dependency LIBlets, computed as:
  MIDlet-Data-Size + Σ (LIBlet-NonShared-Data-Size for distinct LIBlets) + Σ (LIBlet-Shared-Data-Size for distinct LIBlets if it is the first binding for the LIBlet on the device)
  The associated application suite and LIBlets will only be transferred (if necessary) and installed if there is sufficient persistent storage space. In case of insufficient memory, the installation of the application suite MUST fail.
12. If the application suite failed to be authenticated, the installation MUST fail.
13. If circular dependencies are detected in the LIBlets that an application suite depends on, the device MUST reject the installation of such a binding.
14. If a device imposes an upper limit on the number of LIBlet dependencies allowed for a single application suite, and if that upper limit is exceeded, the device MUST reject the installation of the application suite.
15. If the application is not authorized for a permission as defined by the Requesting Permissions for Application Suites and LIBlets section then installation must fail. The code of the application suite and the LIBlets it depends on MUST NOT be transferred (in case the respective provisioning mechanism requires a transfer).
16. If the device detects a namespace collision between classes in the application suite and classes in the LIBlets it depends on, the device MUST fail the installation of such a binding.
If the application is protected by OMA DRM and the device cannot parse it, then the installation MUST fail.
Each service requested by the application and its LIBlets in MIDlet-Dependency-<n> or LIBlet-Dependency-<n> attributes must be resolved. Each installed LIBlet that exports one of the requested services in its LIBlet-Services attribute must be considered a candidate service provider LIBlet.
- Each unique service provider LIBlet MUST be considered a candidate only if:
  - it is a dependency of an application and there exists at least one common Client between the LIBlet and the application requesting the service. See Application Update for the definition of a common Client.
  Otherwise, no error is reported, and the LIBlet is ignored.
- Each unique LIBlet is considered a candidate only if this LIBlet and its dependencies are not in conflict with the application and its LIBlets and its contents will not cause a namespace collision. If multiple namespace conflicts between candidate LIBlets occur, it is implementation specific which, if any, LIBlets without conflicts are still considered as candidates. If a conflict is detected, no error is reported, the LIBlet is ignored.
- If more than one service provider LIBlet is a candidate and meets all other constraints, the LIBlet with the highest version number must be selected to be bound to the application.
- Each remaining candidate LIBlet is bound to the application only if it is enabled as a service provider of a requested service. Service providers within a LIBlet cannot be individually enabled or disabled; either the entire contents of the LIBlet is made available to the application or it is not bound. The mechanism to enable and disable LIBlets containing service providers is implementation specific.
The dependent LIBlets found during installation or update MUST be bound to the application for use in the Execution Environment. The set of LIBlets remains bound to the application until it is explicitly updated. See Updating Applications to use Updated LIBlets for details.
If a LIBlet that exports a service with a LIBlet-Services attribute does not contain valid service provider information for the service as defined in the Service Provider Packaging then installation MUST fail.
LIBlets that export a service must be enabled when installed.
If there are no problems that prevent installation, the applications contained in the application suite MUST be installed and made available for execution.
The installation is complete when the application suite has been made available on the device, or an unrecoverable failure has occurred. In either case, the status MUST be reported as described in the Status Reports section in case the Provisioning mechanism allows the sending of status reports.
An AMS MAY need to stop all running applications in order to perform an installation of an application suite due to technical reasons caused by this particular MEEP implementation. As these stops are not caused by a security relevant incident, a soft deletion is sufficient in those cases.

Installation of LIBlets

As mentioned before, LIBlets may be installed as part of an application suite installation, if they are among those, the application suite has defined a dependency upon. This kind of LIBlet installation is described in the Application Suite Installation section. This section handles the standalone installation of LIBlets. Standalone installation of LIBlets is the process by which any transfer of a LIBlet as far as required by the provisioning mechanism is performed and LIBlets are made available for usage by application suites. LIBlet installation is optional in MEEP 8, but MUST be supported if Provisioning and LIBlets are supported.

If the LIBlet to be installed depends on one or more LIBlets, implementation MAY make the user aware of all LIBlets the LIBlet depends on. The means by which LIBlet dependencies are presented to the user are implementation specific.

If the LIBlet to be installed depends on other LIBlets, the installation of those is done as part of the requiring LIBlet installation process. It only takes place, if the LIBlet of the required version is not yet installed on the device. In this case, since other applications or LIBlets could depend on other versions of a LIBlet already installed in the device, a LIBlet is not simply replaced with a newer version. Instead, another (but typically newer) version of the LIBlet is installed. Any existing version of the LIBlet MUST NOT be deleted if there are other applications or LIBlets depending on it. It follows that multiple versions of the same LIBlet MAY reside on the device at the same time.

At installation of a trusted LIBlet, the implementation MAY present to the user security information related to this LIBlet.

If the same version of the LIBlet to be explicitly installed is already installed on the device, it SHOULD be treated as an update. See the LIBlet Update section for additional information on how to handle an update.

To explicitly install a LIBlet, the AMS performs the following series of steps and checks and MAY provide the user with feedback about the progress (in an implementation-dependent manner):

The device initiates the transfer of the LIBlet (in case the provisioning mechanism includes any transfer operations).
The LIBlet MUST be checked to verify that the retrieved LIBlet is valid and can be installed on the device. The following problems may occur:
1. If there is insufficient memory to store the LIBlet on the device, the installation MUST fail. In case a LIBlet dependency is specified, the device MUST first verify there is sufficient persistent storage space by summing the JAR size specified in the JADs of the LIBlet to be explicitly installed and all of the dependency LIBlets that the LIBlet declares dependency on, directly or indirectly, using the following formula:
  LIBlet-Jar-Size + Σ(LIBlet-Jar-Size for distinct LIBlets)
  The associated JARs will only be transferred if there is sufficient persistent storage space. If the required version of a dependency LIBlet already exists on the device, its size will be omitted from this total size.
2. If the LIBlet code is not available at the place the provisioning parameters specify it should, the installation MUST fail. Similarly, if a dependency LIBlet is not already installed on the device in the required version and cannot be found at the place the provisioning parameters specify it should, the installation of the LIBlet to be explicitly installed MUST fail.
3. If Application Descriptors are supported, and the size of the LIBlet to be explicitly installed does not match the size specified in the Application Descriptor, the installation MUST fail.
4. If the manifest or any other file cannot be extracted from the piece of software containing the LIBlet to be installed, like a JAR, the installation MUST fail.
5. If the manifest is not in the correct syntax, or if any of the required application attributes are missing in the manifest, or if the manifest contains any application attributes that are allowed only in the JAD (see Appendix A), then the installation MUST fail.
6. If Application Descriptors are supported, and the mandatory attributes in the descriptor LIBlet-Name, LIBlet-Version, and LIBlet-Vendor do not match those in the manifest of the LIBlet to be installed, the installation MUST fail. Similarly, if those mandatory attributes in one of the dependency LIBlet descriptors do not match those in the respective LIBlet manifest, the installation of the LIBlet to be explicitly installed MUST fail as well.
7. If Application Descriptors are supported, the value of each attribute that appears in both, the manifest and Application Descriptor MUST have the identical value. If not identical, the installation MUST fail.
8. If an Application Descriptor (if supported) or Manifest of a LIBlet contains any instances of MIDlet-Dependency-<n> attributes, then the installation of the LIBlet MUST fail.
9. If an Application Descriptor (if supported) or Manifest of a LIBlet contains a MIDlet-Name attribute, then the installation of the LIBlet MUST fail.
10. If the version of a LIBlet, as required by the LIBlet to be installed, or as required by another LIBlet using the using the LIBlet-Dependency-<n> attribute, is not already installed on the device, it MUST be downloaded from the URL as specified in the LIBlet-Dependency-JAD-URL-<n> attribute. If the LIBlet cannot be found there or if it has not the required version, then the installation of the application suite MUST fail.
11. At installation time, the device MUST first verify there is sufficient disk space for persistent data using the data size specified in the JADs (if supported) of the LIBlet to be installed and the dependency LIBlets, computed as:
  LIBlet-Data-Size + Σ (LIBlet-NonShared-Data-Size for distinct LIBlets) + Σ (LIBlet-Shared-Data-Size for distinct LIBlets if it is the first binding for the LIBlet on the device)
  The LIBlet to be installed and dependency LIBlets will only be transferred (if necessary) and installed if there is sufficient persistent storage space. In case of insufficient memory, the installation of the LIBlet MUST fail.
12. If the LIBlet to be explicitly installed failed to be authenticated, the installation MUST fail.
13. If circular dependencies are detected in the LIBlets that the LIBlet to be installed depends on, the device MUST reject the installation of such a binding.
14. If a device imposes an upper limit on the number of LIBlet dependencies allowed for a LIBlet, and if that upper limit is exceeded, the device MUST reject the installation of the LIBlet.
15. If the LIBlet is not authorized for a permission as defined by the Requesting Permissions for Application Suites and LIBlets section then installation must fail. The code of the LIBlet and the LIBlets it depends on MUST NOT be transferred (in case the respective provisioning mechanism requires a transfer).
16. If the device detects a namespace collision between classes in the LIBlet and classes in the LIBlets it depends on, the device MUST fail the installation of such a binding.
Each service requested by the LIBlet and its dependency LIBlets in LIBlet-Dependency-<n> attributes must be resolved. Each installed LIBlet that exports one of the requested services in its LIBlet-Services attribute must be considered a candidate service provider LIBlet.
- Each unique service provider LIBlet MUST be considered a candidate only if:
  - it is a dependency of the LIBlet and there exists at least one common Client between the LIBlet and the LIBlet requesting the service. See LIBlet Update for the definition of a common Client.
  Otherwise, no error is reported, and the LIBlet is ignored.
- Each unique LIBlet is considered a candidate only if this LIBlet and its dependencies are not in conflict with the LIBlet and its dependency LIBlets and its contents will not cause a namespace collision. If multiple namespace conflicts between candidate LIBlets occur, it is implementation specific which, if any, LIBlets without conflicts are still considered as candidates. If a conflict is detected, no error is reported, the LIBlet is ignored.
- If more than one service provider LIBlet is a candidate and meets all other constraints, the LIBlet with the highest version number must be selected to be bound to the requesting LIBlet.
- Each remaining candidate LIBlet is bound to the requesting LIBlet only if it is enabled as a service provider of a requested service. Service providers within a LIBlet cannot be individually enabled or disabled; either the entire contents of the LIBlet is made available to the requesting LIBlet or it is not bound. The mechanism to enable and disable LIBlets containing service providers is implementation specific.
The dependent LIBlets found during installation or update MUST be bound to the requesting LIBlet. The set of dependency LIBlets remains bound to the requesting LIBlet until it is explicitly updated or removed. See Updating Applications and LIBlets to use Updated LIBlets for details.
If a LIBlet that exports a service with a LIBlet-Services attribute does not contain valid service provider information for the service as defined in the Service Provider Packaging then installation MUST fail.
LIBlets that export a service must be enabled when installed.
If there are no problems that prevent installation, the LIBlet MUST be installed and made available for applications.
The installation is complete when the LIBlet has been made available on the device, or an unrecoverable failure has occurred. In either case, the status MUST be reported as described in the Status Reports section in case the Provisioning mechanism allows the sending of status reports.
An AMS MAY need to stop all running applications in order to perform an installation of a LIBlet due to technical reasons caused by this particular MEEP implementation. As these stops are not caused by a security relevant incident, a soft deletion is sufficient in those cases.

Application Suite Update

An application suite update is defined as the operation of installing a specific application suite when there is an application suite with same MIDlet-Name and MIDlet-Vendor attributes already installed on the device. Devices MAY support the updating of application suites. If application suite update is not supported or cannot be accomplished (e.g., because an application suite is preinstalled), then application suite installation fails with status code 913 "Update not supported or failed".

If an application is updated while running, it has to be stopped when the installation of the updated version begins. As this is not a security relevant incident, a soft deletion is sufficient.

If an application suite update does not result in binding to the same Client as the original application suite, then installation MUST fail. Additionally, if an application suite update and the already installed application suite is not authorized by the same Client, then installation MUST fail. How it is decided, whether a Client is the same as another one, depends on the Authentication Provider used.

If the application suite dependencies change, the developer of the application suite needs to provide an updated JAD file containing the new dependencies to be provisioned to the device. These dependencies MUST be resolved like in the initial installation of the application suite.

When updating a dependency declaration chain, the application suite declaring the dependency MUST increase its own version number, regardless of whether or not any code changes occurred to the application suite or LIBlet itself declaring the dependency.

For the case where an application suite is being updated only because of new LIBlet dependencies, the application suite developer will need to check that the required Permissions for new LIBlet dependencies are reflected in application manifest and/or JAD. The application suite will also need to be correctly authenticated.

In case the implementation supports the javax.microedition.rms package, the following has to be taken into account:

For a trusted application suite update, the RMS record stores MUST be retained. For an untrusted application suite update, the RMS record stores MUST be managed as follows:
- If Application Descriptors are supported, and the new Application Descriptor comes from exactly the same source as the original Application Descriptor, then the RMS MUST be retained and made available to the new application suite.
- If the new application suite comes from exactly the same source the original application suite had come from, then the RMS MUST be retained and made available to the new application suite.
- If none of the conditions above are met, then the device MUST use a predefined policy to decide whether the data from the original application suite should be retained and made available to the new application suite.
The format, contents and versioning of the record stores is the responsibility of the application suite. The permissions given to the original application suite SHOULD also be given to the new application suite, if they are granted also to the Client of the new application suite.

LIBlet Update

A LIBlet update is defined as the operation of explicitly installing a specific LIBlet when there is a LIBlet with same LIBlet-Name, LIBlet-Vendor and LIBlet-Versionattributes already installed on the device. Devices MAY support the updating of LIBlets. If LIBlet update is not supported or cannot be accomplished for some reason, then LIBlet installation fails with status code 913 "Update not supported or failed".

If a LIBlet is updated while one or more than one applications using it are running, all those applications have to be stopped when the updating installation of the LIBlet begins. As this is not a security relevant incident, a soft deletion is sufficient.

If a LIBlet update does not result in binding to the same Client as the original LIBlet, then the installation MUST fail. If the original LIBlet has been bound to more than one Client, and the Clients to which the original LIBlet has been bound to are not all among those the updated LIBlet is bound to, then the installation MUST fail. Additionally, if a LIBlet update and the already installed LIBlet is not authorized by the same Client, then installation MUST fail. How it is decided, whether a Client is the same as another one, depends on the Authentication Provider used.

If the LIBlet dependencies change, the developer of the LIBlet needs to provide an updated JAD file containing the new dependencies to be provisioned to the device. These dependencies MUST be resolved like in the initial installation of the LIBlet.

As installed application suites and LIBlets depend on an installed LIBlet, the application developer or the authority performing the update has to make clear that the updated version does not reduce functionality of the original LIBlet (while an extension of functionality is no problem). The provisioning algorithm has no possibility to check this at all. Therefore an update of a LIBlet can cause using applications not to work properly any more or even crash if the provider of the update does not consider this responsibility.

Updating Applications and LIBlets to Use Updated LIBlets

Under specific conditions a LIBlet installed for one application or LIBlet can be used to update other applications and LIBlets that use previous versions of the LIBlet. If allowed by the application or LIBlet and when the application or LIBlet is updated, the LIBlet will be included in the Execution Environment when the application (or for a LIBlet: an application using this LIBlet) is subsequently invoked.

The updated LIBlet can be rebound to an application or LIBlet by reevaluating all of the dependency information used during installation. Each dependency is evaluated and if the dependency expression has a version number that matches then the new LIBlet can be bound to the application or LIBlet. The entire Dependency Declaration Chain must be reprocessed including checking for circular dependency checking. The processing required is the same as re-installing the application or LIBlet but it should not require the transfer of the application or LIBlet JAD or JARs. If any errors are detected, then the update fails and the application or LIBlet must revert to the previously installed state.

The rebinding of LIBlets to applications or LIBlets can be performed immediately, can be deferred indefinitely or can be performed based on a profile setting in the implementation.

Invocation

If the start of an application has been triggered, the device MUST invoke the application with the Execution Environment .

Deletion

Application Suite Deletion

If Provisioning is supported, devices MUST allow to delete application suites, with the exception of Persistent Application. If the deletion is not caused by a security relevant incident like blacklisting of the application or of its Client, a soft deletion is appropriate, otherwise a hard one. Before an application can be deleted, it MUST be always stopped.

LIBlet Deletion

LIBlet deletion is usually done as part of the application suite deletion process, if a LIBlet has no other application suites depending on it. An implementation that has sufficient persistent storage MAY choose to retain LIBlets for possible later use, even after all application suites depending on the LIBlet have been deleted.

A LIBlet becomes unreferenced if there are no application suites installed on the device that specify a dependency on that particular LIBlet or if the LIBlet is not providing a service to or is not bound to any application. It is up to the implementation to determine when (if ever) it is appropriate to delete unreferenced LIBlets. For implementations that do retain unreferenced LIBlets, the AMS MAY provide a means to delete such LIBlets.

Some implementations MAY, according to policy, never allow unreferenced LIBlet automatic deletion, even if the LIBet's reference count drops to zero.

Installation Use Cases

To detemine the behavior in case of the installation or update of an application suite depending on LIBlets can be very complex, because it requires to consider aspects of versioning, security etc. being described in several chapters of the specification.

This section therefore describes some popular use cases and the specification conformant behavior of an implementation in order to simplify orientation for creaters and users of MEEP 8 implementations.

All use case described in this section assume that the implementation supports provisioning of application suites, LIBlets and a security framework, all being optional in MEEP 8.

Case 1: Installation of an application suite that depends on a LIBlet of fixed version

Application suite A1 (authorized by Clients CA1 ... CAn) should be installed
A1 depends on a Liblet L1 (authorized by Clients CL1 ... CLm)
The dependency attributes of A1 allow only version 2 of LIBlet L1.
Before installation, it is checked if there is a non-empty intersection between Clients CA1...CAn and Clients CL1...Clm.
If this intersection is not empty, A1 is assigned to one of the Clients from this intersection CAi (which one is implementation dependent), and the Liblet L1 runs in the context of A1 also assigned to this Client CAi.
If the intersection is empty, the installation of A1 MUST fail.

Case 1a: Like Case 1, but Liblet L1 already resides on the device

When A1 is about to be installed, the Liblet L1 version 2 already resides on the device (installed there with another application suite, or explicitly provided earlier).
Before installation of A1, the same intersection check as in case 1 has to take place.
Depending on the outcome of this check the result is the same as in case 1, respectively.

Case 2: Installation of an application suite that depends on a LIBlet of variable version (wildcard)

Same application suite A1 and Liblet L1 as in case 1, but the dependency attributes of A1 allow several versions of L1, as they use a wildcard ("*" or "+").
The intersection check for Clients is made as described in case 1, but for the highest available and valid version covered by the wildcard.
If the intersection test results in a non-empty set of Clients, A1 will be installed, using this version of L1.
Otherwise the installation of A1 MUST fail.

Case 2a: Like Case 2, but a version of Liblet L1 already resides on the device

Before installation of A1, it is checked which is the highest version of L1 being available and valid as covered by the wildcard in the dependency attribute of A1. This could be the version of L1 that already resides on the device, or a higher version available via provisioning.
If the version of L1 already residing on the device is the highest one being available and valid according to the wildcard, the intersection test of Clients as described above is done for this version of the LIBlet. If the resulting set of Clients is not empty, A1 is installed and uses the version of L1 that has been already available on the device. Otherwise the installation of A1 MUST fail.
If a higher version of L1 being valid according to the wildcard is available via provisioning, then the version of L1 residing on the device is ignored, instead the intersection test of Clients is done for this available version of L1 with a higher version number. If the resulting set of Clients is not empty, then A1 is installed and will use the tested version of L1 that is installed as well. If the intersection test fails, then the installation of A1 MUST fail as well, even if it would have been possible to run with the version of L1 residing on the device!

Case 3: Update of a version of a LIBlet on the device that is used by application suites

A1 has been installed, using L1 version 2 as a result of Case 1/1a or Case 2/2a.
An attempt is made to update version 2 of LIBlet L1.
If the set of Clients having authenticated the update of LIBlet L1 version 2 contains those that have authenticated the original of LIBlet L1 version 2, the LIBlet L1 version 2 is just replaced and all applications suites that have used it before continue using the updated LIBlet L1 version 2.
If this does not apply, and the update of LIBlet L1 version 2 is authenticated by another set of Clients, say CLn1 ... CLnk, then for any application suite using LIBlet L1 version 2 it has to be checked if the respective Client the application suite is bound to, is among CLn1 ... CLnk.
If this check fails for one of the application suites using LIBlet L1 version 2, the update of LIBlet L1 version 2 MUST fail.

Case 4: Installation of a new version of a LIBlet on the device that is used by an application suite

A1 has been installed, using L1 version 2 as a result of Case 1/1a or Case 2/2a.
An attempt is made to install version 3 (a higher version than the one residing on the device) of LIBlet L1.
For all application suites using LIBlet L1 and for which the dependency attribute would allow to use the old version of L1 and the new version as well, it is tested whether the Client the respective application suite is bound to is among the Clients authorizing the new version 3 of LIBlet L1.
Those application suites for which the Client the respective one is bound to is not among the Clients authorizing the new version 3 of LIBlet L1, continue using version 2 of LIBlet L1.
Those application suites for which the Client the respective one is bound to is among the Clients authorizing the new version 3 of LIBlet L1, will use the new version 3 of LIBlet L1 now.
Those application suites that must not use version 3 of the LIBlet L1 anyway due to the restrictions in their dependency attributes, continue using version 2 of LIBlet L1 anyway.

Case 5: Attempt to update an applications suite on the device that uses LIBlets

Application suite A1 has been installed, using LIBlet L1 version 2 as a result of Case 1/1a or Case 2/2a.
Attempt is made to update application suite A1, assuming that the new version also depends on LIBlet L1, but the dependency attribute defining this does not necessarily use the same wildcard.
The highest version of LIBlet L1 being both, available and valid according to that wildcard, is checked whether the intersection of Clients authorizing this new version of application suite A1 and Clients authorizing the identified highest available and valid version of LIBlet L1 being not empty. This highest available and valid version of LIBlet L1 could be the version 2 of L1, already residing on the device and being used by the old version of A1. It could also be a higher version being available by provisioning.
If the intersection set of clients is empty, the update of A1 MUST fail, anf the old version of A1 remains on the device.
Otherwise A1 is updated, and the new version is installed on the device now, using the highest version of L1 being available and valid according to the dependency attribute. If this version of L1 is not the one that was already residing on the device, it will be installed as well.

Case 6: Blacklisting of one of the Clients a LIBlet is bound to

A LIBlet L1, that is bound to several Clients and used by several application suites, resides on a device.
One of the Clients the LIBlet is bound to becomes blacklisted.
If one of the application suites using L1 is bound to that now blacklisted Client, L1 in the context of this application suite is also bound to this Client.
This application suite will be stopped and removed (if possible).
All application suites bound to other Clients are not affected by the blacklisting, as the same LIBlet L1 is in their context bound to the respective same Client.
Which means that, if none of the application suites using L1 is bound to the now blacklisted Client, the blacklisting has no immediate effect with respect to LIBlet L1.

Status Reports

The success or failure of the installation, update, or deletion of an application suite or LIBlet is of interest to the service providing the application suite or LIBlet. The Application Descriptor - if supported - MAY include relevant application attributes for provisioning that specify URLs for status reporting. Those URLs MUST be used for reporting as specified below.

It has to be noted though, that not all Provisioning mechanisms are necessarily able to send status reports. Also, if status reports are supported, not all statuses make sense for every Provisioning mechanism.

If there exists a server, and status reports are supported and sent to this server, the server MAY reply with a 2xx response (typically 200 OK). MEEP implementations won't wait for this answer though.

Unless an acknowledgement is requested with a MIDlet-Install-Notify or LIBlet-Install-Notify attribute whose value includes the ack tag, the sending of any status report MUST be retried until the retry count reaches at least five (5), or it can be determined that there is no server response. The implementation MAY continue to retry the sending of the report.

The installed application suite or LIBlet MUST be made available for use even if no status reports are supported by the Provisioning mechanism, or - if supported - even if the sending of the installation status report fails, unless an acknowledgement is requested with the ack tag in the MIDlet-Install-Notify or LIBlet-Install-Notify attribute. If the ack tag is present, the installation of the application suite or LIBlet MUST fail if a server response indicates that the installation has not succeeded. When an application suite or LIBlet is updated, any ack tag SHOULD be ignored, and the updated application suite or LIBlet be made available immediately.

If the application suite or LIBlet being installed has dependencies on some dependency LIBlets, and status reports are supported, an installation status report MUST be sent to any LIBlet-Install-Notify URL specified by the dependency LIBlet vendor.

If status reports are principally supported, but a deletion status report cannot be sent for some reason (device is offline, no network being configured etc.), the deletion MUST take place nevertheless.

Note that LIBlets are not deleted along with the application suite if there are other application suites that depend on them.

The following table contains the provisioning status codes and suggested status messages as well as a description of the situation that leads to the return of the specified status in case status reports are supported.

Any status code different from 900 (Success) means that the installation has failed.

Table 3-2 : Install Status Codes and Messages
Status Code	Status Message	Situation described by this status
900	Success	Installation successful.
901	Insufficient Memory	There is insufficient memory to store the application suite or LIBlet on the device (if it is transferred from outside the device) or in the area where active application suites and LIBlets reside (if a transfer within the device is required. Before the installation, the device MUST also first verify there is sufficient disk space for persistent data using the data size specified in the JADs (if supported) of the application suite or LIBlet and the dependency LIBlets, computed as: `MIDlet-Data-Size` (or `LIBlet-Data-Size`) + Σ( `LIBlet-NonShared-Data-Size` for distinct LIBlets) + Σ (`LIBlet-Shared-Data-Size` for distinct LIBlets if it is the first binding for the LIBlet on the device) If the available persistent storage space is insufficient for that, this status is also reported.
902	Cancelled	This status can only be reported when using a Provisioning mechanism that allows the cancellation of an application suite or LIBlet installation, e.g. by supported user interaction directly on the device, or by a technician at the source of the application suite or LIBlet to be installed.
903	Loss of Service	This status can only be reported if a transfer takes place within the provisioning process, this transfer takes place via a network, and the network service is lost during installation. It may be impossible though of course to deliver the status report due to the network service outage.
904	Application Suite size mismatch	This status can only be reported, if the Provisioning mechanism supports Application Descriptors, and the size of the application suite or LIBlet to be installed (e.g. the size of the JAR, if this is the format the application suite or LIBlet installation data is provided) does not match the size specified in the Application Descriptor.
905	Attribute mismatch	This status can only be reported, if the Provisioning mechanism supports Application Descriptors, and the mandatory attributes in the descriptor `MIDlet-Name`, `MIDlet-Version`, and `MIDlet-Vendor` do not match those in the manifest of the application suite (for application suite installation) or the mandatory attributes in the descriptor `LIBlet-Name`, `LIBlet-Version`, and `LIBlet-Vendor` do not match those in the manifest of the LIBlet (for LIBlet installation). Similarly, if the Provisioning mechanism supports Application Descriptors, and the mandatory attributes in one of the dependency LIBlets' descriptor `LIBlet-Name`, `LIBlet-Version`, and `LIBlet-Vendor` do not match those in the respective dependency LIBlet JAR manifest. Also, if Application Descriptors are supported, the value of each attribute that appears in both, the manifest and Application Descriptor MUST have the identical value, otherwise this status is reported as well (with the exception of any application suite with the `MicroEdition-Profile` attribute equal to "IMP-1.0", or untrusted application suites with the `MicroEdition-Profile` attribute equal to "IMP-NG", or any application suites with the `MicroEdition-Profile` attribute equal to "IMP-NG" if security framework is not implemented). In case of OTA Provisioning, the default variant of Provisioning in MEEP 8, this status is also reported if the OTA takes place via IP, and `MIDlet-Required-IP-Version` attribute is specified, and that IP version is not supported by the implementation.
906	Invalid Descriptor	This status is reported for the following situations: if an Application Descriptor (if supported) or manifest of an Application Suite contains any instances of `LIBlet-Dependency-`<n> attributes, or of `LIBlet-Name` if any LIBlet Application Descriptor (if supported) or manifest of a LIBlet associated with the application suite contains any instances of `MIDlet-Dependency-`<n> attributes, or of `MIDlet-Name` if Application Descriptors are supported by the Provisioning mechanism, and an Application Descriptor is not formatted according to the syntax defined in Application Attributes if Application Descriptors are supported by the Provisioning mechanism, and an Application Descriptor does not contain all of the application attributes designated as mandatory by Appendix A MUST be present in the Application Descriptor if Application Descriptors are supported by the Provisioning mechanism, and an Application Descriptor contains any application attributes that are allowed only in the Jar manifest (see Appendix A)
907	Invalid Installation Data	This status is reported for the following situations: if the piece of software containing the installation data for the application suite or a LIBlet, e.g. a JAR, is not in the format expected by the Provisioning mechanism if the manifest or any other file cannot be extracted from the piece of software containing the application suite or a LIBlet, e.g. a JAR if the manifest is not in the correct syntax, or if any of the required application attributes are missing in the manifest, or if the manifest contains any application attributes that are allowed only in the JAD (see Appendix A) in case of OTA Provisioning, the default variant of Provisioning in MEEP 8, if the JAR is not available at the `MIDlet-Jar-URL` or `LIBlet-Jar-URL` attribute in the descriptor, or if a dependent LIBlet is not already installed on the device and the JAR is not available at the `LIBlet-Jar-URL` attribute in the descriptor if an Application Descriptor (if supported) or the application suite or LIBlet data are in a transport format that cannot be recognized by the implementation or cannot be converted into the required UTF-8 code.
908	Incompatible Configuration or Profile	The configuration or profile required by this application suite or LIBlet is not supported by the software stack available within the implementation on this device.
909	Application authentication failure	If the application suite or a LIBlet fails to be authenticated (see Authentication Providers for details. Also if an application suite or LIBlet from a trusted Client tries to define a (direct or indirect) dependency from a LIBlet not coming from a trusted Client (if the "vendor" part of the Dependency attribute does not refer to a trusted Client).
910	Application authorization failure	This status is reported in the following situations: if an application suite or LIBlet is not authorized for a critical permission as defined by the Requesting Permissions for an Application Suites section if an application suite or LIBlet update does not result in binding to the same Client as the original application suite or LIBlet if an application suite or LIBlet update and the already installed application suite or LIBlet is not authorized by the same Client
911	Push registration failure	If a static push registration fails for a reason other than not being authorized.
912	Deletion notification	Sent if deletion of an application suite occured.
913	Update not supported or failed	Sent if an attempt was made to update an existing application suite on the device by trying to install an application suite with same `MIDlet-Name` and `MIDlet-Vendor`, or to update an existing LIBlet on the device by trying to install a LIBlet with same `LIBlet-Name`, `LIBlet-Vendor` and `LIBlet-Version`, and updates are not supported by this implementation, or the update failed due to other reasons (e.g. because an application suite to be updated is preinstalled).
915	One or more missing dependency	The `MIDlet-Dependency-<n>` and `LIBlet-Dependency-<n>` attributes allow an application or a LIBlet to specify a dependency on an implementation of a standard optional API, a service, a proprietary API, or a LIBlet. Any dependencies that cannot be satisfied by an implementation MUST be treated as an invalid packaging and causes this status to be reported.
916	Circular LIBlet dependency	If circular dependencies are detected in the LIBlets that an application suite or LIBlet depends on.
917	LIBlet namespace collision	If the device detects a namespace collision between classes in the application suite or LIBlet and classes in the LIBlets it depends on.
918	LIBlet dependencies limit exceeded	If a device imposes an upper limit on the number of LIBlet dependencies allowed for a single application suite or LIBlet, and if that upper limit is exceeded.
919	General failure	If installation of a valid application suite or LIBlet fails due to an unexpected internal error in the device, or if installation of an application suite or LIBlet fails due an error that cannot be reflected by one of the other status codes.
920	Service Configuration Error	If a LIBlet that exports a service with a `LIBlet-Services` attribute does not contain valid service provider information for the service as defined in the Service Provider Packaging.
953	Non-Acceptable Content	If an application is protected by OMA DRM and the device cannot parse it.