Additional requirements for specific app types for Windows Phone
May 31, 2013
An app that uses specific phone capabilities must meet the following additional requirements.
A location aware app can access the phone location by using the classes in the System.Device.Location namespace. For more information, see Location for Windows Phone 8.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.1 - Location aware app | Users have the ability to turn off the Location Service on the phone from the System Settings page. Location aware apps must remain responsive when the Location Service is turned off on the phone. Recommendations
|
|
The Microsoft Push Notification Service provides a dedicated, resilient, and persistent channel for pushing notifications from a web service to a mobile device. For more information, see Push notifications for Windows Phone. For more information about Tiles, see Tiles for Windows Phone.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.2.1 – Configurable functionality | In the UI or Settings menu, the app must provide the user with the ability to independently disable toast notifications. All apps that use toast notifications must also adhere to section 2.9 of the App policies for Windows Phone. |
|
6.2.2 – Toast notification opt-in | The first time that your app uses the BindToShellToast() method, the app must ask the user for explicit permission to receive toast notifications. Recommendations Use "Allow toast notifications." as the text label for this setting. Important Note:You are only required to ask the user for permission on the first use of the BindToShellToast method. You are not required to ask the user for permission again. For example, if your app calls BindToShellToast each time your app loads, you would only prompt the user the first time the app is launched. |
|
It is possible that an app in the foreground can continue to run when the phone screen is locked by setting the ApplicationIdleDetectionMode property.
When your app runs under a locked screen, it could consume power outside of the user's control and could add to their data costs without their awareness. For this reason, your app must minimize power usage when running under a locked screen, and adhere to the following requirements.
Important Note: |
|---|
For the best user experience in apps that target Windows Phone OS 7.1, Microsoft strongly recommends that you utilize the following new features while your app runs under lock, instead of setting the ApplicationIdleDetectionMode property:
|
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.3.1 - Minimize power usage when running under a locked screen | All apps that run under a locked screen must stop any UI updates, active timers, and other non-critical processing when notified that the screen is locked. |
|
6.3.2 - Apps that play audio under a locked screen | ||
6.3.2.1 - Audio playback and battery life under a locked screen | The minimum battery life of the phone must be greater than six hours while the app plays audio under a locked screen. |
|
6.3.2.2 - Idle behavior under a locked screen | If an app is not playing audio when the phone is locked, the app must remain idle while the phone screen is locked. |
|
6.3.3 - Apps that do not play audio under a locked screen | ||
6.3.3.1 - Minimum battery life under a locked screen | The minimum battery life of the phone must be greater than 120 hours while the app is running under a locked screen. |
|
An app in the Music + Videos Hub provides an integrated music and video experience on the phone as its primary function. When an app calls the MediaHistory or MediaHistoryItem classes, it is considered to be a Music + Videos Hub app and will appear in the Extras list (known in Windows Phone OS 7.0 as Marquee list) when installed on the phone. The submission process detects that the app uses these classes and automatically updates the hub type to Music + Videos in the Windows Phone app manifest file.
The following requirements apply only to a Music + Videos Hub app.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.4.1 - Music + Videos Hub app functionality | The app functionality must be related to video and/or music media playback. |
|
6.4.2 - Music + Videos Hub History and Now Playing list functionality | When a user taps a tile associated with the app in the History or Now Playing list of the Music + Videos Hub, the app must either (a) launch the playback experience for the content identified in the tile, or (b) launch a view that provides information about the previously played media content and allows the user to resume. The app must not launch to the main or default landing page when the user taps on a content tile in the History, Now Playing, or New list of the Music + Videos Hub. |
|
6.4.3 - Music + Videos Hub History list updates | The app must update the History list of the Music + Videos Hub when the app plays media. |
|
6.4.4 - Music + Videos Hub New list updates | The app must update the New list of the Music + Videos Hub when media is added to the device or when the user creates an "object" in the app (for example, a radio station is created, a music tag is created.) |
|
6.4.5 - Music + Videos Hub containers | When the media is associated with a container, the hub tile in New and History lists in the Music + Videos Hub must represent a valid container, such as album, artist, playlist, radio station, rather than individual media items. |
|
6.4.6 – Music + Videos Hub content | The hub tiles in the Music + Videos Hub must not contain advertisements, media feeds, or other unsolicited content. |
|
6.4.7 – Music + Videos Hub iconography rules | Comply with the iconography rules for the Music + Videos Hub as documented in the How to integrate with the Music and Videos Hub for Windows Phone topic. |
|
Important Note: |
|---|
Requirements in section 6.5 do not apply to Music + Videos Hub apps, as described in section 6.4. |
An app can play media in the background while it is running even when its primary function is not related to music or video. An app that plays music, audio, or sound effects must meet the following requirements:
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.5.1 – Initial launch functionality | Note:This requirement only applies to Windows Phone OS 7.1 and Windows Phone OS 8.0 XAML apps. When the user is already playing music on the phone when the app is launched, the app must not pause, resume, or stop the active music in the phone MediaQueue by calling the Microsoft.Xna.Framework.Media.MediaPlayer class. If the app plays its own background music or adjusts background music volume, it must ask the user for consent to stop playing/adjust the background music (e.g. message dialog or settings menu). This prompt must occur each time the app launches, unless there is an opt-in setting provided to the user and the user has used this setting to opt-in. |
|
6.5.2 - Configurable functionality | If an app plays background music, the app must provide the user with configurable settings for both the background music, and the background music volume. |
|
6.5.3 - Apps that play a video or audio segment | Note:This requirement only applies to Windows Phone OS 7.1 and Windows Phone OS 8.0 XAML apps. An app may interrupt currently playing music on the phone to play a non-interactive full motion video, or a non-interactive audio segment (e.g. cut-scene or media clip) without asking for user consent. An app must resume the music that was previously playing, once the app is closed. For more information on how to meet this requirement for Windows Phone OS 7.0, see Creating and Using an XNA Dispatcher Service. |
|
6.5.4 – SoundEffect and background music | The SoundEffect class must not be used to play a continuous background music track in an app. |
|
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.6.1 – Photo-editing apps: functionality | The app must implement the primary functionality associated with photo manipulation. |
|
6.6.2 - Photo-editing apps: declaration | Windows Phone OS 7.0 The Extras.xml file in the root XAP package must be valid according to the description in the Photo Extras App Extensibility for Windows Phone topic, located in the Windows Phone OS 7.0 documentation located here. Windows Phone OS 7.1 or higher The app must correctly declare an extension as described in Photo extensibility for Windows Phone. | |
6.6.3 – Photo-editing apps: launch behaviors | The app must support two kinds of launch behaviors:
|
|
6.6.4 – Photo-editing apps: photo manipulation | The app must display and allow photo manipulation for the photo that is used to launch the app. |
|
6.6.5 – Photo-editing apps: entry points | A photo-editing app must register for the correct entry point depending on the phone's OS version. For apps that target Windows Phone OS 7.0 or Windows Phone OS 7.1 Your app must register for the apps entry point. For apps that target Windows Phone 8 Your app must register for the edit entry point. For more information, see Photo extensibility for Windows Phone. |
With App Connect, your app can be launched from the share menu in the photo viewer and provide a rich user experience for sharing photos to a web service. For more information about how to extend the photos experience, see Photo extensibility for Windows Phone.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.7.1 - Photo-sharing apps: functionality | The app must implement the primary functionality associated with photo uploading and sharing. |
|
6.7.2 - Photo-sharing apps: launch behaviors | The app must support two kinds of launch behaviors:
|
|
The following requirements in section 6.8 apply only to apps developed for Windows Phone OS 7.1 or higher.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.8.1 Photos Hub apps: primary app functionality | For Windows Phone OS 7.1 or higher The primary functionality of the app must be related to the camera or to photos. |
|
The following requirements in section 6.9 apply only to apps developed for Windows Phone OS 7.1 or higher.
For more information about background audio, see Background audio overview for Windows Phone.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.9.1- User initiated background audio | For Windows Phone OS 7.1 or higher The app must not initiate background audio playback unless a user activates a discoverable UI element that the app provides. |
|
6.9.2 – Stopping background audio | For Windows Phone OS 7.1 or higher When the app is in the foreground, the app must provide the user with a discoverable UI element that allows the user to stop audio playback. |
|
6.9.3 – Universal volume control commands | For Windows Phone OS 7.1 or higher An app must stop playing audio in the background when the user taps the stop button on the universal volume control. If the playback service supports the pause action, pausing the background audio through the universal volume control must pause or restart the audio according to the user's actions. |
|
6.9.4 – Universal volume control strings | For Windows Phone OS 7.1 or higher When background audio from an app plays, the metadata sent from the app to be displayed in the universal volume control must describe the audio, such as the song, track, artist, playback status or app name. App error codes must not be displayed in the universal volume control. Advertisements and other irrelevant content are prohibited in the universal volume control. |
|
6.9.5 – Background audio streaming agent | For Windows Phone OS 7.1 or higher An app that uses the AudioStreamingAgent API must use it only to perform tasks related to audio playback and management of associated metadata. |
|
The following requirements in section 6.10 apply only to apps developed for Windows Phone OS 7.1 or higher.
For more information about background file transfers, see Background file transfers for Windows Phone.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.10.1 – User-initiated background transfers | For Windows Phone OS 7.1 or higher The app must not initiate a background transfer unless a user activates a discoverable UI element that the app provides. |
|
6.10.2 – Status of background transfers | For Windows Phone OS 7.1 or higher The app must allow a user to view the status of all active and pending background transfers through a discoverable UI element while the app is in the foreground. |
|
6.10.3 – Cancelling background transfers | For Windows Phone OS 7.1 or higher The app must provide a user with a discoverable UI element that allows the user to cancel an active or pending background transfer. |
|
The following requirements in section 6.11 apply only to apps developed for Windows Phone 8.
Apps that register one or both of the two navigation protocols, "ms-drive-to" and "ms-walk-to", must adhere to the following requirements:
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.11.1 – Navigation protocol turn by turn navigation | For Windows Phone 8 Your app must provide real-time turn by turn navigation. |
|
6.11.2 – Navigation protocol information modification | For Windows Phone 8 Your app must not modify the information received from the navigation protocols, including, without limitation:
|
|
6.11.3 - Navigation protocol latitude and longitude | For Windows Phone 8 Your app must not route to a destination other than the destination latitude and longitude provided by the navigation protocols. |
|
6.11.4 – Navigation protocol app launch | For Windows Phone 8 Your app must not launch any other app prior to providing real-time turn by turn navigation |
|
6.11.5 – Navigation protocol app launch delay | For Windows Phone 8 When your app is launched via the navigation protocol, the app must begin real-time navigation immediately unless user authentication or identification is necessary prior to launching navigation. |
|
6.11.6 – Navigation protocol access | For Windows Phone 8 You may not sell, lease or sublicense access to the navigation protocols. |
The following requirements in section 6.12 apply only to apps developed for Windows Phone 8.
Rich media apps must adhere to the following requirements. For more information about rich media apps, see Rich media extensibility for Windows Phone 8.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.12.1 – Rich media apps: functionality | When a photo is opened by using the open link in the photo viewer, the app must immediately load a unique viewing or editing experience for the photo |
|
The following requirements in section 6.13 apply only to apps developed for Windows Phone 8.
Lens apps must adhere to the following requirements. For more information about lens apps, see Lenses for Windows Phone 8.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.13.1 – Lens apps: functionality | When a lens app is launched from the lens picker, the app must immediately display the app viewfinder. If a lens app requires the user to complete either of the following actions, the app must immediately display the app viewfinder after the action is completed:
|
|
The following requirements in section 6.14 apply only to apps developed for Windows Phone 8.
VoIP apps must adhere to the following requirements. For more information about VoIP apps, see VoIP apps for Windows Phone 8.
Requirement | Requirement Text | Test Steps |
|---|---|---|
6.14.1 – Call coordinator registration | All incoming and outgoing VoIP calls must use the VoipCallCoordinator class. |
|
6.14.2 – Audio-only VoIP calls | If a user taps the audio button for a VoIP call, the app must not display a video feed of the user to the other party. |
|
6.14.3 - Raw push notifications for VoIP apps | The raw push notification type 4 must be used only for incoming VoIP calls. |
|
6.14.4 - VoIP ringtone duration | The VoIP ringtone duration must be between 5 to 120 seconds, inclusive. |
|
6.14.5 - VoIP ringtone file size | The VoIP ringtone file size must be 2 MB or less. |
|
Important Note: