Tampas de privacidade e interruptores de corte das câmeras

Este artigo fornece orientações de design de dispositivo para obturadores de privacidade ou kill switches, considerações sobre a deteção do estado do obturador e como se espera que os obturadores interajam com os requisitos HLK existentes para LEDs indicadores.

Requisitos comuns do LED

Independentemente de obturadores ou kill switches, o HLK requer que um LED indicador visível esteja ligado quando o ISP estiver capturando dados do sensor. Para câmeras RGB, se a câmera estiver ativa, um único LED de comprimento de onda visível (por exemplo, branco, verde, azul e assim por diante) deve estar ligado:

Para câmeras com um sensor RGB + IR, isso pode ser mais complexo porque a câmera IR requer um LED iluminador, eo LED iluminador pode usar um comprimento de onda visível (850 nm) ou comprimento de onda invisível (940 nm). Além disso, os aplicativos podem transmitir do sensor IR por si só, o sensor RGB por si só, ou ambos simultaneamente.

Projetos que usam um iluminador IR com comprimento de onda visível podem optar por usar o LED do iluminador IR como o LED indicador visível. Isto significa que se a câmara IR está ligada por si só, os requisitos HLK são satisfeitos com o LED iluminador IR aceso.

Projetos usando um iluminador IR de comprimento de onda invisível devem usar um LED de comprimento de onda visível para indicar quando a câmera IR está ativa, para satisfazer os requisitos HLK. Recomendamos que partilhe o LED indicador da câmara em uso, para que o mesmo LED de comprimento de onda visível se ligue quando o sensor IR e/ou sensor RGB estiver ligado:

Recomendamos que todos os projetos liguem o LED indicador regular em uso quando a câmera IR ou RGB é usada, independentemente de o LED iluminador IR usa um comprimento de onda visível ou não. Aqui está a tabela completa dos principais requisitos do LED:

Estado do fluxo	LED IR visível (850 nm)	LED IR invisível (940 nm)
Câmera desligada	LEDs OFF	LEDs DESLIGADOS
Apenas câmara RGB ligada	Indicador em uso ON, iluminador IR OFF	Indicador em uso ON, iluminador IR OFF
Apenas câmara IR ligada	Indicador em uso não necessário, mas recomendado ON	Indicador em uso ON, iluminador IR ON
RGB e câmera infravermelha ligada	Indicador em uso ON, iluminador IR ON	Indicador em uso ON, iluminador IR ON

Observação

Os requisitos de LED podem diferir para projetos com tampas de privacidade para a câmara ou interruptores de desligamento da câmara. Consulte Requisitos de LED do obturador de privacidade da câmera para obter informações com obturadores de privacidade da câmera e Requisitos de LED HLK para kill switches da câmera.

Experiências de IA sempre ativas (por exemplo, presença humana baseada em câmera)

Para dispositivos que suportam recursos de IA baseados em câmera e sempre ativos, onde o chip de IA compartilha o sensor principal da câmera, os requisitos de LED são diferentes quando o circuito dedicado à presença está acessando exclusivamente a câmera. Consulte o Whitepaper de deteção de presença no Microsoft Partner Center para obter detalhes.

Controles de privacidade de hardware

Quando os designs de câmaras incluem controlos de privacidade de hardware, existem dois princípios fundamentais das nossas orientações de design:

1. Os dispositivos com controlos de privacidade devem proporcionar uma experiência de utilizador consistente e confiança no estado de privacidade:

   • Uma vez que um cliente aprenda como o obturador em seu dispositivo parece e se comporta, esse conhecimento deve se aplicar a qualquer dispositivo que ele use que tenha um obturador.

2. Em nenhuma circunstância um controle de privacidade da câmera pode dar uma falsa impressão de privacidade:

   • Os dispositivos não devem deixar de oferecer privacidade quando mais importante para o cliente. Se o obturador de privacidade da câmera estiver fechado ou o kill switch da câmera estiver desligado, os clientes esperam que nenhuma imagem possa ser capturada até que interajam com o controle físico para desativar o recurso de privacidade.

Tipos de controlos

São definidas duas formas de controlo de privacidade, obturadores de privacidade da câmara (mecânicos e eletromecânicos) e interruptores de segurança da câmara. Dependendo do formato do dispositivo, das metas de custo da lista de materiais e do preço do dispositivo, um fabricante de equipamentos originais (OEM) pode optar por implementar o obturador em qualquer uma dessas formas. Uma constante importante em todos os três é que eles devem agir no nível físico ou de hardware, o que significa que nenhum software está envolvido, uma vez que o software pode ser comprometido.

Obturador mecânico de privacidade da câmera

Obturadores mecânicos são o design mais simples, estes são uma tampa de lente deslizante simples que o usuário aciona manualmente para bloquear a câmera ou não. Eles são projetados usando um material opaco que bloqueia totalmente a lente quando fechada. Este design é inerentemente infalível, no sentido de que ele fisicamente não pode ser forçado a abrir de qualquer maneira, exceto pelo usuário ao deslizá-lo.

Obturador de privacidade da câmera eletromecânica

As persianas eletromecânicas são persianas mecânicas controladas eletricamente. Em vez de o utilizador abrir ou fechar manualmente o obturador, o obturador integrado abre/fecha em resposta ao premir de um botão físico no dispositivo.

Observação

Embora esta solução geralmente exija firmware, ela deve ser isolada de outros componentes. Em outras palavras, o controlador e o botão do obturador não devem ter vetores de ataque, como barramentos de comunicação ou a capacidade de o firmware ser reprogramado. O projeto deve exigir interação de hardware e não ser controlável a partir de software.

Interruptores de desativação da câmera

Alguns dispositivos hoje vêm com um recurso de kill switch da câmera, que desconecta fisicamente o dispositivo da câmera do sistema quando desligado, fornecendo um controle de hardware para bloquear o acesso à câmera sem exigir um obturador físico para cobrir a lente / sensor. Embora isso seja robusto contra ataques, cria uma experiência de usuário ruim. Ao remover o dispositivo quando o interruptor está desligado, o sistema não consegue perceber que o chassi ainda tem uma câmera, mas que ela está desligada. Isso é problemático de uma perspetiva UX se a câmera é involuntariamente desligada por um usuário que desconhece o interruptor, uma vez que os aplicativos relatam que não há câmeras conectadas. Também pode fazer com que determinadas aplicações falhem ou se comportem mal se a câmara for removida durante a utilização ou aparecer enquanto a aplicação está em execução.

Assim, a Microsoft não recomenda nem suporta o uso de interruptores de desativação da câmara que removem completamente a câmara do sistema. Em vez disso, recomendamos uma das duas soluções:

1. Um obturador físico, conforme descrito em Obturador de privacidade da câmera mecânica e Obturador de privacidade da câmera eletromecânica.

2. Um "kill switch" que desconecta o sensor, em vez do Processador de Sinal de Imagem (ISP), e faz com que o ISP sintetize quadros pretos.

Para a segunda solução, a câmera ainda aparece no sistema, e os aplicativos podem continuar a usá-la. O ISP responde a todos os comandos (iniciar/parar streaming, DDIs como brilho ou contraste, alterações de tipo de mídia e assim por diante) normalmente, independentemente de o kill switch estar ativo ou não. No entanto, quando o kill switch é ativado, o ISP para de capturar dados reais do sensor e, em vez disso, sintetiza e transmite quadros pretos, tudo transparente da perspetiva do aplicativo.

Obturadores com várias câmaras num painel

Quando os clientes usam dispositivos com obturadores (por exemplo, obturadores com várias câmeras IR e RGB em um painel), eles esperam que, se o obturador estiver fechado, a privacidade seja protegida contra qualquer acesso inesperado à câmera. Quando os sistemas têm duas câmeras no mesmo painel, como uma câmera RGB e IR para suportar o Windows Hello, é importante garantir que o obturador não dê uma falsa sensação de segurança. Não se espera que os clientes entendam que pode haver um segundo sensor de câmera para o Windows Hello, e alguns dispositivos usam um único sensor para RGB + IR. Devido a isso, o obturador deve cobrir todas as câmeras no painel.

Garantir que os obturadores e os interruptores de segurança sejam aplicados à câmera IR é de extrema importância, pois a câmera IR pode ser acessada por aplicativos e produzir imagens de razoável alta-fidelidade da cena, como mostrado abaixo. Não conseguir ocluir o sensor IR representaria uma falsa sensação de segurança e quebra de confiança do usuário no mérito de privacidade do obturador.

Observação

O Windows Hello Face requer uma câmara RGB e IR. Se a câmara RGB estiver ocluída, o Windows Hello não funcionará corretamente. Ambos os fluxos RGB e IR são usados para habilitar contra-medidas anti-falsificação.

Orientação do projeto do obturador físico (mecânico ou eletromecânico)

Quando um cliente usa um dispositivo com um obturador físico, a presença do obturador dá uma forte expectativa implícita sobre o nível de privacidade que ele oferece. Simplificando, essa expectativa do usuário é que, se o dispositivo tiver um obturador e o obturador estiver fechado, ele estará protegido contra qualquer acesso inesperado à câmera. É crucial que a implementação do recurso corresponda às expectativas implícitas, caso contrário, perde toda a confiança.

Além disso, todo o conceito de um obturador de privacidade é fornecer uma camada de segurança que é reforçada contra qualquer ataque prático de software. Em outras palavras, se o dispositivo tiver um obturador e o sistema estiver totalmente comprometido por software mal-intencionado, esse software não pode comprometer a privacidade do usuário. Novamente, para simplificar, a expectativa é que o obturador só possa mudar de estado se o usuário interagir fisicamente com o controle do obturador de hardware no dispositivo.

Considerações de projeto mecânico

Espera-se que os obturadores físicos, acionados manual ou eletromecanicamente, sejam feitos de um material opaco que bloqueia totalmente o sensor quando fechado e é visível a olho nu:

Conforme descrito em Obturadores com várias câmeras em um painel, os dispositivos com câmera IR e RGB separada no mesmo painel devem ter ambos os sensores bloqueados simultaneamente quando o obturador é fechado. Suponha um design de sensor duplo como o seguinte:

Quando o obturador está fechado, ele deve cobrir o sensor RGB, é opcional para cobrir o sensor IR:

Observação

Atualmente, suportamos uma isenção para câmeras cujos projetos de obturador mecânico não cobrem a câmera IR. Quando um obturador físico está a ocluir a câmera RGB, é aceitável que o firmware ISP descarte a saída de imagem da câmera IR e a substitua por uma imagem preta sintetizada. No entanto, se o sensor IR é usado para deteção de presença, recomenda-se não cobrir o sensor IR e garantir que o sensor de presença é funcional. Consulte o Whitepaper de deteção de presença no Microsoft Partner Center para obter detalhes. Uma futura atualização do HLK adotará essa exceção e exigirá apenas obturadores físicos para ocluir fisicamente o RGB, para garantir a robustez da solução e uma proteção mais forte da privacidade do cliente.

Considerações sobre o comportamento da câmera

Quando uma câmara está equipada com um obturador físico, a câmara deve continuar a funcionar normalmente, independentemente do estado do obturador. Se uma aplicação estiver a transmitir a partir da câmara, continua a capturar e transmitir dados reais do sensor, mesmo que o obturador esteja fechado. Espera-se que a oclusão total do sensor por um obturador fechado produza uma imagem preta ou muito próxima dele.

Os OEMs podem optar por substituir a imagem por uma imagem estática quando o obturador é fechado (por exemplo, uma imagem de uma câmera com uma barra através dela). Esta imagem deve ser estática e não pode ser alterada do software para proteger contra exploits. Para dispositivos com obturadores de privacidade, a substituição de imagem pode ocorrer dentro do ISP ou dentro do driver, embora a substituição dentro do ISP seja recomendada para reduzir a necessidade de DMFTs e adicionar carga ao dispositivo host.

Privacidade da câmara Requisitos do LED do obturador

Os requisitos de LED devem seguir os requisitos especificados em Requisitos Comuns de LED. Isso significa que, se alguma câmera no painel estiver ligada, um LED indicador de câmera de comprimento de onda visível em uso deve permanecer aceso, independentemente de o obturador estar aberto ou fechado. No entanto, é aceitável que o design físico do obturador cubra o LED quando o obturador está fechado. Os diagramas abaixo ilustram um cenário quando a câmera está transmitindo ativamente:

Para projetos que apresentam tanto uma câmara IR quanto uma câmara RGB, alguns fabricantes podem desejar desligar o LED iluminador IR se a câmara IR for usada enquanto o obturador está fechado. Recomendamos contra isso, pois adiciona complexidade adicional por pouco valor; a câmara IR só estará ativa se o Windows Hello estiver em execução, e o Windows Hello exibe uma mensagem durante este período indicando que está a tentar iniciar sessão, mas o obturador está fechado. Consulte Implementação do kill switch para obter detalhes.

No entanto, se um LED iluminador IR de 840 nm (visível) não é o único LED indicador em uso para a câmera IR (por exemplo, um LED normal visível branco / verde / azul é iluminado quando a câmera IR está ativa), então um design pode desligar o LED iluminador IR quando o obturador está fechado.

Mecanismos de alternância do estado do obturador

Os dispositivos que implementam obturadores de privacidade não devem permitir qualquer forma de controle de software do obturador e só devem abrir ou fechar o obturador em resposta à interação explícita do usuário com o controle do obturador. Esse controle do obturador pode ser um controle deslizante mecânico ou um botão físico que aciona um obturador eletromecânico. Nenhum software pode alterar o estado do obturador, mesmo que um controlo de hardware possa substituir o software e manter o obturador fechado, uma vez que um obturador fechado nem sempre significa que o controlo de privacidade está ativado. De igual modo, o obturador pode não abrir ou fechar numa aplicação que utiliza a câmara, pelo mesmo motivo. Em resumo, se o utilizador olhar para o dispositivo e vir que o obturador está fechado, deve ser capaz de inferir inequivocamente que a sua privacidade está protegida até tomar medidas físicas para abrir o obturador.

Deteção e relatórios do estado do obturador

Muitos dos problemas com os designs de privacidade da câmera no mercado decorrem de situações em que um usuário fecha involuntariamente o obturador e não consegue descobrir por que sua câmera está produzindo uma imagem em branco ou não funcionando. Assim, uma parte fundamental do recurso de obturador de privacidade do Windows depende da câmera ser capaz de relatar de forma confiável seu estado do obturador. Com esta informação, as aplicações podem informar o utilizador que o obturador está fechado para que possam reagir em conformidade. As alterações de estado do obturador devem ser detetadas e relatadas o mais rápido possível após a ocorrência do evento.

Dois métodos são propostos para detetar o estado do obturador, sensores físicos e deteção baseada em firmware. Ambos os métodos relatam o estado do obturador detetado através de CT_PRIVACY_CONTROL se originado de um dispositivo UVC, ou de KSPROPERTY_CAMERACONTROL_PRIVACY se originado de um driver AVStream ou DMFT.

Consulte Notificação do obturador de privacidade para obter mais detalhes.

Sensor de deteção de estado físico

O estado do obturador pode ser detetado com um sensor físico que pode detetar se o obturador está aberto ou fechado. Os sensores físicos podem reportar deterministicamente o estado do obturador e podem fornecer uma experiência mais confiável. A Microsoft não tem nenhuma orientação específica disponível sobre projetos de sensores ou recomendações específicas para a tecnologia de sensores.

Deteção de estado baseada em firmware ISP

Alguns designs podem optar por ignorar um obturador físico e, em vez disso, usar o firmware dentro do ISP para processar a imagem e relatar o estado do obturador inferido. Tal solução analisaria a imagem capturada no firmware e compará-la com um limite para determinar se o obturador parece estar fechado. Esta é uma solução de baixo custo, uma vez que não requer peças novas e também é capaz de detetar coisas como fita sobre um sensor. No entanto, há duas considerações importantes ao optar por usar tal design:

1. O projeto pode indicar incorretamente um obturador fechado em ambientes escuros. No entanto, espera-se que este seja um risco / problema mínimo, já que a câmera não seria utilizável em um ambiente com pouca luz de qualquer maneira.

2. A menos que o ISP seja capaz de amostragem periódica do sensor sempre que ele estiver fora do D3, esse método impede que os aplicativos sejam capazes de consultar dados precisos do estado do sensor até que eles comecem a transmitir da câmera.

A segunda consideração acima cria um desafio. Se a câmera não informar o estado do obturador quando não está transmitindo, mas um aplicativo foi escrito para verificar e reagir ao estado do obturador antes do streaming, coisas ruins podem acontecer. Em resposta ao feedback que recebemos dos parceiros, este requisito foi flexibilizado. Também estamos atualizando a documentação da API para aconselhar os desenvolvedores de software a não tomarem decisões com base no estado do obturador relatado quando não estiver transmitindo. Por exemplo, aconselharemos explicitamente os desenvolvedores de aplicativos a não permitir que a câmera seja ligada se o obturador estiver relatando que ela está fechada.

Para evitar o risco de problemas de compatibilidade com aplicações que não aderem a este conselho, espera-se que as câmaras que não conseguem detetar o estado do obturador quando não estão a transmitir em fluxo comuniquem que o obturador está ABERTO sempre que não está a transmitir. Caso contrário, se a câmara conseguir detetar o estado do obturador quando não estiver a transmitir, espera-se que detete e reporte o estado do obturador sempre que não estiver em D3.

Observação

Os algoritmos de deteção do obturador baseados em análise de imagem devem ser sempre implementados no firmware, em vez de um driver, para evitar o aumento da carga da CPU e para máxima robustez.

Aqui está um diagrama ilustrando o comportamento esperado para um dispositivo com um obturador de privacidade da câmera:

Tabela de resumo do comportamento do obturador de privacidade da câmera

A tabela a seguir resumiu o comportamento esperado de uma câmera com um obturador de privacidade da câmera (manual ou eletromecânico):

Estado do ISP	Estado do obturador	LED indicador visível	Imagem transmitida para PC	O estado do CT_PRIVACY_CONTROL foi reportado
Inativo/D3	Aberto	Desligado*	N/A	Aberto
Inativo/D3	Fechado	Desligado*	N/A	Aberto
Streaming (qualquer aplicativo)	Aberto	Ligado*	Imagem do sensor capturada	Aberto
Streaming (qualquer aplicativo)	Fechado	Ligado*	Imagem do sensor capturada	Fechado

(*) Consulte Requisitos de LED do obturador de privacidade da câmera e Mecanismos de alternância do estado do obturador para obter detalhes sobre os requisitos de LED indicador.

(**) Consulte Deteção e relatório do estado do obturador para obter detalhes, em alguns cenários o estado do obturador ainda será atualizado quando não estiver transmitindo.

Orientação de design de kill switch

Quando um cliente usa um dispositivo com um kill switch, ele está colocando confiança em um switch de hardware para proteger robustamente contra qualquer aplicativo que tente capturar sua imagem. Simplificando, a expectativa do utilizador é que, se o meu dispositivo tiver um interruptor de emergência e o interruptor de emergência for ativado, a minha privacidade estará protegida contra qualquer acesso não autorizado à câmara. É crucial que a implementação do recurso corresponda às expectativas implícitas, caso contrário, perde toda a confiança.

Além disso, todo o conceito de um kill switch é fornecer uma camada de segurança que é reforçada contra qualquer ataque prático de software. Se o dispositivo tiver um kill switch e o sistema estiver totalmente comprometido por software mal-intencionado, esse software não poderá substituir o kill switch e comprometer a privacidade do usuário. Simplificando, a expectativa é que *o kill switch só possa ser ativado/desativado pelo usuário que interage fisicamente com o dispositivo.

Em comparação com os designs de obturadores de privacidade, os kill switches são mais complexos e apresentam mais desafios para garantir confiança. Isso ocorre porque eles carregam o mesmo nível de expectativa de robustez (espera-se que um interruptor físico funcione perfeitamente em todos os cenários), mas não fornecem a garantia que um obturador físico sobre a lente fornece. Isso significa que os dispositivos que oferecem kill switches devem produzir uma experiência consistente, clara e confiável.

Funcionalidade do interruptor de emergência

Os kill switches funcionam dizendo ao firmware do ISP para parar de capturar a partir do sensor e sintetizar uma imagem preta. Desta forma, a câmera ainda está disponível e funcional do ponto de vista das aplicações, mas não há dados reais do sensor sendo transmitidos para o sistema operacional host quando o kill switch está ativo. Um design robusto funcionaria da seguinte forma:

1. O sinal físico do switch se conecta a um GPIO no ISP, para indicar se o switch está ativo ou não

2. Quando o kill switch está ativo, o ISP:

   1. Desconecta eletricamente o sensor

   2. Começa a sintetizar quadros pretos para substituir quadros reais do sensor desconectado

   3. Informa que o obturador está fechado através da funcionalidade de notificação do obturador de privacidade

Na prática, o silício ISP que suporta essa experiência completa, incluindo uma desconexão elétrica do sensor quando o kill switch GPIO está ativo, ainda não está disponível no mercado. Assim, os designs atuais requerem a modificação da etapa 2a acima para "Parar o sensor ou descartar os dados do sensor no firmware". Planeamos trabalhar com fornecedores de ISP para mitigar a necessidade deste alojamento em silício futuro.

Observação

É fundamental que a funcionalidade kill switch seja implementada no firmware do ISP, e não dentro de um driver em execução no sistema operacional host. Os dados reais de imagem do sensor não devem ser transferidos para o OS quando o kill switch está no estado "kill".

Tal como acontece com os obturadores de privacidade, os OEMs podem substituir a imagem por uma imagem estática quando o Kill Switch está no estado "matar". A substituição de imagem pode ocorrer dentro do ISP ou dentro do driver, embora a substituição dentro do ISP seja recomendada para reduzir a necessidade de DMFTs e adicionar carga ao dispositivo host. Se a substituição de imagem for realizada no driver, observe que o requisito de que os dados de imagem reais não sejam transferidos para o sistema operacional quando o kill switch estiver no estado "matar" ainda se aplica.

Implementação de kill switch

O estado do kill switch não deve ser controlado por software, caso contrário, um aplicativo mal-intencionado pode gravar o controle para ativar ou desativar o kill switch. Eles devem ser controlados por um switch conectado a um GPIO no ISP.

É importante que, quando os interruptores de desativação das câmaras estiverem desativados, a câmara esteja ainda visível no sistema e os aplicativos ainda possam fazer streaming a partir dela, a imagem simplesmente fique preta. Os frames continuam a ser entregues ao SO, e a câmara continua a responder aos controlos; as aplicações não sabem que o switch está no estado de desativação, a menos que a aplicação esteja a usar as APIs CameraOcclusionInfo. Isso permite que a câmera seja desativada através de um controle de hardware sem introduzir mensagens confusas de "câmera não encontrada" ou correr o risco de certos aplicativos falharem ao virar o interruptor.

Conforme descrito em Obturadores com várias câmeras em um painel, os dispositivos com câmeras IR e RGB separadas no mesmo painel devem ter ambos os sensores desativados simultaneamente quando o kill switch é ativado.

Requisitos do LED HLK

O HLK requer que o LED indicador esteja ligado quando o ISP estiver capturando dados do sensor. Ativar o kill switch significa que o ISP deve parar de capturar dados reais do sensor, então o LED também deve se desligar com o kill switch. Isso evita qualquer confusão ou quebra de confiança, se o cliente vê um indicador luminoso ou LED iluminador IR, ele sabe que o software está atualmente capturando sua imagem, e se ele não vê um LED aceso, eles sabem que eles não estão sendo capturados.

Relatório de estado do kill switch

O estado do kill switch deve ser comunicado através de CT_PRIVACY_CONTROL (se for proveniente de um dispositivo UVC) ou KSPROPERTY_CAMERACONTROL_PRIVACY (se for proveniente de um controlador AVStream ou DMFT). O estado do interruptor de desligamento da câmera deve ser relatado sempre que o ISP estiver fora do modo D3.

Consulte Notificação de obturador/comutador de privacidade para obter mais detalhes.

Tabela de resumo do comportamento do kill switch

A tabela a seguir resume o comportamento esperado de uma câmara com um interruptor de desligamento da câmara.

Estado do ISP	Estado do interruptor de emergência	LED indicador visível	Imagem transmitida para PC	O estado do CT_PRIVACY_CONTROL foi reportado
Inativo/D3	Correr	Desligado*	N/A	Abrir
Inativo/D3	Matar	Desligado*	N/A	Fechar
Streaming (qualquer aplicativo)	Correr	Ligado*	Imagem do sensor capturada	Abrir
Streaming (qualquer aplicativo)	Matar	Desligado*	Quadros em branco sintetizados	Fechar

(*) Consulte Requisitos de LED do obturador de privacidade da câmera e Mecanismos de alternância do estado do obturador para obter detalhes sobre os requisitos de LED indicador.

Orientação do ISV para eventos de disparo/interruptor

Quando uma câmara com um obturador de privacidade ou kill switch segue as orientações nesta documentação, o estado do obturador/interruptor é reportado ao SO quando a câmara está a transmitir. Os aplicativos que usam a câmera podem monitorar eventos de alteração de estado do obturador e responder de acordo, como produzindo um aviso útil de que a câmera está bloqueada por um obturador ou interruptor.

Consulte as seguintes APIs para obter mais informações:

CameraOcclusionInfo Classe

CameraOcclusionState Classe

VideoDeviceController.CameraOcclusionInfo Propriedade