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

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

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

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.

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

BB+, P1 - smoketest blocker

Stealing and investigating.

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.

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?

Looks like a dup of bug 818933?

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

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.

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.

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

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.

(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

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