Obturadores de privacidad de la cámara y interruptores de eliminación
En este artículo se proporcionan instrucciones de diseño de dispositivos para obturadores de privacidad o interruptores de eliminación, consideraciones para detectar el estado del obturador y cómo se espera que las persianas interactúen con los requisitos de HLK existentes para los LED de indicador.
Requisitos comunes de LED
Independientemente de los obturadores o interruptores de eliminación, HLK requiere que un LED de indicador visible esté encendido cuando el ISP captura los datos del sensor. En el caso de las cámaras RGB, si la cámara está activa, un LED de longitud de onda visible único (por ejemplo, blanco, verde, azul, etc.) debe estar activado:
En el caso de las cámaras con un sensor RGB+IR, esto puede ser más complejo porque la cámara IR requiere un LED iluminador, y el LED iluminador puede usar una longitud de onda visible (850 nm) o una longitud de onda invisible (940 nm). Además, las aplicaciones pueden transmitirse desde el sensor ir por sí mismo, el sensor RGB por sí mismo o ambos simultáneamente.
Los diseños que usan un iluminador ir de longitud de onda visible pueden optar por usar el LED iluminador IR como el LED indicador visible. Esto significa que si la cámara IR está activada por sí misma, los requisitos de HLK están satisfechos por el LED iluminador ir que se está iluminando:
Los diseños que usan un iluminador ir de longitud de onda invisible deben usar un LED de longitud de onda visible para indicar cuándo la cámara IR está activa, para satisfacer los requisitos de HLK. Se recomienda compartir el LED del indicador de uso de la cámara, para que el mismo LED de longitud de onda visible se active cuando el sensor IR o rgb esté activado:
Recomendamos que todos los diseños activen el LED del indicador normal en uso cuando se use la cámara IR o RGB, independientemente de si el LED iluminador IR usa una longitud de onda visible o no. Esta es la tabla completa de los requisitos principales de LED:
Stream estado | LED IR visible (850 nm) | LED DE IR invisible (940 nm) |
---|---|---|
Cámara desactivada | LED DESACTIVADOs | LED DESACTIVADOs |
Solo cámara RGB en | Indicador en uso ON, iluminador IR OFF | Indicador en uso ON, iluminador IR OFF |
Solo cámara ir en | Indicador en uso no necesario, pero recomendado on | Indicador en uso ON, iluminador IR ON |
Cámara RGB e IR en | Indicador en uso ON, iluminador IR ON | Indicador en uso ON, iluminador IR ON |
Nota
Los requisitos de LED pueden diferir para diseños con persianas de privacidad de la cámara o interruptores de eliminación de cámara. Consulte Requisitos de LED de obturador de privacidad de la cámara para obtener información sobre los obturadores de privacidad de la cámara y los requisitos de HLK LED para conmutadores de eliminación de cámara.
Experiencias de inteligencia artificial siempre activadas (por ejemplo, presencia humana basada en cámara)
En el caso de los dispositivos que admiten características de inteligencia artificial basadas en cámara siempre activadas, donde el silicio de IA comparte el sensor de cámara principal, los requisitos de LED difieren cuando el silicio de presencia dedicada accede exclusivamente a la cámara. Consulte las notas del producto detección de presencia en el Centro de partners de Microsoft para obtener más información.
Controles de privacidad de hardware
Cuando los diseños de cámara incluyen controles de privacidad de hardware, hay dos principios clave de nuestra guía de diseño:
Los dispositivos con controles de privacidad deben proporcionar una experiencia de usuario coherente y una confianza en el estado de privacidad:
- Una vez que un cliente aprende cómo se ve y se comporta el obturador en su dispositivo, ese conocimiento debe aplicarse a cualquier dispositivo que use que tenga un obturador.
En ningún caso, un control de privacidad de la cámara puede dar una falsa impresión de privacidad:
- Los dispositivos no deben dejar de ofrecer privacidad cuando sea más importante para el cliente. Si el obturador de privacidad de la cámara está cerrado o el interruptor de eliminación de la cámara está desactivado, los clientes esperan que no se pueda capturar ninguna imagen hasta que interactúen con el control físico para desactivar la característica de privacidad.
Tipos de controles
Se definen dos formas de controles de privacidad, persianas de privacidad de la cámara (mecánica y electromecánica) y interruptores de eliminación de cámara. Según el factor de forma del dispositivo, los objetivos de costo boM y el punto de precio del dispositivo, un OEM puede optar por implementar el obturador en cualquiera de estos formularios. Una constante importante en los tres es que deben actuar en el nivel físico o de hardware, lo que significa que no hay software implicado, ya que el software se puede poner en peligro.
Obturador de privacidad de la cámara mecánica
Las persianas mecánicas son el diseño más sencillo, son una cubierta de lente deslizante simple que el usuario acciona manualmente para bloquear la cámara o no. Están diseñados utilizando un material opaco que bloquea completamente la lente cuando se cierra. Este diseño es intrínsecamente infalible en el sentido de que físicamente no se puede poner en peligro para abrirse de ninguna manera, excepto el usuario deslizarlo.
Obturador de privacidad de la cámara electromecánica
Los obturadores electromecánicos son obturadores mecánicos controlados eléctricamente. En lugar de abrir o cerrar manualmente el obturador, el obturador integrado se abre o cierra en respuesta a la presión de un botón físico en el dispositivo.
Nota
Aunque esta solución normalmente requerirá firmware, debe aislarse de otros componentes. Es decir, el controlador y el botón del obturador no deben tener vectores de ataque como buses de comunicación o la capacidad de volver a programar el firmware. El diseño debe requerir interacción de hardware y no ser controlable desde el software.
Conmutadores de eliminación de cámara
Algunos dispositivos se suministran hoy con una función de interruptor de eliminación de cámara, que desconecta físicamente el dispositivo de cámara del sistema cuando está apagado, proporcionando un control de hardware para bloquear el acceso a la cámara sin necesidad de un obturador físico para cubrir la lente o sensor. Aunque esto es sólido contra ataques, crea una experiencia de usuario deficiente. Al quitar el dispositivo cuando el interruptor está apagado, el sistema no puede decir que el chasis todavía tiene una cámara en él, pero que se acaba de apagar. Esto es problemático desde una perspectiva de la experiencia de usuario si un usuario no reconoce involuntariamente la cámara, ya que las aplicaciones notificarán que no hay ninguna cámara conectada. También puede hacer que determinadas aplicaciones se bloqueen o se comporten incorrectamente si la cámara se quita durante el uso o aparece mientras se ejecuta la aplicación.
En consecuencia, Microsoft no recomienda ni admite el uso de conmutadores de eliminación de cámara que quitan toda la cámara del sistema. En su lugar, se recomienda una de las dos soluciones:
Obturador físico, como se describe en Obturador de privacidad de la cámara mecánica y obturador de privacidad de la cámara electromecánica.
Un conmutador de eliminación que desconecta el sensor, en lugar del ISP, y hace que el ISP sintetizar fotogramas negros.
Para la segunda solución, la cámara sigue apareciendo en el sistema y las aplicaciones pueden seguir utilizándola. El ISP responde a todos los comandos (start/stop streaming, DDIs como brillo o contraste, cambios de tipo multimedia, etc.) normalmente, independientemente de si el modificador de eliminación está activo o no. Sin embargo, cuando se activa el modificador de eliminación, el ISP deja de capturar datos reales del sensor y, en su lugar, sintetiza y transmite fotogramas negros, todo transparente desde la perspectiva de la aplicación.
Obturadores con varias cámaras en un panel
Cuando los clientes usan dispositivos con obturadores (por ejemplo, obturadores con varias cámaras IR y RGB en un panel), esperan que, si el obturador está cerrado, la privacidad está protegida contra cualquier acceso inesperado a la cámara. Cuando los sistemas tienen dos cámaras en el mismo panel, como una cámara RGB e IR para admitir Windows Hello, es importante asegurarse de que el obturador no da un falso sentido de seguridad. No se espera que los clientes comprendan que puede haber un segundo sensor de cámara para Windows Hello y algunos dispositivos usan un solo sensor para RGB+IR. Debido a esto, el obturador debe cubrir todas las cámaras del panel.
Garantizar que los obturadores y los interruptores de eliminación se apliquen a la cámara IR es de suma importancia, ya que las aplicaciones pueden acceder a la cámara IR y generar imágenes razonablemente de alta fidelidad de la escena, como se muestra a continuación. Si no se ocluye el sensor ir, se representaría una falsa sensación de seguridad y vulneración de confianza del usuario en el mérito de privacidad del obturador.
Nota
Windows Hello Face requiere una cámara RGB e IR. Si la cámara RGB está ocluida, Windows Hello no funcionará correctamente. Las secuencias RGB e IR se usan para habilitar medidas contra la suplantación de identidad.
Guía de diseño de obturador físico (mecánica o electromecánica)
Cuando un cliente usa un dispositivo con un obturador físico, la presencia del obturador ofrece una fuerte expectativa implícita sobre el nivel de privacidad que proporciona. Simplemente, esa expectativa del usuario es que si el dispositivo tiene un obturador y el obturador está cerrado, están protegidos contra cualquier acceso inesperado a la cámara. Es fundamental que la implementación de la característica se encuentre en las expectativas implícitas; de lo contrario, pierde toda la confianza.
Además, todo el concepto de obturador de privacidad es proporcionar una capa de seguridad que se protege contra cualquier ataque de software práctico. En otras palabras, si el dispositivo tiene un obturador y el sistema está totalmente comprometido por software malintencionado, ese software no puede poner en peligro la privacidad del usuario. De nuevo, para poner simplemente, la expectativa es que el obturador solo puede cambiar el estado si el usuario interactúa físicamente con el control de obturador de hardware en el dispositivo.
Consideraciones de diseño mecánico
Se espera que las persianas físicas, ya sean manual o electromecánicamente accionadas, estén hechas de un material opaco que bloquee completamente el sensor cuando esté cerrado y esté visible a simple vista:
Como se describe en Obturadores con varias cámaras en un panel, los dispositivos con cámara IR y RGB independientes en el mismo panel deben tener ambos sensores bloqueados simultáneamente cuando se cierra el obturador. Supongamos un diseño de sensor dual como el siguiente:
Cuando el obturador está cerrado, debe cubrir el sensor RGB, es opcional cubrir el sensor IR:
Nota
Actualmente se admite una exención para las cámaras cuyos diseños mecánicos de obturador no cubren la cámara IR. Cuando un obturador físico está ocluyendo la cámara RGB, es aceptable que el firmware isp descarte la salida de la imagen de la cámara IR y reemplácela por una imagen negra sintetizada. Sin embargo, si el sensor IR se usa para la detección de presencia, se recomienda no cubrir el sensor ir y asegurarse de que el sensor de presencia es funcional. Consulte las notas del producto detección de presencia en el Centro de partners de Microsoft para obtener más información. Una futura actualización de HLK adoptará esta excepción y solo requerirá obturadores físicos para ocluir físicamente el RGB, para garantizar la solidez de la solución y una mayor protección de la privacidad del cliente.
Consideraciones sobre el comportamiento de la cámara
Cuando una cámara está equipada con un obturador físico, la cámara debe seguir funcionando con normalidad, independientemente del estado del obturador. Si una aplicación se transmite desde la cámara, continúa capturando y transmitiendo datos reales del sensor incluso si el obturador está cerrado. Se espera que la oclusión completa del sensor por un obturador cerrado genere una imagen negra o muy cerca de él.
Los OEM pueden optar por reemplazar la imagen por una imagen estática cuando se cierra el obturador (por ejemplo, una imagen de una cámara con una barra diagonal a través de ella). Esta imagen debe ser estática y no se puede cambiar del software para protegerse contra vulnerabilidades de seguridad. En el caso de los dispositivos con obturadores de privacidad, el reemplazo de imágenes puede producirse dentro del ISP o dentro del controlador, aunque se recomienda reemplazar dentro del ISP para reducir la necesidad de DMFT y agregar carga al dispositivo host.
Requisitos de LED de obturador de privacidad de la cámara
Los requisitos de LED deben cumplir los requisitos de LED comunes especificados. Esto significa que, si hay alguna cámara en el panel, un LED indicador de longitud de onda visible en uso debe permanecer encendido independientemente de si el obturador está abierto o cerrado. Sin embargo, es aceptable que el diseño físico del obturador cubra el LED cuando se cierra el obturador. En los diagramas siguientes se muestra un escenario en el que la cámara está transmitiendo activamente:
En el caso de los diseños con una cámara IR y RGB, algunos fabricantes pueden querer apagar el LED iluminador IR si se usa la cámara IR mientras el obturador está cerrado. Se recomienda contra esto, ya que agrega complejidad adicional para poco valor; la cámara IR solo estará activa si se está ejecutando Windows Hello y Windows Hello muestra un mensaje durante este tiempo en el que intenta iniciar sesión, pero el obturador está cerrado. Consulte Kill switch implementation (Implementación del modificador de eliminación ) para obtener más información.
Sin embargo, si un LED iluminador IR de 840 nm (visible) no es el único LED indicador en uso para la cámara IR (por ejemplo, un LED visible normal blanco/verde/azul se ilumina cuando la cámara IR está activa), entonces un diseño puede activar el LED iluminador IR cuando se cierra el obturador.
Mecanismos de alternancia de estado de obturación
Los dispositivos que implementan obturadores de privacidad no deben permitir ninguna forma de control de software del obturador, y solo deben abrir o cerrar el obturador en respuesta al usuario que interactúa explícitamente con el control de obturación. Este control de obturador puede ser un control deslizante mecánico o un botón físico que acciona un obturador electromecánico. Ningún software puede cambiar el estado del obturador, incluso si un control de hardware puede invalidar el software y mantener cerrado el obturador, ya que un obturador cerrado no siempre significa que el control de privacidad está habilitado. Del mismo modo, es posible que el obturador no se abra o cierre en una aplicación utilizando la cámara, por la misma razón. En resumen, si el usuario mira el dispositivo y ve que el obturador está cerrado, debe ser capaz de deducir inequívocamente que su privacidad está protegida hasta que realice una acción física para abrir el obturador.
Detección e informes de estado de obturación
Muchos de los problemas con los diseños de privacidad de la cámara en el mercado proceden de situaciones en las que un usuario cierra involuntariamente el obturador y no puede averiguar por qué su cámara está produciendo una imagen en blanco o no funciona. En consecuencia, una parte clave de la característica de obturador de privacidad de Windows se basa en que la cámara puede notificar de forma confiable su estado de obturación. Con esta información, las aplicaciones pueden informar al usuario de que el obturador está cerrado para que pueda reaccionar en consecuencia. Los cambios de estado del obturador se deben detectar y notificar lo antes posible después de que se produzca el evento.
Se propone dos métodos para detectar el estado del obturador, los sensores físicos y la detección basada en firmware. Ambos métodos notifican el estado de obturación detectado a través de CT_PRIVACY_CONTROL si se originan en un dispositivo UVC o KSPROPERTY_CAMERACONTROL_PRIVACY si se originan desde un controlador AVStream o DMFT.
Consulte Notificación de obturación de privacidad para obtener más detalles.
Sensor de detección de estado físico
El estado del obturador se puede detectar con un sensor físico que pueda detectar si el obturador está abierto o cerrado. Los sensores físicos pueden notificar de forma determinista el estado del obturador y pueden proporcionar una experiencia más confiable. Microsoft no tiene ninguna guía específica disponible en los diseños de sensores ni en recomendaciones específicas para la tecnología del sensor.
Detección de estado basado en firmware de ISP
Algunos diseños pueden optar por omitir un obturador físico y, en su lugar, usar el firmware dentro del ISP para procesar la imagen e informar del estado de obturación inferido. Esta solución analizaría la imagen capturada en firmware y la compararía con un umbral para determinar si el obturador parece estar cerrado. Se trata de una solución de bajo costo, ya que no requiere ninguna nueva parte y también es capaz de detectar cosas como cinta sobre un sensor. Sin embargo, hay dos consideraciones importantes al elegir usar este diseño:
El diseño puede informar falsamente de un obturador cerrado en entornos oscuros. Sin embargo, esto se espera que sea un riesgo o problema mínimo, ya que la cámara no sería utilizable en un entorno tan ligero de todos modos.
A menos que el ISP sea capaz de realizar muestreos periódicos desde el sensor siempre que esté fuera de D3, este método impide que las aplicaciones puedan consultar datos precisos del estado del sensor hasta que empiecen a transmitirse desde la cámara.
La segunda consideración anterior crea un desafío. Si la cámara no puede notificar el estado del obturador cuando no se está transmitiendo, pero se escribió una aplicación para comprobar y reaccionar al estado del obturador antes de la transmisión, podrían ocurrir cosas malas. En respuesta a los comentarios que hemos recibido de los asociados, este requisito ha sido relajado. También estamos actualizando la documentación de la API para recomendar a los desarrolladores de software que tomen decisiones basadas en el estado de obturación notificado cuando no se transmite. Por ejemplo, aconsejaremos explícitamente a los desarrolladores de aplicaciones que no permitan que la cámara se active si el obturador informa de que está cerrado.
Para evitar el riesgo de problemas de compatibilidad con las aplicaciones que no cumplen este consejo, las cámaras que no pueden detectar el estado del obturador cuando no se espera que el streaming notifique que el obturador es OPEN siempre que no se transmite. De lo contrario, si la cámara puede detectar el estado del obturador cuando no se transmite, se espera que detecte y notifique el estado del obturador en cualquier momento que no esté en D3.
Nota
Los algoritmos de detección de obturación basados en análisis de imágenes siempre deben implementarse en el firmware en lugar de en un controlador, para evitar aumentar la carga de CPU y para lograr una máxima solidez.
Este es un diagrama que ilustra el comportamiento esperado para un dispositivo con un obturador de privacidad de la cámara:
Tabla de resumen del comportamiento del obturador de privacidad de la cámara
En la tabla siguiente se resume el comportamiento esperado de una cámara con un obturador de privacidad de la cámara (manual o electromecánico):
Estado de ISP | Estado del obturador | LED indicador visible | Imagen transmitida al equipo | Estado de CT_PRIVACY_CONTROL notificado |
---|---|---|---|---|
Inactivo/D3 | Abierto | Desactivado* | N/D | Abierto |
Inactivo/D3 | Closed | Desactivado* | N/D | Abierto** |
Streaming (cualquier aplicación) | Abierto | En* | Imagen de sensor capturada | Abierto |
Streaming (cualquier aplicación) | Closed | En* | Imagen de sensor capturada | Closed |
(*) Consulta Requisitos del LED de obturador de privacidad de la cámara y Mecanismos de alternancia de estado de obturación para obtener más información sobre los requisitos del LED del indicador.
(**) Consulte Detección de estado de obturación e informes para obtener más información, en algunos escenarios, el estado del obturador se seguirá actualizando cuando no se transmite.
Guía de diseño del modificador de eliminación
Cuando un cliente usa un dispositivo con un modificador de eliminación, confía en un conmutador de hardware para protegerse de forma sólida frente a cualquier aplicación que intente capturar su imagen. Simplemente, esa expectativa del usuario es que si mi dispositivo tiene un interruptor de eliminación y el interruptor de eliminación está activado, mi privacidad está protegida contra cualquier acceso inesperado a la cámara. Es fundamental que la implementación de la característica se encuentre en las expectativas implícitas; de lo contrario, pierde toda la confianza.
Además, todo el concepto de un interruptor de eliminación es proporcionar una capa de seguridad que se protege contra cualquier ataque de software práctico. Si el dispositivo tiene un conmutador de eliminación y el sistema está totalmente comprometido por software malintencionado, ese software no puede invalidar el modificador de eliminación y poner en peligro la privacidad del usuario. En pocas palabras, la expectativa es que el modificador de eliminación solo pueda activarse o desactivarse por el usuario que interactúe físicamente con el dispositivo.
En comparación con los diseños de obturador de privacidad, los interruptores de eliminación son más complejos y conllevan más desafíos para ofrecer confianza. Esto se debe a que llevan el mismo nivel de expectativa de solidez (se espera que un conmutador físico funcione perfectamente en todos los escenarios), pero no proporcionan la garantía de que proporciona un obturador físico sobre la lente. Esto significa que los dispositivos que ofrecen modificadores de eliminación deben producir una experiencia coherente, clara y confiable.
Funcionalidad de modificador de eliminación
Los conmutadores de eliminación funcionan indicando al firmware del ISP que deje de capturar desde el sensor y, en su lugar, sintetizar una imagen negra. De este modo, la cámara sigue estando disponible y funcional desde la perspectiva de las aplicaciones, pero hay cero datos reales del sensor que se transmiten al sistema operativo host cuando el conmutador de eliminación está activo. Un diseño sólido funcionaría de la siguiente manera:
La señal física del conmutador se conecta a un GPIO en el ISP, para indicar si el conmutador está activo o no
Cuando el modificador de eliminación está activo, el ISP:
Desconecta eléctricamente el sensor
Comienza a sintetizar marcos negros para reemplazar fotogramas reales del sensor desconectado.
Informa de que el obturador se cierra a través de la característica de notificación del obturador de privacidad.
En la práctica, el silicio ISP que soporta esta experiencia completa, incluida una desconexión eléctrica del sensor cuando el interruptor de eliminación GPIO está activo, aún no está disponible en el mercado. En consecuencia, los diseños actuales requieren la modificación del paso 2a anterior para "Detener el sensor o descartar los datos del sensor dentro del firmware". Tenemos previsto trabajar con proveedores de ISP para mitigar la necesidad de este alojamiento en el futuro silicio.
Nota
Es fundamental implementar la funcionalidad del conmutador de eliminación en el firmware del ISP y no dentro de un controlador que se ejecuta en el sistema operativo host. Los datos de imagen reales del sensor no se deben transferir al sistema operativo cuando el conmutador de eliminación está en estado "kill".
Al igual que con los obturadores de privacidad, los OEM pueden reemplazar la imagen por una imagen estática cuando el modificador de eliminación está en estado "kill". El reemplazo de imágenes puede producirse dentro del ISP o dentro del controlador, aunque se recomienda reemplazar dentro del ISP para reducir la necesidad de DMFT y agregar carga al dispositivo host. Si el reemplazo de imágenes se realiza en el controlador, tenga en cuenta el requisito de que los datos de imagen reales no se transfieran al sistema operativo cuando el modificador de eliminación esté en estado "kill" todavía se aplica.
Implementación del modificador de eliminación
El estado del modificador de eliminación no debe ser controlado por software; de lo contrario, una aplicación malintencionada podría escribir el control para activar o desactivar el modificador de eliminación. Deben controlarse mediante un conmutador conectado a un GPIO en el ISP.
Es importante que cuando se apaguen los interruptores de eliminación de cámaras, la cámara sigue apareciendo en el sistema y las aplicaciones pueden seguir transmitiendo desde ella, la imagen se queda en negro. Los fotogramas siguen siendo entregados al sistema operativo y la cámara sigue respondiendo a los controles; Las aplicaciones no saben que el modificador está en estado "kill", a menos que la aplicación use las API CameraOcclusionInfo . Esto permite que la cámara se deshabilite a través de un control de hardware sin introducir mensajes confusos "cámara no encontrada" o arriesgarse a que ciertas aplicaciones se bloqueen al voltear el conmutador.
Como se describe en Obturadores con varias cámaras en un panel, los dispositivos con cámaras IR y RGB independientes en el mismo panel deben tener ambos sensores deshabilitados simultáneamente cuando se activa el interruptor de eliminación.
Requisitos de LED de HLK
HLK requiere que el LED del indicador esté encendido cuando el ISP captura los datos del sensor. Activar el interruptor de eliminación significa que el ISP debe dejar de capturar datos reales del sensor, por lo que también se espera que el LED se apague con el interruptor de eliminación. Esto evita cualquier confusión o incumplimiento de confianza, si el cliente ve un indicador iluminado o led iluminador de IR, sabe que el software está capturando su imagen actualmente, y si no ve un LED iluminado, sabe que no se está capturando.
Eliminación de informes de estado del conmutador
El estado del interruptor de eliminación debe notificarse a través de CT_PRIVACY_CONTROL (si se originan en un dispositivo UVC) o KSPROPERTY_CAMERACONTROL_PRIVACY (si se originan en un controlador AVStream o DMFT). El estado del interruptor de eliminación de cámara debe notificarse cada vez que el ISP está fuera de D3.
Consulte Notificación de cambio/obturador de privacidad para obtener más detalles.
Tabla de resumen de comportamiento del modificador de eliminación
En la tabla siguiente se resume el comportamiento esperado de una cámara con un conmutador de eliminación de cámara:
Estado de ISP | Estado del modificador de eliminación | LED indicador visible | Imagen transmitida al equipo | Estado de CT_PRIVACY_CONTROL notificado |
---|---|---|---|---|
Inactivo/D3 | Ejecutar | Desactivado* | N/D | Abrir |
Inactivo/D3 | Terminar | Desactivado* | N/D | Cerrar |
Streaming (cualquier aplicación) | Ejecutar | En* | Imagen de sensor capturada | Abrir |
Streaming (cualquier aplicación) | Terminar | Desactivado* | Marcos en blanco sintetizados | Cerrar |
(*) Consulta Requisitos del LED de obturador de privacidad de la cámara y Mecanismos de alternancia de estado de obturación para obtener más información sobre los requisitos del LED del indicador.
Guía de ISV para eventos de obturación y conmutador
Cuando una cámara con un interruptor de cierre o obturador de privacidad sigue las instrucciones de esta documentación, el estado del obturador o conmutador se notifica al sistema operativo cuando la cámara está transmitiendo. Después, las aplicaciones que usan la cámara pueden supervisar los eventos de cambio de estado de obturación y responder en consecuencia, como al producir un aviso útil de que la cámara está bloqueada por un obturador o conmutador.
Consulte las SIGUIENTES API para obtener más información: