Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
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 DM 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.

Copy Code
<Add>
  <CmdID>1</CmdID>
  <Item>
	<Target>
	 
<LocURI>./Vendor/MSFT/SoftwareDisable/DisabledSystemFiles/
{FileToBlock1}</LocURI>
	</Target>
	<Meta>
	<Format xmlns="syncml:metinf">chr</Format>
	</Meta>
	<Data>
{FileFriendlyNameToBlock1}</Data>
  </Item>
  <CmdID>2</CmdID>
  <Item>
	<Target>
	 
<LocURI>./Vendor/MSFT/SoftwareDisable/DisabledSystemFiles/
{FileToBlock2}</LocURI>
	</Target>
  </Item>
</Add>

Code Example

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

Copy Code
<Delete>
  <CmdID>1</CmdID>
  <Item>
	<Target>
	 
<LocURI>./Vendor/MSFT/SoftwareDisable/DisabledSystemFiles/
{FileToUnBlock1}</LocURI>
	</Target>
  </Item>
</Delete>
<Delete>
  <CmdID>2</CmdID>
  <Item>
	<Target>
	 
<LocURI>./Vendor/MSFT/SoftwareDisable/DisabledSystemFiles/
{FileToUnBlock2}</LocURI>
	</Target>
  </Item>
</Delete>

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 SyncBody node in an OMA DM provisioning file. For more information about the syntax of the provisioning file, see OMA DM Provisioning Files.

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 or removed from the block list.

{FileFriendlyNameToBlock1}

Optional friendly name for the first file in the block list. 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 or removed from 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