Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Description • 10 years ago

I'm not sure what causes this but I see FMD launching itself a little while after startup even though I don't have it enabled.  We shouldn't be doing that, as it wastes memory and other resources.

	Peter deHaan [:pdehaan]
	Comment 1 • 10 years ago

Filed in GitHubs as https://github.com/mozilla-services/FindMyDevice/issues/277

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 2 • 10 years ago

This looks like a legit bug to me.

See discussion here for more: https://bugzilla.mozilla.org/show_bug.cgi?id=938901#c14

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 3 • 10 years ago

I'm not sure about blocking 2.1 on this, though. FMD is extraordinarily low on developer time.

	Guilherme Gonçalves [:ggp]
	Comment 4 • 10 years ago

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #2)
> This looks like a legit bug to me.
> 
> See discussion here for more:
> https://bugzilla.mozilla.org/show_bug.cgi?id=938901#c14

This comment is outdated. We do everything listed in it from the System app now (apps/system/findmydevice_launcher.js), and as a result the FMD app doesn't need to be launched on startup.

If, however, you once enabled FMD and then disabled it, there will be alarms waking up the FMD app periodically so it pings the server, and due to the changes introduced in bug 1030249, this will happen even while FMD is disabled. I believe these alarms could explain this bug (a logcat with Gaia debug traces enabled would let us know for sure.)

I don't think anything should stop us from changing our behavior while disabled so we only notify the server once and never set alarms, but we should run this by the server-side folks too.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 5 • 10 years ago

Yeah, that's possible.  I believe I did enable FMD at one point.  Won't be able to check anything until next week though.

	vkrishnamoorthy
	Comment 6 • 10 years ago

given that the issue only occurs in some cases, should we remove it from the nom list? 

Also NI JR for comments on ggp's proposal in comment 4

	JR Conlin [:jrconlin,:jconlin]
	Comment 7 • 10 years ago

The server only replies to pings, and generally doesn't instigate them. Another possibility not mentioned here is if SimplePush is used, it may request FMD to wake up. I think that ggp noted that if it's disabled, FMD either unregisters from SimplePush or just ignores the wake request. The server doesn't delete the Push URL (except when the device is deleted).

In any case, whatever ggp recommends for the client is fine by me.

	Guilherme Gonçalves [:ggp]
	Comment 8 • 10 years ago

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #7)
> ... if it's disabled, FMD either unregisters from SimplePush or just ignores the wake request. The
> server doesn't delete the Push URL (except when the device is deleted).

We just ignore it, but retain the push endpoint, and we don't automatically close the app even when we ignore it (though we probably will once bug 1040588 is done). I'd be surprised if it turned out to be push that's causing the app to wake up here.

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 9 • 10 years ago

Hey Kyle - Are you still able to repro this bug? If so, would you mind enabling debug traces and attaching a logcat? Thanks - Jared

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 10 • 10 years ago

STR:

1. Factory reset a device.
2. Go through FTU/etc
3. Arrive at the homescreen.  Look at b2g-info/ps, see that FMD is not running.
4. Go into settings and activate the lockscreen.
5. Turn the screen off and on again
6. Unlock the device.  Look at b2g-info/ps, see that FMD is now running.

This is a bug in the system app integration, afaict.  We shouldn't be launching FMD if it's not enabled.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 11 • 10 years ago

This also affects the performance of the device since the unlock animation/etc is now competing against FMD launching for resources.

	Guilherme Gonçalves [:ggp]
	Comment 12 • 10 years ago

Great, thanks Kyle. So this is not related to alarms, but rather to the fact that we wake up the FMD app to cancel commands when the screen is unlocked (bug 1027749). This is the relevant part of the code: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/findmydevice_launcher.js#L69

It shouldn't be hard to tweak it so that we never launch the app when disabled. About delaying the animation, I supposed we could wait a few milliseconds before launching the app, but maybe the best approach would be to first check with the lockscreen folks whether there's a more suitable event we should be acting on, instead of 'lockscreen-appclosing' (ideally, one that fires after the animation).

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 13 • 10 years ago

I just assumed that this was happening at the same time as the animation.  If it's actually happening after the animation completes that's great.

	Dietrich Ayala (:dietrich)
	Comment 14 • 10 years ago

Kyle, triage is reviewing this to evaluate blocking for 2.1. Does this visibly impact lockscreen performance?

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 15 • 10 years ago

I don't know.  If the second half of comment 12 is correct it does not.

	Guilherme Gonçalves [:ggp]
	Comment 16 • 10 years ago

Just to be clear: I don't know when 'lockscreen-appclosing' fires relative to the lockscreen animation. I'm only suggesting that, in case it turns out to fire during the animation, we switch to another event (which will require coordinating with the lockscreen team if we need to add a new event for this).

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 17 • 10 years ago

I think we could switch to the 'lockscreen-appclosed' event, but I'm not sure it is necessary.

Based on some semi-recent slides[1], and confirmed by manually setting listeners in the WebIDE debugger, the sequence of events is:

1. "lockscreen-appclosing" fires
2. lockscreen animation occurs
3. "lockscreen-appclosed" fires

What's funny is that grepping through the system app for these two events is inconclusive: it seems that both events are used in rather similar situations. I'm not sure if it is really important or not for us to change the event we're listening to.

Maybe Alive can educate us a bit ^_^

[1] see slide 58: http://www.slideshare.net/DavidSkyAlive/fxos-window-management-101

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 18 • 10 years ago

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #17)
> I think we could switch to the 'lockscreen-appclosed' event, but I'm not
> sure it is necessary.
> 
> Based on some semi-recent slides[1], and confirmed by manually setting
> listeners in the WebIDE debugger, the sequence of events is:
> 
> 1. "lockscreen-appclosing" fires
> 2. lockscreen animation occurs
> 3. "lockscreen-appclosed" fires

This is correct!

> 
> What's funny is that grepping through the system app for these two events is
> inconclusive: it seems that both events are used in rather similar
> situations. I'm not sure if it is really important or not for us to change
> the event we're listening to.
> 
> Maybe Alive can educate us a bit ^_^
> 
> [1] see slide 58:
> http://www.slideshare.net/DavidSkyAlive/fxos-window-management-101

Hey, it depends on your use case. What's the call flow the FMD in this bug, could you please elobrate?

	bhavana bajaj [:bajaj]
	Comment 19 • 10 years ago

jared/:ggp,

Can you help here? Triage asked if the impact to the lockscreen perf was visible, and looks like there was some back and forth on the implementation. I am not certain of the user impact here or would atleast need a vidyo to look at to make a call.

From the read on the comments thus far, I do not think this would block the release for 2.1 nevertheless given the perf gain we want this fixed. If its low risk and is done before FC(Oct 13) we could even consider uplifting the improvement to 2.1

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 20 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #18)
> 
> Hey, it depends on your use case. What's the call flow the FMD in this bug,
> could you please elobrate?

Sure!

1. Suppose you thought your phone was lost, so you used FMD to lock it remotely and set it to ring.
2. Suppose that you find your device, then unlock the lockscreen.
3. At this point, you have proved you own the device, so we want to wait until the lockscreen animation is done, then wake the FMD app, and have it clear the ring and lock commands[1].

Right now, we set a setting and wake the FMD app after 'lockscreen-appclosing' fires. Is this going to have negative performance impact on the lockscreen animation? Do we need to switch to 'lockscreen-appclosed'?

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/findmydevice_launcher.js#L69-L76

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 21 • 10 years ago

Hi Bhavana - I will ni? you when I get a response from Alive and I'll translate it into non-technical terms :-)

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 22 • 10 years ago

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #20)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #18)
> > 
> > Hey, it depends on your use case. What's the call flow the FMD in this bug,
> > could you please elobrate?
> 
> Sure!
> 
> 1. Suppose you thought your phone was lost, so you used FMD to lock it
> remotely and set it to ring.
> 2. Suppose that you find your device, then unlock the lockscreen.
> 3. At this point, you have proved you own the device, so we want to wait
> until the lockscreen animation is done, then wake the FMD app, and have it
> clear the ring and lock commands[1].
> 
> Right now, we set a setting and wake the FMD app after
> 'lockscreen-appclosing' fires. Is this going to have negative performance
> impact on the lockscreen animation? Do we need to switch to
> 'lockscreen-appclosed'?
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> findmydevice_launcher.js#L69-L76

I believe lockscreen-appclosed is better for you.
(Still not sure why this is related to this bug summary)

BTW, use settings to launch fmd is a bad pattern. Do you have a bug opened to fix it?

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 23 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #22)

Hi Alive,

Thanks for the info. I have a couple of followup questions:

> 
> I believe lockscreen-appclosed is better for you.
> (Still not sure why this is related to this bug summary)

Do you think lockscreen-appclosing will have negative performance impact on the lockscreen that would affect users? I'm still not clear whether this change is important enough to need uplift.

> BTW, use settings to launch fmd is a bad pattern. Do you have a bug opened
> to fix it?

Yes, there is much room for improvement in FMD. Would you suggest instead using mozApps.mgmt.getAll() to get an App object, then call fmdApp.launch()?

	Guilherme Gonçalves [:ggp]
	Comment 24 • 10 years ago

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #23)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #22) 
> > BTW, use settings to launch fmd is a bad pattern. Do you have a bug opened
> > to fix it?
> 
> Yes, there is much room for improvement in FMD. Would you suggest instead
> using mozApps.mgmt.getAll() to get an App object, then call fmdApp.launch()?

Note that we don't really use a setting to launch the FMD app, but rather we use an IAC message (see shared/js/findmydevice_iac_api.js). We do launch FMD in response to settings being changed, though, if that's what you mean.

Jared's proposal would replace the IAC API with mozApps when launching the app. I'm ok with that, if it brings any benefit, but it's not clear to me whether it does.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 25 • 10 years ago

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #23)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #22)
> 
> Hi Alive,
> 
> Thanks for the info. I have a couple of followup questions:
> 
> > 
> > I believe lockscreen-appclosed is better for you.
> > (Still not sure why this is related to this bug summary)
> 
> Do you think lockscreen-appclosing will have negative performance impact on
> the lockscreen that would affect users? I'm still not clear whether this
> change is important enough to need uplift.

I will say maybe because there's no data now.
Do you regularly launch FMD every time when lockscreen is unlocking/closing? If so it's a problem.

> 
> > BTW, use settings to launch fmd is a bad pattern. Do you have a bug opened
> > to fix it?
> 
> Yes, there is much room for improvement in FMD. Would you suggest instead
> using mozApps.mgmt.getAll() to get an App object, then call fmdApp.launch()?

mozApps.getSelf then launch is what you want.

BTW if you have some time I want to know more about FMD - how it works, how it interacts with system, how we could improve.

	vkrishnamoorthy
	Comment 26 • 10 years ago

Kyle, Alive, can we remove this from the 2.1? list? it based on my reading this does not seem to happen when the user has not enabled FMD.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 27 • 10 years ago

This does happen if you do not enable FMD.  FMD is launched every time you unlock the lockscreen, regardless of whether or not it has been enabled.

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 28 • 10 years ago

Yeah, it's also a trivial change to listen for the other event (which fires after lockscreen animation is _really_ done). I'll submit that once gaia is reopened.

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 29 • 10 years ago

Actually, I'll work on the better fix, which is not to attach the FMD listener unless the user has turned it on.

	bhavana bajaj [:bajaj]
	Comment 30 • 10 years ago

I think we can consider uplift once we know what the patch looks like keeping the risk/reward timeline in mind.

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 31 • 10 years ago

Hi :ggp,

This is basically the same patch you f+'d last week, but I've added tests for the expected behavior when FMD is disabled.

Do you have time to take a look?

Thanks,

Jared

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 32 • 10 years ago

Thanks again for the information.

> 
> BTW if you have some time I want to know more about FMD - how it works, how
> it interacts with system, how we could improve.

I'm currently working on writing some docs and building a list of refactoring bugs for FMD. I'll let you know (and email dev-gaia) when those docs are ready for feedback :-)

	Guilherme Gonçalves [:ggp]
	Comment 33 • 10 years ago

Comment on attachment 8500784 [details]
Github PR 24859

I'm holding back the r+ right now mostly because I'd like to understand the changes to MockNavigatorSettings, but it looks good overall, thanks!

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 34 • 10 years ago

Comment on attachment 8500784 [details]
Github PR 24859

Hey ggp,

Updated for review feedback, mind taking another look?

Also, I realized that you might not be able to r+, since you're not a peer on system. Which of the system peers has reviewed this code in the past?

	Guilherme Gonçalves [:ggp]
	Comment 35 • 10 years ago

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #34)
> Comment on attachment 8500784 [details]
> Github PR 24859
> 
> Hey ggp,
> 
> Updated for review feedback, mind taking another look?

Looks good. I don't care that much about the duplication change, so I'm fine with leaving it
as it is if you think it's better.

> Also, I realized that you might not be able to r+, since you're not a peer
> on system. Which of the system peers has reviewed this code in the past?

I've had :vingtetun review my system patches in the past, and :kgrandon has agreed to review this one, so I'll flag him.

	Kevin Grandon :kgrandon
	Comment 36 • 10 years ago

Comment on attachment 8500784 [details]
Github PR 24859

I've taken a look at the code and it looks fine to me. I'll double check on the module policy, because I think it makes sense to be able to delegate these, but I'll just leave an R+ and request that :ggp gives some feedback here if he has time :)

	Guilherme Gonçalves [:ggp]
	Comment 37 • 10 years ago

Comment on attachment 8500784 [details]
Github PR 24859

Thanks, Kevin!

	Dietrich Ayala (:dietrich)
	Comment 38 • 10 years ago

Triage group clearing flag. Request approval for uplift on the patch per Bhavana's comment above.

	Steven Yang [:styang]
	Comment 39 • 10 years ago

We will need the fix on 2.1S. Setting 2.1S? for triage. ni? chens and evelyn for surveying the patch for uplifting to 2.1s.

	Evelyn Hung
	Comment 40 • 10 years ago

Chens is trying to make a 2.1s patch. He will update here. Thanks.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use) Reporter
	Comment 41 • 10 years ago

(In reply to Evelyn Hung [:evelyn] from comment #40)
> Chens is trying to make a 2.1s patch. He will update here. Thanks.

It would be nice if we landed it on master at some point too ...

	Sherman Chen [:chens] (inactive) Assignee
	Comment 42 • 10 years ago

Jared, 

I'm following on pull request's comment and it says bug 1079411 will have a better way solving this. May I know when is the target date for bug 1079411, or should we have this on master first?

	Kai-Chih Hu [:khu]
	Comment 43 • 10 years ago

It may have benefits to land this to 2.2 for 256MB optimization.

	Sherman Chen [:chens] (inactive) Assignee
	Comment 44 • 10 years ago

:ggp, Jared,

I've pick Jared's patch and fix conflicts on 2.1 branch, would you review this and give some feedback if we are good to land this on 2.1?

	Jared Hirsch [:jhirsch] (he/him) (Needinfo please)
	Comment 45 • 10 years ago

Hi Kevin - I'm not sure firefox accounts works at all in a low-memory environment like 256MB. Sam might recall this more clearly.

Hi Sherman - Thanks for the patch, I'm very busy right now and I'm afraid I won't be able to review your patch in a timely manner. Maybe ggp or :gerard-majax has time?

	Sam Penrose
	Comment 46 • 10 years ago

All I recall regarding low-memory situations is that the Persona libs (some shared with FxA) were deleted from Gecko to make the latter fit in Tarako. I can certainly read any 256MB-specific Gecko patches for affected libs, but I suspect that there aren't any, and that standard acceptance tests would catch gross breakage.

	Guilherme Gonçalves [:ggp]
	Comment 47 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Thanks! I left some comments on the PR, but it's looking good to me so far.

	Sherman Chen [:chens] (inactive) Assignee
	Comment 48 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Hi :ggp,

I've addressed those comments you made and update the pull request, would you review this patch again and give some feedback? thanks!

	Keven Kuo [:kkuo]
	Comment 49 • 10 years ago

Change this case as 2.1+ and Sherman as owner.

--
Keven

	Guilherme Gonçalves [:ggp]
	Comment 50 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

I added a few more comments/questions to the PR, thanks for addressing the old ones!

	Sherman Chen [:chens] (inactive) Assignee
	Comment 51 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Hi :ggp,

I've add some comments on github, would you review this patch again? thanks!

	Guilherme Gonçalves [:ggp]
	Comment 52 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

This looks good overall. The only big thing that is missing is to make sure we add the event handlers if FMD is already enabled when the device starts up, like I mentioned in this comment: https://github.com/shamenchens/gaia/commit/c1accd5b51144f0033b565d84124a7ce6d83aae0#commitcomment-9317618 . I'd like to have one final look once you do this, please.

Also, since you're making changes to the System app and I'm not a System peer, I'm not really allowed to give you an official review+. Usually what we do in these cases is I'll give the patch a feedback+ and flag a System peer (usually :kgrandon) to look at the patch and give it the final review+.

	Sherman Chen [:chens] (inactive) Assignee
	Comment 53 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Hi :ggp, thanks for your feedback, I've addressed the comment on github, would you like to take a look? thanks!

Hi Kevin, could you also review this patch and give some feedback? thanks!

	Sherman Chen [:chens] (inactive) Assignee
	Comment 54 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Fixing unit test, cancel r?

	Sherman Chen [:chens] (inactive) Assignee
	Comment 55 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Hi :ggp, Kevin, I've updated the pr and hopefully fix integration test error and addressed comments on github. Could you review this patch and give some feedback? thanks!

	Guilherme Gonçalves [:ggp]
	Comment 56 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

Looks good, thank you!

	Kevin Grandon :kgrandon
	Comment 57 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

I'm going to just review stamp this based on comment 56 and the fact that this is just a branch patch it seems like. (I don't have time to do an in-depth review and test, so contact qa if you need that). Thanks!

	Sherman Chen [:chens] (inactive) Assignee
	Comment 58 • 10 years ago

Comment on attachment 8548746 [details]
Pull request to v2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Pre-existed situation.
[User impact] if declined: Find my device will always launch when unlock lockscreen even if it's not enabled, could have performance impact on low-end devices.
[Testing completed]: Manual test and unit test.
[Risk to taking this patch] (and alternatives if risky): Should be relative low, an observer is added to check FMD is enable or not.
[String changes made]: None

	Sherman Chen [:chens] (inactive) Assignee
	Comment 59 • 10 years ago

I'm not sure if we can add qawanted to verify 2.1 branch with this patch (attachment 8548746 [details]), so please correct me if I misused this.

	bhavana bajaj [:bajaj]
	Comment 60 • 10 years ago

waiting for master landing here before branch uplift.

	Sherman Chen [:chens] (inactive) Assignee
	Comment 61 • 10 years ago

I'm not requesting for uplift, attachment 8548746 [details] is only for 2.1 branch patch, and Jared is working on bug 1079411 for master fix with FMD refactoring. Could we land this patch on 2.1 first?

	bhavana bajaj [:bajaj]
	Comment 62 • 10 years ago

(In reply to Sherman Chen [:chens] from comment #61)
> I'm not requesting for uplift, attachment 8548746 [details] is only for 2.1
> branch patch, and Jared is working on bug 1079411 for master fix with FMD
> refactoring. Could we land this patch on 2.1 first?

I see, thanks ..yes branch path is fine given we have a working bug open for master.
What's the plan for this in 2.2?

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 63 • 10 years ago

This issue is fixed when the patch from comment 59 is applied on the Flame 2.1

Find my device is not running when looking at b2g-info

Environmental Variables:
Device: Flame 2.1
Build ID: 20150122001404
Gaia: d5f0b24894cb5848d6cf7f199f0bde508f7f2e7a
Gecko: 38ac70ca969b
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

	Sherman Chen [:chens] (inactive) Assignee
	Comment 64 • 10 years ago

(In reply to bhavana bajaj [:bajaj] from comment #62)
> I see, thanks ..yes branch path is fine given we have a working bug open for
> master.
> What's the plan for this in 2.2?

I found there's feature-b2g-2.2? flag, maybe there's triage meeting will track it down?
But I would say 2.1 FMD launcher is far from 2.2, it would be better to uplift from master to 2.2 in bug 1079411.

	Sherman Chen [:chens] (inactive) Assignee
	Comment 65 • 10 years ago

2.1: https://github.com/mozilla-b2g/gaia/commit/234ec27050481f4787f1f4750ec26f62ce5cc2c0

	Ryan VanderMeulen [:RyanVM]
	Comment 66 • 10 years ago

Based on your comments, should v2.2 be marked wontfix in this bug?

	Sherman Chen [:chens] (inactive) Assignee
	Comment 67 • 10 years ago

Yes, I think it would be better to fix 2.2 in bug 1079411 and mark wontfix in this one.

	Alissa（leave from Mozilla）
	Comment 68 • 9 years ago

This issue has beenverified as pass on v2.1&v2.1s according to the STR in comment #10
> 1. Factory reset a device.
> 2. Go through FTU/etc
> 3. Arrive at the homescreen.  Look at b2g-info/ps, see that FMD is not
> running.
> 4. Go into settings and activate the lockscreen.[The default is enabled on flame2.1]
> 5. Turn the screen off and on again
> 6. Unlock the device.  Look at b2g-info/ps, see that FMD is now running.

We use "watch adb shell b2g-info" on linux, FMD won't be launched if we didn't enable it. 

Device: Flame2.1[pass]
Build ID               20150615001205
Gaia Revision          f8b848c82d1ed589f7a1eb5cc099830c867ff1d4
Gaia Date              2015-06-08 09:48:23
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/7d767fc15126
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150615.040550
Firmware Date          Mon Jun 15 04:06:02 EDT 2015
Bootloader             L1TC000118D0

Device:2.1s[pass]
Gaia-Rev        90463896d22b564fdd3202a97ff941e6cdc502ae
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/1ead146c2edf
Build-ID        20150615001204
Version         34.0
Device-Name     scx15_sp7715ea
FW-Release      4.4.2
FW-Incremental  122
FW-Date         Thu Feb  5 12:42:58 CST 2015