Obturadores de privacidade da câmera e interruptores de encerramento
Este artigo fornece diretrizes de design de dispositivo para obturadores de privacidade ou interruptores de encerramento, considerações para sensoriamento de estado do obturador e como espera-se que as janelas interajam com os requisitos de HLK existentes para LEDs indicadores.
Requisitos comuns de LED
Independentemente de obturadores ou interruptores de encerramento, o HLK requer que um LED indicador visível esteja ATIVADO 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) deverá estar LIGADO:
Para câmeras com um sensor RGB+IR, isso pode ser mais complexo porque a câmera IR requer um LED iluminador, e o LED do 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 de IR por si só, o sensor RGB por si só ou ambos simultaneamente.
Designs usando um iluminador IR de comprimento de onda visível podem optar por usar o LED do iluminador IR como o LED do indicador visível. Isso significa que, se a câmera IR estiver ativada por si só, os requisitos de HLK serão atendidos pelo LED do iluminador de IR que está sendo aceso:
Os designs que usam 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 atender aos requisitos de HLK. É recomendável compartilhar o LED indicador em uso da câmera, para que o mesmo LED de comprimento de onda visível seja ativado quando o sensor ir e/ou o sensor RGB estiver ATIVADO:
Recomendamos que todos os designs liguem o LED indicador regular em uso quando a câmera IR ou RGB for usada, independentemente de o LED do iluminador IR usar um comprimento de onda visível ou não. Aqui está a tabela completa dos principais requisitos de LED:
| estado Stream | LED ir visível (850 nm) | LED ir invisível (940 nm) |
|---|---|---|
| Câmera desligada | LEDs OFF | LEDs OFF |
| Somente câmera RGB ativada | Indicador em uso ON, iluminador DE IR OFF | Indicador em uso ON, iluminador DE IR OFF |
| Somente câmera IR ativada | Indicador em uso não necessário, mas RECOMENDADO COMO ATIVADO | Indicador em uso ON, iluminador de IR ATIVADO |
| Câmera RGB e IR ativada | Indicador em uso ON, iluminador de IR ATIVADO | Indicador em uso ON, iluminador de IR ATIVADO |
Observação
Os requisitos de LED podem ser diferentes para designs com obturadores de privacidade da câmera ou comutadores de encerramento de câmera. 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 comutadores de encerramento de câmera.
Experiências de IA sempre ativadas (por exemplo, presença humana baseada em câmera)
Para dispositivos que dão suporte a recursos de IA sempre ativados baseados em câmera, em que o silício de IA compartilha o sensor da câmera main, os requisitos de LED diferem quando o silício de presença dedicado está acessando exclusivamente a câmera. Consulte o White paper Detecção de Presença no Microsoft Partner Center para obter detalhes.
Controles de privacidade de hardware
Quando os designs de câmera incluem controles de privacidade de hardware, há dois princípios principais de nossas diretrizes de design:
Os dispositivos com controles de privacidade devem fornecer uma experiência de usuário consistente e confiança no estado de privacidade:
- Depois que um cliente aprende como o obturador em seu dispositivo parece e se comporta, esse conhecimento deve se aplicar a qualquer dispositivo que ele usa que tenha um obturador.
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 fornecer privacidade quando mais importantes para o cliente. Se o obturador de privacidade da câmera estiver fechado ou o botão de encerramento da câmera estiver desativado, os clientes esperam que nenhuma imagem possa ser capturada até interagir com o controle físico para desativar o recurso de privacidade.
Tipos de controles
Duas formas de controles de privacidade são definidas, obturadores de privacidade da câmera (mecânicos e eletromecânicos) e interruptores de encerramento de câmera. Dependendo do fator forma do dispositivo, das metas de custo da BOM e do ponto de preço do dispositivo, um OEM pode optar por implementar o obturador em qualquer um desses formulários. Uma constante importante entre os três é que eles devem agir no nível físico ou de hardware, o que significa que nenhum software está envolvido, pois o software pode ser comprometido.
Obturador de privacidade da câmera mecânica
Obturadores mecânicos são o design mais simples, estas são uma simples capa de lente deslizante que o usuário atua manualmente para bloquear a câmera ou não. Eles são projetados usando um material opaco que bloqueia totalmente a lente quando fechada. Esse design é inerentemente infalível no sentido de que eles fisicamente não podem ser comprometidos para abrir de qualquer maneira, exceto pelo usuário deslizando-o.
Obturador de privacidade da câmera eletromecânica
Obturadores eletromecânicos são obturadores mecânicos controlados eletricamente. Em vez de o usuário abrir ou fechar manualmente o obturador, o obturador integrado abre/fecha em resposta à pressão de um botão físico no dispositivo.
Observação
Embora essa solução geralmente exija firmware, ela deve ser isolada de outros componentes. Em outras palavras, o controlador do obturador e o botão não devem ter vetores de ataque, como barramentos de comunicação ou a capacidade de reprogramação do firmware. O design deve exigir interação de hardware e não ser controlável por meio de software.
Interruptores de encerramento da câmera
Alguns dispositivos hoje são fornecidos com um recurso de interruptor de encerramento de câmera, que desconecta fisicamente o dispositivo de 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, ele cria uma experiência de usuário ruim. Ao remover o dispositivo quando o interruptor está desativado, o sistema não pode dizer que o chassi ainda tem uma câmera, mas que ele está desligado. Isso é problemático do ponto de vista da experiência do usuário se a câmera for desativada involuntariamente por um usuário que desconhece o comutador, pois os aplicativos relatarão que não há câmeras conectadas. Isso também pode fazer com que determinados aplicativos falhem ou se comportem mal se a câmera for removida durante o uso ou aparecer enquanto o aplicativo estiver em execução.
Assim, a Microsoft não recomenda nem dá suporte ao uso de comutadores de câmera que removem toda a câmera do sistema. Em vez disso, recomendamos uma das duas soluções:
Um obturador físico, conforme descrito em Obturador de privacidade da câmera mecânica e obturador de privacidade da câmera eletromecânica.
Um comutador kill que desconecta o sensor, em vez do 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 comutador de encerramento estar ativo ou não. No entanto, quando o comutador kill é ativado, o ISP para de capturar dados reais do sensor e, em vez disso, sintetiza e transmite quadros pretos, todos transparentes da perspectiva do aplicativo.
Obturadores com várias câmeras em um 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 dar suporte a 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 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 obturadores e interruptores de encerramento se apliquem à câmera IR é de extrema importância porque a câmera ir pode ser acessada por aplicativos e produzir imagens razoavelmente de alta fidelidade da cena, conforme mostrado abaixo. Não ocluir o sensor de IR representaria uma falsa sensação de segurança e violação da confiança do usuário no mérito de privacidade do obturador.
Observação
Windows Hello Face requer uma câmera RGB e IR. Se a câmera RGB estiver ocluída, Windows Hello não funcionará corretamente. Os fluxos RGB e IR são usados para habilitar medidas antifalsificação contra falsificação.
Diretrizes de design 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 oferece uma forte expectativa implícita sobre o nível de privacidade que ele fornece. 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 faça jus às expectativas implícitas, caso contrário, ela perde toda a confiança.
Além disso, todo o conceito de um obturador de privacidade é fornecer uma camada de segurança protegida 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 poderá comprometer a privacidade do usuário. Novamente, para simplificar, a expectativa é que o obturador só possa alterar o estado se o usuário interagir fisicamente com o controle do obturador de hardware no dispositivo.
Considerações sobre design mecânico
Espera-se que as persianas físicas, sejam elas acionados manual ou eletromecanicamente, sejam feitas de um material opaco que bloqueie totalmente o sensor quando fechado e seja visível a olho nu:
Conforme descrito em Obturadores com várias câmeras em um painel, dispositivos com câmera IR e RGB separadas 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 é fechado, ele deve cobrir o sensor RGB, é opcional cobrir o sensor de IR:
Observação
Atualmente, damos suporte a uma isenção para câmeras cujos designs mecânicos de obturador não cobrem a câmera IR. Quando um obturador físico está ocluindo a câmera RGB, é aceitável que o firmware isp descarte a saída da imagem da câmera IR e substitua-a por uma imagem preta sintetizada. No entanto, se o sensor de IR for usado para Detecção de Presença, é recomendável não cobrir o sensor de IR e garantir que o sensor de presença esteja funcional. Consulte o White paper Detecção de Presença no Microsoft Partner Center para obter detalhes. Uma atualização futura 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âmera é equipada com um obturador físico, a câmera deve continuar operando normalmente, independentemente do estado do obturador. Se um aplicativo estiver transmitindo da câmera, ele continuará capturando e transmitindo dados reais do sensor, mesmo que o obturador esteja fechado. Espera-se que a oclusão completa 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). Essa imagem deve ser estática e não pode ser alterada do software para proteger contra explorações. 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.
Requisitos de LED do obturador de privacidade da câmera
Os requisitos de LED devem seguir os requisitos especificados requisitos comuns de LED. Isso significa que, se qualquer câmera no painel estiver ativada, um LED indicador de comprimento de onda visível em uso deverá permanecer ligado, 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 é fechado. Os diagramas abaixo ilustram um cenário em que a câmera está transmitindo ativamente:
Para designs com uma câmera IR e RGB, alguns fabricantes podem querer desligar o LED do iluminador IR se a câmera IR for usada enquanto o obturador estiver fechado. Recomendamos isso, pois ele adiciona complexidade adicional para pouco valor; a câmera do IR só estará ativa se Windows Hello estiver em execução e Windows Hello exibir uma mensagem durante esse tempo que está tentando fazer logon, mas o obturador está fechado. Confira Implementação do comutador de encerramento para obter detalhes.
No entanto, se um LED do iluminador IR de 840 nm (visível) não for o único LED indicador em uso para a câmera IR (por exemplo, um LED branco/verde/azul visível normal será iluminado quando a câmera IR estiver ativa), um design poderá desligar o LED do iluminador IR quando o obturador estiver fechado.
Mecanismos de alternação de 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 ao usuário interagir explicitamente com o controle do obturador. Esse controle do obturador pode ser um controle deslizante mecânico ou um botão físico que atua um obturador eletromecânico. Nenhum software pode alterar o estado do obturador, mesmo que um controle de hardware possa substituir o software e manter o obturador fechado, pois um obturador fechado nem sempre significa que o controle de privacidade está habilitado. Da mesma forma, o obturador pode não abrir ou fechar um aplicativo usando a câmera, pelo mesmo motivo. Em resumo, se o usuário olhar para o dispositivo e ver que o obturador está fechado, ele deverá ser capaz de inferir inequivocamente que sua privacidade está protegida até que ele tome medidas físicas para abrir o obturador.
Sensoriamento e relatórios de estado do obturador
Muitos dos problemas com designs de privacidade de 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 de obturador. Com essas informações, os aplicativos podem informar ao usuário que o obturador está fechado para que ele possa reagir adequadamente. As alterações de estado do obturador devem ser detectadas e relatadas assim que possível após a ocorrência do evento.
Dois métodos são propostos para detectar o estado do obturador, sensores físicos e detecção baseada em firmware. Ambos os métodos relatam o estado do obturador detectado por meio de CT_PRIVACY_CONTROL se originou de um dispositivo UVC ou KSPROPERTY_CAMERACONTROL_PRIVACY se for proveniente de um driver AVStream ou DMFT.
Confira Notificação do obturador de privacidade para obter mais detalhes.
Sensor de detecção de estado físico
O estado do obturador pode ser detectado com um sensor físico que pode detectar se o obturador está aberto ou fechado. Os sensores físicos podem relatar 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 designs de sensor ou recomendações específicas para tecnologia de sensor.
Detecção de estado baseada em firmware do 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. Essa solução analisaria a imagem capturada no firmware e a compararia com um limite para determinar se o obturador parece estar fechado. Essa é uma solução de baixo custo, pois não requer novas partes e também é capaz de detectar itens como fita em um sensor. No entanto, há duas considerações importantes ao optar por usar esse design:
O design pode relatar falsamente um obturador fechado em ambientes escuros. No entanto, espera-se que isso seja um risco/problema mínimo, pois a câmera não seria utilizável em um ambiente tão baixo de luz de qualquer maneira.
A menos que o ISP seja capaz de fazer a amostragem periódica do sensor sempre que estiver fora do D3, esse método impede que os aplicativos possam consultar dados de estado precisos do sensor até que iniciem o streaming da câmera.
A segunda consideração acima cria um desafio. Se a câmera não relatar o estado do obturador quando não estiver transmitindo, mas um aplicativo tiver sido gravado para marcar e reagir ao estado do obturador antes do streaming, coisas ruins poderão acontecer. Em resposta aos comentários que recebemos de parceiros, esse requisito foi relaxado. Também estamos atualizando a documentação da API para aconselhar os desenvolvedores de software a não tomar decisões com base no estado do obturador relatado quando não está transmitindo. Por exemplo, aconselharemos explicitamente os desenvolvedores de aplicativos a não permitirem que a câmera seja ativada se o obturador estiver relatando que ela está fechada.
Para evitar o risco de problemas de compatibilidade com aplicativos que não aderem a esse conselho, câmeras que não conseguem detectar o estado do obturador quando não há streaming devem relatar que o obturador está ABERTO sempre que não está transmitindo. Caso contrário, se a câmera puder detectar o estado do obturador quando não estiver transmitindo, espera-se detectar e relatar o estado do obturador sempre que não estiver em D3.
Observação
Os algoritmos de detecção de obturador baseados em análise de imagem sempre devem ser implementados no firmware em vez de um driver, para evitar o aumento da carga da CPU e a robustez máxima.
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ânica):
| Estado do ISP | Estado do obturador | LED de indicador visível | Imagem transmitida para o computador | Estado de CT_PRIVACY_CONTROL relatado |
|---|---|---|---|---|
| Ocioso/D3 | Aberto | Desativado* | N/D | Aberto |
| Ocioso/D3 | Fechadas | Desativado* | N/D | Aberto** |
| Streaming (qualquer aplicativo) | Aberto | Em* | Imagem do sensor capturada | Aberto |
| Streaming (qualquer aplicativo) | Fechadas | Em* | Imagem do sensor capturada | Fechadas |
(*) Consulte Requisitos de LED do obturador de privacidade da câmera e Mecanismos de alternação de estado do obturador para obter detalhes sobre os requisitos de LED do indicador.
(**) Confira Sensoriamento de estado do obturador e relatórios para obter detalhes. Em alguns cenários, o estado do obturador ainda será atualizado quando não estiver transmitindo.
Diretrizes de design de comutador de encerramento
Quando um cliente usa um dispositivo com um comutador de encerramento, ele está colocando confiança em um comutador de hardware para proteger robustamente contra qualquer aplicativo que tente capturar sua imagem. Simplificando, essa expectativa do usuário é que, se meu dispositivo tiver um interruptor de encerramento e o botão de encerramento estiver ativado, minha privacidade estará protegida contra qualquer acesso inesperado à câmera. É crucial que a implementação do recurso faça jus às expectativas implícitas, caso contrário, ela perde toda a confiança.
Além disso, todo o conceito de um kill switch é fornecer uma camada de segurança protegida contra qualquer ataque prático de software. Se o dispositivo tiver um comutador kill 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 comutador kill só possa ser ativado/desativado pelo usuário interagindo fisicamente com o dispositivo.
Em comparação com os designs do obturador de privacidade, os kill switches são mais complexos e carregam mais desafios para entregar com confiança. Isso ocorre porque eles carregam o mesmo nível de expectativa de robustez (espera-se que um comutador físico funcione perfeitamente em todos os cenários), mas eles não fornecem a garantia de que um obturador físico sobre a lente fornece. Isso significa que os dispositivos que oferecem comutadores de encerramento devem produzir uma experiência consistente, clara e confiável.
Funcionalidade de comutador de encerramento
Os comutadores kill operam informando ao firmware ISP para parar de capturar do sensor e, em vez disso, sintetizar uma imagem preta. Dessa forma, a câmera ainda está disponível e funcional da perspectiva dos aplicativos, mas não há dados reais do sensor sendo transmitidos para o sistema operacional host quando o comutador kill está ativo. Um design robusto funcionaria da seguinte maneira:
O sinal físico do comutador se conecta a um GPIO no ISP, para indicar se o comutador está ativo ou não
Quando o comutador kill estiver ativo, o ISP:
Eletricamente desconecta o sensor
Começa a sintetizar quadros pretos para substituir quadros reais do sensor desconectado
Relata que o obturador está fechado por meio do recurso de notificação do obturador de privacidade
Na prática, o silício ISP que dá suporte a essa experiência completa, incluindo uma desconexão elétrica do sensor quando o gpio kill switch está ativo, ainda não está disponível no mercado. Assim, os designs atuais exigem modificação da etapa 2a acima para "Parar o sensor ou descartar os dados do sensor no firmware". Planejamos trabalhar com fornecedores isp para atenuar a necessidade dessa acomodação no silício futuro.
Observação
É fundamental que a funcionalidade de kill switch seja implementada no firmware ISP e não dentro de um driver em execução no sistema operacional host. Os dados reais da imagem do sensor não devem ser transferidos para o sistema operacional quando o comutador kill está no estado "kill".
Assim como acontece com o Privacy Shutters, os OEMs podem substituir a imagem por uma imagem estática quando o Kill Switch estiver no estado "kill". A substituição da 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 executada no driver, observe o requisito de que os dados de imagem reais não sejam transferidos para o sistema operacional quando o comutador kill estiver no estado "kill" ainda se aplicará.
Implementação do comutador de encerramento
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 comutador kill. Eles devem ser controlados por um comutador conectado a um GPIO no ISP.
É importante que quando as câmeras matam os comutadores estiverem desligadas, a câmera ainda aparece no sistema e os aplicativos ainda podem transmitir dele, a imagem fica preta. Os quadros continuam a ser entregues ao sistema operacional e a câmera continua respondendo aos controles; os aplicativos não sabem que a opção está no estado "kill", a menos que o aplicativo esteja usando as APIs CameraOcclusionInfo . Isso permite que a câmera seja desabilitada por meio de um controle de hardware sem introduzir mensagens confusas de "câmera não encontrada" ou arriscar que determinados aplicativos falhem ao inverter o comutador.
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 desabilitados simultaneamente quando o comutador kill é ativado.
Requisitos de LED do HLK
O HLK requer que o LED do indicador esteja ATIVADO quando o ISP estiver capturando dados do sensor. Ativar o comutador de encerramento significa que o ISP deve parar de capturar dados reais do sensor, portanto, espera-se que o LED também desative com o comutador kill. Isso evita qualquer confusão ou violação de confiança, se o cliente vir um indicador iluminado ou LED do iluminador de IR, ele saberá que o software está capturando sua imagem no momento e, se não vir um LED aceso, ele saberá que não está sendo capturado.
Relatório de estado de comutador de eliminação
O estado do comutador kill deve ser relatado por meio de CT_PRIVACY_CONTROL (se originado de um dispositivo UVC) ou KSPROPERTY_CAMERACONTROL_PRIVACY (se originado de um driver AVStream ou DMFT). O estado do Comutador de Eliminação de Câmera deve ser relatado sempre que o ISP estiver fora do D3.
Consulte Notificação de obturador/comutador de privacidade para obter mais detalhes.
Tabela de resumo do comportamento do comutador de encerramento
A tabela a seguir resumiu o comportamento esperado de uma câmera com um comutador de encerramento de câmera:
| Estado ISP | Estado do comutador de encerramento | LED de indicador visível | Imagem transmitida para o computador | Estado de CT_PRIVACY_CONTROL relatado |
|---|---|---|---|---|
| Ocioso/D3 | Executar | Desativado* | N/D | Aberto |
| Ocioso/D3 | Encerrar | Desativado* | N/D | Fechar |
| Streaming (qualquer aplicativo) | Executar | Em* | Imagem do sensor capturada | Aberto |
| Streaming (qualquer aplicativo) | Encerrar | Desativado* | Quadros em branco sintetizados | Fechar |
(*) Confira Requisitos de LED do obturador de privacidade da câmera e Mecanismos de alternagem de estado do Obturador para obter detalhes sobre os requisitos de LED do indicador.
Diretrizes do ISV para eventos de obturador/comutador
Quando uma câmera com um obturador de privacidade ou comutador de encerramento segue as diretrizes nesta documentação, o estado do obturador/comutador é relatado ao sistema operacional quando a câmera está transmitindo. Os aplicativos que usam a câmera podem monitorar eventos de alteração de estado do obturador e responder adequadamente, como produzindo um aviso útil de que a câmera está bloqueada por um obturador ou comutador.
Consulte as seguintes APIs para obter mais informações: