+++ 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.
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: ? → +
Whiteboard: [LOE:L][blocked-on-input Chris Lee, see comment 0] → [LOE:L]
"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: + → -
Agree with comment 2. Is there a bug already that is tracking the work for what you're describing there?
That's purely a gaia feature, but good question --- who owns image sharing in gaia?
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.
Djf/Dale - Can one of you file a Gaia bug to track this work? Thanks.
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"
6 years ago
Depends on: 803471
6 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?
After bug 803471, the main benefit to this work will be get us off more android treadmill.
Whiteboard: [LOE:L] → [LOE:L][tech-p3]
Whiteboard: [LOE:L][tech-p3] → [LOE:L][tech-p3][dependency: marketplace-partners]
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
Last Resolved: 9 months ago
Resolution: --- → INVALID
Bulk correction of resolution of B2G bugs to INCOMPLETE.
Resolution: INVALID → INCOMPLETE
Resolution: INCOMPLETE → DUPLICATE
See Also: → bug 1104616
Duplicate of bug: 976398
You need to log in before you can comment on or make changes to this bug.