Visão geral dos recursos de aplicativo

Recursos são os arquivos adicionais e o conteúdo estático usado pelo seu código, como bitmaps, definições de layout, strings da interface do usuário, instruções de animação, entre outras coisas.

É importante sempre exteriorizar os recursos do aplicativo, como imagens e strings do código, para que você possa mantê-los independentemente. Forneça recursos alternativos para configurações específicas do dispositivo, agrupando-os em diretórios de recursos especialmente nomeados. No ambiente de execução, o Android usa o recurso adequado com base na configuração atual. Por exemplo, você pode querer fornecer um layout de IU diferente dependendo do tamanho da tela ou strings diferentes dependendo da configuração de idioma.

Ao exteriorizar os recursos do aplicativo, é possível acessá-los usando códigos de recurso que são gerados na classe R do projeto. Este documento mostra como agrupar os recursos no projeto do Android e fornecer recursos alternativos para configurações específicas do dispositivo e, em seguida, acessá-los do seu código do aplicativo ou de outros arquivos XML.

Agrupamento de tipos de recursos

Posicione cada tipo de recurso em um subdiretório específico do diretório res/ do projeto. Por exemplo, abaixo está a hierarquia de arquivos para um projeto simples:

MyProject/
    src/
        MyActivity.java
    res/
        drawable/
            graphic.png
        layout/
            main.xml
            info.xml
        mipmap/
            icon.png
        values/
            strings.xml

Como se pode ver neste exemplo, o diretório res/ contém todos os recursos (em subdiretórios): um recurso de imagem, dois recursos de layout, diretórios mipmap/ para ícones de inicialização e um arquivo de recurso de string. Os nomes dos diretórios de recursos são importantes e estão descritos na tabela 1.

Observação: para mais informações sobre o uso de pastas mipmap, consulte Visão geral do gerenciamento de projetos.

Tabela 1. Os diretórios de recursos compatíveis dentro do diretório res/ do projeto.

Diretório Tipo de recurso
animator/ Arquivos XML que definem as animações da property.
anim/ Arquivos XML que definem as animações intermediárias. As animações de property também podem ser salvas neste diretório, mas o diretório animator/ é o preferencial para animações de property para distinguir os dois tipos.
color/ Arquivos XML que definem uma lista de estado de cores. Consulte Recurso de lista de estado de cores
drawable/

Os arquivos Bitmap (.png, .9.png, .jpg, .gif) ou arquivos XML são compilados nos seguintes subtipos de recurso drawable:

  • Arquivos Bitmap
  • Nine-Patch (bitmaps redimensionáveis)
  • Listas de estado
  • Formatos
  • Drawables de animação
  • Outros drawables

Veja Recursos desenháveis.

mipmap/ São arquivos drawable para diferentes densidades do ícone na tela de início. Para mais informações sobre o gerenciamento de ícones na tela de início com pastas mipmap/, consulte Visão geral do gerenciamento de projetos.
layout/ Arquivos XML que definem um layout de interface do usuário. Consulte Recurso de layout.
menu/ São arquivos XML que definem os menus do aplicativo, como menu de opções, menu de contexto ou submenu. Consulte Recurso de menu.
raw/

São arquivos arbitrários para salvar na forma bruta. Para abrir esses recursos com InputStream bruto, chame Resources.openRawResource() com o código do recurso, que é R.raw.filename.

No entanto, se precisar de acesso aos nomes e à hierarquia dos arquivos originais, considere salvar alguns recursos no diretório assets/ (em vez de res/raw/). Os arquivos em assets/ não recebem um código de recurso, eles só podem ser lidos com AssetManager.

values/

São arquivos XML que contêm valores simples, como strings, números inteiros e cores.

Enquanto os arquivos de recurso XML que estão em outros subdiretórios res/ definem um único recurso com base no nome do arquivo XML, os arquivos no diretório values/ descrevem vários recursos. Para cada arquivo neste diretório, cada filho do elemento <resources> define um único recurso. Por exemplo: um elemento <string> cria um recurso R.string e um elemento <color> cria um recurso R.color.

Como cada recurso é definido com seu próprio elemento XML, é possível nomear o arquivo da forma que quiser e colocar tipos de recurso variados em um arquivo. No entanto, para esclarecer, você pode querer colocar tipos de recursos únicos em arquivos diferentes. Por exemplo, veja algumas convenções de nome de arquivo para recursos que podem ser criados neste diretório:

Consulte Recursos de string, Recurso de estilo e Mais tipos de recursos.

xml/ São arquivos arbitrários XML que podem ser lidos no ambiente de execução chamando Resources.getXML(). Vários arquivos de configuração XML precisam ser salvos aqui, como uma configuração pesquisável.
font/ São arquivos de fonte com extensões como .ttf, .otf ou .ttc, ou arquivos XML que incluem um elemento <font-family>. Para mais informações sobre fontes como recursos, acesse Fontes em XML.

Atenção: nunca salve arquivos de recurso diretamente no diretório res/ — isso causará um erro do compilador.

Para mais informações sobre determinados tipos de recursos, consulte a documentação Tipos de recursos.

Os recursos salvos nos subdiretórios definidos na tabela 1 são os recursos “padrão”. Ou seja, esses recursos definem o conteúdo e o design padrão para o seu aplicativo. No entanto, tipos diferentes de dispositivos com Android podem chamar diferentes tipos de recursos. Por exemplo, se um dispositivo tiver uma tela maior do que o normal, precisarão ser fornecidos recursos de layout diferentes que aproveitem o espaço extra na tela. Ou, se um dispositivo tiver uma configuração de idioma diferente, é necessário fornecer recursos de string diferentes que traduzam o texto na interface do usuário. Para fornecer esses diferentes recursos para configurações de dispositivo diferentes, você precisa fornecer recursos alternativos, além dos recursos padrão.

Fornecimento de recursos alternativos

Quase todos os aplicativos precisam fornecer recursos alternativos para suportar configurações específicas do dispositivo. Por exemplo, é importante incluir recursos drawable alternativos para densidades de tela diferentes e recursos alternativos de string para idiomas diferentes. No ambiente de execução, o Android detecta a configuração atual do dispositivo e carrega os recursos adequados para o aplicativo.

Figura 1. Dois dispositivos diferentes, cada um usando recursos diferentes de layout.

Para especificar as alternativas de configuração específica para um conjunto de recursos:

  1. Crie um novo diretório no res/ nomeado na forma de <resources_name>-<config_qualifier>.
    • <resources_name> é o nome do diretório dos recursos padrão correspondentes (definido na tabela 1).
    • <qualifier> é um nome que especifica uma configuração individual a que esses recursos se destinam (definido na tabela 2).

    É possível anexar mais de um <qualifier>. Separe cada um com um travessão.

    Atenção: ao anexar vários qualificadores, coloque-os na mesma ordem em que foram listados na tabela 2. Se os qualificadores estiverem na ordem incorreta, os recursos serão ignorados.

  2. Salve os respectivos recursos alternativos neste novo diretório. Os arquivos de recurso precisam ter exatamente os mesmos nomes dos arquivos de recurso padrão.

Por exemplo, a seguir há alguns recursos alternativos e outros padrão:

res/
    drawable/
        icon.png
        background.png
    drawable-hdpi/
        icon.png
        background.png

O qualificador hdpi indica que os recursos neste diretório são destinados a dispositivos com tela de alta densidade. As imagens em cada um desses diretórios drawable são dimensionadas para uma densidade de tela específica, mas os nomes dos arquivos são exatamente os mesmos. Assim, o código de recurso usado para referenciar icon.png ou a imagem background.png será sempre o mesmo, mas o Android selecionará a versão de cada arquivo que melhor corresponder ao dispositivo atual, comparando as informações de configuração com os qualificadores no nome do diretório do recurso.

O Android é compatível com vários qualificadores de configuração e é possível adicionar vários qualificadores a um nome de diretório separando cada qualificador com um travessão. A tabela 2 lista os qualificadores de configuração válidos, em ordem de precedência — caso use vários qualificadores para um diretório de recursos, você precisa adicioná-los ao nome do diretório na ordem em que foram listados na tabela.

Tabela 2. Nomes de qualificadores de configuração.

Configuração Valores do qualificador Descrição
MCC e MNC Exemplos:
mcc310
mcc310-mnc004
mcc208-mnc00
etc.

O código de dispositivos móveis do país (MCC), opcionalmente seguido do código de rede móvel (MNC) do chip no dispositivo. Por exemplo, mcc310 é dos EUA em qualquer operadora, mcc310-mnc004 é dos EUA na Verizon e mcc208-mnc00 é da França na Orange.

Se o dispositivo usar uma conexão de rádio (telefone GSM), os valores MCC e MNC serão os do chip.

Você também pode usar somente o MCC (por exemplo, para incluir recursos legais específicos do país no aplicativo). Caso precise especificar com base somente no idioma, use o qualificador de idioma e região (discutido a seguir). Caso decida usar o qualificador de MCC e MNC, tome cuidado e teste o funcionamento.

Veja também os campos de configuração mcc e mnc, que indicam o código de dispositivos móveis do país atual e o código de rede móvel, respectivamente.

Idioma e região Exemplos:
en
fr
en-rUS
fr-rFR
fr-rCA
b+en
b+en+US
b+es+419

O idioma é definido por um código de idioma ISO 639-1 de duas letras, opcionalmente seguido por um código da região ISO 3166-1-alpha-2 (precedido de r em minúsculo).

Os códigos não diferenciam maiúsculas e minúsculas. O prefixo r é usado para distinguir a parte da região. Não é possível especificar uma região só.

O Android 7.0 (API de nível 24) introduziu suporte a tags de idioma BCP 47, que podem ser usadas para qualificar recursos específicos de idioma e região. As tags de idiomas são compostas pela sequência de uma ou mais subtags, sendo que cada uma delas refina ou estreita o intervalo do idioma identificado pela tag geral. Para mais informações sobre tags de idioma, consulte Tags para identificar idiomas.

Para usar uma tag de idioma BCP 47, concatene b+ e um código de idioma de duas letras ISO 639-1, opcionalmente seguido de subtags separadas por +.

A tag de idioma pode passar por alterações durante a vida útil do seu aplicativo, caso os usuários mudem o idioma nas configurações do sistema. Consulte Processamento de alterações em ambiente de execução para ter informações sobre como isso pode afetar o aplicativo no ambiente de execução.

Consulte Localização para ter acesso a um guia completo para localizar os aplicativos para outros idiomas.

Veja também o método getLocales(), que fornece a lista definida de localidades. Essa lista inclui a localidade primária.

Direção do layout ldrtl
ldltr

A direção do layout do aplicativo. ldrtl significa “layout-direction-right-to-left” (direção do layout da direita para a esquerda). ldltr significa “layout-direction-left-to-right” (direção do layout da esquerda para a direita) e é o valor implícito padrão.

Isso pode se aplicar a qualquer recurso, como layouts, drawables ou valores.

Por exemplo, caso queira fornecer um layout específico para o idioma árabe e layouts genéricos para outros idiomas que seguem a leitura da direita para a esquerda, como os idiomas hebraico e persa, você teria:

res/
    layout/
        main.xml (Default layout)
    layout-ar/
        main.xml (Specific layout for Arabic)
    layout-ldrtl/
        main.xml (Any "right-to-left" language, except
                  for Arabic, because the "ar" language qualifier
                  has a higher precedence.)

Observação: para ativar recursos de layout de leitura da direita para a esquerda para o aplicativo, você precisa definir supportsRtl como "true" e targetSdkVersion como 17 ou maior.

Adicionado na API de nível 17.

smallestWidth sw<N>dp

Exemplos:
sw320dp
sw600dp
sw720dp
etc.

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 ao 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 de o lado de 600 dp ser a altura ou a largura percebida pelo usuário. A menor largura é um tamanho de tela fixo característico do dispositivo. A menor largura do dispositivo não muda quando a orientação da tela é alterada.

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 para celulares 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.

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, porque são pixels de tela não disponíveis para a IU.

Alguns dos valores que você pode usar para tamanhos de tela comuns:

  • 320, para dispositivos com configurações de tela como:
    • 240 x 320 ldpi (celular QVGA)
    • 320 x 480 mdpi (celular)
    • 480 x 800 hdpi (celular de alta densidade)
  • 480, para telas como 480 x 800 mdpi (tablet/celular).
  • 600, para telas como 600 x 1024 mdpi (tablet de 7 polegadas).
  • 720, para telas como 720 x 1280 mdpi (tablet de 10 polegadas).

Quando o aplicativo fornece vários diretórios de recursos com valores diferentes para o qualificador smallestWidth, o sistema usa o mais próximo (sem exceder) ao de smallestWidth do dispositivo.

Adicionado na API de nível 13.

Veja também o atributo android:requiresSmallestWidthDp, que declara a smallestWidth mínima compatível com o aplicativo, e o campo de configuração smallestScreenWidthDp, que retém o valor de smallestWidth do dispositivo.

Para ter mais informações sobre como projetar para telas diferentes e usar esse qualificador, consulte o guia do desenvolvedor Compatibilidade com várias telas.

Largura disponível w<N>dp

Exemplos:
w720dp
w1024dp
etc.

Especifica uma largura mínima disponível da tela, em unidades dp em que o recurso deve ser usado — definida pelo valor <N>. Esse valor de configuração mudará quando a orientação alternar entre paisagem e retrato para corresponder à largura atual.

Isso é frequentemente útil para determinar o uso de um layout de vários painéis, porque, 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.

Quando o aplicativo fornece vários diretórios de recursos com valores diferentes para essa configuração, o sistema usa o mais próximo (sem exceder) ao da largura de tela atual do dispositivo. O valor aqui considera as decorações da tela. Portanto, se o dispositivo tiver alguns elementos de IU persistentes na borda esquerda ou direita da tela, ele usará um valor para a largura menor do que o tamanho atual da tela, considerando esses elementos de IU e reduzindo o espaço disponível para o aplicativo.

Adicionado na API de nível 13.

Veja também o campo de configuração screenWidthDp, que tem a largura atual da tela.

Para ter mais informações sobre como projetar para telas diferentes e usar esse qualificador, consulte o guia do desenvolvedor Compatibilidade com várias telas.

Altura disponível h<N>dp

Exemplos:
h720dp
h1024dp
etc.

Especifica uma altura mínima disponível da tela, em unidades “dp”, em que o recurso deve ser usado — definida pelo valor <N>. Esse valor de configuração mudará quando a orientação alternar entre paisagem e retrato para corresponder à altura atual.

O uso dessa característica para definir a altura exigida pelo layout é útil da mesma forma que w<N>dp é útil para definir a largura exigida, em vez de usar os qualificadores de tamanho e orientação da tela. No entanto, a maioria dos aplicativos não precisa desse qualificador, considerando que as IUs muitas vezes rolam verticalmente e, portanto, são mais flexíveis com relação à disponibilidade de altura e mais exigentes com relação à largura.

Quando o aplicativo fornece vários diretórios de recursos com valores diferentes para essa configuração, o sistema usa o mais próximo (sem exceder) ao da altura de tela atual do dispositivo. O valor aqui considera as decorações da tela. Portanto, se o dispositivo tiver alguns elementos de IU persistentes na borda superior ou inferior da tela, ele usará um valor para a altura menor do que o tamanho atual da tela, considerando esses elementos de IU e reduzindo o espaço disponível para o aplicativo. As decorações da tela que não forem fixas (como uma barra de status do telefone que pode ser ocultada com tela cheia) não serão consideradas aqui, assim como as decorações da janela, como a barra de título ou a barra de ação. Portanto, os aplicativos devem ser preparados para lidar com o espaço um pouco menor do que especificam.

Adicionado na API de nível 13.

Veja também o campo de configuração screenHeightDp, que tem a largura atual da tela.

Para ter mais informações sobre como projetar para telas diferentes e usar esse qualificador, consulte o guia do desenvolvedor Compatibilidade com várias telas.

Tamanho da tela small
normal
large
xlarge
  • small: telas de tamanho semelhante à tela de baixa densidade QVGA. O tamanho mínimo do layout para uma tela pequena é de aproximadamente 320 x 426 unidades dp. Exemplos são QVGA de baixa densidade e VGA de alta densidade.
  • normal: telas de tamanho semelhante à tela de média densidade HVGA. O tamanho mínimo do layout para uma tela normal é de aproximadamente 320 x 470 unidades dp. Exemplos dessas telas são as WQVGA de baixa densidade, HVGA de média densidade e WVGA de alta densidade.
  • large: telas de tamanho semelhante à tela de média densidade VGA. O tamanho mínimo do layout para uma tela grande é de aproximadamente 480 x 640 unidades dp. Exemplos são as telas de densidade média VGA e WVGA.
  • xlarge: telas que são consideravelmente maiores do que a tela tradicional de média densidade HVGA. O tamanho mínimo do layout para uma tela muito grande é de aproximadamente 720 x 960 unidades dp. Na maioria dos casos, dispositivos com telas muito grandes seriam grandes demais para serem carregados em bolsos e, provavelmente, seriam dispositivos no estilo tablet. Adicionado na API de nível 9.

Observação: usar um qualificador de tamanho não significa que os recursos sejam somente para telas desse tamanho. Caso não forneça recursos alternativos com qualificadores que melhor correspondem à configuração atual do dispositivo, o sistema poderá usar quaisquer recursos que representarem a melhor correspondência.

Atenção: se todos os recursos usarem um qualificador de tamanho maior do que a tela atual, o sistema não os usará e o aplicativo apresentará um erro no ambiente de execução (por exemplo, se todos os recursos de layout receberem tag com o qualificador xlarge, mas o dispositivo tiver uma tela de tamanho normal).

Adicionado na API de nível 4.

Consulte Compatibilidade com várias telas para ter mais informações.

Consulte também o campo de configuração screenLayout, que indica se a tela é pequena, normal ou grande.

Aspecto da tela long
notlong
  • long: telas grandes, como WQVGA, WVGA, FWVGA
  • notlong: telas que não são grandes, como QVGA, HVGA e VGA

Adicionado à API de nível 4.

Isso se baseia puramente na relação de aspecto da tela (uma tela “grande” é mais larga). Não tem relação com a orientação da tela.

Consulte também o campo de configuração screenLayout, que indica se a tela é grande.

Tela redonda round
notround
  • round: Telas redondas, como em dispositivo vestíveis redondos
  • notround: Telas retangulares, como celulares ou tablets

Adicionado na API de nível 23.

Consulte também o método de configuração isScreenRound(), que indica se a tela é redonda.

Gama ampla de cores widecg
nowidecg
  • {@code widecg}: telas com uma gama ampla de cores, como Display P3 ou AdobeRGB
  • {@code nowidecg}: telas com uma gama estreita de cores, como sRGB

Adicionado na API de nível 26.

Consulte também o método de configuração isScreenWideColorGamut(), que indica se a tela tem uma gama ampla de cores.

Alto Alcance Dinâmico (HDR) highdr
lowdr
  • {@code highdr}: telas com alto alcance dinâmico
  • {@code lowdr}: telas com alcance dinâmico baixo ou padrão

Adicionado na API de nível 26.

Consulte também o método de configuração isScreenHdr(), que indica se a tela tem recursos HDR.

Orientação da tela port
land
  • port: o dispositivo está na orientação de retrato (vertical).
  • land: o dispositivo está na orientação de paisagem (horizontal).

Isso pode mudar durante a vida útil do aplicativo se o usuário girar a tela. Consulte Processamento de alterações no ambiente de execução para ter informações sobre como isso pode afetar o aplicativo no ambiente de execução.

Veja também o campo de configuração orientation, que indica a orientação atual do dispositivo.

Modo de IU car
desk
television
appliance
watch
vrheadset
  • car: O dispositivo está exibindo em uma dock do carro
  • desk: o dispositivo está exibindo em uma dock de mesa.
  • television: o dispositivo está exibindo em uma televisão, fornecendo uma experiência à distância, onde a IU é em tela grande, o usuário está longe, orientado principalmente por um controle direcional ou por outro tipo de interação sem indicador.
  • appliance: o dispositivo está servindo como uma aplicação, sem tela.
  • watch: o dispositivo tem uma tela que é usada no braço.
  • vrheadset: o dispositivo está exibindo em um fone de ouvido de realidade virtual.

Adicionado na API de nível 8, televisão adicionada na API de nível 13 e relógio adicionado na API de nível 20.

Para ter informações sobre como o aplicativo pode responder quando o dispositivo é inserido ou removido de uma dock, consulte Determinação e monitoramento do tipo e do estado da dock.

Isso pode mudar durante a vida útil do aplicativo se o usuário colocar o dispositivo em uma dock. É possível ativar ou desativar alguns desses modos usando UiModeManager. Consulte Processamento de alterações no ambiente de execução para ter informações sobre como isso pode afetar o aplicativo no ambiente de execução.

Modo noturno night
notnight
  • night: noite
  • notnight: dia

Adicionado na API de nível 8.

Isso pode mudar durante a vida útil do aplicativo se o modo noturno for deixado no modo automático (padrão), em que o modo se altera com base no horário. É possível ativar ou desativar esse modo usando UiModeManager. Consulte Processamento de alterações no ambiente de execução para ter informações sobre como isso pode afetar o aplicativo no ambiente de execução.

Densidade de pixel da tela (dpi) ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi
anydpi
nnndpi
  • ldpi: são telas de baixa densidade, com aproximadamente 120 dpi.
  • mdpi: são telas de média densidade (em HVGA tradicional), com aproximadamente 160 dpi.
  • hdpi: são telas de alta densidade, com aproximadamente 240 dpi.
  • xhdpi: são telas de densidade extra-alta, com aproximadamente 320 dpi. Adicionado na API de nível 8
  • xxhdpi: são telas de densidade extra-extra-alta, com aproximadamente 480 dpi. Adicionado na API de nível 16
  • xxxhdpi: são usos de densidade extra-extra-extra-alta (somente ícone na tela de início, consulte a observação em Compatibilidade com várias telas), com aproximadamente 640 dpi. Adicionado na API de nível 18
  • nodpi: isso pode ser usado para recursos de bitmap que você não quer dimensionar para corresponder à densidade do dispositivo.
  • tvdpi: são telas entre mdpi e hdpi, com aproximadamente 213 dpi. Não é considerado um grupo de densidade “primário”. Ele é destinado principalmente para televisões e a maioria dos aplicativos não precisará dele — fornecer recursos mdpi e hdpi é suficiente para a maioria dos aplicativos e o sistema os dimensionará conforme for apropriado. Adicionado na API de nível 13
  • anydpi: esse qualificador corresponde a todas as densidades de tela e é priorizado em relação a outros qualificadores. Isso é útil para drawables vetoriais. Adicionado na API de nível 21
  • nnndpi: é usado para representar densidades que não são padrão, em que nnn é uma densidade de tela de número inteiro positivo. Não deve ser usado na maioria do casos. Use intervalos de densidade padrão, que reduzem bastante a sobrecarga de ser compatível com várias densidades de telas de dispositivos no mercado.

Há uma razão de escalonamento de 3:4:6:8:12:16 entre as seis densidades principais (ignorando a densidade tvdpi). Então, um bitmap de 9 x 9 em ldpi é 12 x 12 em mdpi, 18 x 18 em hdpi, 24 x 24 em xhdpi e assim por diante.

Caso decida que os recursos de imagem não parecem suficientemente bons para uma televisão ou outros dispositivos e queira testar recursos tvdpi, o fator de dimensionamento é 1,33*mdpi. Por exemplo, uma imagem de 100 x 100 pixels para telas mdpi precisa ter 133 x 133 pixels para tvdpi.

Observação: usar um qualificador de densidade não significa que os recursos sejam somente para telas desta densidade. Caso não forneça recursos alternativos com qualificadores que melhor correspondem à configuração atual do dispositivo, o sistema poderá usar quaisquer recursos que representarem a melhor correspondência.

Consulte Compatibilidade com várias telas para ter mais informações sobre como lidar com as diferentes densidades de tela e como o Android pode dimensionar os bitmaps para encaixá-los na densidade atual.

Tipo de touchscreen notouch
finger
  • notouch: o dispositivo não tem touchscreen.
  • finger: o dispositivo tem um touchscreen que se destina à interação direcional do dedo do usuário.

Veja também o campo de configuração touchscreen, que indica o tipo de touchscreen no dispositivo.

Disponibilidade de teclado keysexposed
keyshidden
keyssoft
  • keysexposed: o dispositivo tem um teclado disponível. Se o dispositivo tiver um teclado de software ativo (o que é provável), ele deverá ser usado mesmo quando o teclado de hardware não estiver exposto ao usuário, mesmo se o dispositivo não tiver teclado de hardware. Caso nenhum teclado de software seja fornecido ou ele esteja desativado, isso será usado somente quando um teclado de hardware for exposto.
  • keyshidden: o dispositivo tem um teclado de hardware disponível, mas está oculto e o dispositivo não tem um teclado de software ativo.
  • keyssoft: o dispositivo tem um teclado de software ativo, visível ou não.

Se você fornecer os recursos keysexposed, mas não os recursos keyssoft, o sistema usará os recursos keysexposed independentemente da visibilidade do teclado, contanto que o sistema tenha um teclado de software ativo.

Isso pode mudar durante a vida útil do aplicativo se o usuário abrir um teclado de hardware. Consulte Processamento de alterações no ambiente de execução para ter informações sobre como isso pode afetar o aplicativo no ambiente de execução.

Veja também os campos de configuração hardKeyboardHidden e keyboardHidden, que indicam a visibilidade de um teclado de hardware e a visibilidade de qualquer tipo de teclado (inclusive de software), respectivamente.

Método principal de entrada de texto nokeys
qwerty
12key
  • nokeys: o dispositivo não tem teclas de hardware para entradas de texto.
  • qwerty: o dispositivo tem um teclado QWERTY de hardware, esteja ele visível ao usuário ou não.
  • 12key: o dispositivo tem um teclado de hardware de 12 teclas, esteja ele visível ao usuário ou não.

Veja também o campo de configuração keyboard, que indica o método de entrada de texto principal disponível.

Versão da plataforma (nível de API) Exemplos:
v3
v4
v7
etc.

O nível de API compatível com o dispositivo. Por exemplo, v1 para a API de nível 1 (dispositivos com Android 1.0 ou mais recente) e v4 para API de nível 4 (dispositivos com Android 1.6 ou mais recente). Veja o documento Níveis de API do Android para ter mais informações sobre esses valores.

Observação: alguns qualificadores de configuração foram adicionados desde o Android 1.0, então nem todas as versões do Android são compatíveis com todos eles. Usar um novo qualificador adiciona implicitamente um qualificador da versão de plataforma, então dispositivos mais antigos com certeza o ignorarão. Por exemplo, usar um qualificador w600dp incluirá automaticamente o qualificador v13, porque o qualificador de largura disponível era novo na API de nível 13. Para evitar quaisquer problemas, sempre inclua um conjunto de recursos padrão (um conjunto de recursos sem qualificadores). Para ter mais informações, consulte a seção Fornecimento da melhor compatibilidade de dispositivo com recursos.

Regras de nome do qualificador

Eis algumas regras sobre como usar nomes de qualificador de configuração:

  • É possível especificar vários qualificadores para um único conjunto de recursos, separados por traços. Por exemplo, drawable-en-rUS-land aplica-se aos dispositivos em inglês dos EUA na orientação de paisagem.
  • Os qualificadores precisam estar na ordem listada na tabela 2. Por exemplo:
    • Incorreto: drawable-hdpi-port/
    • Correto: drawable-port-hdpi/
  • Os diretórios de recursos alternativos não podem ser aninhados. Por exemplo, não é possível ter res/drawable/drawable-en/.
  • Os valores não diferenciam letras maiúsculas e minúsculas. O compilador de recursos converte nomes de diretório para letras minúsculas antes de processar para evitar problemas nos sistemas de arquivo que não diferenciam maiúsculas e minúsculas. Qualquer letra maiúscula nos nomes é só para o benefício da leitura.
  • Somente um valor para cada tipo de qualificador é suportado. Por exemplo, se você quiser usar os mesmos arquivos drawables para Espanha e França, não será possível ter um diretório chamado drawable-rES-rFR/. Em vez disso, você precisará de dois diretórios de recursos, como drawable-rES/ e drawable-rFR/, que contêm os arquivos adequados. No entanto, não é obrigatório duplicar os mesmos arquivos em ambos os locais. Em vez disso, é possível criar um alias para um recurso. Consulte Criação de recursos de alias abaixo.

Após salvar os recursos alternativos nos diretórios nomeados com esses qualificadores, o Android aplicará automaticamente os recursos no aplicativo com base na configuração atual do dispositivo. Sempre que um recurso for solicitado, o Android verificará diretórios de recursos alternativos que contenham o arquivo de recurso solicitado e, em seguida, encontrará o melhor recurso correspondente (discutido abaixo). Se não houver recursos alternativos que correspondam a uma configuração de dispositivo específica, o Android usará os recursos padrão correspondentes (o conjunto de recursos para um tipo de recurso específico que não inclua um qualificador de configuração).

Criação de recursos de alias

Quando estiver com um recurso que gostaria de usar para mais de uma configuração de dispositivo, mas não quiser fornecê-lo como um recurso padrão, não será necessário usar o mesmo recurso em mais de um diretório de recursos alternativos. Em vez disso, é possível (em alguns casos) criar um recurso alternativo que age como um alias para um recurso salvo no diretório de recurso padrão.

Observação: nem todos os recursos oferecem um mecanismo que possibilita criar um alias para outro recurso. Em particular, recursos de animação, de menu, brutos e de outros tipos no diretório xml/ não oferecem essa função.

Por exemplo: você tem um ícone do aplicativo, icon.png, e precisa da versão exclusiva para diferentes localidades. No entanto, duas localidades, inglês canadense e francês canadense, precisam usar a mesma versão. Você pode presumir que precisa copiar a mesma imagem para o diretório do recurso do inglês canadense e do francês canadense, mas não é verdade. Em vez disso, é possível salvar a imagem que é usada para ambos como icon_ca.png (qualquer nome que não seja icon.png) e colocá-la no diretório res/drawable/ padrão. Em seguida, crie um arquivo icon.xml em res/drawable-en-rCA/ e em res/drawable-fr-rCA/ que referencie o recurso icon_ca.png usando o elemento <bitmap>. Isso permite que você armazene somente uma versão do arquivo PNG e dois arquivos XML pequenos que apontam para ele. Um exemplo de arquivo XML é exibido abaixo.

Drawable

Para criar um alias para um drawable existente, use o elemento <drawable>. Por exemplo:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <drawable name="icon">@drawable/icon_ca</drawable>
</resources>

Se salvar esse arquivo como drawables.xml (em um diretório de recursos alternativos, como res/values-en-rCA/), ele será compilado em um recurso que pode ser referenciado como R.drawable.icon, mas é um alias do recurso R.drawable.icon_ca, salvo em res/drawable/.

Layout

Para criar um alias para um layout existente, use o elemento <include>, agrupado em um <merge>. Por exemplo:

<?xml version="1.0" encoding="utf-8"?>
<merge>
    <include layout="@layout/main_ltr"/>
</merge>

Se salvar esse arquivo como main.xml, ele será compilado em um recurso que pode ser referenciado como R.layout.main, mas é um alias do recurso R.layout.main_ltr.

Strings e outros valores simples

Para criar um alias para uma string existente, basta usar o código de recurso da string desejado como o valor para a nova string. Por exemplo:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="hello">Hello</string>
    <string name="hi">@string/hello</string>
</resources>

O recurso R.string.hi é agora um alias de R.string.hello.

Outros valores simples funcionam da mesma forma. Por exemplo, uma cor:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="red">#f00</color>
    <color name="highlight">@color/red</color>
</resources>

Acesso aos recursos do aplicativo

Depois de fornecer um recurso no aplicativo, é possível aplicá-lo referenciando o código do recurso. Todos os códigos de recursos são definidos na classe R do projeto que a ferramenta aapt gera automaticamente.

Quando o aplicativo é compilado, aapt gera a classe R, que contém códigos de recursos para todos os recursos no diretório res/. Para cada tipo de recurso, há uma subclasse R (por exemplo, R.drawable para todos os recursos drawable) e, para cada recurso daquele tipo, há um número inteiro estático (por exemplo, R.drawable.icon). Esse número inteiro é o código do recurso que pode ser usado para recuperá-lo.

Apesar de a classe R ser o local onde os códigos de recursos são especificados, não será necessário verificá-la para descobrir um código de recurso. Ele é sempre composto do seguinte:

  • O tipo de recurso: Cada recurso é agrupado em um "tipo", como string, drawable e layout. Para saber mais sobre os diferentes tipos, consulte Tipos de recursos.
  • O nome do recurso, que é o nome do arquivo, excluindo a extensão ou o valor no atributo android:name do XML, se o recurso for um valor simples (como uma string).

Há duas formas de acessar um recurso:

  • No código: usando um número inteiro estático de uma subclasse de sua classe R, como:
    R.string.hello

    string é o tipo de recurso e hello é o nome do recurso. Há muitas APIs do Android que podem acessar seus recursos quando você fornece um código de recurso nesse formato. Consulte Acesso aos recursos no código.

  • No XML: usando uma sintaxe XML especial que também corresponde ao código de recurso definido em sua classe R, como:
    @string/hello

    string é o tipo de recurso e hello é o nome do recurso. Você pode usar essa sintaxe em um recurso XML em qualquer lugar em que um valor é esperado e que seja fornecido em um recurso. Consulte Acesso aos recursos do XML.

Acesso aos recursos no código

Você pode usar um recurso no código passando o código do recurso como parâmetro do método. Por exemplo, é possível definir uma ImageView para usar o recurso res/drawable/myimage.png usando setImageResource():

Kotlin

val imageView = findViewById(R.id.myimageview) as ImageView
imageView.setImageResource(R.drawable.myimage)

Java

ImageView imageView = (ImageView) findViewById(R.id.myimageview);
imageView.setImageResource(R.drawable.myimage);

Também é possível recuperar recursos individuais usando métodos em Resources, de que é possível ter uma instância com getResources().

Sintaxe

Esta é a sintaxe para referenciar um recurso no código:

[<package_name>.]R.<resource_type>.<resource_name>
  • <package_name> é o nome do pacote em que o recurso está localizado (não é obrigatório ao referenciar recursos de seu pacote).
  • <resource_type> é a subclasse R do tipo de recurso.
  • <resource_name> é o nome do arquivo do recurso sem a extensão ou o valor do atributo android:name no elemento XML (para valores simples).

Consulte Tipos de recursos para ter mais informações sobre cada tipo de recurso e como referenciá-los.

Casos de uso

Há muitos métodos que aceitam um parâmetro de código de recurso e você pode recuperar recursos usando métodos em Resources. É possível ter uma instância de Resources com Context.getResources().

Abaixo há alguns exemplos do acesso aos recursos no código:

Kotlin

// Load a background for the current screen from a drawable resource
window.setBackgroundDrawableResource(R.drawable.my_background_image)

// Set the Activity title by getting a string from the Resources object, because
//  this method requires a CharSequence rather than a resource ID
window.setTitle(resources.getText(R.string.main_title))

// Load a custom layout for the current screen
setContentView(R.layout.main_screen)

// Set a slide in animation by getting an Animation from the Resources object
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
        R.anim.hyperspace_in))

// Set the text on a TextView object using a resource ID
val msgTextView = findViewById(R.id.msg) as TextView
msgTextView.setText(R.string.hello_message)

Java

// Load a background for the current screen from a drawable resource
getWindow().setBackgroundDrawableResource(R.drawable.my_background_image) ;

// Set the Activity title by getting a string from the Resources object, because
//  this method requires a CharSequence rather than a resource ID
getWindow().setTitle(getResources().getText(R.string.main_title));

// Load a custom layout for the current screen
setContentView(R.layout.main_screen);

// Set a slide in animation by getting an Animation from the Resources object
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
        R.anim.hyperspace_in));

// Set the text on a TextView object using a resource ID
TextView msgTextView = (TextView) findViewById(R.id.msg);
msgTextView.setText(R.string.hello_message);

Atenção: nunca modifique o arquivo R.java manualmente — ele é gerado pela ferramenta aapt quando o projeto é compilado. As alterações serão modificadas na próxima compilação.

Acesso aos recursos do XML

Você pode definir valores para alguns atributos e elementos XML usando uma referência a um recurso existente. Isso será feito com frequência ao criar arquivos de layout para fornecer strings e imagens para os widgets.

Por exemplo, se você adicionar um Button ao layout, use um recurso de string para o texto do botão:

<Button
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="@string/submit" />

Sintaxe

Esta é a sintaxe para referenciar um recurso em um recurso XML:

@[<package_name>:]<resource_type>/<resource_name>
  • <package_name> é o nome do pacote em que o recurso está localizado (não é obrigatório ao referenciar recursos do mesmo pacote).
  • <resource_type> é a subclasse R do tipo de recurso.
  • <resource_name> é o nome do arquivo do recurso sem a extensão ou o valor do atributo android:name no elemento XML (para valores simples).

Consulte Tipos de recursos para ter mais informações sobre cada tipo de recurso e como referenciá-los.

Casos de uso

Em alguns casos, é preciso usar um recurso para um valor em XML (por exemplo, para aplicar uma imagem drawable a um widget), mas você também pode usar um recurso em XML em qualquer lugar que aceite um valor simples. Por exemplo, se você tiver o seguinte arquivo de recursos que inclui um recurso de cor e um recurso de string:

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <color name="opaque_red">#f00</color>
   <string name="hello">Hello!</string>
</resources>

É possível usar esses recursos no arquivo de layout a seguir para definir a cor e a string do texto:

<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:textColor="@color/opaque_red"
    android:text="@string/hello" />

Nesse caso, não é preciso especificar o nome do pacote na referência do recurso porque os recursos são do seu pacote. Para referenciar um recurso do sistema, é preciso incluir o nome do pacote. Por exemplo:

<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:textColor="@android:color/secondary_text_dark"
    android:text="@string/hello" />

Observação: use recursos de string o tempo inteiro para que seu aplicativo possa ser localizado para outros idiomas. Para ter informações sobre a criação de recursos alternativos (como strings localizadas), consulte Fornecimento de recursos alternativos. Para ter acesso a um guia completo para localizar o aplicativo para outros idiomas, consulte Localização.

Você pode até mesmo usar recursos em XML para criar alias. Por exemplo, é possível criar um recurso drawable que seja um alias para outro recurso drawable:

<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/other_drawable" />

Isso parece redundante, mas pode ser muito útil ao usar um recurso alternativo. Leia mais sobre Criação de recursos de alias.

Referência a atributos de estilo

Um recurso de atributo de estilo permite referenciar o valor de um atributo no tema atualmente aplicado. Referenciar um atributo de estilo permite personalizar a aparência de elementos da IU deixando-os com estilo que corresponda a variações padrão fornecidas pelo tema atual, em vez de fornecer um valor codificado. Referenciar um atributo de estilo essencialmente significa “usar o estilo que é definido por esse atributo no tema atual”.

Para referenciar um atributo de estilo, a sintaxe do nome é quase idêntica ao formato normal de recurso, mas, em vez do símbolo arroba (@), use um ponto de interrogação (?). Além disso, a parte do tipo de recurso é opcional. Por exemplo:

?[<package_name>:][<resource_type>/]<resource_name>

Por exemplo, veja como você pode referenciar um atributo para definir a cor do texto para que corresponda à cor “principal” do texto do tema do sistema:

<EditText id="text"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:textColor="?android:textColorSecondary"
    android:text="@string/hello_world" />

Aqui o atributo android:textColor especifica o nome de um atributo de estilo no tema atual. O Android agora usa o valor aplicado ao atributo de estilo android:textColorSecondary como o valor para android:textColor nesse widget. Como a ferramenta de recursos do sistema sabe que um recurso de atributo é esperado nesse contexto, não é preciso declarar explicitamente o tipo (que seria ?android:attr/textColorSecondary) — você pode excluir o tipo de attr.

Acesso aos arquivos originais

Apesar de ser incomum, pode ser necessário acessar os arquivos e os diretórios originais. Nesse caso, salvar os arquivos em res/ não funcionará, porque a única forma de ler um recurso de res/ é com o código do recurso. Em vez disso, você pode salvar os recursos no diretório assets/.

Arquivos salvos no diretório assets/ não recebem nenhum código de recurso, portanto, não é possível referenciá-los com a classe R nem de recursos XML. Em vez disso, é possível consultar arquivos no diretório assets/ como um sistema de arquivos normal e ler dados brutos usando o AssetManager.

No entanto, se você só precisar da capacidade de ler dados brutos (como um arquivo de vídeo ou áudio), salve o arquivo no diretório res/raw/ e leia um stream de bytes usando openRawResource().

Acesso aos recursos da plataforma

O Android contém uma série de recursos padrão, como estilos, temas e layouts. Para acessá-los, qualifique a referência de recurso com o nome do pacote android. Por exemplo, o Android fornece um recurso de layout que pode ser usado para listar itens em um ListAdapter:

Kotlin

listAdapter = ArrayAdapter(this, android.R.layout.simple_list_item_1, myarray)

Java

setListAdapter(new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, myarray));

Nesse exemplo, simple_list_item_1 é um recurso de layout definido pela plataforma para itens em uma ListView. Você pode usá-lo em vez de criar o próprio layout para itens de lista.

Fornecimento da melhor compatibilidade de dispositivo com recursos

Para o aplicativo suportar várias configurações de dispositivo, é muito importante que você sempre forneça recursos padrão para cada tipo de recurso que o aplicativo usar.

Por exemplo: se o aplicativo for compatível com vários idiomas, sempre inclua um diretório values/ (em que as strings sejam salvas) sem qualificadores de região e idioma. Se colocar todos os arquivos de string em diretórios que têm qualificadores de região e idioma, o aplicativo apresentará erros ao entrar em execução em dispositivo configurado para um idioma que as strings não suportem. Porém, contanto que você forneça recursos values/ padrão, o aplicativo será executado sem problemas (mesmo que o usuário não entenda o idioma — é melhor do que apresentar erros).

Do mesmo modo, se você fornecer recursos de layout diferentes com base na orientação da tela, escolha uma orientação como a padrão. Por exemplo: em vez de fornecer recursos de layout em layout-land/ para paisagem e layout-port/ para retrato, deixe uma como padrão, como layout/ para paisagem e layout-port/ para retrato.

Fornecer recursos padrão é importante não só porque o aplicativo pode ser executado em uma configuração que você não tenha antecipado, mas também porque as novas versões do Android, às vezes, adicionam qualificadores de configuração que as versões mais antigas não suportam. Se usar um novo qualificador de recurso, mas mantiver a compatibilidade do código com versões mais antigas do Android, quando uma versão mais antiga do Android executar seu aplicativo, ocorrerá um erro caso você não forneça os recursos padrão, porque ele não poderá usar os recursos nomeados com o novo qualificador. Por exemplo: se minSdkVersion estiver definido como 4 e você qualificar todos os recursos drawable usando o modo noturno (night ou notnight, que foram adicionados à API de nível 8), o dispositivo com API de nível 4 não poderá acessar os recursos drawable e apresentará falha. Neste caso, você provavelmente precisará que notnight seja o recurso padrão. Portanto, exclua esse qualificador para que os recursos drawable fiquem em drawable/ ou drawable-night/.

Então, para fornecer a melhor compatibilidade de dispositivo, sempre forneça os recursos padrão para os recursos imprescindíveis para o aplicativo para ter o desempenho adequado. Em seguida, crie recursos para configurações específicas de dispositivo usando os qualificadores de configuração.

Há uma exceção a essa regra: se a minSdkVersion do aplicativo for 4 ou mais recente, você não precisará de recursos drawable padrão ao fornecer recursos drawable alternativos com o qualificador de densidade da tela. Mesmo sem os recursos drawable padrão, o Android poderá encontrar a melhor correspondência entre as densidades de tela alternativas e dimensionar os bitmaps conforme necessário. No entanto, para ter a melhor experiência em todos os tipos de dispositivo, forneça drawables alternativos para todos os três tipos de densidade.

Como o Android encontra o melhor recurso correspondente

Ao solicitar um recurso a que você fornece alternativas, o Android seleciona quais recursos alternativos usar no ambiente de execução, dependendo da configuração atual do dispositivo. Para demonstrar como o Android seleciona um recurso alternativo, presuma que os seguintes diretórios drawable contenham versões diferentes das mesmas imagens:

drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/

E presuma que a configuração do dispositivo seja a seguinte:

Localidade = en-GB
Orientação da tela = port
Densidade de pixel da tela = hdpi
Tela tátil ao toque = notouch
Método principal de entrada de texto = 12key

Ao comparar a configuração do dispositivo com os recursos alternativos disponíveis, o Android seleciona drawables de drawable-en-port.

O sistema chega à conclusão de que recursos usar com a seguinte lógica:

Figura 2. Fluxograma de como o Android encontra o melhor recurso correspondente.

  1. Elimine os arquivos de recurso que contradizem a configuração do dispositivo.

    O diretório drawable-fr-rCA/ é eliminado, porque contradiz a localidade en-GB.

    drawable/
    drawable-en/
    drawable-fr-rCA/
    drawable-en-port/
    drawable-en-notouch-12key/
    drawable-port-ldpi/
    drawable-port-notouch-12key/
    

    Exceção: a densidade de pixel da tela é a que o qualificador não eliminou devido a uma contradição. Apesar de a densidade da tela do dispositivo ser hdpi, drawable-port-ldpi/ não é eliminado, porque todas as densidades de telas são consideradas uma correspondência neste ponto. Saiba mais no documento Compatibilidade com várias telas.

  2. Escolha o (próximo) qualificador de maior precedência na lista (tabela 2). Comece com MCC e, em seguida, siga para baixo.
  3. Algum dos diretórios de recurso incluem este qualificador?
    • Se não, volte à etapa 2 e veja o próximo qualificador. Neste exemplo, a resposta é “não” até que o qualificador de idioma seja alcançado.
    • Se sim, prossiga para a etapa 4.
  4. Elimine os diretórios de recurso que não incluem esse qualificador. No exemplo, o sistema elimina todos os diretórios que não incluem um qualificador de idioma:
    drawable/
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    drawable-port-ldpi/
    drawable-port-notouch-12key/
    

    Exceção: se o qualificador em questão for a densidade de pixel da tela, o Android seleciona a opção mais próxima da densidade de tela do dispositivo. Geralmente, o Android prefere escalonar uma imagem original maior em vez de uma menor. Consulte Compatibilidade com várias telas.

  5. Volte e repita as etapas 2, 3 e 4 até que reste somente um diretório. No exemplo, a orientação da tela é o próximo qualificador, onde há várias correspondências. Portanto, os recursos que não especificarem uma orientação de tela serão eliminados:
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    

    O diretório restante é drawable-en-port.

Apesar de esse processo ser executado para cada recurso solicitado, o sistema posteriormente aprimora alguns aspectos. Esse tipo de otimização, quando a configuração do dispositivo é conhecida, pode eliminar os recursos alternativos que nunca correspondem. Por exemplo, se o idioma da configuração for inglês (“en”), qualquer diretório de recurso que tiver um qualificador de idioma definido para outro idioma que não seja inglês nunca será incluído no conjunto de recursos verificados (apesar de um diretório de recursos sem o qualificador de idioma ainda ser incluído).

Ao selecionar os recursos com base nos qualificadores de tamanho da tela, o sistema usará os recursos projetados para uma tela menor do que a tela atual, caso não tenha recursos que correspondam de forma mais eficaz (por exemplo, uma tela de tamanho grande usará os recursos de tela de tamanho normal, 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 o aplicativo apresentará falha se nenhum outro recurso corresponder à configuração do dispositivo (por exemplo, se todos os recursos de layout estiverem com a tag do qualificador xlarge, mas o dispositivo tiver uma tela de tamanho normal).

Observação: a precedência do qualificador (na tabela 2) é mais importante do que o número de qualificadores que correspondem exatamente ao dispositivo. Por exemplo, na etapa 4 acima, a última escolha na lista inclui três qualificadores que correspondem exatamente ao dispositivo (orientação, tipo de touchscreen e método de entrada), enquanto drawable-en tem somente um parâmetro que corresponde (idioma). No entanto, o idioma tem uma precedência maior que esses outros qualificadores, então drawable-port-notouch-12key está fora.