WP7 Capabilities required by framework?

Dec 22, 2011 at 6:04 AM

Our app failed the WP marketplace submission due to their claim that the app requires a gyroscope, which I make no attempt to use anywhere in my code:

Comments: The application cannot be tested for compliance for Windows Phone 7 Application Certification Requirementsdue to geographic, hardware, and/or software limitation(s). The application requires a device with a gyroscope.

Is the built in Catel services for this stuff causing the requirments to be beyond what I am actually using in my app and have stated in my manifest? (just networking is all I require)

Running the marketplace test kit I see this:

[INFORMATION] : Capabilities used by application :
ID_CAP_NETWORKING
ID_CAP_PHONEDIALER
ID_CAP_SENSORS
ID_CAP_LOCATION
ID_CAP_ISV_CAMERA
ID_CAP_MEDIALIB


 

Coordinator
Dec 22, 2011 at 7:33 AM

I don't think this has to do anything with Catel using the libraries (simply because they are always available, and not instantiated as long as you don't resolve the services). What I think is that you used the Catel project templates for windows phone 7. In this project file, the capabilities are enabled by default.

To disable a capability, you can go to the Properties folder of the project, then go to WMAppManifest and remove the ID_CAP_ lines you don't need. I think that will solve the issue.

Dec 22, 2011 at 7:22 PM
Edited Dec 22, 2011 at 7:23 PM

    <Capabilities>
      <Capability Name="ID_CAP_PHONEDIALER"/>
      <Capability Name="ID_CAP_NETWORKING" />
    </Capabilities>

I had already cleaned them up before submission to the app store.  I get these warnings when I run their maketplace test tool and using the automated tests.  They are using MSIL code of the app to detect capabilities, so probably just referencing the code is enought to trigger the capability need even though its never instantiated by the app.

http://msdn.microsoft.com/en-us/library/gg180730(v=vs.92).aspx

I'll keep tinkering with this though, see if I'm just overlooking something.

Coordinator
Dec 22, 2011 at 7:43 PM

Hmmm, let me think what can be done to solve this problem. The simplest is to just remove the services, but then you need to compile Catel yourself. Another solution is to try and see if it works to no register the services (then the classes use it, but they are never instantiated).

Dec 22, 2011 at 9:26 PM

So I removed all the service classes and recompiled Catel.  The requirements detected by their tool changed to:

Result Details
[INFORMATION] : Capabilities used by application :
ID_CAP_NETWORKING
ID_CAP_PHONEDIALER
ID_CAP_MEDIALIB


 So I'll try re-submitting with this build.  As for a way around this that may be difficult without doing it in separate assemblies for each service, that you reference when you actually need it for the project perhaps.

Coordinator
Dec 23, 2011 at 4:40 PM

Thanks for the additional information. I will try some stuff with the market place tool to see if I can find a solution without creating separate assemblies.

Coordinator
Jan 6, 2012 at 2:40 PM

How did the submission go? Is your app accepted? If so, we will try to find a way to get passed certification without the hassle.

Jan 16, 2012 at 6:04 PM

I got past the capabilities part of the submissions process, just dealing with some tombstoning crashes that I hadn't tested.  Throwing a key not found in the phoneapplicationpagelogic.cs with the auto tombstoning when you hit the windows key and then go back, trying to figure it out right now.

Jan 16, 2012 at 6:52 PM

So whats going on is I navigate from one view model to the next, hit windows key to tombstone, hit back which takes you to second view model that resumes fine, hit back again and then hit the exception.  The first view model had already unhooked OnApplicationDeactivated in OnTargetControlUnloaded so the view model was never serialized for tombstone, then when browsing back the OnTargetControlLoaded was called and since PhoneApplicationService.Current.STartupMode == active it tried to resume from a tombstone that never existed.

Coordinator
Jan 17, 2012 at 8:01 AM

Strange. When the back button is pressed for the 2nd time, it should just navigate to a uri (say shop.xaml?id=15). Then, the view model should also be constructed automatically again. Only the last view model should be tombstoned.

Once the VM has been recovered from tombstone, it should not try it again. Will take a look at this.

Coordinator
Jan 17, 2012 at 8:11 AM

I quickly took a look at this file: PhoneApplicationPageLogic.cs

If it has been recovered once, it will not recover again. However, I added this fix:

case TombstoningMode.Auto:
    if (PhoneApplicationService.Current.State.ContainsKey(TombstoneKey))
    {
        byte[] data = PhoneApplicationService.Current.State[TombstoneKey] as byte[];
        if (data != null)
        {
            ViewModel = ViewModelBase.DeserializeFromTombstoning(ViewModelType, data);
        }
    }
(so it now checks whether the TombstoneKey actually exists)

Coordinator
Jan 17, 2012 at 6:50 PM

I have committed the fix.

Jan 17, 2012 at 7:01 PM

Thanks.  In the meantime I just switched it over to manual, but that fix looks like it should do the trick.