Confira abaixo as atualizações feitas nessas áreas específicas de exibição:
- Redimensionar atividades e telas
- Tamanhos e proporções de tela
- Políticas de exibição
- Mostrar configurações da janela
- Identificadores de tela estática
- Usar mais de duas telas
- Foco por tela
Redimensionar atividades e telas
Para indicar que um app não oferece suporte ao modo de várias janelas ou ao redimensionamento,
as atividades usam o atributo resizeableActivity=false. Os 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 das relativas à posição da janela), o que pode interromper a entrada em 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 do iniciador
enquanto já estiver em um modo de tela dividida, a plataforma sairá do modo de tela dividida e
iniciará a atividade não redimensionável no modo de tela cheia.
Os 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 não relacionados a atividades.
- 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 elas podem ser dimensionadas temporariamente se a atividade tiver declarado 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 como incompatível com várias janelas usando
o atributo android:resizeableActivity e quando essa
atividade atende a uma das condições descritas abaixo, quando a configuração de tela
aplicada precisa mudar, a atividade e o processo são salvos com a
configuração original, e o usuário recebe uma capacidade 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 ao segmentar o nível da API ou declarar 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 desdobrar o dispositivo, a configuração, o tamanho e a proporção da atividade não mudam, mas a opção de reiniciar a atividade é exibida.
Quando resizeableActivity não está definido (ou está definido como
true), o app oferece suporte total ao 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
conferente (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 altas e finas para proporções de 1:1. Os apps podem definir
ApplicationInfo#maxAspectRatio
e o ApplicationInfo#minAspectRatio da tela que eles
podem processar.
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 as exigidas 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 apenas atividades que oferecem suporte a essas telas pequenas podem ser colocadas
ali.
Os apps podem ativar essa opção declarando um tamanho mínimo com suporte menor que
ou igual ao tamanho de tela de destino. Para isso, use os atributos de layout de atividade android:minHeight e
android:minWidth no
AndroidManifest.
Políticas de exibição
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:
- Exibir estado e rotação
- Alguns eventos de teclas e movimento
- Janelas de decoração e da interface do sistema
No Android 9 (e versões anteriores), a classe PhoneWindowManager processava
políticas de exibição, estado e configurações, rotação, rastreamento de
molduras de janela 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.
Mostrar as configurações da janela
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 sobreposição
- Rotação de usuários e modo de rotação
- Tamanho, densidade e modo de escalonamento 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 é alterada. 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 é armazenado em /data,
pode ser necessário usar outra lógica para restaurá-lo se ele for apagado por uma limpeza.
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 o 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
gerado para essa tela incrementando um contador estático. Se o sistema
adicionou e removeu a mesma tela, um ID diferente foi 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
versões anteriores) incluísse DisplayInfo#uniqueId, ele não tinha 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 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 para uniqueId,
DisplayInfo.address contém DisplayAddress, um
identificador de tela 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
tela estável (o mesmo que em 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, ele é 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 tela HWC (que pode ser opaco e não 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 tela, bem como o blob EDID da tela.
O SurfaceFlinger extrai informações do fabricante ou 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 legado,
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 IDs fixados 0
e 1.
A partir do Android 10, o SurfaceFlinger pode usar uma API Hardware Composer (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 para uma tela
física usando SurfaceControl#getPhysicalDisplayToken depois de receber
o ID de exibição de 64 bits de SurfaceControl#getPhysicalDisplayIds ou
de um evento 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, outras telas internas 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 tela 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_INTERNALouDisplay.TYPE_EXTERNAL(anteriormente conhecidas comoDisplay.TYPE_BUILT_INeDisplay.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 de HWC e -1 representa uma tela inválida ou uma tela virtual que não é de 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 tela, o SurfaceFlinger analisará a estrutura EDID e alocará IDs de tela
64 bits estáveis para telas físicas e virtuais do HWC. Os IDs são expressos usando
um tipo de opção, em que o valor nulo representa uma tela inválida ou uma tela 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 contém 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 principal (o app que foi iniciado mais recentemente), ao criar uma tela virtual oculta, um app malicioso pode capturar a entrada do usuário, mesmo usando 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 são focalizadas, o sistema fornece 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
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. Isso é necessário para que
apenas uma fonte, WindowManager, precise rastrear a ordem Z das atividades.
O ActivityStackSupervisor#getTopDisplayFocusedStack() usa uma
abordagem semelhante para casos em que a pilha mais focada do 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
interageu mais recentemente.
Consulte InputDispatcher::mFocusedWindowHandlesByDisplay e
InputDispatcher::setFocusedDisplay(). Os apps focados também são atualizados
separadamente no InputManagerService por meio de
NativeInputManager::setFocusedApplication().
Em 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.