Select a language to translate this page!
Powered by Microsoft® Translator
One of the things I really enjoy about developing for Windows Phone is being able to reach a diverse audience across the globe. Windows Phone users access my apps on phones from different manufacturers, all with varying capabilities and price points to meet local needs. While I benefit from the diverse audience, it does take a little planning on my part to create a great user experience and to ensure that my apps comply with the Windows Phone technical certification requirements.
In this post I’ll help you identify the phone features and hardware your app requires, and then provide guidance on how define these needs in Visual Studio.
Windows Phone uses the app manifest file to identify the software capabilities, hardware required, and memory each app requires to run correctly:
Make sure your app is not marking capabilities and requirements that it doesn’t need. Users see your app’s capabilities and requirements when they install the app, and may decide not to move forward with installation if they see that your app uses capabilities that they don’t want to enable, or that are not related to the purpose of the app.
In a scenario in which your app can provide value even when some hardware is absent, use API checks to first detect the presence of the hardware, and then to inform users if some features are disabled because of missing hardware.
The following steps explain how you can modify support for different Windows Phone capabilities in your app.
Open your project in Visual Studio, go to the Solution Explorer, and then in the Properties folder, open WMAppManifest.xml. Then, add or remove the capabilities as illustrated here:
Windows Phone 7 project
Windows Phone 8 project
If the hardware or functional capabilities you need are not listed in Visual Studio, you must manually edit the manifest file. To do this, first understand all the capabilities available, and then edit the manifest file in a text editor, such as Notepad, or directly in the code. Right-click the file in Solution Explorer, click Open With, and then edit through Notepad or ‘view code’. You turn these on by adding the correct flag:
App requires at least 90 MB of RAM
App requires at least 180 MB of RAM
App requires the front-facing camera
App requires the rear camera
App requires a phone with NFC chip
App requires a compass
App requires gyroscope to measure rotational velocity
Here’s an example of the manifest flag that shows the software, hardware, and functional capabilities:
If your app uses the Microsoft Ad Control, be sure to enable the following capabilities:
Windows Phone 7 Silverlight
Windows Phone 7 XNA
In some scenarios, capabilities are added automatically. Here are some examples:
Having a variety of phones with different price points creates opportunities to reach out to more users. Take the time to set the correct information and get your app ready to be successful on a variety of Windows Phone devices.
The following table shows examples of how capabilities appear to consumers in the web Store and on the phone:
How capabilities are shown in app details page of an app on the Windows Phone web Store
How capabilities are shown in the app details page of an app on Windows Phone
If your app targets Windows Phone 7.1, you can use the Store Test Kit to verify the capabilities that are being detected, to confirm they align with what you are expecting. The Windows Phone 8.0 SDK includes the Store Test Kit, and the Windows Phone 7 SDK requires you to install a stand-alone tool to run these tests.
Take the following steps to run the Store Test Kit for Windows Phone 7 project:
Windows Phone users appreciate having visibility into my app requirements, so that they can make an informed choice about downloading and purchasing your app. In the end, the user gets an app that performs well on their phone, and you get a better review for your apps. Everyone wins.
I’d like to hear from you. Please let me know your questions about defining capabilities, as well as suggestions for topics you’d like me to cover in future blog posts.
@bzamora unfortunately this flag is not available for WP7.5 apps. There is no way how to prevent installation of apps requiring front facing camera on WP7.5. I can only use the ID_HW_FRONTCAMERA for warning users, but that's all.
@mbarclay103, the requirements that are shown to consumers, including the sensors, are taken from the app manifest flags and taken from the third party controls. So LinkedIn either has this capability defined in the manifest flag, or uses a third party control.
@Necroman: if your app *requires* a certain capability to run (or the app will not work), make sure the HARDWARE flag is defined in the manifest, so automatically the app is not installed in phones that do not have the front facing camera. If the app can work even without the front facing camera, just make sure you have the SOFTARE capability turned on. I would think the mirror app requires a front facing camera to be useful, so double check that the HARDWARE flag (ID_REQ_FRONTCAMERA) is turned on.
@Eirenarch: in the AdControl docs it says that the phone dialer is required for 'click-to-call' ads, see here
Why the hell does the ad control require phone dialer?
I've just received email from the "The Windows Phone Certification Team", that my app "Mirror" that is using front facing camera has issues regarding the optional hardware capabilities (front camera).
The problem is the proposed solution in the mail is already implemented both for WP7 and WP8, so what should I do? There is no way how to prevent installation of my app on WP7 devices without front facing camera?
oh nice we need that in app design thank you :)
Hi, nice post. One of my pet topics. About an hour ago and before reading your post, I tweeted about the new LinkedIn app and why it requires movement and directional sensor access when there is no apparent end user feature that uses it. What do you think? pic.twitter.com/bY37eREuGe