Technical Certification Requirements
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. |
|
|
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. |
|
|
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. |
|
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 |
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
5.2.4.2 – Back Button: First Screen |
Pressing the Back button from the first screen of an application must close the application. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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
Receiving a SMS or MMS message
|
|
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. |
|
|
Requirement |
Requirement Text |
Test Steps |
|---|---|---|
|
5.4.1 Malicious Software Screening |
The application must be free of viruses, malware, and any malicious software. |
|
|
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. |
|
|
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. |
|
|
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. |
|
