In Windows Phone 8, you are responsible for specifying the correct capabilities that are used by your application in the WMAppManifest.xml file. This is a departure from Windows Phone 7, where capabilities are detected during ingestion, with the capabilities being written to the WMAppManifest.xml file – overwriting what you specified during development. There are good and bad aspects to the WP7 approach, in WP7 you and your customers got the correct list of capabilities ensuring an accurate shopping and installation experience. The drawback was that in some cases, the capabilities detection would not properly detect an assembly in your app, resulting in a failure during certification testing due to the app not functioning properly or crashing.
For the Windows Phone 8 Store Test Kit, capability detection is no longer part of the automated tests. This is still available for Windows Phone 7 apps.
With the change in capability detection, you may be tempted to just include all of the capabilities. The problem with this is certain capabilities trigger different prompts in the install experience. For example, if you have specified the ID_CAP_LOCATION capability, during installation the user will be prompted with the ‘This application is using the location API, are you sure you want to install this?’ (I’m paraphrasing) prompt. If your app is not using the Location API, the user will get a misleading prompt during installation.
Additionally the capabilities of your app are listed in the Windows Phone Store catalog. This list is generated from the manifest file. Specifying the capabilities of your app accurately will reflect the true functionality of your app to your potential customers.
See the Windows Phone 8 documentation topic ’App capabilities and hardware requirements for Windows Phone’ for information on capabilities and their related assemblies.