Certification Failure for IPhoneApplicationService

Oct 18, 2010 at 10:33 AM


I can now i think understand why when I submitted my app it said the app required the 'RunUnderLock' privilege. I read into this and it said something along the lines of if you disable the ApplicationIdleDetectionMode and/or UserIdleDetectionMode then you need to prompt the user you are doing so. 

I read that you have recently fixed an issue in IPhoneApplicationService whereby the default implementation does the following:

        /// <summary>        /// The application idle detection mode.        /// </summary>        public IdleDetectionMode ApplicationIdleDetectionMode        {            get { return phoneService.ApplicationIdleDetectionMode; }            set { phoneService.ApplicationIdleDetectionMode = value; }        }
        /// <summary>        /// The user idle detedction mode.        /// </summary>        public IdleDetectionMode UserIdleDetectionMode        {            get { return phoneService.UserIdleDetectionMode; }            set { phoneService.UserIdleDetectionMode = value; }        }

However, why would this cause a certification failure if your app never actually called the setter of the property to disable either of these settings? That seems strange.

I guess i'll have to way and see on the results of certification (my app has been in for nearly 7 days and is still under testing!). It would be a real shame if I have to resubmit because of this;(

Oct 18, 2010 at 3:08 PM

I'm sorry if that causes you a problem. It seams a bit extreme to me, but I got an email saying that someone's app failed because of the mere reference to that property....

Oct 18, 2010 at 3:50 PM

Oops. And I was just about to Add UserIdleDetectionMode=Disabled when my app needed to be run for a few minutes hands-free. I'll be submitting tonight, and hope that it goes through with just the property references in iPhoneApplicationService. I will follow up here if they reject it. What's weird is that the MSDN docs and submission guidelines only talk about getting user opt-in for ApplicationIdleDetectionMode, and simply reference UserIdleDetectionMode as a way to turn off automatic screen blanking, which is all I need. I don't need my app to keep running after lock; I just want to prevent it during the active cycle. Sigh.

Oct 18, 2010 at 3:59 PM

Rob, I noticed that the change c579c0a63feb only removes ApplicationIdleDetectionMode. Shouldn't UserIdleDetectionMode also be removed as well? They are both of type IdleDetectionMode.

Oct 18, 2010 at 4:29 PM

I only received an email about the one property, but I can easily remove the other as well. Give me a minute :)

Oct 18, 2010 at 4:31 PM


Oct 18, 2010 at 5:52 PM
Edited Oct 18, 2010 at 5:57 PM

Hmm. the documentation is very thin about UserIdleDetectionMode. 6.3 of the Application Submission Guidelines only talks about ApplicationIdleDetectionMode as requiring user opt-in, and thus be a cause of rejection if you did not implement that. I think I might uncomment (or add back in) the UserIdleDetectionMode property and see what happens. As I understand it, UserIdleDetectionMode is merely intended to keep the phone from locking/screen blanking while your app is already running, ApplicationIdleDetectionMode is meant to allow the app to keep running even when locked, which I don't need. If I do this local modification, I'll report back. Lots of games are using UserIdleDetectionMode.

See this forum thread: http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/fadd14ca-1bf6-47f3-a5f9-3597c7a5132e

Comments from Andreas Saudemont:

You also have a couple of options regarding the lock screen:

The UserIdleDetectionMode property of PhoneApplicationService can be set to IdleDetectionMode.Disabled, in which case the screen won't automatically lock until either the application is deactivated/closed or until the property is set back to IdleDetectionMode.Enabled.

The ApplicationUserIdleDetectionMode property of PhoneApplicationService can also be set to IdleDetectionMode.Disabled, in which case the application will keep running when the screen is locked. This has some caveats, though: 1) ApplicationUserIdleDetectionMode cannot be enabled after it has been disabled; 2) according to the application certification requirements (PDF) , you must ask the user for explicit permission plus the user must be able to switch this behavior off from the application settings; and 3) the application will still be tombstoned when the user presses the Start key.

Based on everything I've seen, I don't think using UserIdleDetectionMode is a cause for rejection, but I could be wrong. I believe that it is using (or referencing, in this case) ApplicationIdleDetectionMode, and not implementing user opt-in. I'm determined to find out - the hard way if necessary It's not like I'm losing income from a $0.99 app if it is not accepted right away :). I DO think however that Tombstoning should make sure it is (re-)Enabled, in case the user presses the Back, Windows or Search buttons, while your app has it set to Disabled, and I think I can find the place to do that in the Tombstone method. I don't care about it in Ressurect. We'll see.

Update: found another discussion thread:


Comments by Mick M:

This is true at least for ApplicationIdleDetectionMode. Refer App Cert Requirements 6.3.2 Launch Configuration of Running under a Locked Screen. I would agree though that user permission for this wouldn't be a bad idea.

Also some guidance on using UserIdleDetectionMode sensibly from the doco : It is recommended that applications that disable user idle detection implement their own form of idle detection and enable UserIdleDetectionMode when appropriate. For example, an accelerometer-based game could enable user idle detection if the accelerometer shows no activity for a period of time.

This seems fairly apt for Simon's application in question.


Oct 19, 2010 at 10:52 AM


I just got my certification results (failure but for other reason) and the property reference did mean that Microsoft included the tes plan 'Run Under Lock Screen' (which did confuse me when I initiallly submitted), but there was no failure relating to this test plan, so the property reference (at least for me) did not cause any problems. 

I've re-submitted with the latest version of CM as of yesterday and I notice that the 'Run Under Lock Screen' app requirement is no longer flagged so it should definitely not be a problem now.

Oct 19, 2010 at 10:54 AM
Edited Oct 19, 2010 at 10:54 AM

I believe ApplicationIdleDetectionMode is the thing that triggers the privilege request at least, as I said I resubmitted with yesterday's build which had the UserIdleDetectionMode on it and the flag on my submission to check for Run Under Lock privilege was removed

Oct 19, 2010 at 2:08 PM

Ok. We might add the UserIdleDetectionMode property back. I want to wait a little longer just to be on the safe side. I certainly don't want CM to be the cause of countless app cert fails....

Oct 19, 2010 at 7:25 PM

I submitted last night with a modified CM build which kept UserIdleDetectionMode, added a reset to it when tombstoned (if disabled) in the PhoneBootstrapper, and I used that setting when my app needs to guard against being timed out by the screen saver (re-enabling it when that state is complete). Run Under Lock privilege did not show up in the first analysis, and I will report back my results in a few days.

Oct 22, 2010 at 5:48 AM

First report back not good: Testing Failed, but there is a problem with the site where you get a blank page with a malformed URL when you select 'View test results', when you actually are supposed to get a pdf file listing the failed use case(s). I tried different browsers to no avail. At any rate, like Keith, I did not get the Run Under Lock flag when I submitted, so it's something else, which I remain hopeful to see someday. I posted my issue on the App Hub Technical Issues sub-forum, and no less that Laurence Moroney replied that he had had exactly the same problem. I also had found out earlier tonight at our ONETUG meeting that Russ Fustino still doesn't know the results of his failed test from several days ago. Sheesh. Keith, how long did it take to get your test results? I will update whenever...

Oct 22, 2010 at 2:16 PM

I've heard reports of various individuals not being able to get test failure results. That's horrible. When you get them, if it appears to be related to CM in any way, please send me as much info as possible. I'll try to get any necessary fix in as soon as humanly possible.

Oct 22, 2010 at 6:54 PM
Edited Oct 25, 2010 at 3:52 AM

Thanks. Rob. You are amazing for your energy. Hope you have a great CodeCamp tomorrow.

Update: I found my test results pdf attached to an email when I got home tonight. You all are gonna love this -- I had a little bit of phone border around my screen capture. That was it. I resubmitted this evening.

Update 2: I resubmitted with the new screen shots and passed with flying colors. Rob, I think it's safe to add the references tp ApplicationIdleDetectionMode and UserIdleDetectionMode back into the PhoneBootstrapper. Since I actually set UserIdleDetectionMode (Disabled when the play button is hit and my app is playing the metronome ticks., and Enabled when the stop button is pressed), I added this code to the Tombstone method in my local copy so that pressing back or search would not leave it Disabled (just before the closure and after all of the properties are persisted):

    if (phoneService.UserIdleDetectionMode == IdleDetectionMode.Disabled)
        phoneService.UserIdleDetectionMode = IdleDetectionMode.Enabled;

There is an interesting post (http://www.imaginativeuniversal.com/blog/post/2010/10/21/WP7-Deactivated-!3d-Tombstone.aspx) on 'Why Deactivated is not the same as Tombstoned'. Reading this makes me wonder if setting UserIdleDetectionMode to Disabled in the app, and if the hardware Back button is then pressed, is UserIdleDetectionMode still Disabled? Thoughts and comments welcome.

Nov 16, 2010 at 9:44 PM

Just a reminder, Rob. Are you going to, or did you already, put UserIdleDetectionMode and/or ApplicationIdleDetectionMode properties back in IPhoneService.cs (I think that's where they lived)? Assuming you will not trap a UserIdleDetectionMode reset on a call to the Tombstone method (if its disabled) I'm going to maintain my own paste of the snippet above (probably add that to OnClose as well) as needed, since it's an application level switch that should be surrendered when tombstoning.

Thanks to you both for your continued work on CM. You deserve the top spot on Justin's Wiki. Hope one of you plan to speak at the Orlando Code Camp in March.

Nov 17, 2010 at 1:28 AM

Is it confirmed then that having those problems don't cause app rejection?

Nov 17, 2010 at 8:35 PM

I can absolutely confirm that my app (MetroGnome) was certified with code that sets UserIdleDetectionMode to Disabled when the metronome is started, and which sets it to back to Enabled when that metronome is stopped, as well as when the device is tombstoned as shown by the example a few posts above in my version of the Tombstone method. I tested this on a real phone with elapsed time as well as an incoming phone call. It is my understanding that when the application is closed, UserIdleDetectionMode would fall out of scope anyway, so I'm pretty sure it doesn't need to be reset in the OnClose handler. I cannot speak for ApplicationIdleDetectionMode, since when my app is done, it's done, and I didn't need to certify against 6.3 of the Application Submission Guidelines, and thus have a user opt-in screen. Furthermore, the Capability Detection tool did not detect anything untoward in my app with this approach.

And that's about all I have to say about that :).

Nov 18, 2010 at 3:13 AM

I created a ticket to add those properties back onto the interface/adapter.

Nov 23, 2010 at 9:08 PM

PostScript: I published an update to my WP7 app using the latest build of CM which added the IdleDetectionMode properties back into the IPhoneService. I added my UserIdleDetectionMode.Enabled (if Disabled) calls in OnClose and Tombstone. It passed certification and is published, even though the capabilities report after upload included RunsUnderLock (which is not, technically true, since my app prevents lock while in a Playing state). So, the saga continues ROFLOL...