Change the Block List Example for OMA Client Provisioning

4/8/2010

The following examples show how to add and remove files that are in the device ROM to the block list by using the OMA Client Provisioning protocol. In this example the first file is added to the allow list with an optional friendly filename.

Code Example

The following example XML shows how to add two files to the block list.

<characteristic type="SoftwareDisable">
  <characteristic type="DisabledSystemFiles">
    <parm name="{FileToBlock1}" value="{FileFriendlyNameToBlock1}" />
    <parm name="{FileToBlock2}" />
  </characteristic>
</characteristic>

Code Example

The following example XML shows how to remove two files from the block list.

<characteristic type="SoftwareDisable">
  <characteristic type="DisabledSystemFiles">
    <noparm name="{FileToUnBlock1}" />
    <noparm name="{FileToUnBlock2}" />
  </characteristic>
</characteristic>

Remarks

One provisioning XML file typically contains configuration information for multiple configuration service providers. To use this example, you must replace the values as appropriate, and add the node as a child of the OMA Client Provisioning file. For information about the syntax of this file, see OMA Client Provisioning Files. For examples, see OMA Client Provisioning XML File Examples.

Binary filename values under SoftwareDisable/DisabledSystemFiles must first be converted to Unicode, then UTF-8 encoded, and then URI escaped before they are sent to the device.

For these examples, replace the information in braces {} with correct values for your system. The following table shows the meaning of the information that you must replace.

String to replace	Meaning
{FileToBlock1}	The filename of the first file to be added to the block list.
{FileFriendlyNameToBlock1}	Optional friendly name for the first block-list file. This will display in the notification dialog when the block-listed file tries to run.
{FileToBlock2}	The filename of the second file to be added to the block list.
{FileToUnBlock1}	The filename of the first file to be removed from the block list.
{FileToUnBlock2}	The filename of the second file to be removed from the block list.

If an in-ROM application is block-listed and the binary file is already on the device in the FILES section of ROM when the block list is deployed, the device will use the file to generate the file hash and add it to the revocation list. If the file is not on the device when the block list is deployed, the device cannot automatically generate the revocation hash. If the file is later added to the device the in-ROM execution of the file will be blocked, but the user can still copy the in-ROM file to RAM and execute it. To prevent this, the device manager should either reapply the in-ROM block list after the file is on the device, or put the file hash in the revocation list by using the LoaderRevocation Configuration Service Provider.

The device will restart after the block list is updated.

See Also

Reference

SoftwareDisable Configuration Service Provider

Concepts

SoftwareDisable Configuration Service Provider Examples for OMA Client Provisioning