Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo fornece orientações de design de dispositivos para obturadores de privacidade ou interruptores de desligamento, considerações sobre a detecção de estado do obturador e como se espera que os obturadores interfiram com os requisitos HLK existentes para LEDs indicadores.
Requisitos comuns de LED
Independentemente de obturadores ou interruptores de segurança, 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) 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 um comprimento de onda invisível (940 nm). Além disso, os aplicativos podem transmitir do sensor IR individualmente, do sensor RGB individualmente ou de 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 indicador visível. Isso significa que, se a câmera IR estiver ativada sozinha, os requisitos de HLK serão atendidos com o LED do iluminador IR aceso.
Os designs 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 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 ativem o LED do indicador em uso regular 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 do fluxo | LED IR visível (850 nm) | LED IR invisível (940 nm) |
|---|---|---|
| Câmera desativada | LEDs DESATIVADOS | LEDs DESLIGADOS |
| Somente a câmera RGB ligada | Indicador em uso ON, iluminador DE IR OFF | Indicador em uso ON, iluminador DE IR OFF |
| Somente a câmera IR ligada | Indicador em uso não necessário, mas recomendado ON | Indicador em uso ON, Iluminador DE IR ON |
| Câmera RGB e IR ativada | Indicador em uso ON, Iluminador DE IR ON | Indicador em uso ON, Iluminador DE IR ON |
Observação
Os requisitos de LED podem ser diferentes para designs com cortinas de privacidade da câmera ou interruptores de desativação da câmera. Consulte os requisitos de LED do obturador de privacidade da câmera para obter informações sobre obturadores de privacidade da câmera e requisitos de LED do HLK para interruptores de desligamento da 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 ativos baseados em câmera, onde o chip de IA compartilha o sensor principal da câmera, os requisitos de LED diferem quando o chip dedicado para presença está acessando exclusivamente a câmera. Consulte o Whitepaper de 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:
Dispositivos com controles de privacidade devem fornecer uma experiência de usuário consistente e confiança no estado de privacidade:
- Uma vez 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 falhar em proporcionar privacidade nos momentos mais importantes para o cliente. Se o obturador de privacidade da câmera estiver fechado ou o botão de desligamento 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, cortinas de privacidade para câmeras (mecânicas e eletromecânicas) e interruptores de desconexão da câmera. Dependendo do formato do dispositivo, dos custos da lista de materiais e da faixa de preço do dispositivo, um OEM pode optar por implementar o obturador em qualquer uma dessas formas. 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; são uma simples tampa deslizante de lente 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 fechado. 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 eletromecânico de privacidade da câmera
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 de obturador e o botão não devem ter vetores de ataque, como barramentos de comunicação ou a capacidade de reprogramar firmware. O design deve exigir interação de hardware e não ser controlável por meio do software.
Interruptores de desligamento de câmera
Alguns dispositivos hoje em dia vêm com um recurso de interruptor de desligamento da câmera, que desconecta fisicamente o dispositivo da câmera do sistema quando desativado, fornecendo um controle de hardware para bloquear o acesso à câmera sem a necessidade de uma cobertura física para cobrir a lente ou sensor. Embora isso seja robusto contra ataques, ele cria uma experiência de usuário ruim. Ao remover o dispositivo enquanto o comutador está desligado, o sistema não consegue perceber que o chassi ainda possui uma câmera, mas que está desativada. Isso pode ser problemático do ponto de vista da UX se a câmera for desativada involuntariamente por um usuário que desconhece o botão, já que os aplicativos relatam 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 oferece suporte ao uso de interruptores que desativam totalmente a câmera do sistema. Em vez disso, recomendamos uma das duas soluções:
Um obturador físico, conforme descrito no obturador de privacidade da câmera mecânica e no obturador de privacidade da câmera eletromecânica.
Um interruptor de segurança 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. 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 interruptor de segurança estar ativo ou não. No entanto, quando o interruptor de segurança é ativado, o ISP para de capturar dados reais do sensor e, em vez disso, sintetiza e transmite quadros pretos, totalmente transparente na perspectiva do aplicativo.
Obturadores com várias câmeras em um painel
Quando os clientes usam dispositivos com obturadores (por exemplo, janelas com várias câmeras IR e RGB em um painel), eles esperam que, se o obturador estiver fechado, a privacidade será 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 ao 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 os obturadores e os interruptores de segurança se apliquem à câmera de infravermelho é de extrema importância porque a câmera de infravermelho pode ser acessada por aplicativos e produzir imagens de alta fidelidade razoável da cena, conforme mostrado abaixo. A falha ao ocluir o sensor de IR representaria uma falsa sensação de segurança e violação da confiança do usuário quanto ao mérito de privacidade da cortina.
Observação
O Windows Hello Face requer uma câmera RGB e IR. Se a câmera RGB estiver obstruída, Windows Hello não funcionará corretamente. Os fluxos RGB e IR são usados para habilitar medidas de combate à falsificação.
Diretrizes de design do obturador físico (mecânica ou eletromecânica)
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 faz 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 que seja 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 janelas físicas, seja manual ou eletromecanicamente atuadas, sejam feitas 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, 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 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 a substitua 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 Whitepaper de 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 janelas físicas 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 está 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 para o LED do obturador de privacidade da câmera
Os requisitos de LED devem seguir os requisitos especificados requisitos de LED comuns. Isso significa que, se qualquer câmera no painel estiver ativada, um LED de indicador de comprimento de onda visível em uso deverá permanecer ativado, 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 estiver 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 desativar o LED do iluminador IR se a câmera IR for usada enquanto o obturador estiver fechado. Recomendamos contra isso, pois adiciona complexidade adicional para pouco valor; a câmera IR só estará ativa se o Windows Hello estiver em execução, e ele exibirá uma mensagem durante esse tempo em que tenta fazer logon, com o obturador fechado. Consulte o kill switch implementation para mais 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 é iluminado quando a câmera IR está ativa), um design pode desligar o LED do iluminador IR quando o obturador está fechado.
Mecanismos de alternância de estado do obturador
Os dispositivos que implementam janelas 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, já que um obturador fechado nem sempre significa que o controle de privacidade está habilitado. Da mesma forma, o obturador pode não abrir ou fechar quando um aplicativo usa a câmera, pela mesma razão. Em resumo, se o usuário olha para o dispositivo e vê que o obturador está fechado, ele deve 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 o obturador involuntariamente e não consegue descobrir por que sua câmera está produzindo uma imagem em branco ou não está 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 detectado do obturador por meio de CT_PRIVACY_CONTROL se se originar de um dispositivo UVC, ou KSPROPERTY_CAMERACONTROL_PRIVACY se se originar de um driver AVStream ou DMFT.
Consulte a notificação sobre o 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. 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 a tecnologia de sensor.
Detecção de estado baseada em firmware de 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 projeto pode indicar 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 realizar amostragem periódica do sensor sempre que estiver fora do estado D3, esse método impede que os aplicativos consultem o estado preciso do sensor até que iniciem a transmissão 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 foi criado para verificar e reagir ao estado do obturador antes da transmissão, coisas ruins poderão acontecer. Em resposta aos comentários que recebemos dos parceiros, esse requisito foi relaxado. Também estamos atualizando a documentação da API para aconselhar os desenvolvedores de software contra tomar decisões com base no estado do obturador relatado quando não está em streaming. Por exemplo, aconselhamos explicitamente os desenvolvedores de aplicativos a não permitirem que a câmera seja ativada se o obturador estiver relatando que ele está fechado.
Para evitar o risco de problemas de compatibilidade com aplicativos que não aderem a esse conselho, câmeras que não podem detectar o estado do obturador quando não estão transmitindo devem relatar que o obturador está ABERTO sempre que não estão transmitindo. Caso contrário, se a câmera puder sentir o estado do obturador quando não estiver transmitindo, deverá detectar e relatar o estado do obturador sempre que não estiver na D3.
Observação
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 para 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 PC | Relatado estado de CT_PRIVACY_CONTROL |
|---|---|---|---|---|
| Ocioso/D3 | Aberto | Desligado* | Não aplicável | Aberto |
| Ocioso/D3 | Fechado | Desligado* | Não aplicável | Aberto** |
| Streaming (qualquer aplicativo) | Aberto | Em* | Imagem do sensor capturada | Aberto |
| Streaming (qualquer aplicativo) | Fechado | Ligado* | Imagem do sensor capturada | Fechado |
(*) Consulte os requisitos do LED do obturador de privacidade da câmera e os mecanismos de alternância do estado do obturador para obter detalhes sobre os requisitos do LED indicador.
(**) Consulte o sensor de estado do Obturador e os relatórios para obter detalhes, em alguns cenários o estado do obturador ainda será atualizado quando não estiver transmitindo.
Diretrizes de design do interruptor de emergência
Quando um cliente usa um dispositivo com um interruptor de desligamento, ele está colocando confiança em um interruptor de hardware para proteger de forma robusta contra qualquer aplicativo que tente capturar sua imagem. Simplesmente, a expectativa do usuário é que, se meu dispositivo tiver um interruptor de desativação e se o interruptor estiver ativado, minha privacidade estará protegida contra qualquer acesso inesperado à câmera. É crucial que a implementação do recurso faz 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 interruptor de emergência e o sistema estiver totalmente comprometido por software mal-intencionado, esse software não poderá substituir o interruptor de emergência e comprometer a privacidade do usuário. Simplificando, a expectativa é que o interruptor só possa ser ativado/desativado pelo usuário mediante interação física 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 assegurar 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 interruptores de desligamento devem proporcionar uma experiência consistente, clara e confiável.
Funcionalidade de interruptor de emergência
Interruptores de desativação operam ao instruir o firmware ISP a 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 de desligamento 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 interruptor de desligamento estiver ativo, o ISP:
Desconecta eletricamente 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 de ISP que oferece suporte a essa experiência completa, incluindo a desconexão elétrica do sensor quando o GPIO do "kill switch" está ativo, ainda não está disponível no mercado. Assim, os designs atuais exigem a modificação da etapa 2a acima para "Parar o sensor ou descartar os dados do sensor no firmware". Planejamos trabalhar com fornecedores de ISP para reduzir a necessidade dessa acomodação em futuros desenvolvimentos de semicondutores.
Observação
É fundamental que a funcionalidade do kill switch seja implementada no firmware ISP e não dentro de um driver em execução no sistema operacional host. Dados reais de imagem do sensor não devem ser transferidos para o sistema operacional quando o interruptor de segurança está no estado "desativado".
Assim como acontece com o Privacy Shutters, os OEMs podem substituir a imagem por uma imagem estática quando o Kill Switch está no estado "kill". 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 executada no driver, observe o requisito de que os dados reais da imagem não sejam transferidos para o sistema operacional, ainda se aplicando quando o interruptor de desligamento estiver no estado "kill".
Implementação do interruptor de emergência
O estado do "kill switch" não deve ser controlado por software; caso contrário, um aplicativo mal-intencionado pode manipular o controle para ativar ou desativar o "kill switch". Eles devem ser controlados por um comutador conectado a um GPIO no ISP.
É importante que, quando os interruptores de interrupção da câmera estejam desligados, a câmera ainda apareça no sistema e os aplicativos ainda possam transmitir dela, apenas a imagem fica preta. Os frames continuam a ser entregues ao sistema operacional e a câmera continua respondendo aos controles; os aplicativos não sabem que o interruptor 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, dispositivos com câmeras IR e RGB separadas no mesmo painel devem ter ambos os sensores simultaneamente desabilitados quando o interruptor de segurança é 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 interruptor de emergência significa que o ISP deve parar de capturar dados reais do sensor, portanto, espera-se que o LED também se desligue junto com o interruptor de emergência. Isso evita qualquer confusão ou violação de confiança, se o cliente vir um indicador aceso 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 do estado do kill switch
O estado do interruptor 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 "Camera Kill Switch" deve ser relatado sempre que o ISP estiver fora do modo D3.
Consulte a notificação do obturador/comutador de privacidade para obter mais detalhes.
Tabela de resumo do comportamento do interruptor de desligamento de emergência
A tabela a seguir resume o comportamento esperado de uma câmera com um interruptor de desativação da câmera:
| Estado do ISP | Estado do interruptor de emergência | LED de indicador visível | Imagem transmitida para o PC | Relatado estado de CT_PRIVACY_CONTROL |
|---|---|---|---|---|
| Ocioso/D3 | Correr | Desligado* | Não aplicável | Abrir |
| Ocioso/D3 | Kill | Desligado* | Não aplicável | Fechar |
| Streaming (qualquer aplicativo) | Correr | Em* | Imagem do sensor capturada | Abrir |
| Streaming (qualquer aplicativo) | Kill | Desligado* | Quadros em branco sintetizados | Fechar |
(*) Consulte os requisitos do LED do obturador de privacidade da câmera e os mecanismos de alternância do estado do obturador para obter detalhes sobre os requisitos do LED indicador.
Diretrizes de ISV para eventos de obturador/comutador
Quando uma câmera com um obturador de privacidade ou um interruptor de segurança segue as diretrizes nesta documentação, o estado do obturador/interruptor é informado 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: