Extensões do WindowManager

A biblioteca Jetpack WindowManager permite que os desenvolvedores de aplicativos ofereçam suporte a novos formatos de dispositivo e ambientes de várias janelas.

As Extensões do WindowManager (Extensões) são um módulo da plataforma Android que permite uma variedade de recursos do Jetpack WindowManager. O módulo é implementado no AOSP em frameworks/base/libs/WindowManager/Jetpack e enviado em dispositivos que oferecem suporte aos recursos do WindowManager.

Distribuição do módulo de extensões

As extensões são compiladas em uma biblioteca .jar e colocadas na partição system_ext em um dispositivo se as extensões estiverem ativadas no arquivo makefile do dispositivo.

Para ativar as extensões em um dispositivo, adicione o seguinte ao arquivo makefile do dispositivo do produto:

$(call inherit-product, $(SRC_TARGET_DIR)/product/window_extensions.mk)

Isso ativa os pacotes androidx.window.extensions e androidx.window.sidecar no dispositivo e define a propriedade persist.wm.extensions.enabled. A inclusão desses pacotes no arquivo makefile também coloca declarações em etc/permissions/, disponibilizando-as para processos de aplicativos. Normalmente, os módulos são carregados e executados como parte do processo do aplicativo no momento da execução quando usados pela biblioteca Jetpack WindowManager, o que torna a operação semelhante ao código de framework do lado do cliente, conforme mostrado na figura a seguir:

O módulo androidx.window.extensions é o módulo de extensões atual em desenvolvimento ativo. O módulo androidx.window.sidecar é um módulo legado incluído para compatibilidade com as versões mais antigas do Jetpack WindowManager, mas o sidecar não é mais mantido ativamente.

A figura a seguir mostra a lógica para determinar o uso de androidx.window.extensions ou androidx.window.sidecar.

Módulos de extensões

As extensões oferecem recursos de janelas para dispositivos dobráveis de tela grande e dispositivos que oferecem suporte a janelas em telas externas. As áreas de recursos incluem:

• Incorporação de atividades
• Informações de layout da janela
• Área da janela

As implementações de extensões do OEM podem fornecer componentes nulos ou componentes com implementações padrão ou de stub dos métodos na WindowExtensions interface se o hardware do dispositivo não oferecer suporte aos recursos correspondentes, a menos que o recurso seja solicitado especificamente no Documento de definição de compatibilidade (CDD) 7.1.1.1.

Extensões e APIs do Jetpack

O módulo de extensões do WindowManager fornece a própria superfície de API, além das APIs públicas da plataforma. O módulo de extensões é desenvolvido publicamente em uma biblioteca do Jetpack androidx.window.extensions não voltada para desenvolvedores, para que o Jetpack WindowManager (androidx.window) possa se vincular a ele no tempo de compilação. A superfície da API de extensões normalmente fornece APIs de nível inferior.

As APIs fornecidas pelas extensões são destinadas ao uso apenas pela biblioteca Jetpack WindowManager. As APIs de extensões não são destinadas a serem chamadas diretamente por desenvolvedores de aplicativos. A biblioteca de extensões não pode ser adicionada como uma dependência para um aplicativo no arquivo de build do Gradle para garantir a funcionalidade correta. Evite pré-compilar a biblioteca de extensões diretamente em um aplicativo. Em vez disso, confie no carregamento no momento da execução para evitar o carregamento de uma combinação de classes de extensões pré-compiladas e fornecidas no momento da execução.

O Jetpack WindowManager (androidx.window) deve ser adicionado como uma dependência do aplicativo e fornece as APIs públicas voltadas para o desenvolvedor, incluindo aquelas para recursos de extensões do WindowManager. A biblioteca do WindowManager carrega automaticamente as extensões no processo do aplicativo e envolve as APIs de extensões de nível inferior em abstrações de nível superior e interfaces mais focadas. As APIs do WindowManager Jetpack seguem os padrões de desenvolvimento de apps Android modernos e destinam-se a fornecer interoperabilidade conveniente, integrando-se bem a bases de código que usam outras bibliotecas do AndroidX.

Versões e atualizações de extensões

O módulo de extensões pode ser atualizado com as atualizações anuais ou trimestrais da plataforma Android. As atualizações trimestrais permitem que o nível da API de extensões seja aumentado entre as atualizações da API da plataforma Android, permitindo uma iteração mais rápida e oferecendo aos OEMs uma oportunidade de adicionar acesso oficial à API a novos recursos próximos aos lançamentos de hardware.

A tabela a seguir lista as versões da API androidx.window.extensions para várias versões do Android.

O nível da API de extensões (coluna central) é aumentado sempre que há uma adição à superfície da API estável atual (coluna à direita).

Compatibilidade com versões anteriores e futuras

O Jetpack WindowManager lida com a complexidade de atualizações frequentes de nível da API, evolução rápida da API e compatibilidade com versões anteriores. Quando o código da biblioteca é executado no processo do aplicativo, a biblioteca verifica o nível da API de extensões declarado e fornece acesso aos recursos de acordo com o nível declarado.

Para proteger um aplicativo contra falhas no momento da execução, o WindowManager também realiza uma verificação de reflexão Java no momento da execução das APIs de extensões disponíveis de acordo com o nível da API de extensões declarado. Se houver uma incompatibilidade, o WindowManager poderá desativar o uso de extensões (parcial ou totalmente) e informar os recursos relevantes como não disponíveis para o aplicativo.

As extensões do WindowManager são implementadas como um system_ext módulo que usa APIs privadas da plataforma para chamar o núcleo do WindowManager, DeviceStateManager, e outros serviços do sistema na implementação dos recursos de extensões.

A compatibilidade pode não ser mantida com versões de pré-lançamento de extensões anteriores à versão trimestral ou anual correspondente da plataforma Android com que as versões são finalizadas. O histórico completo das APIs de extensões pode ser encontrado nos arquivos de texto da API window:extensions:extensions da ramificação de lançamento.

As versões mais recentes de extensões precisam continuar funcionando com versões mais antigas do WindowManager compiladas em aplicativos para manter a compatibilidade com versões futuras. Para garantir isso, qualquer nova versão da API de extensões só adiciona novas APIs e não remove as mais antigas. Como resultado, aplicativos com versões mais antigas do WindowManager podem continuar usando as APIs de extensões mais antigas com que os apps foram compilados.

A verificação do CTS garante que, para qualquer versão declarada de APIs de extensões no dispositivo, todas as APIs dessa versão e das anteriores estejam presentes e funcionais.

Desempenho

O módulo de extensões é armazenado em cache em carregadores de classe do sistema não bootclasspath por padrão a partir do Android 14 (nível 34 da API). Portanto, não há impacto de performance devido ao carregamento do módulo na memória na inicialização do app. O uso de recursos de módulos individuais pode ter uma pequena influência nas características de performance dos apps quando chamadas de IPC adicionais são realizadas entre o cliente e o servidor.

Módulos

Incorporação de atividades

O componente de incorporação de atividades permite que os aplicativos otimizem a interface para dispositivos de tela grande e telas externas. A incorporação de atividades permite a apresentação de duas atividades lado a lado em um layout de vários painéis, facilitando o desenvolvimento de apps adaptáveis para aplicativos legados.

O componente de incorporação de atividades precisa estar disponível em todos os dispositivos que têm uma tela integrada igual ou maior que sw600dp. A incorporação de atividades também precisa ser ativada em dispositivos que oferecem suporte a conexões de tela externa, já que o aplicativo pode ser mostrado em um tamanho maior quando telas externas são conectadas no momento da execução.

Configuração do dispositivo

Nenhuma configuração específica do dispositivo é necessária, além de ativar o módulo de extensões , conforme descrito na seção Distribuição do módulo de extensões. É recomendável ativar as extensões em todos os dispositivos que oferecem suporte ao modo de várias janelas. É provável que as versões futuras do Android exijam extensões em configurações comuns de dispositivos portáteis e de tela grande.

Informações de layout da janela

O componente de informações de layout da janela identifica a posição e o estado da articulação em um dispositivo dobrável quando a articulação cruza uma janela do aplicativo. As informações de layout da janela permitem que os aplicativos respondam e mostrem layouts otimizados no modo de mesa em dispositivos dobráveis. Consulte Fazer seu app reconhecer um dispositivo dobrável para mais detalhes sobre o uso.

Os dispositivos Android dobráveis que incluem uma articulação que conecta áreas de painel de exibição separadas ou contínuas precisam disponibilizar as informações sobre a articulação para aplicativos usando WindowLayoutComponent.

A posição e os limites da articulação precisam ser informados em relação à janela do aplicativo identificada por um Context transmitido para a API. Se os limites da janela do aplicativo não se cruzarem com os limites da articulação, o `DisplayFeature` da articulação DisplayFeature não poderá ser informado. Também é aceitável não informar os recursos de exibição quando a posição deles não puder ser informada de maneira confiável, como quando uma janela do aplicativo pode ser movida livremente pelo usuário no modo de várias janelas ou no modo de letterboxing de compatibilidade.

Para recursos de dobra, as atualizações de estado precisam ser informadas quando a posição da articulação muda entre os estados estáveis. Por padrão, em um estado de exibição plana, a API precisa informar FoldingFeature.State.FLAT. Se o hardware do dispositivo puder ser deixado em um modo meio dobrado em um estado estável, a API precisará informar FoldingFeature.State.HALF_OPENED. Não há estado fechado na API, já que, nesse caso, a janela do aplicativo não estaria visível ou não estaria cruzando os limites da articulação.

Configuração do dispositivo

Para oferecer suporte à implementação do recurso de dobra, os OEMs precisam fazer o seguinte:

• Configure os estados do dispositivo em device_state_configuration.xml para serem usados por DeviceStateManagerService. Consulte DeviceStateProviderImpl.java para referência.

  Se as implementações padrão de DeviceStateProvider ou DeviceStatePolicy não forem adequadas para o dispositivo, uma implementação personalizada poderá ser usada.

• Ative o módulo de extensões, conforme descrito na seção Distribuição do módulo de extensões.

• Especifique o local dos recursos de exibição no recurso de string com.android.internal.R.string.config_display_features (geralmente em frameworks/base/core/res/res/values/config.xml na sobreposição do dispositivo).

  O formato esperado para a string é:

  <type>-[<left>,<top>,<right>,<bottom>]

  O type pode ser fold ou hinge. Os valores de left, top, right e bottom são coordenadas de pixels inteiros no espaço de coordenadas de exibição na orientação de exibição natural. A string de configuração pode conter vários recursos de exibição separados por ponto e vírgula.

  Exemplo:

  <!-- Jetpack WindowManager display features -->
  <string name="config_display_features" translatable="false">fold-[1000,0,1000,2000]</string>
  

• Defina o mapeamento entre os identificadores de estado do dispositivo interno usados em DeviceStateManager e as constantes de estado público enviadas aos desenvolvedores em com.android.internal.R.array.config_device_state_postures.

  O formato esperado para cada entrada é:

  <device_specific_state_identifier>:<Jetpack WindowManager state identifier>

  Os identificadores de estado com suporte são:

  • COMMON_STATE_NO_FOLDING_FEATURES = 1: o estado não tem recursos de dobra a serem informados. Por exemplo, pode ser o estado fechado do dispositivo dobrável típico com a tela principal no lado interno.
  • COMMON_STATE_HALF_OPENED = 2: o recurso de dobra está meio aberto.
  • COMMON_STATE_FLAT = 3: o recurso de dobra é plano. Por exemplo, pode ser o estado aberto do dispositivo dobrável típico com a tela principal no lado interno.
  • COMMON_STATE_USE_BASE_STATE = 1000: no Android 14, um valor que pode ser usado para estados emulados em que o estado da articulação é derivado usando o estado base, conforme definido em CommonFoldingFeature.java

  See DeviceStateManager.DeviceStateCallback#onBaseStateChanged(int) for more information.

  Exemplo:

  <!-- Map of System DeviceState supplied by DeviceStateManager to WindowManager posture.-->
  <string-array name="config_device_state_postures" translatable="false">
    <item>0:1</item>    <!-- CLOSED       : COMMON_STATE_NO_FOLDING_FEATURES -->
    <item>1:2</item>    <!-- HALF_OPENED  : COMMON_STATE_HALF_OPENED -->
    <item>2:3</item>    <!-- OPENED       : COMMON_STATE_FLAT -->
    <item>3:1</item>    <!-- REAR_DISPLAY : COMMON_STATE_NO_FOLDING_FEATURES -->
    <item>4:1000</item> <!-- CONCURRENT   : COMMON_STATE_USE_BASE_STATE -->
  </string-array>
  

Área da janela

O componente de área da janela fornece um conjunto de recursos que oferecem aos aplicativos acesso a telas e áreas de exibição adicionais em alguns dispositivos dobráveis e de várias telas.

O modo de tela traseira permite que um aplicativo mostre a interface de visualização da câmera na tela externa de um dispositivo dobrável para permitir o uso da câmera principal do dispositivo para selfies e vídeos. Os dispositivos que têm uma tela externa compatível com o Android (conforme definido pelo CDD do Android em termos de atributos como tamanho, densidade e recursos de navegação disponíveis) que se alinha às câmeras traseiras do dispositivo precisam fornecer acesso ao modo de tela traseira.

No Android 14, o modo de tela dupla permite que aplicativos executados no display interno de um dispositivo dobrável mostrem conteúdo adicional na tela externa voltada para outros usuários. Por exemplo, a tela externa pode mostrar a visualização da câmera para a pessoa que está sendo fotografada ou gravada.

Configuração do dispositivo

Para oferecer suporte à implementação do recurso de dobra, os OEMs precisam fazer o seguinte:

• Configure os estados do dispositivo em device_state_configuration.xml para serem usados por DeviceStateManagerService. Consulte DeviceStateProviderImpl.java para mais informações.

  Se a implementação padrão de DeviceStateProvider ou DeviceStatePolicy não for adequada para o dispositivo, uma implementação personalizada poderá ser usada.

• Para dispositivos dobráveis que oferecem suporte ao modo aberto ou plano, especifique os identificadores de estado correspondentes em com.android.internal.R.array.config_openDeviceStates.

• Para dispositivos dobráveis que oferecem suporte a estados dobrados, liste os identificadores de estado correspondentes em com.android.internal.R.array.config_foldedDeviceStates.

• Para dispositivos dobráveis que oferecem suporte a um estado meio dobrado (a articulação está meio aberta como um laptop), liste os estados correspondentes em com.android.internal.R.array.config_halfFoldedDeviceStates.

• Para dispositivos que oferecem suporte ao modo de tela traseira:

  • Liste os estados correspondentes em com.android.internal.R.array.config_rearDisplayDeviceStates para DeviceStateManager.
  • Especifique o endereço de exibição física da tela traseira em com.android.internal.R.string.config_rearDisplayPhysicalAddress.
  • Especifique o identificador de estado em com.android.internal.R.integer.config_deviceStateRearDisplay a ser usado pelas extensões.
  • Adicione o identificador de estado em com.android.internal.R.array.config_deviceStatesAvailableForAppRequests para disponibilizá-lo aos aplicativos.

• No Android 14, para dispositivos que oferecem suporte ao modo de tela dupla (simultânea):

  • Defina com.android.internal.R.bool.config_supportsConcurrentInternalDisplays como true.
  • Especifique o endereço de exibição física da tela traseira em com.android.internal.R.config_deviceStateConcurrentRearDisplay.
  • Especifique o identificador de estado em com.android.internal.R.integer.config_deviceStateConcurrentRearDisplay a ser usado pelas extensões se o identificador for disponibilizado para aplicativos.
  • Adicione o identificador de estado em com.android.internal.R.array.config_deviceStatesAvailableForAppRequests para disponibilizá-lo aos aplicativos.

Verificação

Os OEMs precisam verificar as implementações para garantir o comportamento esperado em cenários comuns. Os testes do CTS e os testes usando o Jetpack WindowManager estão disponíveis para OEMs para testar implementações.

Testes do CTS

Para executar os testes do CTS, consulte Executar testes do CTS. Os testes do CTS relacionados ao Jetpack WindowManager estão em cts/tests/framework/base/windowmanager/jetpack/. O nome do módulo de teste é CtsWindowManagerJetpackTestCases.

Testes do WindowManager

Para fazer o download dos testes do Jetpack WindowManager, siga as instruções do Android Jetpack. Os testes estão localizados na biblioteca de janelas no módulo window:window: window/window/src/androidTest/.

Para executar os testes de dispositivo para o módulo window:window na linha de comando, faça o seguinte:

1. Conecte um dispositivo que tenha as opções do desenvolvedor e a depuração USB ativadas.
2. Permita que o computador depure o dispositivo.
3. Abra um shell no diretório raiz do repositório androidx.
4. Mude o diretório para framework/support.
5. Execute este comando: ./gradlew window:window:connectedAndroidTest.
6. Analise os resultados.

Para executar os testes no Android Studio, faça o seguinte:

1. Abra o Android Studio.
2. Conecte um dispositivo que tenha as opções do desenvolvedor e a depuração USB ativadas.
3. Permita que o computador depure o dispositivo.
4. Navegue até um teste na biblioteca de janelas do módulo de janelas.
5. Abra uma classe de teste e execute usando as setas verdes no lado direito do editor.

Como alternativa, você pode criar uma configuração no Android Studio para executar um método de teste, uma classe de teste ou todos os testes em um módulo.

Os resultados podem ser analisados manualmente examinando a saída do shell. Alguns testes são ignorados se o dispositivo não atender a determinadas suposições. Os resultados são salvos em um local padrão, e os analistas podem escrever um script para automatizar a análise dos resultados.