Descripción general de los recursos de la app (vistas)

Conceptos y la implementación de Jetpack Compose

Los recursos son los archivos adicionales y el contenido estático que usa tu código, como mapas de bits, definiciones de diseño, strings de interfaz de usuario, instrucciones de animación, etc.

Siempre debes externalizar los recursos para apps, como imágenes y cadenas de tu código, para que puedas mantenerlos de forma independiente. Además, debes proporcionar recursos alternativos para configuraciones de dispositivos específicos agrupándolos en directorios de recursos con un nombre especial. En tiempo de ejecución, Android utiliza el recurso adecuado según la configuración actual. Por ejemplo, puedes proporcionar un diseño de la IU diferente según el tamaño de la pantalla o cadenas diferentes según la configuración de idioma.

Una vez que externalizas los recursos para tu app, puedes acceder a ellos con los IDs de recursos que se generan en la clase R de tu proyecto. En este documento, se muestra cómo agrupar los recursos en tu proyecto de Android. También se muestra cómo proporcionar recursos alternativos para configuraciones de dispositivos específicos y acceder a ellos desde el código de tu app u otros archivos en formato XML posteriormente.

Agrupa los recursos según su tipo

Coloca cada tipo de recurso en un subdirectorio específico del directorio res/ de tu proyecto. Por ejemplo, esta es la jerarquía de archivos de un proyecto simple:

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

El directorio res/ contiene todos los recursos en sus subdirectorios: un recurso de imagen, dos recursos de diseño, un directorio mipmap/ para los íconos de selector y un archivo de recursos de cadenas. Los nombres de los directorios de recursos son importantes y se describen en la tabla 1.

Tabla 1. Directorios de recursos admitidos dentro del directorio res/ del proyecto.

Directorio

Tipo de recurso

animator/

Archivos en formato XML que definen animaciones de propiedades.

anim/

Archivos en formato XML que definen animaciones de interpolación. En este directorio también se pueden guardar animaciones de propiedades, pero se prefiere incluir estas últimas en el directorio animator/ para distinguir entre los dos tipos.

color/

Archivos en formato XML que definen una lista de estados de colores. Para obtener más información, consulta el Recurso de lista de estados de color.

drawable/

Archivos de mapas de bits (PNG, .9.png, JPG o GIF) o archivos en formato XML que, al compilarse, generan los siguientes subtipos de recursos de elementos de diseño:

  • Archivos de mapas de bits
  • Archivos nine-patch (mapas de bits reajustables)
  • Listas de estados
  • Formas
  • Elementos de diseño de animaciones
  • Otros elementos de diseño

Para obtener más información, consulta Recursos de elementos de diseño.

mipmap/

Archivos de elementos de diseño para diferentes densidades de los íconos de selectores. Para obtener más información sobre la administración de los íconos de selector con carpetas mipmap/, consulta Cómo agregar íconos de apps en directorios mipmap.

layout/

Archivos en formato XML que definen el diseño de una interfaz de usuario. Para obtener más información, consulta Recurso de diseño.

menu/

Archivos en formato XML que definen menús de apps, como un menú de opciones, un menú contextual o un submenú. Para obtener más información, consulta la sección Recurso de menú.

raw/

Archivos arbitrarios para guardar sin procesar. Para abrir estos recursos con un objeto InputStream sin procesar, llama a Resources.openRawResource con el ID del recurso, que es R.raw.filename.

Sin embargo, si necesitas acceder a los nombres de archivo y jerarquía de archivos originales, puedes guardar los recursos en el directorio assets/ en lugar de res/raw/. A los archivos de assets/ no se les asigna un ID de recurso, por lo cual puedes leerlos solamente con AssetManager.

values/

Archivos en formato XML que contienen valores simples, como cadenas, valores enteros y colores.

Mientras que los archivos de recursos XML en otros subdirectorios res/ definen un solo recurso basado en el nombre del archivo XML, los archivos del directorio values/ describen varios recursos. En relación con los archivos de este directorio, cada componente secundario del elemento define un único recurso. Por ejemplo, un elemento crea un recurso R.string, y un elemento crea un recurso R.color.

Dado que cada recurso se define con su propio elemento XML, puedes asignar el nombre que desees al archivo y colocar diferentes tipos de recursos en un archivo. Sin embargo, para mayor claridad, es recomendable que coloques tipos de recursos únicos en diferentes archivos. Por ejemplo, a continuación, se incluyen algunas convenciones de asignación de nombres de archivos para los recursos que puedes crear en este directorio:

Para obtener más información, consulta Recursos de cadenas, Recursos de estilo y Más tipos de recursos.

xml/

Archivos XML arbitrarios que se pueden leer en el tiempo de ejecución llamando a Resources.getXML(). Aquí se deben guardar diversos archivos de configuración XML.

font/

Archivos de fuentes con extensiones como TTF, OTF o TTC, o archivos en formato XML que incluyen un elemento . Para obtener más información sobre las fuentes como recursos, consulta Cómo agregar una fuente como recurso XML.

Los recursos que guardes en los subdirectorios definidos en la tabla 1 son tus recursos predeterminados. Es decir, estos recursos definen el diseño y el contenido predeterminados de tu app. Sin embargo, es posible que los diferentes tipos de dispositivos con tecnología Android necesiten distintos tipos de recursos.

Por ejemplo, puedes proporcionar diferentes recursos de diseño para que los dispositivos que tienen pantallas más grandes de lo normal aprovechen el espacio adicional en la pantalla. También puedes proporcionar diferentes recursos de cadenas que traduzcan el texto en la interfaz de usuario según la configuración de idioma del dispositivo. Para proporcionar estos recursos diferentes a distintas configuraciones de dispositivos, debes proporcionar recursos alternativos, además de tus recursos predeterminados.

Cómo ofrecer recursos alternativos

Casi todas las apps proporcionan recursos alternativos para admitir configuraciones de dispositivos específicas. Por ejemplo, debes incluir recursos de elementos de diseño alternativos para diferentes densidades de pantallas y recursos de cadenas alternativos para diferentes idiomas. En el tiempo de ejecución, Android detecta la configuración del dispositivo actual y carga los recursos adecuados para tu app.

Figura 1: Dos dispositivos que usan diferentes recursos de diseño según el tamaño de la pantalla.

Si quieres especificar alternativas de configuraciones específicas para un conjunto de recursos, haz lo siguiente:

  1. Crea un directorio nuevo en res/ con el formato <resources_name>-<qualifier>.

    • <resources_name> es el nombre del directorio de los recursos predeterminados correspondientes (definidos en la tabla 1).
    • <qualifier> es un nombre que especifica una configuración individual para la cual se deben usar estos recursos (que se definen en la tabla 2).

    Puedes agregar más de un <qualifier>. Separa cada uno con un guion.

  2. Guarda los recursos alternativos correspondientes en este nuevo directorio. Los archivos de recursos deben llevar exactamente el mismo nombre que los archivos de recursos predeterminados.

Por ejemplo, estos son algunos recursos predeterminados y alternativos:

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

El calificador hdpi indica que los recursos de ese directorio son para dispositivos con pantalla de alta densidad. Las imágenes de estos directorios de elementos de diseño están dimensionadas para densidades de pantalla específicas, pero los nombres de archivo son exactamente iguales. De esta manera, el ID de recurso que usas para hacer referencia a la imagen icon.png o background.png es siempre el mismo. Android selecciona la versión de cada recurso que mejor se ajusta al dispositivo actual comparando la información de configuración del dispositivo con los calificadores del nombre del directorio de recursos.

En la tabla 2, se enumeran los calificadores de configuración válidos en orden de precedencia. Puedes agregar varios calificadores a un nombre de directorio separando cada calificador con un guion. Si utilizas varios calificadores para un directorio de recursos, debes agregarlos al nombre del directorio en el orden en el que se enumeran en la tabla.

Tabla 2. Nombres de calificadores de configuración.

Configuración

Valores de calificadores

Descripción

MCC y MNC

Ejemplos:

mcc310

mcc310-mnc004

mcc208-mnc00

El código móvil de país (MCC), opcionalmente seguido del código de red móvil (MNC) de la tarjeta SIM del dispositivo. Por ejemplo, mcc310 se refiere a Estados Unidos con cualquier operador, mcc310-mnc004 se refiere a Estados Unidos con Verizon y mcc208-mnc00 se refiere a Francia con Orange.

Si el dispositivo utiliza una conexión de radio (es decir, es un teléfono GSM), los valores del MCC y el MNC provienen de la tarjeta SIM.

También puedes usar el MCC solo, por ejemplo, para incluir recursos legales de países específicos en tu app. Si necesitas especificar el uso de recursos solamente en función del idioma, utiliza el calificador de idioma, secuencia de comandos (opcional) y región (opcional). Si usas el calificador de MCC y MNC, hazlo con cuidado y comprueba que funcione como se espera.

Consulta también los campos de configuración mcc y mnc, que indican el código móvil de país y el código de red móvil actuales, respectivamente.

Idioma, secuencia de comandos (opcional) y región (opcional)

Ejemplos:

en

fr

en-rUS

fr-rFR

fr-rCA

b+en

b+en+US

b+es+419

b+zh+Hant

b+sr+Latn+RS

El idioma se define con un código de idioma ISO 639-2{:.external} de dos letras, seguido opcionalmente de un código de región ISO 3166-1-alpha-2{:.external} de dos letras (precedido de r en minúscula).

Los códigos no distinguen mayúsculas de minúsculas. El prefijo r se usa para distinguir la parte de la región. No puedes especificar una región sola.

Android 7.0 (nivel de API 24) introdujo la compatibilidad con las etiquetas de idioma BCP 47{:.external}, que puedes usar para la calificación de recursos de idiomas y regiones específicos. Una etiqueta de idioma se compone de una secuencia de una o más subetiquetas. Cada una acota o afina la variedad del idioma que identifica la etiqueta general. Para obtener más información sobre las etiquetas de idioma, consulta Etiquetas para identificar idiomas{:.external}.

Para usar una etiqueta de idioma BCP 47, concatena b+ y un código de idioma ISO 639-2{:.external} de dos letras, al que puedes agregar dos subetiquetas separadas con +.

La etiqueta de idioma puede cambiar mientras se usa tu app si los usuarios cambian el idioma en la configuración del sistema. Para obtener información sobre cómo esto puede afectar a tu app durante el tiempo de ejecución, consulta Cómo administrar los cambios en la configuración.

Para obtener una guía completa acerca de cómo localizar tu app a otros idiomas, consulta Cómo localizar tu app.

Consulta también el método getLocales, que proporciona la lista definida de configuraciones regionales. Esta lista incluye la configuración regional principal.

Género gramatical masculine
feminine
neuter

Es el género gramatical del usuario. Se usa para idiomas que tienen género gramatical.

Por ejemplo, si necesitas proporcionar diferentes recursos para los usuarios de habla francesa, puedes usar directorios como los siguientes:

res/
  values-fr/
    strings.xml (cadenas predeterminadas con género no especificado)
  values-fr-masculine/
    strings.xml (cadenas con género masculino)
  values-fr-feminine/
    strings.xml (cadenas con género femenino)
  values-fr-neuter/
    strings.xml (cadenas con género neutro)

Consulta Flexión gramatical en Android.

Consulta también el método de configuración getGrammaticalGender(), que indica el género gramatical.

Se agregó en el nivel de API 34.

Dirección del diseño

ldrtl

ldltr

La dirección del diseño de tu app. ldrtl significa "dirección del diseño de derecha a izquierda". ldltr significa "dirección del diseño de izquierda a derecha" y es el valor implícito predeterminado.

Esto puede aplicarse a cualquier recurso, como diseños, elementos de diseño o valores.

Por ejemplo, si deseas proporcionar un diseño específico para el idioma árabe y un diseño genérico para cualquier otro idioma "de derecha a izquierda" (como persa o hebreo), deberías usar directorios como los siguientes:

res/
layout/
main.xml
(diseño predeterminado)
layout-ar/
main.xml (diseño específico para árabe)
layout-ldrtl/
main.xml (cualquier idioma de derecha a izquierda, excepto el árabe, ya que el calificador de idioma "ar" tiene mayor precedencia)

Nota: Para habilitar las funciones de diseño de derecha a izquierda en tu app, debes establecer SupportsRtl en "true" y establecer TargetSdkVersion en 17 o un valor superior.

Se agregó en el nivel de API 17.

Ancho más pequeño

swdp

Ejemplos:

sw320dp

sw600dp

sw720dp

etc.

Es la dimensión más corta del área de la pantalla disponible para una app. En concreto, el elemento smallestWidth de la ventana de la app es la parte más corta de la altura y el ancho disponibles de la ventana. También puede considerarse "el menor ancho posible" de la ventana. Puedes usar este calificador para asegurarte de que tu app tenga, como mínimo,  dp de ancho disponible para su IU.

Por ejemplo, si tu diseño requiere que la dimensión más pequeña del área de pantalla sea siempre de al menos 600 dp, puedes usar este calificador para crear los recursos de diseño en un directorio res/layout-sw600dp/. El sistema usa estos recursos solo cuando la menor dimensión de la pantalla disponible es de al menos 600 dp, independientemente de si el lado de 600 dp es la altura o el ancho que el usuario percibe. El ancho más pequeño puede cambiar si se cambia el tamaño de la ventana (cambiando el ancho o la altura disponibles) o si se reposiciona (posiblemente, cambiando las inserciones del sistema).

El uso del ancho más pequeño para determinar el tamaño general de la pantalla es útil porque el ancho es, a menudo, el factor que impulsa la creación de un diseño. Una IU a menudo se desplaza verticalmente, pero tiene restricciones bastante rígidas en cuanto al espacio mínimo que necesita en sentido horizontal.

El ancho disponible es también el factor clave para determinar si se usará un diseño de un solo panel para los teléfonos móviles o un diseño de varios paneles para las tablets. Por lo tanto, probablemente te preocupe más el ancho mínimo posible de cada dispositivo.

El ancho más pequeño de un dispositivo tiene en cuenta las decoraciones de la pantalla y la IU del sistema. Por ejemplo, si el dispositivo tiene elementos persistentes de IU en la pantalla que ocupan espacio a lo largo del eje del ancho más pequeño, el sistema declara que el ancho más pequeño es menor que el tamaño real de la pantalla, porque esos píxeles no están disponibles para tu IU.

Estos son algunos valores que puedes utilizar para tamaños de pantallas comunes:

  • 320, para dispositivos con configuraciones de pantalla como las siguientes:
    • 240 x 320 ldpi (teléfono celular QVGA)
    • 320 x 480 mdpi (teléfono celular)
    • 480 × 800 hdpi (teléfono celular de alta densidad)
  • 480, para pantallas de 480 x 800 mdpi (tablet/teléfono celular)
  • 600, para pantallas de 600 x 1024 mdpi (tablet de 7 pulgadas)
  • 720, para pantallas de 720 x 1280 mdpi (tablet de 10 pulgadas)

Cuando tu app proporciona directorios de múltiples recursos con valores diferentes para el calificador smallestWidth, el sistema utiliza el más cercano (sin superarlo) al smallestWidth del dispositivo.

Se agregó en el nivel de API 13.

Consulta también el atributo android:requiresSmallestWidthDp, que declara el smallestWidth mínimo con el cual tu app es compatible, y el campo de configuración smallestScreenWidthDp, que contiene el valor smallestWidth del dispositivo.

Para obtener más información sobre el diseño de diferentes pantallas con este calificador, consulta Diseño responsivo o adaptable con vistas.

Ancho y altura disponibles

wdp

hdp

Ejemplos:

w720dp

w1024dp

h720dp

h1024dp

etc.

Especifica el ancho o la altura de pantalla mínimos disponibles (en unidades dp definidas por el valor ) en los que se debe utilizar el recurso. Estos valores de configuración se comparan con el ancho y alto de la pantalla actual cuando la orientación del dispositivo cambia entre vertical y horizontal, el dispositivo se pliega o se despliega, o el sistema entra en el modo multiventana o sale de este. En el modo multiventana, los valores reflejan el ancho y la altura de la ventana que contiene la app, no el ancho y la altura de la pantalla del dispositivo. De manera similar, para las actividades incorporadas, los valores corresponden al ancho y la altura de las actividades individuales, no al ancho y la altura de la pantalla. Para obtener más información, consulta Incorporación de actividades.

A menudo, el ancho y la altura disponibles resultan útiles para determinar si debe usarse un diseño de varios paneles, ya que, incluso en una tablet, no suele ser conveniente usar el mismo diseño de varios paneles en las orientaciones vertical y horizontal. Por lo tanto, puedes usar estos para especificar el ancho o la altura mínimos que se requieren para el diseño, en lugar de usar el tamaño de pantalla y los calificadores de orientación juntos.

Cuando tu app proporciona directorios de múltiples recursos con valores diferentes para estas configuraciones, el sistema utiliza el más cercano (sin superarlo) al ancho de pantalla actual del dispositivo. Para determinar la opción más cercana, agrega las diferencias entre el ancho real de la pantalla y el ancho especificado con la diferencia entre la altura real de la pantalla y la altura especificada, con alturas y anchos no especificados que tengan el valor 0.

Los valores excluyen el área ocupada por las inserciones de ventana, por lo que, si el dispositivo tiene elementos persistentes de la IU en los bordes de la pantalla, los valores de ancho y alto son más pequeños que las dimensiones reales de la pantalla, incluso cuando la app se muestra de borde a borde con Window.setDecorFitsSystemWindows o WindowCompat.setDecorFitsSystemWindows.

Algunas decoraciones de pantalla verticales que no son fijas (como la barra de estado del teléfono que se puede ocultar cuando está en pantalla completa) no se tienen en cuenta aquí, ni tampoco las decoraciones de la ventana, como la barra de título o la barra de acciones, por lo que las apps deben estar preparadas para trabajar con un espacio algo más pequeño del que especifican.

Nota: El sistema elige el recurso que coincida tanto con el ancho como con la altura. Por lo tanto, la opción que más se recomienda es un recurso que especifique ambos en lugar de uno que especifique solo uno de los dos. Por ejemplo, si la pantalla real es de 720 dp de ancho por 1,280 dp de alto y un recurso se califica con w720dp y otro se califica como w700dp-h1200dp, se elige el último aunque el primero sea una coincidencia exacta de lo que especifica.

Se agregó en el nivel de API 13.

Consulta también los campos de configuración screenWidthDp y screenHeightDp, que contienen el ancho y la altura actuales de la pantalla.

Para obtener más información sobre el diseño de diferentes pantallas con este calificador, consulta Diseño responsivo o adaptable con vistas.

Tamaño de pantalla

small

normal

large

xlarge

  • small: Pantallas que son de tamaño similar a una pantalla QVGA de baja densidad. El tamaño de diseño mínimo de una pantalla pequeña es de aproximadamente 320 x 426 unidades dp. Dos ejemplos son las pantallas QVGA de baja densidad y las pantallas VGA de alta densidad.
  • normal: Pantallas que son de tamaño similar a una pantalla HVGA de densidad media. El tamaño de diseño mínimo de una pantalla normal es de aproximadamente 320 x 470 unidades dp. Algunos ejemplos de tales pantallas son las pantallas WQVGA de baja densidad, HVGA de densidad media y WVGA de alta densidad.
  • large: Pantallas que son de tamaño similar a una pantalla VGA de densidad media. El tamaño de diseño mínimo de una pantalla grande es de aproximadamente 480 x 640 unidades dp. Dos ejemplos son las pantallas VGA y WVGA de densidad media.
  • xlarge: Pantallas que son considerablemente más grandes que la pantalla HVGA de densidad media tradicional. El tamaño de diseño mínimo de una pantalla extragrande es de aproximadamente 720 x 960 unidades dp. En la mayoría de los casos, los dispositivos con pantallas extragrandes son demasiado grandes para llevarlos en un bolsillo y probablemente sean dispositivos similares a tablets. Se agregó en el nivel de API 9.

Nota: El uso de un calificador de tamaño no implica que los recursos sean solamente para pantallas de ese tamaño. Si no proporcionas recursos alternativos con calificadores que se ajusten mejor a la configuración actual del dispositivo, es posible que el sistema utilice los recursos que mejor coincidan.

Precaución: Si todos tus recursos usan un calificador de tamaño mayor que el de la pantalla actual, el sistema no los usa y tu app falla en el tiempo de ejecución. Esto sucede, por ejemplo, si todos los recursos de diseño están etiquetados con el calificador xlarge, pero el dispositivo tiene una pantalla de tamaño normal.

Se agregó en el nivel de API 4.

Consulta también el campo de configuración screenLayout, que indica si la pantalla es pequeña, normal o grande.

Para obtener más información, consulta Descripción general de la compatibilidad de pantallas.

Aspecto de la pantalla

long

notlong

  • long: Pantallas largas, como WQVGA, WVGA, FWVGA
  • notlong: Pantallas que no son largas, como QVGA, HVGA y VGA

Se agregó en el nivel de API 4.

Esto se basa exclusivamente en la relación de aspecto de la pantalla (una pantalla long es más ancha). Este objeto no está relacionado con la orientación de la pantalla.

Consulta también el campo de configuración screenLayout, que indica si la pantalla es larga.

Pantalla circular

round

notround

  • round: pantallas circulares; por ejemplo, un dispositivo wearable circular
  • notround: pantallas rectangulares, como teléfonos y tablets

Se agregó en el nivel de API 23.

Consulta también el método de configuración isScreenRound, que indica si la pantalla es circular.

Gamut amplio de colores

widecg

nowidecg

  • widecg: pantallas con un gamut amplio de colores, como Display P3 o AdobeRGB
  • nowidecg: pantallas con un gamut limitado de colores, como sRGB

Se agregó en el nivel de API 26.

Consulta también el método de configuración isScreenWideColorGamut, que indica si la pantalla tiene un gamut amplio de colores.

Alto rango dinámico (HDR)

highdr

lowdr

  • highdr: pantallas con un rango dinámico alto
  • lowdr: pantallas con un rango dinámico bajo o estándar

Se agregó en el nivel de API 26.

Consulta también el método de configuración isScreenHdr, que indica si la pantalla tiene capacidades de HDR.

Orientación de la pantalla

port

land

  • port: El dispositivo está en orientación vertical.
  • land: El dispositivo está en orientación horizontal.

Esto puede cambiar durante el ciclo de vida de tu app si el usuario gira la pantalla. Para obtener información sobre cómo esto afecta a tu app durante el tiempo de ejecución, consulta Cómo administrar los cambios en la configuración.

Consulta también el campo de configuración orientation, que indica la orientación actual del dispositivo.

Modo de IU

car

desk

television

appliance

watch

vrheadset

  • car: El dispositivo se muestra en un conector para autos.
  • desk: El dispositivo se muestra en un conector para escritorio.
  • television: El dispositivo se muestra en una televisión y proporciona una experiencia de "diez pies" en la que su IU está en una pantalla grande de la cual el usuario se encuentra alejado, y la experiencia se orienta principalmente en torno a un pad direccional o alguna otra interacción que no sea de puntero.
  • appliance: El dispositivo se utiliza como un aparato, sin pantalla.
  • watch: El dispositivo tiene una pantalla y se usa en la muñeca.
  • vrheadset: El dispositivo se muestra en un visor de realidad virtual.

Se agregó en el nivel de API 8; televisión agregada en el nivel de API 13; electrodoméstico agregado en el nivel de API 16; reloj agregado en el nivel de API 20; visor de RV agregado en el nivel de API 26.

Para obtener información sobre cómo puede responder tu app cuando el dispositivo se inserta en un conector o se quita de este, consulta Cómo determinar y supervisar el tipo y el estado del conector.

Esto puede cambiar durante el ciclo de vida de tu app si el usuario coloca el dispositivo en un conector. Puedes habilitar o inhabilitar algunos de estos modos con UiModeManager. Para obtener información sobre cómo esto afecta a tu app durante el tiempo de ejecución, consulta Cómo administrar los cambios en la configuración.

Modo nocturno

night

notnight

  • night: noche
  • notnight: día

Se agregó en el nivel de API 8.

Esto puede cambiar durante el ciclo de vida de tu app si el modo nocturno se deja en modo automático (predeterminado); en ese caso, el modo cambia según el momento del día. Puedes habilitar o inhabilitar este modo con UiModeManager. Para obtener información sobre cómo esto afecta a tu app durante el tiempo de ejecución, consulta Cómo administrar los cambios en la configuración.

Densidad de píxeles de la pantalla (dpi)

ldpi

mdpi

hdpi

xhdpi

xxhdpi

xxxhdpi

nodpi

tvdpi

anydpi

nnndpi

  • ldpi: Pantallas de baja densidad; aproximadamente, 120 dpi
  • mdpi: Pantallas de densidad media (en HVGA tradicional); aproximadamente, 160 dpi
  • hdpi: Pantallas de alta densidad; aproximadamente, 240 dpi.
  • xhdpi: Pantallas de densidad extraalta; aproximadamente, 320 dpi. Se agregó en el nivel de API 8.
  • xxhdpi: Pantallas de densidad extraextraalta; aproximadamente, 480 dpi. Se agregó en el nivel de API 16.
  • xxxhdpi: Usos de densidad extraextraextraalta (ícono de selector solamente; consulta Cómo brindar compatibilidad con diferentes densidades de píxeles); aproximadamente, 640 dpi Se agregó en el nivel de API 18.
  • nodpi: Se usa para los recursos de mapas de bits que no deseas que se escalen, de modo que coincidan con la densidad del dispositivo.
  • tvdpi: Pantallas entre mdpi y hdpi; aproximadamente, 213 dpi. Este no se considera un grupo de densidad "principal". Se usa principalmente para televisiones de 720p, y la mayoría de las apps no lo necesitan. Para paneles de TV de 1080p, usa xhdpi, y para paneles de TV 4K, usa xxxhdpi. Se agregó en el nivel de API 13.
  • anydpi: Coincide con todas las densidades de pantalla y tiene prioridad respecto de otros calificadores. Esto es útil para los elementos de diseño vectoriales. Se agregó en el nivel de API 21.
  • nnndpi: Se usa para representar densidades no estándar, en las que nnn es una densidad de la pantalla representada por un valor entero positivo. No se usa en la mayoría de los casos. Es mejor usar buckets de densidad estándar, que reducen notablemente la sobrecarga que supone admitir la gran variedad de densidades de pantalla de los dispositivos disponibles en el mercado.

Existe una relación de ajuste de escala de 3:4:6:8:12:16 entre las seis densidades principales (si se ignora la densidad tvdpi). Por lo tanto, un mapa de bits de 9 x 9 en ldpi es de 12 x 12 en mdpi, de 18 x 18 en hdpi, de 24 x 24 en xhdpi, etcétera.

Nota: El uso de un calificador de densidad no implica que los recursos sean solamente para pantallas de esa densidad. Si no proporcionas recursos alternativos con calificadores que se ajusten mejor a la configuración actual del dispositivo, el sistema utiliza los recursos que mejor coincidan.

Para obtener más información sobre cómo controlar las diferentes densidades de pantalla y cómo Android podría escalar tus mapas de bits para adaptarlos a la densidad actual, consulta Descripción general de la compatibilidad de pantallas.

Tipo de pantalla táctil

notouch

finger

  • notouch: El dispositivo no tiene una pantalla táctil.
  • finger: El dispositivo tiene una pantalla táctil para utilizar mediante la interacción directa del dedo del usuario.

Consulta también el campo de configuración touchscreen, que indica el tipo de pantalla táctil del dispositivo.

Disponibilidad del teclado

keysexposed

keyshidden

keyssoft

  • keysexposed: El dispositivo tiene un teclado disponible. Si el dispositivo tiene un teclado en pantalla habilitado (lo cual es probable), este puede utilizarse incluso cuando el teclado de hardware no está expuesto al usuario, aunque el dispositivo no tenga un teclado de hardware. Si no se proporciona un teclado en pantalla, o si está inhabilitado, se utiliza solamente cuando el teclado de hardware está expuesto.
  • keyshidden: El dispositivo tiene un teclado de hardware disponible, pero está oculto y el dispositivo no tiene un teclado en pantalla habilitado.
  • keyssoft: El dispositivo tiene un teclado en pantalla habilitado, ya sea visible o no.

Si proporcionas recursos keysexposed, pero no recursos keyssoft, el sistema utiliza los recursos keysexposed independientemente de que un teclado sea visible, siempre que el sistema tenga un teclado en pantalla habilitado.

Esto puede cambiar durante el ciclo de vida de tu app si el usuario abre un teclado de hardware. Para obtener información sobre cómo esto afecta a tu app durante el tiempo de ejecución, consulta Cómo administrar los cambios en la configuración.

Consulta también los campos de configuración hardKeyboardHidden y keyboardHidden, que indican la visibilidad de un teclado de hardware y la visibilidad de cualquier clase de teclado (incluido el teclado de software), respectivamente.

Método principal de entrada de texto

nokeys

qwerty

12key

  • nokeys: El dispositivo no tiene teclas de hardware para la entrada de texto.
  • qwerty: El dispositivo tiene un teclado QWERTY de hardware, que puede ser visible para el usuario o no.
  • 12key: El dispositivo tiene un teclado de hardware de 12 teclas, que puede ser visible para el usuario o no.

Consulta también el campo de configuración keyboard, que indica el método principal de entrada de texto disponible.

Disponibilidad de las teclas de navegación

navexposed

navhidden

  • navexposed: Las teclas de navegación están disponibles para el usuario.
  • navhidden: Las teclas de navegación no están disponibles (por ejemplo, detrás de una tapa cerrada).

Esto puede cambiar durante el ciclo de vida de tu app si el usuario revela las teclas de navegación. Para obtener información sobre cómo esto afecta a tu app durante el tiempo de ejecución, consulta Cómo administrar los cambios en la configuración.

Consulta también el campo de configuración navigationHidden, que indica si las teclas de navegación están ocultas.

Método principal de navegación no táctil

nonav

dpad

trackball

wheel

  • nonav: El dispositivo no tiene otro recurso de navegación que no sea el uso de la pantalla táctil.
  • dpad: El dispositivo tiene un mando de dirección (o pad direccional) para la navegación.
  • trackball: El dispositivo tiene una bola de seguimiento para la navegación.
  • wheel: El dispositivo tiene una rueda de dirección para la navegación (poco común).

Consulta también el campo de configuración navigation, que indica el tipo de método de navegación disponible.

Versión de la plataforma (nivel de API)

Ejemplos:

v3

v4

v7

etc.

Nivel de API que admite el dispositivo. Por ejemplo, v1 para el nivel de API 1 (dispositivos con Android 1.0 o versiones posteriores) y v4 para el nivel de API 4 (dispositivos con Android 1.6 o versiones posteriores). Para obtener más información sobre estos valores, consulta el documento sobre los niveles de API de Android.

Reglas de nombres de calificadores

A continuación se incluyen algunas reglas acerca del uso de los nombres de calificadores de configuración:

  • Puedes especificar varios calificadores, separados por guiones, para un solo conjunto de recursos. Por ejemplo, drawable-en-rUS-land se aplica a dispositivos en inglés (Estados Unidos) en orientación horizontal.
  • Los calificadores deben estar en el orden enumerado en la Tabla 2.
    • Incorrecto: drawable-hdpi-port/
    • Correcto: drawable-port-hdpi/
  • No se pueden anidar los directorios de recursos alternativos. Por ejemplo, no puedes tener res/drawable/drawable-en/.
  • Los valores no distinguen mayúsculas de minúsculas. El compilador de recursos convierte los nombres de directorios a minúsculas antes del procesamiento para evitar problemas en los sistemas de archivos que no distinguen mayúsculas de minúsculas. Cualquier uso de mayúsculas en los nombres es solo para facilitar la lectura.
  • Se admite un solo valor para cada tipo de calificador. Por ejemplo, si deseas usar los mismos archivos de elementos de diseño para España y Francia, no puedes tener un directorio llamado drawable-es-fr/. En cambio, necesitas dos directorios de recursos que contengan los archivos correspondientes, como drawable-es/ y drawable-fr/. Sin embargo, no es necesario que realmente dupliques los archivos en ambas ubicaciones. En su lugar, puedes crear un alias para un recurso, como se describe en la sección Cómo crear recursos de alias.

Una vez que guardas los recursos alternativos en directorios denominados con estos calificadores, Android aplica automáticamente los recursos en tu app de acuerdo con la configuración del dispositivo actual. Cada vez que se solicita un recurso, Android busca directorios de recursos alternativos que contengan el archivo de recursos solicitado y, luego, encuentra el recurso de coincidencia óptima.

Si no existen recursos alternativos que coincidan con una configuración de dispositivo determinada, Android utiliza los recursos predeterminados correspondientes (el conjunto de recursos para un tipo de recurso determinado que no incluye un calificador de configuración).

Cómo crear recursos de alias

Cuando tienes un recurso que deseas utilizar para más de una configuración de dispositivo (pero no deseas proporcionarlo como un recurso predeterminado), no necesitas colocar el mismo recurso en más de un directorio de recursos alternativos. En cambio, puedes crear un recurso alternativo que actúe como un alias para un recurso guardado en tu directorio de recursos predeterminados.

Por ejemplo, imagina que tienes un ícono de la app, icon.png, y necesitas una versión única de ese ícono para diferentes configuraciones regionales. Sin embargo, dos configuraciones regionales, inglés (Canadá) y francés (Canadá), necesitan utilizar la misma versión. No es necesario que copies la misma imagen en el directorio de recursos para inglés (Canadá) y francés (Canadá). En cambio, puedes guardar la imagen que se usa para ambos y utilizar cualquier nombre que no sea icon.png, como icon_ca.png, y disponerla en el directorio res/drawable/ predeterminado. Luego, crea un archivo icon.xml en res/drawable-en-rCA/ y res/drawable-fr-rCA/ que haga referencia al recurso icon_ca.png con el elemento <bitmap>. Esto te permite almacenar una sola versión del archivo PNG y dos archivos en formato XML pequeños que apuntan a dicho archivo PNG. Consulta los ejemplos de las siguientes secciones para obtener más detalles.

Elemento de diseño

Para crear un alias para un elemento de diseño existente, usa el elemento <drawable>.

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

Si guardas este archivo como icon.xml en un directorio de recursos alternativos, como res/values-en-rCA/, se compila en un recurso al cual puedes hacer referencia como R.drawable.icon, pero, en realidad, es un alias del recurso R.drawable.icon_ca que se guarda en res/drawable/.

Diseño

Si quieres crear un alias para un diseño existente, usa el elemento <include> dentro de un <merge>.

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

Si guardas este archivo como main.xml, se compila en un recurso al que puedes hacer referencia como R.layout.main, pero, en realidad, es un alias del recurso R.layout.main_ltr.

Cómo acceder a los recursos de tu app

Una vez que proporciones un recurso en tu aplicación, podrás aplicarlo haciendo referencia a su ID de recurso. Todos los IDs de recursos se definen en la clase R de tu proyecto, que la herramienta aapt genera automáticamente.

Cuando se compila tu aplicación, aapt genera la clase R, que contiene los IDs de recurso de todos los recursos de tu directorio res/. Para cada tipo de recurso, hay una subclase R, como R.drawable para todos los recursos de elementos de diseño. Para cada recurso de ese tipo, hay un número entero estático, por ejemplo, R.drawable.icon. Este número entero es el ID del recurso que puedes usar para recuperar tu recurso.

Si bien en la clase R se especifican los IDs de recursos, no necesitas buscar en ella para hallar uno. Un ID de recurso siempre está compuesto por lo siguiente:

  • El tipo de recurso: Cada recurso se agrupa en un "tipo", como string, drawable y layout. Para obtener más información sobre los diferentes tipos, consulta Descripción general de los tipos de recursos.
  • El nombre del recurso, que es el nombre de archivo sin la extensión o el valor en el atributo XML android:name si el recurso es un valor simple (como una cadena)

Existen dos maneras de acceder a un recurso:

  • En código, usando un número entero estático de una subclase de tu clase R, como: R.string.hello string es el tipo de recurso y hello es el nombre del recurso. Hay muchas APIs de Android que pueden acceder a tus recursos cuando proporcionas un ID de recurso en este formato. Para obtener más información, consulta la sección Cómo acceder a los recursos en código.
  • En XML, usando una sintaxis XML especial que corresponde al ID de recurso definido en tu clase R, por ejemplo: @string/hello string es el tipo de recurso y hello es el nombre del recurso. Puedes usar esta sintaxis en un recurso XML en cualquier lugar donde esté previsto que proporciones un valor en un recurso. Para obtener más información, consulta la sección Cómo acceder a recursos desde XML.

Cómo acceder a los recursos en código

Puedes usar un recurso en código si pasas el ID de recurso como un parámetro del método. Por ejemplo, puedes establecer un ImageView para usar el recurso res/drawable/myimage.png con 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);

También puedes recuperar recursos individuales con métodos en Resources, del cual puedes obtener una instancia con getResources.

Sintaxis

Esta es la sintaxis que necesitas para hacer referencia a un recurso en código:

[<package_name>.]R.<resource_type>.<resource_name>

  • <package_name> es el nombre del paquete en el que se ubica el recurso (no es necesario cuando haces referencia a recursos desde tu paquete).
  • <resource_type> es la subclase R para el tipo de recurso.
  • <resource_name> es el nombre de archivo del recurso sin la extensión o el valor del atributo android:name en el elemento XML (para valores simples).

Casos de uso

Hay muchos métodos que aceptan un parámetro de ID de recurso y puedes recuperar recursos usando métodos en Resources. Puedes obtener una instancia de Resources con Context.getResources.

Aquí te mostramos algunos ejemplos de acceso a recursos en 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);

Cómo acceder a recursos desde XML

Puedes definir valores para algunos atributos y elementos XML usando una referencia a un recurso existente. Generalmente, harás esto cuando crees archivos de diseño para proporcionar imágenes y cadenas para tus widgets.

Por ejemplo, si agregas un Button a tu diseño, usa un recurso de cadena para el texto del botón:

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

Sintaxis

Esta es la sintaxis que necesitas para hacer referencia a un recurso en un recurso XML:

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

  • <package_name> es el nombre del paquete en el que se ubica el recurso (no es necesario cuando se hace referencia a recursos desde el mismo paquete).
  • <resource_type> es la subclase R para el tipo de recurso.
  • <resource_name> es el nombre de archivo del recurso sin la extensión o el valor del atributo android:name en el elemento XML (para valores simples).

Casos de uso

En algunos casos, debes usar un recurso para un valor en XML, por ejemplo, para aplicar una imagen de elemento de diseño a un widget, pero también puedes usar un recurso en XML en cualquier lugar donde se acepte un valor simple. Por ejemplo, si tienes el siguiente archivo de recursos que incluye un recurso de color y un recurso de cadenas:

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

Puedes usar estos recursos en el siguiente archivo de diseño para establecer el color del texto y la cadena de 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" />

En este caso, no necesitas especificar el nombre del paquete en la referencia del recurso porque los recursos son de tu propio paquete. Para hacer referencia a un recurso del sistema, debes incluir el nombre del paquete, como se muestra en el siguiente ejemplo:

<?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" />

Incluso puedes usar recursos en XML para crear alias. Por ejemplo, puedes crear un recurso de elemento de diseño que sea un alias para otro recurso de elemento de diseño:

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

Esto suena redundante, pero puede ser muy útil cuando se usa un recurso alternativo. Para obtener más información, consulta la sección sobre la creación de recursos de alias.

Atributos de estilo de referencia

Un recurso de atributo de estilo te permite hacer referencia al valor de un atributo en el tema aplicado actualmente. Hacer referencia a un atributo de estilo te permite personalizar la apariencia de los elementos de la IU diseñándolos para que coincidan con las variantes estándar que proporciona el tema actual, en lugar de proporcionar un valor codificado. Hacer referencia a un atributo de estilo esencialmente significa "usar el estilo identificado por el atributo en el tema actual".

Para hacer referencia a un atributo de estilo, la sintaxis del nombre es casi idéntica al formato de recurso normal, pero, en lugar del símbolo de arroba (@), usa un signo de interrogación (?). La sección de tipo de recurso es opcional. Por lo tanto, la sintaxis de referencia es la siguiente:

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

Así es como puedes hacer referencia a un atributo para establecer el color de texto de modo que coincida con el color de texto secundario del tema del sistema:

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

Aquí, el atributo android:textColor especifica el nombre de un atributo de estilo en el tema actual. Android ahora usa el valor aplicado al atributo de estilo android:textColorSecondary como el valor para android:textColor en este widget. Debido a que la herramienta de recursos del sistema sabe que se espera un recurso de atributo en este contexto, no necesitas indicar explícitamente el tipo, que es ?android:attr/textColorSecondary. Puedes excluir el tipo attr.

Cómo acceder a los archivos originales

Si bien es poco común, podrías necesitar acceder a tus archivos y directorios originales. Si es así, no podrás guardar tus archivos en res/, ya que el único elemento que permite leer un recurso desde res/ es el ID de recurso. Como alternativa, puedes guardar tus recursos en el directorio assets/.

Los archivos guardados en el directorio assets/ no reciben un ID de recurso, por lo que no puedes hacer referencia a ellos a través de la clase R ni desde recursos XML. En cambio, puedes consultar archivos en el directorio assets/ como en un sistema de archivos normal y leer datos sin procesar usando AssetManager.

Sin embargo, si lo único que necesitas es la capacidad de leer datos sin procesar (como un archivo de audio o video), guarda el archivo en el directorio res/raw/ y lee un flujo de bytes usando openRawResource.

Cómo acceder a recursos de la plataforma

Android contiene una cantidad de recursos estándar, como estilos, temas y diseños. Para acceder a estos recursos, califica la referencia a tu recurso con el nombre de paquete android. Por ejemplo, Android proporciona un recurso de diseño que puedes usar para elementos de lista en un 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));

En este ejemplo, simple_list_item_1 es un recurso de diseño definido por la plataforma para elementos en un ListView. Puedes usar esto en lugar de crear tu propio diseño para los elementos de la lista.

Cómo ofrecer la mejor compatibilidad de dispositivos con recursos

Para que tu app admita varias configuraciones de dispositivos, es muy importante que siempre proporciones recursos predeterminados para cada tipo de recurso que utilice tu app.

Por ejemplo, si tu app admite varios idiomas, incluye siempre un directorio values/ (en el cual se guardan tus cadenas) sin un calificador de idioma y región. En cambio, si colocas todos tus archivos de cadenas en directorios que tienen un calificador de idioma y región, tu app fallará cuando se ejecute en un dispositivo configurado en un idioma que tus cadenas no admitan.

Siempre que proporciones recursos values/ predeterminados, tu app se ejecutará correctamente, incluso si el usuario no comprende el idioma que presenta. Es mejor que un bloqueo.

De la misma manera, si proporcionas diferentes recursos de diseño de acuerdo con la orientación de la pantalla, debes elegir una orientación como predeterminada. Por ejemplo, en lugar de proporcionar recursos de diseño en layout-land/ para la orientación horizontal y layout-port/ para la orientación vertical, deja uno como predeterminado, como layout/ para la orientación horizontal y layout-port/ para la orientación vertical.

Proporcionar recursos predeterminados es importante no solo porque tu app podría ejecutarse en una configuración que no habías previsto, sino también porque las nuevas versiones de Android a veces agregan calificadores de configuración que las versiones anteriores no admiten. Si utilizas un nuevo calificador de recursos, pero mantienes la compatibilidad del código con versiones anteriores de Android, cuando una versión anterior de Android ejecute tu app, esta fallará si no proporcionas recursos predeterminados, ya que no podrá utilizar los recursos denominados con el nuevo calificador.

Por ejemplo, si tu minSdkVersion se establece en 4 y calificas todos tus recursos de elementos de diseño con el modo nocturno (night o notnight, que se agregaron en el nivel de API 8), un dispositivo con nivel de API 4 no podrá acceder a tus recursos de elementos de diseño y fallará. En este caso, probablemente desees que notnight sean tus recursos predeterminados, por lo cual debes excluir ese calificador para que tus recursos de elementos de diseño estén en drawable/ o drawable-night/.

Por lo tanto, para ofrecer la mejor compatibilidad de dispositivo, siempre proporciona recursos predeterminados para los recursos que tu app necesita para funcionar correctamente. Luego, crea recursos alternativos para configuraciones de dispositivos específicos utilizando los calificadores de configuración.

Esta regla tiene una excepción: si la minSdkVersion de tu app es 4 o superior, no necesitas recursos de elementos de diseño predeterminados cuando proporcionas recursos de elementos de diseño alternativos con el calificador de densidad de pantalla. Incluso sin recursos de elementos de diseño predeterminados, Android puede encontrar la mejor coincidencia entre las densidades de pantalla alternativas y escalar los mapas de bits si es necesario. Sin embargo, para brindar la mejor experiencia en todos los tipos de dispositivos, debes proporcionar elementos de diseño alternativos para los tres tipos de densidad.