camera is black if another application uses the camera sensor

[Jean-Baptiste Lallement]

mako #196

If another application uses the camera (e.g Tagger) then the camera is black when the camera-app is active and the other app is in the background.

Test Case 1.
1. Install 'Tagger' from the store
2. Start the camera-app and verify it works
3. Switch to the app scope (don't close the camera)
4. Start Tagger and verify it works
5. Switch to the camera-app

Test Case 2.
1. Install 'Tagger' from the store
2. Start Tagger and verify it works
3. Switch to the Apps scope
4. Start the camera-app

Actual result
When the camera-app is active and Tagger is not, the camera-app is black. When the other application is close, the camera can be used normally by camera-app.

EXpected result
The active application can uses the device.

[John McAleely (john.mcaleely)]

NB, Tagger is planned to be in OEM images at launch

[John McAleely (john.mcaleely)]

To be clear, I think that means this needs to be on the rtm14 list.

[Ugo Riboni (uriboni)]

I think that with the current design applications should explicitly relinquish the use of the sensor when they stop being active (or when they stop needing to use the sensor).

The camera app does this correctly, so when you run first the Camera then run Tagger, Tagger can use the sensor. Unless we want to change the overall design of the system, it's Tagger that needs to be fixed, so I added it to the list of affected apps.

[Jim Hodapp (jhodapp)]

The only thing I would be concerned about is if we can rely on app developers to do this properly to keep use of the camera system sane. We could enforce it though policy, only accepting a camera-based app into the store if it does abide by this rule. But I'd rather have a system where the camera-based app developer doesn't have to worry about doing this. I haven't looked at this part of qtubuntu-camera or the camera-app code yet, so I can't comment on a good technical solution at this time.

[Jim Hodapp (jhodapp)]

@tvoss: do you have any thoughts from an architectural perspective?

[Thomas Voß (thomas-voss)]

I share Jim's concern here. However, the android Camera service does not provide functionality to remotely unlock a camera from a process that did not originally lock it. We could certainly extend the service to provide for the specific functionality, but I think we will not be able to deliver the respective service and integration with our applcation lifecycle in time for RTM. With that, and given that the behavior is somewhat known to Android developers (see http://androidxref.com/4.4.4_r1/xref/frameworks/base/core/java/android/hardware/Camera.java#285), we should make sure that Tagger correctly unlocks the camera, and capture adjustments to the Android camera service in a separate bug.

Do we have access to the Tagger sources? Is it using QtUbuntu camera to access the camera?

[Ugo Riboni (uriboni)]

I am in the process of modifying the tagger to release the camera when the app goes inactive. It uses the QML Camera object to access the camera and everything works find after the fix (see attached branch).

Regarding the long term fix to the camera service, if all we care about is ensuring the camera is released when the app goes inactive, then probably qtubunt-camera can be modified to get the current application instance and listent to the activeChanged signal, and stop the camera automatically.

This however will still require the apps to restart and reconfigure the camera as they come back into focus. Which I'm not sure if it is something we are ok with or we want to make fully transparent too, for the behavior to be symmetrical.

[Ugo Riboni (uriboni)]

Tagger has been fixed to correctly release the camera when it goes inactive.

I created Bug #1375163 to track the rest of the issues discussed in this bug.

[Pat McGowan (pat-mcgowan)]

Invalid per last comment