818955 - If secure camera and camera app is both launched, camera will failed to work, and might cause Gecko to crash

Status: RESOLVED DUPLICATE of bug 818933

(Firefox OS Graveyard :: General, defect, P1)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Enable a passcode lock, in Settings | Phone Lock (e.g. 1111)
 2. Tap power button twice, to get to lock screen.
 3. Slide up the lock animation, and tap the camera button.
   --> Notice that camera seems to work.
 4. Press "home" button to return to lock screen.
 5. Once again: Slide up the lock animation, and tap the camera button.

EXPECTED RESULTS: Functional camera.
ACTUAL RESULTS: Black screen, w/ still-camera & video-camera buttons missing.

Reporting using the recently-released "beta" dogfood build, w/ ID: 20121203114956

Comment 1

[Daniel Holbert [:dholbert]]

(I'm guessing this might have something to do with the first instance of the lockscreen-camera-app keeping a lock on the camera hardware (in the background), as it seems to do with the GPS hardware in bug 818401)

Comment 2

[Daniel Holbert [:dholbert]]

After I perform the STR, the normal camera app (launched from home screen) is broken, too.

Comment 4

[Daniel Holbert [:dholbert]]

Not a dupe of bug 816334.

That bug is about the *video* part of the camera app not taking videos (and sometimes crashing).  However, with that bug's STR, the camera app still displays whatever the camera sees.  So that bug is a video-specific thing.

This bug here is about the camera app breaking (black screen) after the first time you launch it from the lock screen.  Not video-specific -- breaks the whole app.

Comment 5

[Daniel Holbert [:dholbert]]

This might be fixed by bug 818401 -- bug 818401 comment 6 seems like it might confirm (& address) my suspicion in comment 1 here.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

BB+, P1 - smoketest blocker

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Stealing and investigating.

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

STR in comment 0 is fixed by bug 818401 -- that no longer show blank screen.

However, STR in comment 1 still trigger crashes. Below is tested with latest m-c and Otoro.

STR Recap:

1. Enable Passcode lock
2. press the power button twice to go to the lock screen
3. press camera shortcut button on lock screen to use the secure camera
4. press home button to go back
5. unlock
6. launch camera app

Expect: 

1. everything works

Actual:

1. Camera failed to show the stream and soon, Gecko crashes
log: http://pastebin.mozilla.org/1989435


STR #2:

1. Enable Passcode lock
2. unlock
3. launch camera app
4. press home to go back to home screen
5. press the power button twice to go to the lock screen
6. press camera shortcut button on lock screen to use the secure camera

Expected:

1. everything works

Actual:

1. secure camera doesn't work
2. if you unlock and go to the already launched camera app, it is also broken
3. kill it and relaunch doesn't help

Note:

Secure camera lives in the System app (in-process), while Camera app is OOP'd.


This is no longer a Gaia issue.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Gaia is doing an unsupported thing with a certified API.

Dale, did you explain why we have to have two different apps here?  I still don't understand.  Why can't we launch the camera app?

Comment 10

[Dylan Oliver [:doliver]]

Looks like a dup of bug 818933?

Comment 11

[Chiajung Hung [:chiajung]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #8)
> STR in comment 0 is fixed by bug 818401 -- that no longer show blank screen.
> 
> However, STR in comment 1 still trigger crashes. Below is tested with latest
> m-c and Otoro.
> 
> STR Recap:
> 
> 1. Enable Passcode lock
> 2. press the power button twice to go to the lock screen
> 3. press camera shortcut button on lock screen to use the secure camera
> 4. press home button to go back
> 5. unlock
> 6. launch camera app
I tried to port WebRTC capture these days, and found a similar symptom. I think the problem is:

12-13 14:40:04.066   433   450 E CAM_FD  : cam_conf open driver failed: device =/dev/msm_camera/config0: Device or resource busy!

In step 3, it will allocate the camera device via dom/camera API's from gecko process. Which will trigger android::CameraHardwareInterface to open the hardware module. However, there is no hint for it to release the hardware handle when leave. As a result, you can still launch the camera from lock screen even if the camera app launch failed, but /*no other*/ process will have any means to open camera. 

In fact, I think you can repro it by:
1. Enable Passcode lock
2. Launch camera app
3. Go to lockscreen
4. Launch camera from lockscreen

Since camera app do not release camera device, too.

Comment 12

[Chiajung Hung [:chiajung]]

As a result, I think an easy fix would be

1. Add Terminate camera to nsIDOMCamera interface
2. In Terminate, release all hardware resource
3. When camera app leaves, let it calls the Terminate to release hardware resources

By the way, I think such change must affect the init/start preview sequence of camera app.

Comment 13

[Chiajung Hung [:chiajung]]

Hmm...I found I may wrong...

This would be hard to fix from gecko side. Since dom/camera implementation lock up the camera as soon as the GonkCameraControl got initialized.

An easy workaround would be that releasing camera control from app side when it becomes invisible, and reconstruct it when visibility state goes from invisible to visible.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Chiajung Hung [:chiajung] from comment #13)
> Hmm...I found I may wrong...
> 
> This would be hard to fix from gecko side. Since dom/camera implementation
> lock up the camera as soon as the GonkCameraControl got initialized.
> 
> An easy workaround would be that releasing camera control from app side when
> it becomes invisible, and reconstruct it when visibility state goes from
> invisible to visible.

Yes, if you think that make sense more than having a platform fix on the this bug, please change the component and reassign to me. We have the same issue with multiple camera app instance. See bug 816331 comment 10.

Comment 15

[Chiajung Hung [:chiajung]]

After(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> (In reply to Chiajung Hung [:chiajung] from comment #13)
> > Hmm...I found I may wrong...
> > 
> > This would be hard to fix from gecko side. Since dom/camera implementation
> > lock up the camera as soon as the GonkCameraControl got initialized.
> > 
> > An easy workaround would be that releasing camera control from app side when
> > it becomes invisible, and reconstruct it when visibility state goes from
> > invisible to visible.
> 
> Yes, if you think that make sense more than having a platform fix on the
> this bug, please change the component and reassign to me. We have the same
> issue with multiple camera app instance. See bug 816331 comment 10.

I tried to set the Camera._cameraObj to null when visibility change, but it not work. Since the object do not released in gecko layer until GC (correct me if I am wrong).

I will try to add some explicitly termination call to nsIDOMCameraControl, and fix the GonkCameraControl implementation.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Chiajung Hung [:chiajung] from comment #15)
> After(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> > 
> > Yes, if you think that make sense more than having a platform fix on the
> > this bug, please change the component and reassign to me. We have the same
> > issue with multiple camera app instance. See bug 816331 comment 10.
> 
> I tried to set the Camera._cameraObj to null when visibility change, but it
> not work. Since the object do not released in gecko layer until GC (correct
> me if I am wrong).
> 
> I will try to add some explicitly termination call to nsIDOMCameraControl,
> and fix the GonkCameraControl implementation.

As a doomsday workaround, we could |window.close()| the Camera app if it finds itself to be at the background.... that would be like the old-school |hackKillMe| :-P

Comment 18

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Chiajung Hung [:chiajung] from comment #15)
> After(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> > (In reply to Chiajung Hung [:chiajung] from comment #13)
> > > Hmm...I found I may wrong...
> > > 
> > > This would be hard to fix from gecko side. Since dom/camera implementation
> > > lock up the camera as soon as the GonkCameraControl got initialized.
> > > 
> > > An easy workaround would be that releasing camera control from app side when
> > > it becomes invisible, and reconstruct it when visibility state goes from
> > > invisible to visible.
> > 
> > Yes, if you think that make sense more than having a platform fix on the
> > this bug, please change the component and reassign to me. We have the same
> > issue with multiple camera app instance. See bug 816331 comment 10.
> 
> I tried to set the Camera._cameraObj to null when visibility change, but it
> not work. Since the object do not released in gecko layer until GC (correct
> me if I am wrong).
> 
> I will try to add some explicitly termination call to nsIDOMCameraControl,
> and fix the GonkCameraControl implementation.

I already have a patch to do this; am still testing it.