Share via


Requirements for Making Applications FDRM Enabled

4/8/2010

Applications can be FDRM-enabled by calling the generic Windows Mobile FDRM APIs. If an application is using the Windows Mobile FDRM APIs, the application must not compromise the FDRM content or use it in any way other than according to the FDRM rules and restrictions. Applications are required to call the Windows Mobile FDRM APIs explicitly to access protected content. When applications call the Windows Mobile FDRM APIs, notifications specific to the FDRM engine are returned to them.

Note

The methods to enable DShow filters for FDRM is different than the methods required by other applications. FDRM-enabled applications must conform to all the FDRM use rules. For more detailed use definitions, refer to the FDRM engine restrictions or operator requirements provided by your FDRM engine provider. For example, OMA DRM V1.0 is an example of a DRM engine.

The following list shows the requirements for making applications FDRM-enabled:

  1. Enable applications to access DRM-protected content by calling the Windows Mobile FDRM APIs. For more information, see the FDRM API Reference.

    Note

    Applications should not show an error dialog when an error is returned from the FDRM engine.

  2. Before it accesses content, the application must verify that it has valid rights.

    • If content rights have expired, access to any form of the content by the user must be prevented.
    • If content rights are valid, the application must commit rights to the FDRM engine before content use and preview.
      For information about when to commit rights during various use and preview scenarios, see the Rights Commitment Table.
      When a preset sound or image content has expired for a ring tone or home screen, the application must use the default content. The FDRM engine does not inform the user of a reversion to the default content.
      Applications that persist content on the device for an extended period of time with no definite closing of the application should re-verify rights periodically. An example of an application that persists content is a home screen that persists background images. There is no definite time the home screen closes. The recommended periodic timeframe for re-verifying rights is specified in the PersistentView registry settings and is configured by OEMs.
  3. Prevent saving modified versions of FDRM-protected content.

  4. Allow the FDRM engine to show the FDRM UI if applicable.

  5. Prevent forwarding content that is locked to the device. The exceptions to this requirement are limited to the forwarding of content by storing it on removable storage or backing it up by using ActiveSync in protected format.
    For example, you can meet this requirement by using either of the following methods:

    • Disable the forward option, provide no other UI, and block the forward request.

    • Use the FDRM engine UI to notify the user that content cannot be forwarded. Display the notification before you block the forward request.

      Note

      Enable forwarding of FDRM-protected content that is not locked to the device.

  6. The following list shows what to do if the menu has a properties UI:

    • Add a Protected Status line item if appropriate.
    • Add a new menu item or SoftKey to access the FDRM engine Content Protection properties for protected content.
  7. Provide FDRM enabling list views, including messaging lists, for example for message services such as MMS, or file explorer.

    • Protected images may be shown as a thumbnail before expiration without adjusting rights status.
    • Expired content should be differentiated from other content by using a standard Windows Mobile FDRM expired icon, if provided.
    • There is no requirement to differentiate between protected and unprotected content.
      If you scroll through a list view that automatically renders content, wait for the delay time specified as Delay in the OEM configured registry settings. After the delay time, continue with rights verification and commitment if the content is used.
  8. Messaging applications must conform to the Rights Commitment Table and relevant standards for FDRM enabling message previewing and viewing.

  9. Applications that are capable of downloading or receiving FDRM-protected content must call the FDRM engine to help protect the content on the device safely.

  10. Applications that are capable of sending FDRM-protected content that is not locked to the device must use the FileDrmCreateForwardableContent function so that the content is packaged correctly for the sending or receiving application.

  11. An application that has been FDRM-enabled must maintain a minimal delay when it uses FDRM content. When an FDRM-enabled application uses FDRM-protected content, the delay before the start of using, displaying, or playing all content must not be increased more than 500 milliseconds because the FDRM-enabled application uses the FDRM functions.

  12. Applications must check for changes in the FDRM rights store. The FDRM rights store is the FDRM engine provider's store.

    Note

    Applications are not notified of rights updates.

  13. Applications must perform normally if an FDRM client is not included on the Windows Mobile device. However, applications that are not FDRM-enabled will not be granted access to FDRM-protected content.

  14. Applications must conform the recommended application flow for FDRM-protected content.

The following illustration shows an example of the application flow for FDRM-protected content.

Bb446757.cf9ac857-1dcd-44b6-b420-0fb58d5b77f3(en-us,MSDN.10).gif

See Also

Reference

Rights Commitment Table

Concepts

FDRM Application Development
FDRM Application Development