Closed
Bug 785592
(privileged-camera)
Opened 12 years ago
Closed 7 years ago
Implement a camera service to allow streaming to unprivileged apps (with the right permissions)
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 976398
People
(Reporter: cjones, Unassigned)
References
Details
(Keywords: feature, Whiteboard: [LOE:L][tech-p3][dependency: marketplace-partners])
+++ This bug was initially created as a clone of Bug #782456 +++
Bug 782456 moves the camera app OOP for stability reasons, but doesn't add any security. It requires the camera-app subprocess to run as root in order to directly control the camera. We can't let even privileged apps do this, only certified ones.
This allows unprivileged content to grab camera *snapshots* through activities/whatever, but not access a raw camera stream.
The question is, is that sufficient for basecamp or do we have market requirements for access to raw stream?
Per private discussion with clee in Barcelona, initial indications were that stills were sufficient. But this may have changed. Blocked on input from that Chris.
Implementing this is not trivial but also not rocket science. LOE:L is fairly conservative.
Comment 1•12 years ago
|
||
Can you help clarify what 'snapshots' are defined as?
I believe if this is consistent with our conversation in SP, this should be sufficient.
Marking blocking +.
blocking-basecamp: ? → +
Updated•12 years ago
|
Whiteboard: [LOE:L][blocked-on-input Chris Lee, see comment 0] → [LOE:L]
Reporter | ||
Comment 2•12 years ago
|
||
"Snapshot" means a single still image.
Our discussion in SP was to make a gaia inline intent for showing a preview stream and delivering stills back to the requesting app. This bug is different; it's the full enchilada, giving apps direct access to the camera stream.
So blocking- based on that.
blocking-basecamp: + → -
Comment 3•12 years ago
|
||
Agree with comment 2.
Is there a bug already that is tracking the work for what you're describing there?
Reporter | ||
Comment 4•12 years ago
|
||
That's purely a gaia feature, but good question --- who owns image sharing in gaia?
Comment 5•12 years ago
|
||
If I understand correctly, the lesser feature you're describing is a web activity to open the camera and return the resulting photo to the requesting app, right? So I'd guess that Dale Harvey owns that. Cc'ing him.
Reporter | ||
Comment 6•12 years ago
|
||
Correct.
Comment 7•12 years ago
|
||
Djf/Dale - Can one of you file a Gaia bug to track this work? Thanks.
Comment 8•12 years ago
|
||
Filed https://github.com/mozilla-b2g/gaia/issues/4571
I didn't assign anyone. Do you want it, Dale? If you're overloaded, assign it to me, since I'm going to be doing a lot of activities work already.
So now this bug can go back to being about "the whole enchilada"
Reporter | ||
Updated•12 years ago
|
Blocks: b2g-v-next
Comment 9•12 years ago
|
||
Really late to this bug, but I have to ask - why not solve this problem by just implementing support for getUserMedia on b2g?
Reporter | ||
Comment 10•12 years ago
|
||
After bug 803471, the main benefit to this work will be get us off more android treadmill.
Whiteboard: [LOE:L] → [LOE:L][tech-p3]
Updated•11 years ago
|
Alias: privileged-camera
Updated•11 years ago
|
Updated•11 years ago
|
Updated•10 years ago
|
Whiteboard: [LOE:L][tech-p3] → [LOE:L][tech-p3][dependency: marketplace-partners]
Comment 11•7 years ago
|
||
FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component.
If I incorrectly invalidated something, please let me know.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Comment 12•7 years ago
|
||
Bulk correction of resolution of B2G bugs to INCOMPLETE.
Resolution: INVALID → INCOMPLETE
Updated•7 years ago
|
Resolution: INCOMPLETE → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•