Hi, I was wondering, what way is there today to create a web-app (non-native android application) where I'd be able to plug-in a USB camera into an android device and be able to use it as an external camera of sorts. MediaDevices.getUserMedia() does not seem to work on a mobile android device + chrome. It does work on chrome on a pc. My camera is detected and I can select it as camera in a browser, but not on mobile. USB is blocked as device is a video device.
Thanks. On Tuesday, 20 March 2018 at 21:01:43 UTC+1 [email protected] wrote: > Contact emails > > [email protected] > > Summary > > The following set of USB interface classes, which should not be claimed > using the WebUSB API, will be explicitly blocked by Blink: Audio, Video, > HID, Mass Storage, Smart Card, Wireless Controller (Bluetooth and Wireless > USB). These interface classes are already mostly blocked by an operating > system’s built-in class drivers. This change establishes consistency across > platforms. > > Motivation > > The WebUSB API is designed to provide a mechanism for device manufacturers > and developers to build applications supporting novel hardware on the web > instead of through native apps. As explained in the original Intent to > Ship > <https://groups.google.com/a/chromium.org/d/msg/blink-dev/KuXx_k2KIis/-g-75FScBgAJ> > > for WebUSB, most USB devices fall into one of a number of standardized > device classes <http://www.usb.org/developers/defined_class> for which > there are already high-level APIs provided by the Web Platform. For each of > these interface classes the high-level API is the supported path and WebUSB > is the unsupported path. > > Risks > > Interoperability and Compatibility > > Developers may have implemented workarounds at an operating system level > to allow devices of these classes to be claimed by web content using > WebUSB. For example, on Windows, a specially crafted INF file can override > the system default driver for a particular device with the WinUSB driver. > Or, on Linux, udev rules can be configured so that the Linux kernel does > not bind a driver to the device. After this change such workarounds will > not be possible. > > Web developers who have deployed any of the workarounds above will likely > be negative on this change however the overall benefit to developers of > continuing to provide this API for the scenarios in which it is fully > supported outweighs this loss of functionality. > > Ergonomics > > Not applicable. > > Activation > > Not applicable. > > Debuggability > > To avoid developer confusion, a specific SecurityError message will be > used when the claimInterface() method fails due to this filtering and a > message will be logged to the console. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? > > All platforms other than Android WebView, which currently does not support > WebUSB. > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > This feature is currently tested by LayoutTests while it is decided to > what extent the list of blocked interface classes should be part of the > specification or Chrome-specific policy. Moving these tests into > web-platform-tests is a trivial change once this question is resolved. > > Link to entry on the feature dashboard <https://www.chromestatus.com/> > > This is a small change that fits under the existing entry in the feature > dashboard for WebUSB. > > https://www.chromestatus.com/feature/5651917954875392 > > Requesting approval to ship? > > Yes. > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6fd411db-8e03-4c6f-9fe5-989f1914b4e5n%40chromium.org.
