Skip to content

Most visited

Recently visited

Results for

navigation

Compatibilidade com várias telas

O Android é executado em uma variedade de dispositivos que oferecem diferentes tamanhos e densidades de tela. Para aplicativos, o sistema Android oferece um ambiente de desenvolvimento consistente em diferentes dispositivos e realiza a maior parte do trabalho de ajuste da interface de usuário de cada aplicativo à tela na qual ele é exibido. Ao mesmo tempo, o sistema fornece APIs que permitem controlar a IU do aplicativo para tamanhos e densidades de tela específicos para otimizar o design da interface para diferentes configurações de tela. Por exemplo, você pode querer uma IU para tablets que seja diferente da IU para telefones.

Apesar de o sistema realizar o dimensionamento do seu aplicativo para diferentes telas, você deve procurar otimizar o aplicativo para diferentes tamanhos e densidades de tela. Ao fazer isso, você maximiza a experiência do usuário para todos os dispositivos e seus usuários acreditam que seu aplicativo foi projetado para os dispositivos deles — em vez de simplesmente dimensionados para caber na tela de seus dispositivos.

Ao seguir as práticas descritas neste documento, você pode criar um aplicativo exibido corretamente e que fornece uma experiência do usuário otimizada em todas as configurações de tela compatíveis, usando apenas um arquivo .apk.

Observação: As informações contidas neste documento partem do pressuposto que seu aplicativo foi projetado para o Android 1.6 (nível de API 4) ou uma versão posterior. Se seu aplicativo for compatível com Android 1.5 ou versões anteriores, leia Estratégias para Android 1.5 primeiro.

Além disso, esteja ciente de que o Android 3.2 introduziu novas APIs que permitem que você controle de forma mais precisa os recursos de layout que seu aplicativo usa para diferentes tamanhos de tela. Esses novos recursos são especialmente importantes se você estiver desenvolvendo um aplicativo otimizado para tablets. Para saber mais, consulte a seção sobre a Declaração de layouts de tablet para Android 3.2.

Visão geral do suporte a telas

Esta seção fornece uma visão geral do suporte do Android a várias telas, inclusive: uma introdução aos termos e conceitos neste documento e na API, um resumo das configurações de tela às quais o sistema oferece suporte e uma visão geral da API e dos recursos subjacentes de compatibilidade de tela.

Termos e conceitos

Tamanho da tela
Tamanho físico real, medido como a diagonal da tela.

Para manter a simplicidade, o Android agrupa todos os tamanhos de tela reais em quatro tamanhos generalizados: pequena, normal, grande e extra grande.

Densidade da tela
A quantidade de pixels em uma área física da tela, geralmente chamada de dpi (pontos por polegada). Por exemplo, uma densidade de tela “baixa” tem menos pixels em uma determinada área física, em comparação com uma densidade de tela “normal” ou “alta”.

Para manter a simplicidade, o Android agrupa as densidades de tela reais em seis densidades generalizadas: baixa, média, alta, extra-alta, extra-extra-alta e extra-extra-extra-alta.

Orientação
A orientação da tela no ponto de vista do usuário. As opções são paisagem ou retrato, o que significa que a taxa de proporção da tela é larga ou alta, respectivamente. Esteja ciente de que dispositivos diferentes não só operam em diferentes orientações por padrão, mas que a orientação pode ser alterada no tempo de execução quando o usuário gira o dispositivo.
Resolução
O total de pixels físicos em uma tela. Ao adicionar suporte a várias telas, os aplicativos não trabalham diretamente com a resolução: eles devem se preocupar apenas com o tamanho e a densidade da tela conforme especificado pelos grupos generalizados de tamanho e densidade.
Pixel independente de densidade (dp)
Unidade de pixel virtual necessária ao definir o layout da IU para expressar as dimensões do layout ou definir seu posicionamento de forma independente da densidade.

O pixel independente de densidade equivale a um pixel físico em uma tela de 160 dpi, que é a densidade básica presumida pelo sistema para uma tela com densidade “média”. No tempo de execução, o sistema realiza de forma transparente qualquer dimensionamento das unidades de dp, conforme a necessidade, com base na densidade real da tela em uso. A conversão das unidades de pixel em pixels de tela é simples: px = dp * (dpi / 160). Por exemplo, em uma tela de 240 dpi, 1 dp equivale a 1,5 pixels físicos. Você deve sempre usar unidades de dp ao definir a IU do seu aplicativo para garantir a exibição correta da sua interface em telas com diferentes densidades.

Conjunto de telas com suporte

A partir da versão 1.6 (nível de API 4), o Android aceita vários tamanhos e densidades de tela, refletindo as muitas diferentes configurações de tela que um dispositivo pode ter. Você pode usar recursos do sistema Android para otimizar a interface de usuário do seu aplicativo para cada configuração de tela e garantir que ele não só seja renderizado corretamente, mas também ofereça a melhor experiência possível para o usuário em cada tela.

Para simplificar a forma com a qual você projeta suas interfaces de usuário para várias telas, o Android divide os tamanhos e as densidades reais de tela em:

Os tamanhos e as densidades generalizadas são organizadas em uma configuração básica normal em tamanho e mdpi (média) em densidade. Essa configuração básica se baseia na configuração de tela do primeiro dispositivo Android, o T-Mobile G1, que tem uma tela HVGA (até o Android 1.6, essa era a única configuração de tela à qual o Android oferecia suporte).

Cada tamanho e densidade generalizada abrange um intervalo de tamanhos e densidades de tela reais. Por exemplo, dois dispositivos com um tamanho de tela normal podem ter tamanhos de tela reais e taxas de proporção ligeiramente diferentes ao serem medidos manualmente. Da mesma forma, dois dispositivos com densidade de tela de hdpi podem ter densidades de pixels reais ligeiramente diferentes. O Android torna essas diferenças abstratas para os aplicativos, portanto você pode fornecer uma IU projetada para os tamanhos e as densidades generalizadas e deixar que o sistema execute qualquer ajuste final necessário. A figura 1 ilustra como diferentes tamanhos e densidades são categorizados de forma aproximada nos diferentes grupos de tamanhos e densidades.

Figura 1. Ilustração de como o Android mapeia tamanhos e densidades reais em tamanhos e densidades generalizadas (os valores não são exatos).

Ao projetar sua IU para diferentes tamanhos de tela, você descobrirá que cada design exige uma quantidade mínima de espaço. Portanto, cada tamanho de tela generalizado acima tem uma resolução mínima associada definida pelo sistema. Esses tamanhos mínimos são expressos em unidades de “dp” — as mesmas unidades que você deve usar ao definir seus layouts — o que permite ao sistema evitar preocupações com mudanças na densidade da tela.

Observação: Esses tamanhos de tela mínimos não foram tão bem definidos nas versões do Android anteriores à 3.0, portanto você pode encontrar alguns dispositivos classificados incorretamente entre as categorias normal e large. Eles também se baseiam na resolução física da tela e, dessa forma, podem variar entre dispositivos — por exemplo, um tablet de 1024 x 720 com uma barra de sistema tem um pouco menos de espaço disponível para o aplicativo, pois ele é usado pela barra de sistema.

Para otimizar a IU do seu aplicativo para os diferentes tamanhos e densidades de tela, você pode fornecer recursos alternativos para qualquer um dos tamanhos e densidades de tela generalizados. Normalmente, você deve fornecer layouts alternativos para alguns dos diferentes tamanhos de tela e imagens bitmap alternativas para diferentes densidades de tela. No tempo de execução, o sistema usa os recursos apropriados para seu aplicativo de acordo com o tamanho ou a densidade generalizada da tela do dispositivo atual.

Não é preciso fornecer recursos alternativos para cada combinação de tamanho e densidade de tela. O sistema fornece recursos robustos de compatibilidade que podem realizar a maior parte do trabalho de renderização do seu aplicativo em qualquer tela de dispositivo desde que você tenha implementado a IU com técnicas que permitam o redimensionamento uniforme (conforme é descrito nas Práticas recomendadas abaixo).

Observação: As características que definem o tamanho e a densidade generalizada da tela de um dispositivo são independentes entre si. Por exemplo, o tamanho de uma tela de alta densidade WVGA é considerado normal, pois seu tamanho físico é semelhante ao do T-Mobile G1 (o primeiro dispositivo Android e a configuração básica de tela). Por outro lado, uma tela de densidade média WVGA é considerada como tendo um tamanho de tela grande. Apesar de oferecer a mesma resolução (o mesmo número de pixels), a tela de densidade média WVGA tem uma densidade de tela menor, o que significa que cada pixel é fisicamente maior e, dessa forma, a tela inteira é maior do que a tela básica (tamanho normal).

Independência de densidade

Seu aplicativo atinge a “independência de densidade” quando preserva o tamanho físico (do ponto de vista do usuário) dos elementos da interface do usuário quando ele é exibido em telas com diferentes densidades.

É importante manter a independência de densidade, pois, sem ela, um elemento de IU (como um botão) fica fisicamente maior em uma tela de baixa densidade e menor em uma tela de alta densidade. Essas mudanças de tamanho relacionadas à densidade podem causar problemas no layout e na usabilidade do seu aplicativo. As figuras 2 e 3 mostram a diferença entre um aplicativo sem e com independência de densidade, respectivamente.

Figura 2. Exemplo de aplicativo incompatível com diferentes densidades, mostrado em telas de baixa, média e alta densidade.

Figura 3. Exemplo de aplicativo com boa compatibilidade com diferentes densidades (independência de densidade), mostrado em telas de baixa, média e alta densidade.

O sistema Android ajuda seu aplicativo a alcançar a independência de densidade de duas maneiras:

Na figura 2, a visualização de texto e o drawable bitmap têm dimensões especificadas em pixels (unidades de px), portanto, as visualizações são fisicamente maiores em uma tela de baixa densidade e menores em uma tela de alta densidade. Isso ocorre porque, apesar dos tamanhos reais das telas possam ser os mesmos, a tela de alta densidade têm mais pixels por polegada (a mesma quantidade de pixels cabe em uma área menor). Na figura 3, as dimensões do layout são especificadas são especificadas em pixels independentes de densidade (unidades de dp). Como a configuração básica para pixels independentes de densidade é uma tela de densidade média, o dispositivo com a tela de densidade média parece igual ao da figura 2. Para telas de baixa e alta densidade, no entanto, o sistema dimensiona os valores de pixels independentes de densidade para menos e para mais, respectivamente, para caber na tela conforme for apropriado.

Na maioria dos casos, você pode garantir a independência de densidade no seu aplicativo simplesmente especificando todos os valores de dimensões de layout em pixels independentes de densidade (unidades de dp) ou com "wrap_content", conforme for apropriado. O sistema então dimensiona os drawables bitmap conforme a necessidade para exibi-los no tamanho apropriado, de acordo com o fator de dimensionamento correto da densidade da tela atual.

No entanto, o dimensionamento de bitmap pode resultar em bitmaps desfocados ou pixelados, que são apresentados nas capturas de tela acima. Para evitar esses artefatos, forneça recursos de bitmap alternativos para diferentes densidades. Por exemplo, você deve fornecer bitmaps de resoluções maiores para telas de alta densidade, que serão usados pelo sistema em vez de redimensionar o bitmap projetado para telas de densidade média. A seção a seguir descreve melhor como fornecer recursos alternativos para diferentes configurações de tela.

Como oferecer suporte a várias telas

A base do suporte do Android a várias telas é sua capacidade de gerenciar a renderização do layout e dos drawables bitmap de um aplicativo de forma apropriada para a configuração de tela atual. O sistema realiza a maior parte do trabalho para renderizar seu aplicativo corretamente em cada configuração de tela, dimensionando os layouts para caberem no tamanho/densidade da tela e dimensionando os drawables bitmap para a densidade da tela, conforme for apropriado. Para trabalhar com diferentes configurações de tela de maneira mais estável, você também deve:

Observação: Insira todos os seus ícones de inicialização nas pastas res/mipmap-[density]/, não nas pastas res/drawable-[density]/ . O sistema Android mantém os recursos nessas pastas específicas a densidades, como a mipmap-xxxhdpi, independentemente da resolução do dispositivo no qual seu aplicativo estiver instalado. Esse comportamento permite que aplicativos de inicialização escolham o ícone de melhor resolução para que seu aplicativo o exiba na tela inicial. Para obter mais informações sobre o uso de pastas mipmap, consulte Visão geral do gerenciamento de projetos.

Os qualificadores de configuração de tamanho e densidade correspondem aos tamanhos e densidades generalizados descritos na seção Conjunto de telas com suporte acima.

Observação: Se não estiver familiarizado com os qualificadores de configuração e com como o sistema os usa para aplicar recursos alternativos, leia Fornecimento de recursos alternativos para saber mais.

No tempo de execução, o sistema garante a melhor exibição possível na tela atual com o seguinte procedimento para qualquer recurso:

  1. O sistema usa o recurso alternativo apropriado

    Com base no tamanho e na densidade da tela atual, o sistema usa qualquer recurso específico de tamanho e densidade fornecido no seu aplicativo. Por exemplo, se o dispositivo tiver uma tela de alta densidade e o aplicativo solicitar um recurso drawable, o sistema buscará um diretório de recursos drawable que melhor corresponda à configuração do dispositivo. Dependendo dos outros recursos alternativos, um diretório de recursos com o qualificador hdpi (como drawable-hdpi/) pode ser a melhor correspondência, portanto, o sistema usa o recurso drawable desse diretório.

  2. Se nenhum recurso correspondente estiver disponível, o sistema usa o recurso padrão e o dimensiona conforme a necessidade de acordo com o tamanho e a densidade da tela atual

    Os recursos “padrão” são aqueles que não são marcados com um qualificador de configuração. Por exemplo, os recursos em drawable/ são os recursos drawable padrão. O sistema pressupõe que os recursos padrão são projetados para a configuração básica de tamanho e densidade de tela, ou seja, um tamanho de tela normal e uma densidade média. Dessa forma, o sistema amplia os recursos de densidade padrão para telas de alta densidade e os reduz para telas de baixa densidade, conforme for apropriado.

    No entanto, quando o sistema procurar um recurso específico de densidade e não o encontrar no diretório específico de densidade, nem sempre ele usará os recursos padrão. Em vez disso, o sistema poderá usar um dos outros recursos específicos de densidade para fornecer resultados melhores ao dimensioná-los. Por exemplo, ao procurar por um recurso de baixa densidade que não esteja disponível, o sistema prefere reduzir a versão de alta densidade do recurso, pois ele pode facilmente reduzir um recurso de alta densidade para a densidade baixa a um fator de 0,5, produzindo menos artefatos em comparação ao dimensionamento de um recurso de densidade média a um fator de 0,75.

Para saber mais sobre como o Android seleciona recursos alternativos ao fazer a correspondência dos qualificadores de configuração à configuração do dispositivo, leia Como o Android encontra o recurso ideal.

Uso de qualificadores de configuração

O Android oferece suporte a vários qualificadores de configuração que permitem que você controle como o sistema seleciona seus recursos alternativos com base nas características da tela do dispositivo atual. Os qualificadores de configuração são strings que podem ser incluídas em um diretório de recurso no seu projeto Android e que específica a configuração para a qual os recursos dentro dela foram projetados.

Para usar um qualificador de configuração:

  1. Crie um novo diretório dentro do diretório res/ do seu projeto e nomeie-o usando este formato: <resources_name>-<qualifier>
    • <resources_name> é o nome padrão do recurso (como drawable ou layout).
    • <qualifier> é um qualificador de configuração da tabela 1 abaixo, que especifica a configuração de tela para a qual esses recursos devem ser usados (como hdpi ou xlarge).

    Você pode usar mais de um <qualifier> por vez — basta separar cada qualificador com um traço.

  2. Salve os recursos específicos de configuração apropriados no novo diretório. Os arquivos de recurso devem ter exatamente os mesmos nomes dos arquivos de recurso padrão.

Por exemplo, xlarge é um qualificador de configuração para telas extra-grandes. Ao incluir essa string em um nome de diretório de recurso (como layout-xlarge), isso indica ao sistema que esses recursos devem ser usados em dispositivos que têm telas extra grandes.

Tabela 1. Qualificadores de configuração que permitem que você forneça recursos especiais para diferentes configurações de tela.

Característica da tela Qualificador Descrição
Tamanho small Recursos para telas pequenas.
normal Recursos para telas normais. (Esse é o tamanho básico.)
large Recursos para telas grandes.
xlarge Recursos para telas extra-grandes.
Densidade ldpi Recursos para telas de baixa densidade (ldpi) (~ 120 dpi).
mdpi Recursos para telas de média densidade (mdpi) (~ 160 dpi). (Essa é a densidade básica.)
hdpi Recursos para telas de alta densidade (hdpi) (~ 240 dpi).
xhdpi Recursos para telas de extra-alta densidade (xhdpi) (~ 320 dpi).
xxhdpi Recursos para telas de extra-extra-alta densidade (xxhdpi) (~ 480 dpi).
xxxhdpi Recursos para telas de extra-extra-extra-alta densidade (xxxhdpi) (~ 640 dpi). Use essa opção apenas para o ícone de inicialização; consulte a observação acima.
nodpi Recursos para todas as densidades. Esses são recursos independentes de densidade. O sistema não dimensiona recursos marcados com esse qualificador, independentemente da densidade da tela atual.
tvdpi Recursos para telas entre mdpi e hdpi; aproximadamente 213 dpi. Esse não é considerado um grupo de densidades “primário”. Ele é destinado principalmente para televisões e a maioria dos aplicativos não deve precisar dele — fornecer recursos mdpi e hdpi é suficiente para a maioria dos aplicativos e o sistema os dimensionará conforme for apropriado. Se julgar necessário fornecer recursos tvdpi, dimensione-os a um fator de 1,33*mdpi. Por exemplo, uma imagem de 100 x 100 pixels para telas mdpi devem ter 133 x 133 pixels para tvdpi.
Orientação land Recursos para telas na orientação de paisagem (taxa de proporção larga).
port Recursos para telas na orientação de retrato (taxa de proporção alta).
Taxa de proporção long Recursos para telas que têm uma taxa de proporção significativamente mais alta ou mais larga (na orientação de retrato ou paisagem, respectivamente) do que a configuração de tela básica.
notlong Recursos para uso em telas que têm uma taxa de proporção semelhante à configuração de tela básica.

Observação: Se você estiver desenvolvendo seu aplicativo para Android 3.2 e versões posteriores, consulte a seção Declaração de layouts de tablet para Android 3.2 para saber mais sobre os novos qualificadores de configuração que devem ser usados ao declarar recursos de layout para tamanhos de tela específicos (em vez de usar os qualificadores de tamanho na tabela 1).

Para saber mais sobre como esses qualificadores correspondem de forma aproximada a tamanhos e densidades de tela reais, consulte a seção Conjunto de telas com suporte, anteriormente neste documento.

Por exemplo, os diretórios de recursos de aplicativo a seguir fornecem diferentes designs de layout para diferentes tamanhos de tela e diferentes drawables. Use as pastas mipmap/ para os ícones de inicialização.

res/layout/my_layout.xml              // layout for normal screen size ("default")
res/layout-large/my_layout.xml        // layout for large screen size
res/layout-xlarge/my_layout.xml       // layout for extra-large screen size
res/layout-xlarge-land/my_layout.xml  // layout for extra-large in landscape orientation

res/drawable-mdpi/graphic.png         // bitmap for medium-density
res/drawable-hdpi/graphic.png         // bitmap for high-density
res/drawable-xhdpi/graphic.png        // bitmap for extra-high-density
res/drawable-xxhdpi/graphic.png       // bitmap for extra-extra-high-density

res/mipmap-mdpi/my_icon.png         // launcher icon for medium-density
res/mipmap-hdpi/my_icon.png         // launcher icon for high-density
res/mipmap-xhdpi/my_icon.png        // launcher icon for extra-high-density
res/mipmap-xxhdpi/my_icon.png       // launcher icon for extra-extra-high-density
res/mipmap-xxxhdpi/my_icon.png      // launcher icon for extra-extra-extra-high-density

Para ver como usar recursos alternativos e obter uma lista completa de qualificadores de configuração (não apenas para configurações de tela), consulte Fornecimento de recursos alternativos.

Esteja ciente de que, quando o sistema Android seleciona os recursos a serem usados no tempo de execução, ele usa certa lógica para determinar os recursos com a “melhor correspondência”. Ou seja, os qualificadores que você usar não precisam ser uma correspondência exata da configuração de tela atual em todos os casos para que o sistema os use. Especificamente, ao selecionar recursos com base nos qualificadores de tamanho, o sistema usará recursos projetados para uma tela menor do que a tela atual caso não haja recursos que correspondam melhor (por exemplo, usa tela de tamanho grande usará recursos para telas normais, se necessário). No entanto, se os únicos recursos disponíveis forem maiores do que a tela atual, o sistema não os usará e seu aplicativo travará se nenhum outro recurso corresponder à configuração do dispositivo (por exemplo, se todos os recursos estiverem marcados com o qualificador xlarge, mas o dispositivo tiver uma tela de tamanho normal). Para saber mais sobre como o sistema seleciona recursos, leia Como o Android encontra o recurso ideal.

Dica: Se você tiver alguns recursos drawable que o sistema nunca deva dimensionar (talvez você pretenda realizar ajustes na imagem por conta própria no tempo de execução), coloque-os em um diretório com o qualificador de configuração nodpi. Recursos com esse qualificador são considerados agnósticos de densidade e o sistema não os dimensionará.

Design de layouts e drawables alternativos

Os tipos de recursos alternativos que você deve criar dependem das necessidades do seu aplicativo. Normalmente, você deve usar os qualificadores de tamanho e orientação para fornecer recursos de layout alternativos e usar os qualificadores de densidade para fornecer recursos drawable bitmap alternativos.

As seções a seguir resumem como usar os qualificadores de tamanho e densidade para fornecer layouts alternativos e drawables, respectivamente.

Layouts alternativos

Geralmente, você pode descobrir se precisará de layouts alternativos para diferentes tamanhos de tela ao testar seu aplicativo em diferentes configurações de tela. Por exemplo:

Para resumir, você deve garantir que o layout do seu aplicativo:

Se sua IU usar bitmaps que precisem se encaixar no tamanho de uma visualização mesmo depois que o sistema dimensionar o layout (como a imagem de fundo de um botão), use arquivos bitmap Nine-Patch. Os arquivos Nine-Patch basicamente são arquivos PNG em que você especifica regiões bidimensionais que podem ser esticadas. Quando o sistema precisa dimensionar a visualização na qual o bitmap é usado, ele estica o bitmap Nine-Patch, mas apenas nas regiões especificadas. Dessa forma, não é preciso fornecer diferentes drawables para diferentes tamanhos de tela, pois o bitmap Nine-Patch pode ajustar-se a qualquer tamanho. Entretanto, você deve fornecer versões alternativas dos seus arquivos Nine-Patch para diferentes densidades de tela.

Drawables alternativos

Figura 4. Tamanhos relativos para drawables bitmap que oferecem suporte a cada densidade.

Quase todos os aplicativos devem ter recursos drawable alternativos para diferentes densidades de tela, pois quase todos têm um ícone de inicialização que deve ter uma aparência adequada em todas as densidades de tela. Da mesma forma, se você incluir outros drawables bitmap no aplicativo (como para ícones de menu ou outros gráficos no seu aplicativo), forneça versões alternativas de cada um deles para diferentes densidades.

Observação: Você só precisa fornecer drawables específicos de densidade para arquivos bitmap (.png, .jpg ou .gif) e Nine-Patch (.9.png). Caso use arquivos XML para definir formas, cores ou outros recursos drawable, você deve inserir uma cópia no diretório de drawables padrão (drawable/).

Para criar drawables bitmap alternativos para diferentes densidades, siga a taxa de dimensionamento 3:4:6:8:12:16 entre as seis densidades generalizadas. Por exemplo, se tiver um drawable bitmap que tenha 48 x 48 pixels para telas de densidade média, os diferentes tamanhos deverão ser:

Para saber mais sobre o design de ícones, consulte as Diretrizes de design de ícones, que incluem informações de tamanho para vários drawables bitmap, como ícones de inicialização, ícones de menu, ícones de barra de status, ícones de guia e muito mais.

Declaração de layouts de tablet para Android 3.2

Para a primeira geração de tablets que executa o Android 3.0, a maneira correta de declarar layouts de tablet era inseri-los em um diretório com o qualificador de configuração xlarge (por exemplo, res/layout-xlarge/). Para acomodar outros tipos de tablets e tamanhos de tela — em particular, tablets de 7 pol. — o Android 3.2 introduz uma nova maneira de especificar recursos para tamanhos de tela mais discretos. A nova técnica é baseada na quantidade de espaço da qual seu layout precisa (como 600 dp de largura), em vez de tentar fazer o layout caber nos grupos de tamanhos generalizados (como large ou xlarge).

O desafio do design para tablets de 7 pol. ao usar os grupos de tamanhos generalizados é que esse tipo de tablet se encontra, tecnicamente, no mesmo grupo que um telefone de 5 pol. (o grupo large). Embora esses dois dispositivos sejam aparentemente de tamanhos semelhantes, a quantidade de espaço para a IU de um aplicativo é significativamente diferente, assim como o estilo de interação de um usuário. Portanto, telas de 7 e 5 pol. nem sempre devem usar o mesmo layout. Para fornecer diferentes layouts para esses dois tipos de tela, o Android agora permite especificar recursos de layout com base na largura e/ou altura realmente disponível no layout do aplicativo, especificadas em unidades de dp.

Por exemplo, após projetar o layout que deseja usar para dispositivos de estilo de tablet, você pode determinar que o layout para de funcionar corretamente quando a tela tem menos de 600 dp de largura. Dessa forma, esse limite se torna o tamanho mínimo exigido para o layout de tablet. Portanto, você agora pode especificar que esses recursos de layout sejam usados apenas quando houver pelo menos 600 dp de largura disponível para a IU do seu aplicativo.

Você deve selecionar uma largura e projetá-la como seu tamanho mínimo ou testar a menor largura permitida por seu layout quando ele estiver completo.

Observação: Lembre-se de que todos os valores usados com essas novas APIs de tamanho são valores em pixels independentes de densidade (dp) e que as dimensões do seu layout devem ser sempre definidas usando unidades de dp, pois o importante é a quantidade de espaço em tela disponível depois que o sistema considera a densidade da tela (em vez de usar a resolução bruta de pixels). Para saber mais sobre os pixels independentes de densidade, leia os Termos e conceitos apresentados anteriormente neste documento.

Uso de novos qualificadores de tela

As diferentes configurações de recursos que você pode especificar com base no espaço disponível para seu layout são resumidas na tabela 2. Esses novos qualificadores oferecem mais controle sobre os tamanhos de tela específicos que seu aplicativo permite em comparação com os grupos de tamanhos de telas tradicionais (pequena, normal, grande e extra grande).

Observação: Os tamanhos especificados usando esses qualificadores não são tamanhos reais de telas. Em vez disso, os tamanhos são para a largura ou a altura em unidades de dp que estão disponíveis para sua janela de atividade. O sistema Android pode usar parte da tela para a IU do sistema (como a barra de sistema na parte inferior da tela ou a barra de status na parte superior), portanto, a tela pode não estar totalmente disponível para seu layout. Dessa forma, os tamanhos declarados devem ser especificamente para os tamanhos dos quais sua atividade precisa — o sistema considera qualquer espaço usado pela IU do sistema ao declarar quanto espaço ele fornece para seu layout. Além disso, esteja ciente de que a barra de ações é considerada parte do espaço de janela do seu aplicativo, apensar de seu layout não a declarar, portanto, ela reduz o espaço disponível para o layout e deve ser considerada no design.

Tabela 2. Novos qualificadores de configuração para tamanho de tela (introduzidos no Android 3.2).

Configuração da telaValores do qualificadorDescrição
smallestWidth sw<N>dp

Exemplos:
sw600dp
sw720dp

O tamanho fundamental de uma tela, como indicado pela menor dimensão da área da tela disponível. Especificamente, o valor smallestWidth do dispositivo é o menor da altura e largura da tela (pode-se também interpretar isso como a "menor largura possível" da tela). É possível usar esse qualificador para garantir que, independentemente da orientação atual da tela, o aplicativo tenha pelo menos <N> dps de largura disponível para a IU.

Por exemplo, se seu layout exigir que a menor dimensão da área da tela seja de pelo menos 600 dp, é possível usar o seguinte qualificador para criar os recursos do layout: res/layout-sw600dp/. O sistema usará esses recursos somente quando a menor dimensão da tela disponível for de pelo menos 600 dp, independentemente se o lado de 600 dp é a altura ou a largura percebida pelo usuário. O valor smallestWidth é uma característica fixa do tamanho da tela do dispositivo;o valor smallestWidth do dispositivo não altera quando a orientação da tela muda.

O valor smallestWidth de um dispositivo leva em consideração decorações de tela e a IU do sistema. Por exemplo, se o dispositivo tiver alguns elementos de IU persistentes na tela que consideram o espaço ao longo do eixo de smallestWidth, o sistema declarará que smallestWidth é menor do que o tamanho atual da tela, pois são pixels de tela não disponíveis para a IU.

Essa é uma alternativa para os qualificadores de tamanho generalizados (small, normal, large, xlarge) que permite definir um número discreto para o tamanho efetivamente disponível para sua IU. Usar smallestWidth para determinar o tamanho geral da tela é útil porque a largura é frequentemente o fator determinante para o design de um layout. Com frequência, uma IU tem rolagem vertical, mas também limitações rígidas no espaço mínimo de que precisa horizontalmente. A largura disponível também é um fator essencial para determinar o uso de um layout de um painel ou de um layout de vários painéis para tablets. Dessa forma, é provável que você se importe mais com a menor largura possível disponível em cada dispositivo.
Largura de tela disponível w<N>dp

Exemplos:
w720dp
w1024dp

Especifica uma largura mínima disponível em unidades de dp em que o recurso deve ser usado — definido pelo valor <N>. O valor correspondente do sistema para a largura muda quando a orientação da tela é alternada entre paisagem e retrato para refletir a largura real atual disponível para sua IU.

Isso é frequentemente útil para determinar o uso de um layout de vários painéis, pois, mesmo em um dispositivo tablet, você às vezes não quer o mesmo layout de vários painéis para a orientação retrato e paisagem. Dessa forma, esse recurso pode ser usado para especificar a largura mínima de que seu layout precisa em vez de usar os dois qualificadores de tamanho e orientação da tela juntos.
Altura de tela disponível h<N>dp

Exemplos:
h720dp
h1024dp
etc.

Especifica uma altura mínima da tela, em unidades de dp em que os recursos devem ser usados — definido pelo valor <N>. O valor correspondente do sistema para a altura muda quando a orientação da tela é alternada entre paisagem e retrato para refletir a altura real atual disponível para sua IU.

Usar esse recurso para definir a altura de que seu layout precisa é útil da mesma forma que w<N>dp é útil para definir a largura necessária, em vez de usar os qualificadores de tamanho e orientação da tela juntos. No entanto, a maioria dos aplicativos não precisará desse qualificador, considerando que as IUs são frequentemente roladas verticalmente e, portanto, são mais flexíveis em termos de altura disponível, enquanto a largura é mais rígida.

Embora o uso desses qualificadores possa parecer mais complicado do que o uso dos grupos de tamanhos de tela, ele, na verdade, deve ser mais simples depois que você determinar os requisitos da sua IU. Ao projetar sua IU, o fator mais importante para você provavelmente é o tamanho real do seu aplicativo ao alternar entre uma IU para telefone e uma IU para tablets que use vários painéis. O ponto exato dessa troca dependerá do seu design específico — talvez você precise de uma largura de 720 dp para seu layout de tablet, talvez 600 dp baste, ou 480 dp ou qualquer outro valor. Ao usar os qualificadores da tabela 2, você controla o tamanho preciso no qual seu layout muda.

Para saber mais sobre esses qualificadores de configuração de tamanho, consulte o documento Fornecimento de recursos.

Exemplos de configuração

Para ajudar você a direcionar seus designs para diferentes tipos de dispositivos, veja a seguir alguns valores para larguras de telas típicas:

Ao usar os qualificadores de tamanho da tabela 2, seu aplicativo pode alternar entre seus diferentes recursos de layout para telefones e tablets usando qualquer valor que você queira para a largura e/ou altura. Por exemplo, se 600 dp for a menor largura disponível que seu layout de tablet permite, você pode fornecer estes dois conjuntos de layouts:

res/layout/main_activity.xml           # For handsets
res/layout-sw600dp/main_activity.xml   # For tablets

Nesse caso, a largura menor do espaço em tela disponível deve ser 600 dp para que o layout de tablet seja aplicado.

Para outros casos nos quais você queira personalizar ainda mais sua IU para diferenciar entre tamanhos como tablets de 7 e 10 pol., você pode definir layouts de menor largura adicionais:

res/layout/main_activity.xml           # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml   # For 7” tablets (600dp wide and bigger)
res/layout-sw720dp/main_activity.xml   # For 10” tablets (720dp wide and bigger)

Observe que os dois conjuntos de exemplos de recursos anteriores usam o qualificador de “menor largura”, sw<N>dp, que especifica o menor dos dois lados da tela, independentemente da orientação atual do dispositivo. Dessa forma, o uso do sw<N>dp é uma maneira simples de especificar o tamanho geral da tela disponível para seu layout ignorando a orientação.

Entretanto, em alguns casos, você pode se importar mais com a quantidade exata de largura ou altura atualmente disponível para seu layout. Por exemplo, se você tiver um layout de dois painéis com dois fragmentos lado a lado, você pode querer usá-lo sempre que a tela forneça pelo menos 600 dp de largura, independentemente da orientação do dispositivo. Nesse caso, seus recursos podem ter a seguinte aparência:

res/layout/main_activity.xml         # For handsets (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml  # Multi-pane (any screen with 600dp available width or more)

Observe que o segundo conjunto usa o qualificador de “largura disponível”, w<N>dp. Assim, um dispositivo poderá usar ambos os layouts dependendo da orientação da tela (se a largura disponível for de pelo menos 600 dp em uma orientação e de menos de 600 dp na outra orientação).

Se a altura disponível for uma preocupação para você, é possível fazer o mesmo usando o qualificador h<N>dp. Também é possível combinar os qualificadores w<N>dp e h<N>dp se precisar ser realmente específico.

Declaração de suporte ao tamanho de tela

Após implementar seus layouts para diferentes tamanhos de tela, é igualmente importante que você declare no arquivo de manifesto as telas que seu aplicativo aceita.

Juntamente com os novos qualificadores de configuração para tamanho de tela, o Android 3.2 introduz novos atributos para o elemento <supports-screens> do manifesto:

android:requiresSmallestWidthDp
Especifica o valor necessário para smallestWidth. O atributo smallestWidth é a dimensão mais curta do espaço em tela (em unidades de dp) que deve estar disponível para a IU do seu aplicativo — ou seja, a mais curta das duas dimensões da tela disponível. Portanto, para que um dispositivo seja considerado compatível com seu aplicativo, o valor de smallestWidth do dispositivo deve ser igual ou maior que esse valor. (Geralmente, o valor que você fornece para esse atributo é a “menor largura” que seu layout permite, independentemente da orientação atual da tela.)

Por exemplo, se seu aplicativo for destinado a apenas dispositivos de estilo tablet com uma menor largura disponível de 600 dp:

<manifest ... >
    <supports-screens android:requiresSmallestWidthDp="600" />
    ...
</manifest>

Entretanto, se seu aplicativo permitir todos os tamanhos de tela aos quais o Android oferece suporte (o menor sendo 426 dp x 320 dp), não será preciso declarar esse atributo, pois a menor largura exigida por seu aplicativo é a menor possível em qualquer dispositivo.

Atenção: O sistema Android não dá atenção a esse atributo, portanto, ele não afeta como seu aplicativo se comporta no tempo de execução. Em vez disso, ele é usado para permitir a filtragem para seu aplicativo em serviços como o Google Play. No entanto, o Google Play não oferece suporte a esse atributo para filtragem no momento (no Android 3.2), portanto, você deve continuar usando os outros atributos de tamanho se seu aplicativo não aceitar telas pequenas.

android:compatibleWidthLimitDp
Esse atributo permite ativar o modo de compatibilidade de tela como um recurso opcional para o usuário ao especificar uma “menor largura” máxima que o aplicativo aceita. Se o menor lado da tela disponível de um dispositivo for maior do que o valor que você definir para esse atributo, os usuários ainda poderão instalar seu aplicativo, mas receberão a opção de executá-lo no modo de compatibilidade de tela. Por padrão, o modo de compatibilidade de tela é desativado e o layout é redimensionado para caber na tela normalmente, mas a barra de sistema disponibiliza um botão para ativar e desativar o modo de compatibilidade de tela.

Observação: Se o layout do seu aplicativo for corretamente redimensionado para telas grandes, não é preciso usar esse atributo. Recomendamos evitar o uso desse atributo e, em vez disso, garanta o redimensionamento do layout para telas maiores seguindo as recomendações deste documento.

android:largestWidthLimitDp
Esse atributo permite que você force a ativação do modo de compatibilidade de tela como um ao especificar a “menor largura” máxima aceita pelo aplicativo. Se o menor lado da tela disponível de um dispositivo for maior do que o valor que você definir para esse atributo, o aplicativo será executado no modo de compatibilidade de tela e o usuário não poderá desativá-lo.

Observação: Se o layout do seu aplicativo for corretamente redimensionado para telas grandes, não é preciso usar esse atributo. Recomendamos evitar o uso desse atributo e, em vez disso, garanta o redimensionamento do layout para telas maiores seguindo as recomendações deste documento.

Atenção: Ao desenvolver para Android 3.2 e versões posteriores, não se devem usar atributos de tamanho de tela mais antigos em combinação com os atributos listados acima. O uso de atributos de tamanho novos e antigos pode causar comportamentos inesperados.

Para saber mais sobre cada atributo, siga os respectivos links acima.

Práticas recomendadas

O objetivo de oferecer suporte a várias telas é criar um aplicativo que funcione corretamente e tenha uma boa aparência em qualquer uma das configurações de tela generalizadas permitidas pelo Android. As seções anteriores deste documento fornecem informações sobre como o Android adapta a tela do seu aplicativo para configurações de tela e como você pode personalizar a aparência do aplicativo em diferentes configurações de tela. Esta seção fornece dicas adicionais e uma visão geral de técnicas que ajudam a garantir que o aplicativo seja dimensionado corretamente para diferentes configurações de tela.

A seguir apresentamos uma lista de verificação rápida para garantir que seu aplicativo seja exibido corretamente em diferentes telas:

  1. Use unidades wrap_content, match_parent ou dp ao especificar dimensões em um arquivo de layout XML
  2. Não use valores de pixel rígidos no código do seu aplicativo
  3. Não use AbsoluteLayout (obsoleto)
  4. Forneça drawables bitmap alternativos para diferentes densidades de tela

As seções a seguir fornecem mais detalhes.

1. Use wrap_content, match_parent ou a unidade de dp para as dimensões do layout

Ao definir a android:layout_width e a android:layout_height para visualizações em um arquivo de layout XML, o uso de unidades "wrap_content", "match_parent" ou dp garante que a visualização tenha o tamanho apropriado na tela do dispositivo atual.

Por exemplo, uma visualização com layout_width="100dp" tem 100 pixels de largura em uma tela de densidade média e o sistema a dimensiona para 150 pixels de largura em uma tela de alta densidade para que ela ocupe, aproximadamente, o mesmo espaço físico na tela.

Da mesma forma, você deve dar preferência ao sp (código independente de escala) para definir tamanhos de texto. O fator de escala sp depende de uma configuração do usuário e o sistema define o tamanho da mesma maneira que para dp.

2. Não use valores de pixel rígidos no código do seu aplicativo

Por motivos de desempenho e para manter o código mais simples, o sistema Android usa pixels como a unidade padrão para expressar valores de dimensão ou coordenadas. Isso significa que as dimensões de uma visualização são sempre expressadas no código usando pixels, mas sempre com base na densidade atual da tela. Por exemplo, se myView.getWidth() retornar 10, a visualização tem 10 pixels de largura na tela atual, mas em um dispositivo com uma tela de densidade mais alta, o valor retornado pode ser 15. Se você usar valores de pixel no código do seu aplicativo para trabalhar com bitmaps que não foram pré-dimensionados para a densidade de tela atual, você pode precisar ajustar os valores de pixels usados no seu código de acordo com a fonte do bitmap não dimensionado.

Se seu aplicativo manipula bitmaps ou trabalha com valores de pixel no tempo de execução, consulte a seção abaixo sobre Considerações adicionais sobre densidade.

3. Não use AbsoluteLayout

Diferentemente de outros widgets de layout, o AbsoluteLayout aplica o uso de posições físicas para dispor suas visualizações filhas, o que pode facilmente gerar interfaces de usuário que não funcionam bem em certas telas. Por causa disso, o AbsoluteLayout ficou obsoleto no Android 1.5 (nível de API 3).

No lugar dele, você deve usar o RelativeLayout, que usa o posicionamento relativo para dispor suas visualizações filho. Por exemplo, você pode especificar que um widget de botão deve aparecer “à direita de” um widget de texto.

4. Use recursos específicos de tamanho e densidade

Apesar do sistema dimensionar seu layout e seus recursos drawable com base na configuração de tela atual, você pode querer fazer ajustes na IU em diferentes tamanhos de tela e fornecer drawables bitmap otimizados para diferentes densidades. Isso essencialmente reitera as informações apresentadas anteriormente neste documento.

Se precisar controlar exatamente como seu aplicativo ficará em várias configurações de tela, ajuste seus layouts e drawables bitmap em diretórios de recursos específicos de configuração. Por exemplo, considere um ícone que você queira exibir em telas de média e alta densidade. Basta criar seu ícone em dois tamanhos diferentes (por exemplo, 100 x 100 para densidade média e 150 x 150 para densidade alta) e colocar as duas variações nos diretórios apropriados usando os qualificadores corretos:

res/drawable-mdpi/icon.png   //for medium-density screens
res/drawable-hdpi/icon.png   //for high-density screens

Observação: Se um qualificador de densidade não for definido em um nome de diretório, o sistema presume que os recursos desse diretório são projetados para a densidade média básica e dimensiona os recursos para outras densidades conforme for apropriado.

Para saber mais sobre qualificadores de configuração válidos, consulte Uso de qualificadores de configuração, anteriormente neste documento.

Considerações adicionais sobre densidade

Esta seção contém mais informações sobre como o Android executa o dimensionamento para drawables bitmap em diferentes densidades de tela e como você pode ter mais controle sobre como os bitmaps são renderizados em diferentes densidades. As informações incluídas nesta seção não devem ser importantes para a maioria dos aplicativos, a não ser que você tenha problemas no aplicativo ao executá-lo em diferentes densidades de tela ou se ele manipular gráficos.

Para saber oferecer compatibilidade com várias densidades ao manipular gráficos no tempo de execução, você deve entender como o sistema ajuda a garantir o dimensionamento correto para bitmaps das seguintes maneiras:

  1. Pré-dimensionamento de recursos (como drawables bitmap)

    Com base na densidade da tela atual, o sistema usa qualquer recurso específico de tamanho ou densidade do seu aplicativo e os exibe sem dimensioná-los. Se os recursos não estiverem disponíveis na densidade correta, o sistema carrega os recursos padrão e os amplia ou reduz conforme a necessidade de acordo com a densidade da tela atual. O sistema presume que os recursos padrão (os que se encontram em um diretório sem qualificadores de configuração) são projetados para a densidade de tela básica (mdpi), a não ser que eles sejam carregados de um diretório de recursos específico de densidade. Dessa forma, o pré-dimensionamento é o que o sistema faz ao redimensionar um bitmap para o tamanho apropriado da densidade da tela atual.

    Se você solicitar as dimensões de um recurso pré-dimensionado, o sistema retornará valores que representem as dimensões após o redimensionamento. Por exemplo, um bitmap projeto a 50 x 50 pixels para uma tela mdpi é dimensionado para 75 x 75 em uma tela hdpi (caso não haja um recurso alternativo para hdpi) e o sistema declara o tamanho dessa maneira.

    Existem algumas situações nas quais você pode não querer que o Android pré-dimensione um recurso. A maneira mais fácil de evitar o pré-dimensionamento é colocar o recurso em um diretório de recursos com o qualificador de configuração nodpi. Por exemplo:

    res/drawable-nodpi/icon.png

    Quando o sistema usa o bitmap icon.png dessa pasta, ele não o dimensiona de acordo com a densidade atual do dispositivo.

  2. Autodimensionamento de dimensões e coordenadas em pixels

    Um aplicativo pode desativar o pré-dimensionamento ao definir android:anyDensity como "false" no manifesto ou programaticamente para um Bitmap ao definir inScaled como "false". Nesse caso, o sistema autodimensiona qualquer coordenada absoluta em pixels e valores de dimensões em pixels no tempo de desenho. Isso é feito para garantir que os elementos da tela definidos como pixels ainda sejam exibidos no mesmo tamanho físico aproximado que eles teriam na tela de densidade básica (mdpi). O sistema realiza esse dimensionamento de forma transparente para o aplicativo e informa as dimensões ajustadas em pixels ao aplicativo em vez das dimensões físicas em pixels.

    Por exemplo, suponha que um dispositivo tenha uma tela WVGA de alta densidade, que tenha 480 x 800 e aproximadamente o mesmo tamanho que uma tela HVGA tradicional, mas que esteja executando um aplicativo que tenha desativado o pré-dimensionamento. Nesse caso, o sistema “mentirá” para o aplicativo quando ele consultar as dimensões da tela e informará 320 x 533 (a conversão em mdpi aproximada para a densidade da tela). Em seguida, quando o aplicativo executar operações de desenho, como invalidar o retângulo de (10,10) para (100, 100), o sistema transformará as coordenadas dimensionando-as para os valores corretos e invalidará a região (15,15) para (150, 150). Essa discrepância pode causar comportamentos inesperados se o aplicativo manipular o bitmap dimensionado diretamente, mas essa é considerada uma troca razoável para manter o desempenho dos aplicativos no mais alto nível possível. Se você se deparar com essa situação, leia a seção a seguir sobre a Conversão de unidades de dp em unidades de pixel.

    Geralmente, não se recomenda desativar o pré-dimensionamento. A melhor maneira de oferecer suporte a várias telas é seguir as técnicas básicas descritas acima em Como oferecer suporte a várias telas.

Se seu aplicativo manipular bitmaps ou interagir diretamente com pixels na tela de outra maneira, pode ser necessário executar etapas adicionais para oferecer suporte a diferentes densidades de tela. Por exemplo, se você responder a gestos de toque contando o número de pixels que um dedo cruzar, será preciso usar os valores apropriados de pixels independentes de densidade em vez dos pixels reais.

Dimensionamento de objetos bitmap criados no tempo de execução

Figura 5. Comparação de bitmaps pré-dimensionados e autodimensionados.

Se seu aplicativo criar um bitmap na memória (um objeto Bitmap), o sistema presumirá que ele foi projetado para a tela de densidade média básica, por padrão, e autodimensionará o bitmap no tempo de desenho. O sistema aplica o “autodimensionamento” a um Bitmap quando o bitmap tem propriedades de densidade não especificadas. Se você não levar em conta a densidade da tela do dispositivo atual e especificar as propriedades de densidade do bitmap, o autodimensionamento pode resultará em artefatos de dimensionamento da mesma forma que ocorre quando você não fornece recursos alternativos.

Para controlar se um Bitmap no tempo de execução é dimensionado ou não, você pode especificar a densidade do bitmap com setDensity(), passando uma constante de densidade de DisplayMetrics, como DENSITY_HIGH ou DENSITY_LOW.

Se estiver criando um Bitmap usando BitmapFactory, por exemplo, de um arquivo ou stream, você pode usar BitmapFactory.Options para definir as propriedades do bitmap pois ele já existe, o que determinar se ou como o sistema o dimensionará. Por exemplo, você pode usar o campo inDensity para definir a densidade para a qual o bitmap é projetado e o campo inScaled para especificar se o bitmap deve ser dimensionado de acordo com a densidade da tela do dispositivo atual.

Ao definir o campo inScaled como false, você desativa qualquer pré-dimensionamento que o sistema possa aplicar ao bitmap; o sistema, então, o dimensionará automaticamente no tempo de desenho. O uso do dimensionamento automático em vez de pré-dimensionamento pode consumir mais recursos de CPU, mas usa menos memória.

A figura 5 demonstra os resultados dos mecanismos de pré-dimensionamento e dimensionamento automático ao carregar bitmaps de densidade baixa (120), média (160) e alta (240) em uma tela de alta densidade. As diferenças são sutis, pois todos os bitmaps estão sendo dimensionados de acordo com a densidade da tela atual, no entanto os bitmaps dimensionados têm aparências ligeiramente diferentes dependendo de terem sido pré-dimensionados ou dimensionados automaticamente no tempo de desenho.

Observação: No Android 3.0 e em versões posteriores, não deve haver diferenças perceptíveis entre bitmaps pré-dimensionados e dimensionados automaticamente devido às melhorias na estrutura de gráficos.

Conversão de unidades de dp em unidades de pixel

Em alguns casos, você precisará expressar dimensões em dp e convertê-las em pixels. Imagine um aplicativo no qual um gesto de rolagem ou navegação seja reconhecido depois que o dedo do usuário tenha sido movido em pelo menos 16 pixels. Em uma tela de configuração básica, o dedo do usuário deve ser movido em 16 pixels / 160 dpi, o que equivale a 1/10 de uma polegada (ou 2,5 mm) para que o gesto seja reconhecido. Em um dispositivo com uma tela de alta densidade (240 dpi), o dedo do usuário deve ser movido em 16 pixels / 240 dpi, o que equivale a 1,7 mm (ou 1/15 de polegada). A distância é muito mais curta e, dessa forma, o aplicativo parece ser mais sensível para o usuário.

Para corrigir esse problema, o limite de gesto deve ser expresso no código em dp e convertido em pixels. Por exemplo:

// The gesture threshold expressed in dp
private static final float GESTURE_THRESHOLD_DP = 16.0f;

// Get the screen's density scale
final float scale = getResources().getDisplayMetrics().density;
// Convert the dps to pixels, based on density scale
mGestureThreshold = (int) (GESTURE_THRESHOLD_DP * scale + 0.5f);

// Use mGestureThreshold as a distance in pixels...

O campo DisplayMetrics.density especifica o fator de escala a usar para converter unidades de dp em pixels de acordo com a densidade da tela atual. Em uma tela de média densidade, o DisplayMetrics.density equivale a 1,0; em uma tela de alta densidade ele equivale a 1,5; em uma tela de extra-alta densidade, ele equivale a 2,0; e, em uma tela de baixa densidade, ele equivale a 0,75. Esse valor é o fator pelo qual você deve multiplicar as unidades de dp para obter a contagem real de pixels para a tela atual. (Em seguida, adicione 0.5f para arredondar o valor para o próximo número não fracionado ao realizar a conversão para número inteiro.) Para saber mais, consulte a classe DisplayMetrics.

No entanto, em vez de definir um limite arbitrário para esse tipo de evento, você deve usar os valores de configuração pré-dimensionados disponíveis em ViewConfiguration.

Uso de valores de configuração pré-dimensionados

Você pode usar a classe ViewConfiguration para acessar distâncias, velocidades e tempos comuns usados pelo sistema Android. Por exemplo, pode-se obter a distância em pixels usada pela estrutura como limite de rolagem com getScaledTouchSlop():

private static final int GESTURE_THRESHOLD_DP = ViewConfiguration.get(myContext).getScaledTouchSlop();

Métodos em ViewConfiguration iniciados pelo prefixo getScaled garantem o retorno de um valor em pixels exibido corretamente independentemente da densidade atual da tela.

Como testar seu aplicativo em várias telas

Figura 6. Um conjunto de AVDs para testar o suporte a telas.

Antes de publicar seu aplicativo, você deve testá-lo extensivamente em todos os tamanhos e densidades de telas aceitos. O Android SDK abrange aparências de emulador que podem ser usadas para replicar os tamanhos e as densidades de configurações comuns de telas nas quais o aplicativo poderá ser executado. Você também pode modificar o tamanho, a densidade e a resolução padrão das aparências de emulador para replicar as características de qualquer tela específica. O uso de aparências de emulador e de configurações personalizadas adicionais permite que você teste qualquer configuração de tela possível. Assim, você não precisa comprar diversos dispositivos apenas para testar o suporte a telas do seu aplicativo.

Para configurar um ambiente para testar o suporte a telas do seu aplicativo, crie uma série de AVDs (Android Virtual Devices), usando aparências de emulador e configurações de tela que reproduzam tamanhos e densidades de tela que você deseja que seu aplicativo aceite. Para isso, você pode usar o AVD Manager para criar os AVDs e iniciá-los com uma interface gráfica.

Para iniciar o Android SDK Manager, execute o SDK Manager.exe do seu diretório Android SDK (apenas no Windows) ou execute android do diretório <sdk>/tools/ (em todas as plataformas). A figura 6 mostra o AVD Manager com uma seleção de AVDs para testar várias configurações de tela.

A tabela 3 mostra as várias aparências de emulador disponíveis no Android SDK, que podem ser usadas para emular algumas das mais comuns configurações de tela.

Para saber mais sobre como criar e usar AVDs para testar seu aplicativo, consulte Gerenciamento de AVDs com o AVD Manager.

Tabela 3. Várias configurações de tela disponibilizadas pelas aparências de emulador no Android SDK (indicadas em negrito) e outras resoluções representativas.

Densidade baixa (120), ldpi Densidade média (160), mdpi Densidade alta (240), hdpi Densidade extra-alta (320), xhdpi
Tela pequena QVGA (240 x 320) 480 x 640
Tela normal WQVGA400 (240 x 400)
WQVGA432 (240 x 432)		 HVGA (320 x 480) WVGA800 (480 x 800)
WVGA854 (480 x 854)
600 x 1024		 640 x 960
Tela grande WVGA800** (480 x 800)
WVGA854** (480 x 854)		 WVGA800* (480 x 800)
WVGA854* (480 x 854)
600 x 1024
Tela extra-grande 1024 x 600 WXGA (1280 x 800)†
1024 x 768
1280 x 768		 1536 x 1152
1920 x 1152
1920 x 1200		 2048 x 1536
2560 x 1536
2560 x 1600
* Para emular essa configuração, especifique uma densidade personalizada de 160 ao criar um AVD que use uma aparência WVGA800 ou WVGA854.
** Para emular essa configuração, especifique uma densidade personalizada de 120 ao criar um AVD que use uma aparência WVGA800 ou WVGA854.
† Essa aparência está disponível na plataforma Android 3.0

Para ver os números relativos de dispositivos ativos que aceitam qualquer configuração de tela, consulte o painel Screen Sizes and Densities .

Figura 7. Opções de tamanho e densidade que podem ser definidas ao iniciar uma AVD pelo AVD Manager.

Também recomendamos testar seu aplicativo em um emulador configurado para ser executado em um tamanho físico que se aproxime de um dispositivo real. Isso facilita consideravelmente a comparação dos resultados em diversos tamanhos e densidades. Para fazer isso, você deve saber a densidade aproximada, em dpi, do monitor do seu computador (por exemplo, um monitor Dell de 30 pol. tem uma densidade de cerca de 96 dpi). Ao iniciar um AVD pelo AVD Manager, você pode especificar o tamanho da tela para o emulador e o dpi do seu monitor em Launch Options, conforme é mostrado na figura 7.

Se quiser testar seu aplicativo em uma tela que use uma resolução ou densidade incompatíveis com as aparências internas, você pode criar um AVD que use essa resolução ou densidade personalizada. Ao criar um AVD pelo AVD Manager, especifique a resolução em vez de selecionar uma aparência interna.

Se estiver iniciando seu AVD pela linha de comando, você pode especificar a escala para o emulador com a opção -scale. Por exemplo:

emulator -avd <avd_name> -scale 96dpi

Para refinar o tamanho do emulador, você pode passar para a opção -scale um número entre 0,1 e 3 que represente o fator de escala desejado.

Para saber mais sobre como criar AVDs pela linha de comando, consulte Gerenciamento de AVDs pela linha de comando.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.
Sure No thanks