10 out of 13 rated this helpful Rate this topic

Technical Certification Requirements

Windows Phone

January 05, 2012

These requirements apply equally to an application that implements game functionality, commonly referred to as a game.

Requirement

Requirement Text

Test Steps

5.1.1 Multiple Devices Support

The application must run on any Windows Phone device, regardless of model, screen size, keyboard hardware, and manufacturer.

  1. Install your application on two or more Windows Phone devices.

  2. Verify that the application can install and uninstall without error.

  3. After testing the above, ensure your application is installed, and launch it.

  4. Comprehensively test application functionality and features to verify that there are no device-specific issues.

  5. Verify that the application does not cause the device to stop responding or crash.

5.1.2 Application Closure

The application must handle exceptions raised by the .NET Framework and not close unexpectedly. During the certification process, the application is monitored for unexpected closure. An application that closes unexpectedly fails certification. The application must continue to run and remain responsive to user input after the exception is handled.

Recommendations

When handling exceptions, an application should provide a user-friendly error message. You may present a message that is relevant to the context of the application.

  1. Launch your application.

  2. Navigate throughout the application, and then close the application.

  3. Verify that unexpected behavior does not occur during the closing process.

  4. Verify that the application remains responsive to user input and user interaction following an application error.

5.1.3 Application Responsiveness

If an application performs an operation that causes the device to appear to be unresponsive for more than three seconds, such as downloading data over a network connection, the application must display a visual progress or busy indicator.

  1. Launch your application.

  2. Thoroughly test the application features and functionality.

  3. While testing the application, verify that the application does not become unresponsive for more than three seconds.

  4. Verify that a progress indicator is displayed if the application performs an operation that causes the device to appear to be unresponsive for more than three seconds.

  5. If a progress indicator is displayed, verify that the application provides the user with an option to cancel the operation being performed.

Caution note Caution:

Windows Phone OS 7.1 includes a new Fast Application Switching feature. For the best user experience, Microsoft recommends that an application resumes properly within 1 second of when the device is unlocked, the hardware Back button is pressed, or the user resumes the application from the TaskSwitcher. For more information, see Multitasking for Windows Phone and Execution Model for Windows Phone.

Requirement

Requirement Text

Test Steps

5.2.1 Launch Time

  • The application must render the first screen within 5 seconds after launch.

    The application may provide a splash screen image in a file called SplashScreenImage.jpg in the root of the XAP package while the application is still trying to load.

  • Within 20 seconds after launch, the application must be responsive to user input.

  1. Launch your application.

  2. Verify that the application renders the first screen within 5 seconds of launching.

  3. Verify that the application is responsive to user input within 20 seconds of launching.

5.2.2 Application Responsiveness After Being Closed

A Windows Phone application is closed and terminated by the OS when the user navigates away from the application. When an application is started after being closed, its launch time must meet the requirements in Section 5.2.1 – Launch Time.

  1. Launch your application.

  2. Close the application using the Back button, or by selecting the Exit function from the application menu.

  3. Launch your application again.

  4. Verify that the application launches normally within 5 seconds, and is responsive within 20 seconds of launching.

5.2.3 Application Responsiveness After Being Deactivated

A Windows Phone application is deactivated when the user presses the Start button or if the device timeout causes the lock screen to engage. A Windows Phone application is also deactivated with it invokes a Launcher or Chooser API.

A Windows Phone OS 7.0 application is tombstoned (terminated) when it is deactivated. A Windows Phone OS 7.1 application becomes Dormant when it is deactivated but can be terminated by the system when resource use policy causes it to tombstone.

When activated after termination, the application must meet the requirements in Section 5.2.1 – Launch Time.

For more information and best practices, see Execution Model Overview for Windows Phone.

  1. Launch your application.

  2. Close the application using the Start button. Or, if your application does not run under a locked screen.

  3. Launch your application again.

  4. Verify that the application launches normally within 5 seconds, and is responsive within 20 seconds of launching.

  5. If your application includes pause functionality, pause the application.

  6. Launch your application again.

  7. Verify that the application launches normally within 5 seconds, and is responsive within 20 seconds of launching.

5.2.4 Use of Back Button

To maintain a consistent user experience, the Back button must only be used for backwards navigation in the application. The following four requirements relate to use of the Back button.

5.2.4.1 – Back Button: Previous Pages

Pressing the Back button must return the application to the previous page or return to any previous page within the back stack.

  1. Launch your application.

  2. Navigate through the application.

  3. Press the Back button.

  4. Verify that the application closes the screen that is in focus and returns you to a previous page within the back stack.

5.2.4.2 – Back Button: First Screen

Pressing the Back button from the first screen of an application must close the application.

  1. Launch your application.

  2. Press the Back button.

  3. Verify that either the application closes without error, or allows the user to confirm closing the application with a menu or dialog.

5.2.4.3 – Back Button: Context Menus and Dialogs

If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and return the user to the screen where the context menu or dialog box was opened.

  1. Launch your application.

  2. Navigate through the application.

  3. Display a context menu or dialog.

  4. Tap the Back button.

  5. Verify that the context menu or dialog closes and returns you to the screen where the context menu or dialog was opened.

5.2.4.4 – Back Button: Games

For games, when the Back button is pressed during gameplay, the game can choose to present a pause context menu or dialog or navigate the user to the prior menu screen. Pressing the Back button again while in a paused context menu or dialog closes the menu or dialog.

  1. Launch your game.

  2. Begin playing the game.

  3. Tap the Back button.

  4. Verify that the game pauses

5.2.5 Memory Consumption

An application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.

You can use the following classes to query the amount of memory that is available on the device and modify the application behavior at runtime to take advantage of additional memory:

The DeviceTotalMemory value indicates the physical RAM size in bytes. This value is less than the actual amount of device memory. For an application to pass certification, Microsoft recommends that the value returned by ApplicationPeakMemoryUsage is less than 90 MB when DeviceTotalMemory is less than or equal to 256 MB.

5.2.6 Trial Applications

An application must not invoke either of the Trial APIs in a tight loop. For example, a game application must not invoke either of the Trial APIs while in a game loop. The API should be called infrequently and the value returned should be cached. For information about best practices for creating trial applications, see Creating Trial Applications for Windows Phone.

  1. Launch the trial version of your application.

  2. Launch the full version of your application.

  3. Compare the performance of the trial and full versions of your application.

  4. Verify that the performance of the trial version of your application meets the performance requirements in section 5.2.1 through 5.2.5.

Requirement

Requirement Text

Test Steps

5.3.1 – Phone Calls

The application must not delay or prevent the user from initiating a phone call, answering an incoming phone call, or ending a phone call.

  1. Ensure that the phone has a valid cellular connection.

  2. Launch your application.

  3. Receive an incoming phone call.

  4. Verify that the quality of the phone call is not negatively impacted by sounds or vibrations in your application.

  5. End the phone call.

  6. Verify that the application returns to the foreground and resumes.

  7. Close the application by tapping the Start button.

  8. Verify that you can successfully place a phone call.

5.3.2 – SMS and MMS Messages

The application must not delay or prevent the user from sending or receiving SMS or MMS messages.

Sending a SMS or MMS message

  1. Ensure that the phone has a valid cellular connection.

  2. Ensure that the phone is not in Airplane mode by viewing the phone Settings page.

  3. Launch your application.

  4. Close the application by tapping the Start button.

  5. Verify that a SMS or MMS message can be sent to another phone.

Receiving a SMS or MMS message

  1. Confirm the phone has a valid cellular connection.

  2. Ensure that the phone is not in Airplane mode by viewing the phone Settings page.

  3. Send SMS and MMS messages to the phone and wait for up to 10 minutes.

  4. Close the application by tapping the Start button.

  5. Verify that notifications regarding the SMS or MMS messages are displayed on the phone either from within the application, or within 5 seconds after the application is closed.

5.3.3 - Application Responsiveness With Incoming Phone Calls and Messages

The application must not stop responding or close unexpectedly when there is an incoming phone call, SMS message, or MMS message.

  1. Ensure that the phone has a valid cellular connection.

  2. Ensure that the phone is not in Airplane mode by viewing the phone Settings page.

  3. Receive an incoming phone call, SMS message or MMS message.

  4. Verify that the application does not stop responding or close unexpectedly when the notification is received.

  5. After verifying the above step, tap on the message notification or receive the incoming phone call.

  6. If an incoming phone call was received, end the phone call.

  7. If an incoming phone call was received, verify that the application is displayed to the user and the application does not stop responding or close unexpectedly when the phone call is ended.

  8. If a message was received, verify that you can return to the application by pressing the Back button.

Requirement

Requirement Text

Test Steps

5.4.1 Malicious Software Screening

The application must be free of viruses, malware, and any malicious software.

  1. Launch your application.

  2. Scan the application for malware.

  3. Verify that there are no viruses, malware or malicious software in the application.

5.4.2 MSIL Type Safety Verification

Windows Phone implements multiple sandbox mechanisms to help protect the integrity of the device and the applications running on the device. The Common Language Runtime (CLR) on Windows Phone relies on the type-safe execution of application code to help enforce security and isolation mechanisms.

An application must implement type-safe MSIL code to pass certification. For more information about C# unsafe code, see Unsafe Code and Pointers (C# Programming Guide).

5.4.3 Security Transparency Verification

The Windows Phone Application Platform does not allow an application to run security critical code. An application that invokes security critical code will fail certification.

For more information about the .NET Security model, see Security Changes in the .NET Framework 4.

Requirement

Requirement Text

Test Steps

5.5.1 – Language Validation

The product description and UI text of your application must be localized to each language the application supports.

  1. Review the product description of your application and verify that it is localized to the target language.

  2. Launch your application.

  3. Verify that the UI text of your application is localized to the target language.

5.5.2 – Content and Themes

Application content, such as text and visual elements, must be visible and legible regardless of the phone theme. For example, if the phone theme changes from black background to white background, the text and visual elements of your application must be visible or legible.

  1. Navigate to the Settings page in the app list.

  2. Tap theme and change Background to 'Dark'.

  3. Launch your application.

  4. Verify that the text and visual elements of the application are visible and legible.

  5. Navigate back to the theme page under Settings, and change Background to 'Light'

  6. Launch your application.

  7. Verify that the text and visual elements of the application are visible and legible.

Requirement

Requirement Text

Test Steps

Technical Support Information

An application must include the application name, version information, and technical support contact information that are easily discoverable.

  1. Launch your application.

  2. Verify that the application displays the application name, version information and technical support contact information in a location that is easy to discover.

Did you find this helpful?
(1500 characters remaining)