Suporte de exibição

Confira abaixo as atualizações feitas nessas áreas específicas de exibição:

Redimensionar atividades e telas

Para indicar que um app pode não ser compatível com o modo de várias janelas ou com o redimensionamento, as atividades usam o atributo resizeableActivity=false. Problemas comuns encontrados por apps quando as atividades são redimensionadas incluem:

  • Uma atividade pode ter uma configuração diferente do app ou de outro componente não visual. Um erro comum é ler as métricas de exibição do contexto do app. Os valores retornados não serão ajustados às métricas da área visível em que uma atividade é mostrada.
  • Uma atividade pode não processar o redimensionamento e falhar, mostrar uma interface distorcida ou perder o estado devido ao reinício sem salvar o estado da instância.
  • Um app pode tentar usar coordenadas de entrada absolutas (em vez daquelas relativas à posição da janela), o que pode interromper a entrada no modo de várias janelas.

No Android 7 (e versões mais recentes), um app pode ser configurado resizeableActivity=false para sempre ser executado no modo de tela cheia. Nesse caso, a plataforma impede que atividades não redimensionáveis apareçam na tela dividida. Se o usuário tentar invocar uma atividade não redimensionável da tela de início ainda no modo de tela dividida, a plataforma sairá desse modo e iniciará a atividade não redimensionável no modo de tela cheia.

Apps que definem explicitamente esse atributo como false no manifesto não podem ser iniciados no modo de várias janelas, a menos que o modo de compatibilidade seja aplicado:

  • A mesma configuração é aplicada ao processo, que contém todas as atividades e componentes que não são de atividade.
  • A configuração aplicada atende aos requisitos do CDD para telas compatíveis com apps.

No Android 10, a plataforma ainda impede que atividades não redimensionáveis entrem no modo de tela dividida, mas podem ser escalonadas temporariamente se a atividade declarar uma orientação ou proporção fixa. Caso contrário, a atividade será redimensionada para preencher toda a tela, como no Android 9 e versões anteriores.

A implementação padrão aplica a seguinte política:

Quando uma atividade declarada ser incompatível com o modo de várias janelas pelo uso do atributo android:resizeableActivity e quando essa atividade atende a uma das condições descritas abaixo, quando a configuração de tela aplicada precisar mudar, a atividade e o processo serão salvos com a configuração original e o usuário terá uma affordance para reiniciar o processo do app para usar a configuração de tela atualizada.

  • É a orientação fixa pela aplicação de android:screenOrientation
  • O app tem uma proporção máxima ou mínima padrão segmentando o nível da API ou declara a proporção explicitamente

Esta figura mostra uma atividade não redimensionável com uma proporção declarada. Ao dobrar o dispositivo, a janela é reduzida para caber na área, mantendo a proporção usando o letterboxing apropriado. Além disso, uma opção de reiniciar a atividade é fornecida ao usuário sempre que a área de exibição da atividade é alterada.

Ao abrir o dispositivo, a configuração, o tamanho e a proporção da atividade não mudam, mas a opção de reiniciar a atividade aparece.

Quando resizeableActivity não está definido (ou está definido como true), o app é totalmente compatível com redimensionamento.

Implementação

Uma atividade não redimensionável com orientação ou proporção fixa é chamada de modo de compatibilidade de tamanho (SCM, na sigla em inglês) no código. A condição é definida em ActivityRecord#shouldUseSizeCompatMode(). Quando uma atividade do SCM é iniciada, a configuração relacionada à tela (como tamanho ou densidade) é fixada na configuração de substituição solicitada. Assim, a atividade não depende mais da configuração de exibição atual.

Se a atividade do SCM não puder preencher toda a tela, ela será alinhada na parte de cima e centralizada horizontalmente. Os limites de atividade são calculados por AppWindowToken#calculateCompatBoundsTransformation().

Quando uma atividade do SCM usa uma configuração de tela diferente do contêiner (por exemplo, a tela é redimensionada ou a atividade é movida para outra tela), ActivityRecord#inSizeCompatMode() é verdadeiro e SizeCompatModeActivityController (na interface do sistema) recebe o callback para mostrar o botão de reinicialização do processo.

Tamanhos e proporções de tela

O Android 10 oferece suporte a novas proporções de telas longas e finas para proporções 1:1. Os apps podem definir ApplicationInfo#maxAspectRatio e o ApplicationInfo#minAspectRatio da tela que eles podem processar.

proporções de apps no Android 10

Figura 1. Exemplos de proporções de apps com suporte no Android 10

As implementações de dispositivos podem ter telas secundárias com tamanhos e resoluções menores do que os exigidos pelo Android 9 e versões anteriores (mínimo de 2, 5 polegadas de largura ou altura, mínimo de 320 DP para smallestScreenWidth), mas somente atividades que oferecem suporte a essas telas pequenas podem ser colocadas lá.

Os apps podem ativar essa opção declarando um tamanho mínimo com suporte menor que ou igual ao tamanho de exibição de destino. Para fazer isso, use os atributos de layout de atividade android:minHeight e android:minWidth no AndroidManifest.

Políticas de display

O Android 10 separa e move determinadas políticas de exibição da implementação padrão de WindowManagerPolicy em PhoneWindowManager para classes por exibição, como:

  • Estado e rotação da tela
  • Alguns eventos de movimento e teclas
  • Janelas de decoração e da interface do sistema

No Android 9 e versões anteriores, a classe PhoneWindowManager processava as políticas de exibição, o estado e as configurações, a rotação, o rastreamento de frames de janelas de decoração e muito mais. O Android 10 move a maior parte disso para a classe DisplayPolicy, exceto o rastreamento de rotação, que foi movido para DisplayRotation.

Configurações da janela de exibição

No Android 10, a configuração de janelas configurável por tela foi expandida para incluir:

  • Modo de janela de exibição padrão
  • Valores de overscan
  • Rotação de usuários e modo de rotação
  • Tamanho, densidade e modo de dimensionamento forçados
  • Modo de remoção de conteúdo (quando a exibição é removida)
  • Suporte a decorações do sistema e IME

A classe DisplayWindowSettings contém as configurações para essas opções. Eles são mantidos no disco na partição /data em display_settings.xml sempre que uma configuração é modificada. Para mais detalhes, consulte DisplayWindowSettings.AtomicFileStorage e DisplayWindowSettings#writeSettings(). Os fabricantes de dispositivos podem fornecer valores padrão em display_settings.xml para a configuração do dispositivo. No entanto, como o arquivo está armazenado em /data, outra lógica pode ser necessária para restaurá-lo se ele for apagado por uma exclusão permanente.

Por padrão, o Android 10 usa DisplayInfo#uniqueId como um identificador para uma tela ao manter as configurações. uniqueId precisa ser preenchido para todas as telas. Além disso, ele é estável para telas físicas e de rede. Também é possível usar a porta de uma tela física como identificador, que pode ser definido em DisplayWindowSettings#mIdentifier. Em cada gravação, todas as configurações são gravadas para que seja possível atualizar com segurança a chave usada para uma entrada de exibição no armazenamento. Para mais detalhes, consulte Identificadores de tela estática.

As configurações são mantidas no diretório /data por motivos históricos. Originalmente, eles eram usados para manter as configurações definidas pelo usuário, como a rotação da tela.

Identificadores de tela estática

O Android 9 (e versões anteriores) não oferecia identificadores estáveis para telas no framework. Quando uma tela foi adicionada ao sistema, Display#mDisplayId ou DisplayInfo#displayId foi gerada para essa tela incrementando um contador estático. Se o sistema adicionou e removeu a mesma tela, um ID diferente era gerado.

Se um dispositivo tiver várias telas disponíveis na inicialização, elas poderão ser atribuídas a identificadores diferentes, dependendo do tempo. Embora o Android 9 (e anteriores) incluísse DisplayInfo#uniqueId, ele não continha informações suficientes para diferenciar entre telas, porque as telas físicas eram identificadas como local:0 ou local:1 para representar a tela integrada e a externa.

O Android 10 muda DisplayInfo#uniqueId para adicionar um identificador estável e diferenciar telas locais, de rede e virtuais.

Tipo de exibição Formato
Local 
local:<stable-id>
Rede 
network:<mac-address>
Virtual 
virtual:<package-name-and-name>

Além das atualizações de uniqueId, DisplayInfo.address contém DisplayAddress, um identificador de exibição estável em reinicializações. No Android 10, DisplayAddress oferece suporte a telas físicas e de rede. DisplayAddress.Physical contém um ID de exibição estável (igual ao uniqueId) e pode ser criado com DisplayAddress#fromPhysicalDisplayId().

O Android 10 também oferece um método conveniente para receber informações de porta (Physical#getPort()). Esse método pode ser usado no framework para identificar telas de forma estática. Por exemplo, é usado em DisplayWindowSettings). DisplayAddress.Network contém o endereço MAC e pode ser criado com DisplayAddress#fromMacAddress().

Essas adições permitem que os fabricantes de dispositivos identifiquem telas em configurações multitelas estáticas e configurem diferentes configurações e recursos do sistema usando identificadores de tela estáticos, como portas para telas físicas. Esses métodos estão ocultos e são destinados apenas ao uso em system_server.

Dado um ID de exibição HWC (que pode ser opaco e nem sempre estável), esse método retorna o número da porta de 8 bits (específico da plataforma) que identifica um conector físico para saída de exibição, bem como o blob EDID da tela. O SurfaceFlinger extrai informações do fabricante ou do modelo do EDID para gerar os IDs de exibição estáveis de 64 bits expostos ao framework. Se esse método não tiver suporte ou apresentar erros, o SurfaceFlinger voltará ao modo MD legada, em que DisplayInfo#address é nulo e DisplayInfo#uniqueId é fixado, conforme descrito acima.

Para verificar se esse recurso tem suporte, execute:

$ dumpsys SurfaceFlinger --display-id
# Example output.
Display 21691504607621632 (HWC display 0): port=0 pnpId=SHP displayName="LQ123P1JX32"
Display 9834494747159041 (HWC display 2): port=1 pnpId=HWP displayName="HP Z24i"
Display 1886279400700944 (HWC display 1): port=2 pnpId=AUS displayName="ASUS MB16AP"

Usar mais de duas telas

No Android 9 (e versões anteriores), o SurfaceFlinger e o DisplayManagerService assumiam a existência de no máximo duas telas físicas com os IDs codificados 0 e 1.

A partir do Android 10, o SurfaceFlinger pode usar uma API de compositor de hardware (HWC) para gerar IDs de tela estáveis, o que permite gerenciar um número arbitrário de telas físicas. Para saber mais, consulte Identificadores de exibição estáticos.

O framework pode procurar o token IBinder de uma tela física por meio de SurfaceControl#getPhysicalDisplayToken depois de receber o ID da tela de 64 bits de SurfaceControl#getPhysicalDisplayIds ou de um evento de hotplug DisplayEventReceiver.

No Android 10 e versões anteriores, a tela interna principal é TYPE_INTERNAL, e todas as telas secundárias são sinalizadas como TYPE_EXTERNAL, independente do tipo de conexão. Portanto, telas internas adicionais são tratadas como externas. Como solução alternativa, o código específico do dispositivo pode fazer suposições sobre DisplayAddress.Physical#getPort se o HWC for conhecido e a lógica de alocação de porta for previsível.

Essa limitação foi removida no Android 11 (e versões mais recentes).

  • No Android 11, a primeira tela informada durante a inicialização é a principal. O tipo de conexão (interna ou externa) é irrelevante. No entanto, a tela principal não pode ser desconectada e, na prática, ela precisa ser interna. Alguns smartphones dobráveis têm várias telas internas.
  • As telas secundárias são categorizadas corretamente como Display.TYPE_INTERNAL ou Display.TYPE_EXTERNAL (anteriormente conhecidas como Display.TYPE_BUILT_IN e Display.TYPE_HDMI, respectivamente), dependendo do tipo de conexão.

Implementação

No Android 9 e versões anteriores, as telas são identificadas por IDs de 32 bits, em que 0 é a tela interna, 1 é a tela externa, [2, INT32_MAX] são telas virtuais HWC e -1 representa uma tela inválida ou uma tela virtual que não é HWC.

A partir do Android 10, as telas recebem IDs estáveis e persistentes, o que permite que o SurfaceFlinger e o DisplayManagerService rastreiem mais de duas telas e reconheçam telas vistas anteriormente. Se o HWC oferecer suporte a IComposerClient.getDisplayIdentificationData e fornecer dados de identificação de exibição, o SurfaceFlinger analisará a estrutura EDID e alocará IDs de exibição estáveis de 64 bits para telas virtuais físicas e de HWC. Os IDs são expressos usando um tipo de opção, em que o valor nulo representa uma tela inválida ou uma exibição virtual não HWC. Sem o suporte a HWC, o SurfaceFlinger volta ao comportamento legado com no máximo duas telas físicas.

Foco por tela

Para oferecer suporte a várias fontes de entrada que se destinam a telas individuais ao mesmo tempo, o Android 10 pode ser configurado para oferecer suporte a várias janelas com foco, no máximo uma por tela. Isso é destinado apenas a tipos especiais de dispositivos quando vários usuários interagem com o mesmo dispositivo ao mesmo tempo e usam diferentes métodos ou dispositivos de entrada, como o Android Automotive.

É altamente recomendável que esse recurso não seja ativado para dispositivos comuns, incluindo dispositivos com várias telas ou aqueles usados para experiências semelhantes a computadores. Isso se deve principalmente a uma preocupação de segurança que pode fazer com que os usuários se perguntem qual janela tem o foco de entrada.

Imagine o usuário que insere informações seguras em um campo de entrada de texto, talvez fazendo login em um app bancário ou inserindo texto que contenha informações sensíveis. Um app malicioso pode criar uma tela virtual fora da tela para executar uma atividade, também com um campo de entrada de texto. Atividades legítimas e maliciosas têm foco e mostram um indicador de entrada ativo (cursor piscando).

No entanto, como a entrada de um teclado (hardware ou software) é inserida apenas na atividade superior (o app iniciado mais recentemente), ao criar uma tela virtual oculta, um app malicioso pode capturar entradas do usuário, mesmo ao usar um teclado de software na tela principal do dispositivo.

Use com.android.internal.R.bool.config_perDisplayFocusEnabled para definir o foco por tela.

Compatibilidade

Problema:no Android 9 e versões anteriores, no máximo uma janela no sistema tem foco por vez.

Solução: no raro caso em que duas janelas do mesmo processo seriam focalizadas, o sistema daria foco apenas à janela que está mais alta na ordem Z. Essa restrição foi removida para apps destinados ao Android 10, em que é esperado que eles possam oferecer suporte a várias janelas em foco ao mesmo tempo.

Implementação

O WindowManagerService#mPerDisplayFocusEnabled controla a disponibilidade desse recurso. Em ActivityManager, ActivityDisplay#getFocusedStack() agora é usado em vez do rastreamento global em uma variável. ActivityDisplay#getFocusedStack() determina o foco com base na ordem Z em vez de armazenar o valor em cache. Dessa forma, apenas uma origem, a WindowManager, precisa rastrear a ordem Z das atividades.

O ActivityStackSupervisor#getTopDisplayFocusedStack() adota uma abordagem semelhante para os casos em que a pilha com foco superior no sistema precisa ser identificada. As pilhas são percorridas de cima para baixo, procurando a primeira pilha qualificada.

InputDispatcher agora pode ter várias janelas em foco (uma por tela). Se um evento de entrada for específico da tela, ele será enviado para a janela em foco na tela correspondente. Caso contrário, ele será enviado para a janela em foco na tela em foco, que é a tela com que o usuário interagiu mais recentemente.

Consulte InputDispatcher::mFocusedWindowHandlesByDisplay e InputDispatcher::setFocusedDisplay(). Os apps em foco também são atualizados separadamente em InputManagerService por NativeInputManager::setFocusedApplication().

No WindowManager, as janelas em foco também são rastreadas separadamente. Consulte DisplayContent#mCurrentFocus e DisplayContent#mFocusedApp e os respectivos usos. Os métodos de rastreamento e atualização de foco relacionados foram movidos de WindowManagerService para DisplayContent.