1062558 - Find my Device app launches when unlocking the device, even when FMD is disabled.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: FindMyDevice, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 1

[Peter deHaan [:pdehaan]]

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

Comment 2

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

This looks like a legit bug to me.

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

Comment 3

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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

Comment 4

[Guilherme Gonçalves [:ggp]]

(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.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 6

[vkrishnamoorthy]

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

Comment 7

[JR Conlin [:jrconlin,:jconlin]]

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.

Comment 8

[Guilherme Gonçalves [:ggp]]

(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.

Comment 9

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 12

[Guilherme Gonçalves [:ggp]]

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).

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 14

[Dietrich Ayala (:dietrich)]

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

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 16

[Guilherme Gonçalves [:ggp]]

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).

Comment 17

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

(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?

Comment 19

[bhavana bajaj [:bajaj]]

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

Comment 20

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

(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

Comment 21

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

(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?

Comment 23

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

(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()?

Comment 24

[Guilherme Gonçalves [:ggp]]

(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.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

(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.

Comment 26

[vkrishnamoorthy]

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.

Comment 27

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 28

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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.

Comment 29

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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

Comment 30

[bhavana bajaj [:bajaj]]

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

Comment 31

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Attachment: Github PR 24859

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

Comment 32

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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 :-)

Comment 33

[Guilherme Gonçalves [:ggp]]

Comment on attachment 8500784 [details] [review]
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!

Comment 34

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Comment on attachment 8500784 [details] [review]
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?

Comment 35

[Guilherme Gonçalves [:ggp]]

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #34)
> Comment on attachment 8500784 [details] [review]
> 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.

Comment 36

[Kevin Grandon :kgrandon]

Comment on attachment 8500784 [details] [review]
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 :)

Comment 37

[Guilherme Gonçalves [:ggp]]

Comment on attachment 8500784 [details] [review]
Github PR 24859

Thanks, Kevin!

Comment 38

[Dietrich Ayala (:dietrich)]

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

Comment 39

[Steven Yang [:styang]]

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.

Comment 40

[Evelyn Hung]

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

Comment 41

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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 ...

Comment 42

[Sherman Chen [:chens] (inactive)]

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?

Comment 43

[Kai-Chih Hu [:khu]]

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

Comment 44

[Sherman Chen [:chens] (inactive)]

Attachment: Pull request to v2.1

: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?

Comment 45

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

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?

Comment 46

[Sam Penrose]

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.

Comment 47

[Guilherme Gonçalves [:ggp]]

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

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

Comment 48

[Sherman Chen [:chens] (inactive)]

Comment on attachment 8548746 [details] [review]
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!

Comment 49

[Keven Kuo [:kkuo]]

Change this case as 2.1+ and Sherman as owner.

--
Keven

Comment 50

[Guilherme Gonçalves [:ggp]]

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

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

Comment 51

[Sherman Chen [:chens] (inactive)]

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

Hi :ggp,

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

Comment 52

[Guilherme Gonçalves [:ggp]]

Comment on attachment 8548746 [details] [review]
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+.

Comment 53

[Sherman Chen [:chens] (inactive)]

Comment on attachment 8548746 [details] [review]
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!

Comment 54

[Sherman Chen [:chens] (inactive)]

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

Fixing unit test, cancel r?

Comment 55

[Sherman Chen [:chens] (inactive)]

Comment on attachment 8548746 [details] [review]
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!

Comment 56

[Guilherme Gonçalves [:ggp]]

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

Looks good, thank you!

Comment 57

[Kevin Grandon :kgrandon]

Comment on attachment 8548746 [details] [review]
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!

Comment 58

[Sherman Chen [:chens] (inactive)]

Comment on attachment 8548746 [details] [review]
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

Comment 59

[Sherman Chen [:chens] (inactive)]

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

Comment 60

[bhavana bajaj [:bajaj]]

waiting for master landing here before branch uplift.

Comment 61

[Sherman Chen [:chens] (inactive)]

I'm not requesting for uplift, attachment 8548746 [details] [review] 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?

Comment 62

[bhavana bajaj [:bajaj]]

(In reply to Sherman Chen [:chens] from comment #61)
> I'm not requesting for uplift, attachment 8548746 [details] [review] 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?

Comment 63

[KTucker [:KTucker][Inactive 3/4/2016]]

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

Comment 64

[Sherman Chen [:chens] (inactive)]

(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.

Comment 65

[Sherman Chen [:chens] (inactive)]

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

Comment 66

[Ryan VanderMeulen [:RyanVM]]

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

Comment 67

[Sherman Chen [:chens] (inactive)]

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

Comment 68

[Alissa（leave from Mozilla）]

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

Comment 69

[Alissa（leave from Mozilla）]

Attachment: Screenshot from 2015-06-16 03#3a20#3a01.png

Comment 70

[Alissa（leave from Mozilla）]

Attachment: logcat