Skip to content

Most visited

Recently visited

navigation

Provisión de recursos

Vista rápida

  • Los diferentes tipos de recursos pertenecen a diferentes subdirectorios de res/
  • Los recursos alternativos proporcionan archivos de recursos para configuraciones específicas
  • Siempre incluye recursos predeterminados para que tu app no dependa de configuraciones para dispositivos específicos

En este documento:

  1. Agrupación de tipos de recursos
  2. Provisión de recursos alternativos
    1. Reglas de nombres de calificadores
    2. Creación de recursos de alias
  3. Provisión de la mejor compatibilidad de dispositivos con recursos
  4. Cómo Android encuentra el recurso de coincidencia óptima

Consulta también:

  1. Acceso a recursos
  2. Tipos de recursos
  3. Admisión de varias pantallas

Siempre debes externalizar los recursos para aplicaciones como imágenes y strings de tu código, para que puedas mantenerlos de forma independiente. También 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 interfaz de usuario (IU) diferente según el tamaño de la pantalla, o strings diferentes según la configuración de idioma.

Una vez que externalizas los recursos para tu aplicación, puedes acceder a ellos mediante los ID de recursos que se generan en la clase R de tu proyecto. La forma de utilizar los recursos en tu aplicación se explica en la sección Acceso a recursos. En este documento, se muestra cómo puedes agrupar los recursos en tu proyecto de Android y proporcionar recursos alternativos para configuraciones de dispositivos específicos.

Agrupación de tipos de recursos

Debes colocar cada tipo de recurso en un subdirectorio específico del directorio res/ de tu proyecto. Por ejemplo, a continuación se muestra 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  

Como se ve en este ejemplo, el directorio res/ contiene todos los recursos (en subdirectorios): un recurso de imagen, dos recursos de diseño, directorios mipmap/ para los íconos del lanzador y un archivo de recursos de strings. Los nombres del directorio de recursos son importantes y se describen en la tabla 1.

Nota: Para obtener más información sobre el uso de las carpetas mipmap, consulta Información general sobre la administración de proyectos.

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

.
Directorio Tipo de recurso
animator/ Archivos XML que definen animaciones de propiedades.
anim/ Archivos XML que definen animaciones de interpolación de movimiento. (En este directorio, también se pueden guardar animaciones de propiedades, pero se prefiere el directorio animator/ para las animaciones de propiedades, a fin de distinguir entre los dos tipos).
color/ Archivos XML que definen una lista de estados de colores. Consulta la sección Recurso de lista de estado de colores
drawable/

Archivos de mapas de bits (.png, .9.png, .jpg, .gif) o archivos XML que se han compilado en los siguientes subtipos de recursos de elemento de diseño:

  • Archivos de mapas de bits
  • Nueve parches (mapas de bits reajustables)
  • Listas de estados
  • Formas
  • Elementos de diseño de animaciones
  • Otros elementos de diseño

Consulta la sección Recursos de elementos de diseño.

mipmap/ Archivos de elemento de diseño para diferentes densidades de los íconos lanzadores. Para obtener más información sobre la administración de los íconos lanzadores con carpetas mipmap/, consulta Información general sobre la administración de proyectos.
layout/ Archivos XML que definen el diseño de una interfaz de usuario. Consulta la sección Recurso de diseño.
menu/ Archivos XML que definen menús de aplicaciones, como un menú de opciones, un menú contextual o un submenú. Consulta la sección Recurso de menú.
raw/

Archivos arbitrarios para guardar sin procesar. Para abrir estos recursos con un 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 los archivos originales y a la jerarquía de archivos, puedes considerar la posibilidad de guardar algunos 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 mediante AssetManager.

values/

Archivos XML que contienen valores simples, como strings, valor enteros y colores.

Los archivos de recursos XML en otros subdirectorios res/ definen un único recurso basado en el nombre del archivo XML, mientras que los archivos del directorio values/ describen varios recursos. En el caso de un archivo de este directorio, cada campo secundario del elemento <resources> define un único recurso. Por ejemplo, un elemento <string> crea un recurso R.string y un elemento <color> 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:

Consulta las secciones Recursos de strings, Recursos de estilo y Más tipos de recursos.

xml/ Archivos XML arbitrarios que se pueden leer en tiempo de ejecución llamando a Resources.getXML(). Aquí se deben guardar diversos archivos de configuración XML , por ejemplo, una configuración que permite búsqueda.

Advertencia: Nunca guardes archivos de recursos directamente dentro del directorio res/; de lo contrario, se producirá un error en el compilador.

Para obtener más información sobre ciertos tipos de recursos, consulta la documentación Tipos de recursos.

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 aplicación. Sin embargo, es posible que los diferentes tipos de dispositivos con tecnología Android necesiten distintos tipos de recursos. Por ejemplo, si un dispositivo tiene una pantalla más grande de lo normal, debes proporcionar diferentes recursos de diseño que aprovechen el espacio extra de la pantalla. O bien, si un dispositivo tiene una configuración de idioma diferente, debes proporcionar distintos recursos de strings que traduzcan el texto en su interfaz de usuario. Para proporcionar estos recursos diferentes para distintas configuraciones de dispositivos, debes proporcionar recursos alternativos, además de tus recursos predeterminados.

Provisión de recursos alternativos

Figura 1: Dos dispositivos diferentes, cada uno de los cuales usa diferentes recursos de diseño.

Casi todas las aplicaciones deben proporcionar recursos alternativos para admitir configuraciones de dispositivos específicos. Por ejemplo, debes incluir recursos de elementos de diseño para diferentes densidades de pantallas y recursos de strings alternativos para diferentes idiomas. En tiempo de ejecución, Android detecta la configuración del dispositivo actual y carga los recursos adecuados para tu aplicación.

Para especificar alternativas para configuraciones específicas para un conjunto de recursos:

  1. Crea en res/ un nuevo directorio cuyo nombre lleve la forma <resources_name>-<config_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 guión.

    Advertencia: Cuando agregues varios calificadores, debes disponerlos en el mismo orden en el que se enumeran en la tabla 2. Si los calificadores están ordenados de manera incorrecta, los recursos se ignoran.

  2. Guarda los recursos alternativos respectivos en este nuevo directorio. Los archivos de recursos deben tener 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 cada uno de estos directorios de elementos de diseño están dimensionadas para una densidad de pantalla específica, pero los nombres de archivo son exactamente iguales. De este modo, el ID de recurso que usas para hacer referencia a la imagen icon.png o background.png es siempre el mismo, pero 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.

Android admite varios calificadores de configuración, y tú puedes agregar múltiples calificadores a un nombre de directorio separando cada calificador con un guión. En la tabla 2 se enumeran los calificadores de configuración válidos, en orden de precedencia; 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
etc.

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

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

También puedes utilizar el MCC solo (por ejemplo, para incluir recursos legales de países específicos en su aplicación). Si necesitas especificar solamente en función del idioma, utiliza el calificador de idioma y región (lo cual se trata a continuación). Si decides utilizar el calificador de MCC y MNC, debes hacerlo con cuidado y comprobar que funcione de la forma esperada.

También observa 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 y región Ejemplos:
en
fr
en-rUS
fr-rFR
fr-rCA
etc.

El idioma se define mediante un código de idioma ISO 639-1 de dos letras, opcionalmente seguido de un código de región ISO 3166-1-alfa-2 de dos letras (precedido por “r” en minúscula).

Para los códigos no se distinguen mayúsculas ni minúsculas; el prefijo r se usa para distinguir la parte de la región. No se puede especificar una región sola.

Esto puede cambiar durante el ciclo de vida de tu aplicación si el usuario modifica el idioma en la configuración del sistema. Consulta la sección Manejo de cambios en tiempo de ejecución para obtener información sobre la forma en la que esto afecta tu aplicación durante el tiempo de ejecución.

Consulta la sección Localización para obtener una guía completa para localizar tu aplicación en otros idiomas.

Consulta también el campo de configuración locale, que indica la configuración regional actual.

Dirección del diseño ldrtl
ldltr

Dirección del diseño de tu aplicación. 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) tendrías lo siguiente:

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.)

Nota: Para habilitar las funciones de diseño de derecha a izquierda para tu app, debes fijar supportsRtl en "true" y targetSdkVersion en 17 o más.

Se agregó en el nivel de API 17.

smallestWidth sw<N>dp

Ejemplos:
sw320dp
sw600dp
sw720dp
etc.

El tamaño fundamental de una pantalla, indicado por la dimensión más corta del área de pantalla disponible. En concreto, el smallestWidth del dispositivo es la parte más corta de la altura y el ancho disponibles de la pantalla (también puede considerarse como "el menor ancho posible" de la pantalla). Puedes usar este calificador para asegurarte de que, independientemente de la orientación actual de la pantalla, tu aplicación tenga, al menos, <N> dps 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, res/layout-sw600dp/. El sistema utilizará estos recursos solo cuando la menor dimensión de la pantalla disponible sea de, al menos, 600 dp, independientemente de que el lado de 600 dp sea la altura o el ancho percibido por el usuario. El smallestWidth es una característica fija de tamaño de pantalla del dispositivo; el smallestWidth del dispositivo no se modifica cuando la orientación de la pantalla cambia.

El smallestWidth de un dispositivo tiene en cuenta las decoraciones de la pantalla y la IU del sistema. Por ejemplo, si el dispositivo tiene algunos elementos de IU persistentes en la pantalla que ocupan espacio a lo largo del eje del smallestWidth, el sistema declara que el smallestWidth es menor que el tamaño de pantalla real, porque esos son píxeles de pantalla no disponibles para su IU. Por lo tanto, el valor que utilizas debe ser la dimensión más pequeña real que requiere tu diseño (generalmente, este valor es el "ancho más pequeño" que tu diseño admite, independientemente de la orientación actual de la pantalla).

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 x 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 aplicación 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 aplicación 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 y el uso de este calificador, consulta la guía para desarrolladores Admisión de varias pantallas.

Ancho disponible w<N>dp

Ejemplos:
w720dp
w1024dp
etc.

Especifica un ancho de pantalla mínimo disponible, en unidades dp en las cuales se debe usar el recurso; definido por el valor <N>. Este valor de configuración se modificará cuando la orientación cambie entre horizontal y vertical para coincidir con el ancho real actual.

Cuando tu aplicación proporciona directorios de múltiples recursos con valores diferentes para esta configuración, el sistema utiliza el más cercano (sin superarlo) al ancho de pantalla actual del dispositivo. El valor tiene en cuenta las decoraciones de la pantalla; por lo tanto, si el dispositivo tiene algunos elementos de IU persistentes en el borde izquierdo o derecho de la pantalla, utiliza un valor para el ancho que es menor que el tamaño real de la pantalla, y tiene en cuenta estos elementos de IU y reduce el espacio disponible de la aplicación.

Se agregó en el nivel de API 13.

Consulta también el campo de configuración screenWidthDp , que contiene el ancho de pantalla actual.

Para obtener más información sobre el diseño de diferentes pantallas y el uso de este calificador, consulta la guía para desarrolladores Admisión de varias pantallas.

Altura disponible h<N>dp

Ejemplos:
h720dp
h1024dp
etc.

Especifica una altura de pantalla mínima disponible, en unidades "dp" en las cuales se debe utilizar el recurso; definido por el valor <N>. Este valor de configuración se modificará cuando la orientación cambie entre horizontal y vertical para coincidir con la altura actual.

Cuando tu aplicación proporciona directorios de múltiples recursos con valores diferentes para esta configuración, el sistema utiliza el más cercano (sin superarlo) a la altura de pantalla actual del dispositivo. El valor tiene en cuenta las decoraciones de la pantalla; por lo tanto, si el dispositivo tiene algunos elementos de IU persistentes en el borde superior o inferior de la pantalla, utiliza un valor para la altura que es menor que el tamaño real de la pantalla, y tiene en cuenta estos elementos de IU y reduce el espacio disponible de la aplicación. Las decoraciones de pantalla que no son fijas (por ejemplo, una barra de estado que se puede ocultar en el modo de pantalla completa) no se tienen en cuenta en este caso, y tampoco se tienen en cuenta las decoraciones de ventanas como la barra de título o la barra de acciones, por lo que las aplicaciones deben estar preparadas para utilizar un espacio un poco más pequeño del que especifican.

Se agregó en el nivel de API 13.

Consulta también el campo de configuración screenHeightDp , que contiene el ancho de pantalla actual.

Para obtener más información sobre el diseño de diferentes pantallas y el uso de este calificador, consulta la guía para desarrolladores Admisión de varias pantallas.

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. Algunos 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. Algunos 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 extra grande es de aproximadamente 720 x 960 unidades dp. En la mayoría de los casos, los dispositivos con pantallas extra grandes serían demasiado grandes para llevarlos en un bolsillo y probablemente serían 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 son 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 sean la mejor coincidencia.

Advertencia: Si todos tus recursos usan un calificador de tamaño más grande que la pantalla actual, el sistema no los usará y tu aplicación se bloqueará en tiempo de ejecución (por ejemplo, si todos los recursos de diseño están etiquetados con el calificador xlarge, pero el dispositivo es una pantalla de tamaño normal).

Se agregó en el nivel de API 4.

Consulta Admisión de varias pantallas para obtener más información.

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

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 "larga" es más ancha). Esto 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.

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 aplicación si el usuario gira la pantalla. Consulta la sección Manejo de cambios en tiempo de ejecución para obtener información sobre la forma en la que esto afecta tu aplicación durante el tiempo de ejecució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
  • 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, orientada principalmente en torno a un DPAD u 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.

Se agregó en el nivel de API 8; televisión agregada en el nivel de API 13; reloj agregado en el nivel de API 20.

Para obtener información sobre cómo puede responder tu app cuando el dispositivo se inserta en un conector o se lo retira de este, consulta Determinación y control del estado y el tipo de acoplamiento.

Esto puede cambiar durante el ciclo de vida de tu aplicación si el usuario coloca el dispositivo en un conector. Puedes habilitar o inhabilitar algunos de estos modos mediante UiModeManager. Consulta la sección Manejo de cambios en tiempo de ejecución para obtener información sobre la forma en la que esto afecta tu aplicación durante el tiempo de ejecució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 aplicación si el modo nocturno se deja en modo automático (predeterminado), en cuyo caso, el modo cambia según el momento del día. Puedes habilitar o inhabilitar este modo utilizando UiModeManager. Consulta la sección Manejo de cambios en tiempo de ejecución para obtener información sobre la forma en la que esto afecta tu aplicación durante el tiempo de ejecución.

Densidad de píxeles de la pantalla (dpi) ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi
anydpi
  • 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 extra alta; aproximadamente, 320 dpi. Se agregó en el nivel de API 8.
  • xxhdpi: Pantallas de densidad extra extraalta; aproximadamente, 480 dpi. Se agregó en el nivel de API 16.
  • xxxhdpi: usos de densidad extra extra extraalta (ícono lanzador únicamente, consulta la nota en Compatibilidad con varias pantallas); aproximadamente, 640 dpi. Se agregó en el nivel de API 18.
  • nodpi: Esto se puede utilizar para los recursos de mapas de bits que no deseas que se escalen para que coincidan con la densidad del dispositivo.
  • tvdpi: Pantallas entre mdpi y hdpi; aproximadamente, 213 dpi. Este no se considera un grupo "primario" de densidad. Se utiliza principalmente para televisiones, y la mayoría de las apps no deberían necesitarlo; la provisión de recursos mdpi y hdpi es suficiente para la mayoría de las apps y el sistema los escalará según corresponda. Se agregó en el nivel de API 13.
  • anydpi: este calificador coincide con todas las densidades de pantalla y tiene prioridad respecto de otros calificadores. Resulta útil para los elementos de diseño del vector. Se agregó en el nivel de API 21.

Existe una relación de ajuste de escala de 3:4:6:8:12:16 entre las seis densidades primarias (ignorando 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.

Si decides que tus recursos de imagen no se ven lo suficientemente bien en una televisión o en otros dispositivos determinados, y deseas probar los recursos tvdpi, el factor de escala es 1,33* mdpi. Por ejemplo, una imagen de 100 px x 100 px para pantallas mdpi debe ser de 133 px x 133 px para tvdpi.

Nota: El uso de un calificador de densidad no implica que los recursos son solamente para pantallas de esa densidad. 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 sean la mejor coincidencia.

Consulta la sección Admisión de varias pantallas para obtener más información sobre cómo manejar diferentes densidades de pantalla y cómo Android podría escalar tus mapas de bits para adaptarlos a la densidad actual.

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 dirección e interacción 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 de software 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 de software, o si está inhabilitado, se lo utiliza solo 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 de software habilitado.
  • keyssoft: El dispositivo tiene un teclado de software habilitado, 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 de software habilitado.

Esto puede cambiar durante el ciclo de vida de tu aplicación si el usuario abre un teclado de hardware. Consulta la sección Manejo de cambios en tiempo de ejecución para obtener información sobre la forma en la que esto afecta tu aplicación durante el tiempo de ejecució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.

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 el nivel de API 4 (dispositivos con Android 1.6 o versiones posteriores). Consulta el documento Niveles de Android API para obtener más información sobre estos valores.

Nota: Desde la versión de Android 1.0, se han agregado algunos calificadores de configuración; por lo tanto, no todas las versiones de Android admiten todos los calificadores. Al utilizar un nuevo calificador, se agrega de forma implícita el calificador de la versión de la plataforma, de modo que los dispositivos anteriores lo ignorarán. Por ejemplo, al utilizar un calificador w600dp, se incluirá automáticamente el calificador v13, porque el calificador de ancho disponible era nuevo en el nivel de API 13. Para evitar problemas, siempre incluye un conjunto de recursos predeterminados (un conjunto de recursos sin calificadores). Para obtener más información, consulta la sección sobre Provisión de la mejor compatibilidad de dispositivos con recursos.

Reglas de nombres de calificadores

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

Una vez que guardes los recursos alternativos en directorios denominados con estos calificadores, Android aplica automáticamente los recursos en tu aplicación 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 (lo que se explica a continuación). 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).

Creación de 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 (en algunos casos) crear un recurso alternativo que actúe como un alias para un recurso guardado en su directorio de recursos predeterminados.

Nota: No todos los recursos ofrecen un mecanismo mediante el cual puedas crear un alias para otro recurso. En particular, los recursos de animación, de menú, sin procesar y de otro tipo no especificados del directorio xml/ no ofrecen esta función.

Por ejemplo, imagina que tienes un ícono de aplicación, icon.png, y necesitas una versión única de dicho ícono para diferentes configuraciones regionales. Sin embargo, dos configuraciones regionales, Inglés (Canadá) y Francés (Canadá), necesitan utilizar la misma versión. Quizá supongas que debes copiar la misma imagen en el directorio de recursos tanto para Inglés (Canadá) como para Francés (Canadá), pero no es así. En cambio, puedes guardar la imagen que se usa para ambos como icon_ca.png (cualquier nombre que no sea icon.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 mediante el elemento <bitmap>. Esto te permite almacenar una sola versión del archivo PNG y dos archivos XML pequeños que apuntan a dicho archivo PNG. (A continuación, se muestra un ejemplo de archivo XML).

Elemento de diseño

Para crear un alias para un elemento de diseño existente, usa el elemento <bitmap>. Por ejemplo:

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

Si guardas este archivo como icon.xml (en un directorio de recursos alternativos, como res/drawable-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 (guardado en res/drawable/).

Diseño

Para crear un alias para un diseño existente, usa el elemento <include>, dentro de un <merge>. Por ejemplo:

<?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 cual puedes hacer referencia como R.layout.main, pero en realidad es un alias del recurso R.layout.main_ltr .

Strings y otros valores simples

Para crear un alias para una string existente, simplemente utiliza el ID de recurso de la string deseada como el valor de la nueva string. Por ejemplo:

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

El recurso R.string.hi ahora es un alias para R.string.hello.

Otros valores simples funcionan de la misma manera. Por ejemplo, un color:

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

Provisión de la mejor compatibilidad de dispositivos con recursos

Para que tu aplicación admita varias configuraciones de dispositivos, es muy importante que siempre proporciones recursos predeterminados para cada tipo de recurso utilizado por tu aplicación.

Por ejemplo, si tu aplicación admite varios idiomas, incluye siempre un directorio values/ (en el cual se guardan tus strings) sin un calificador de idioma y región. En cambio, si colocas todos tus archivos de strings en directorios que tienen un calificador de idioma y región, tu aplicación fallará cuando se ejecute en un dispositivo configurado en un idioma que tus cadenas no admiten. Sin embargo, siempre que proporciones recursos values/ predeterminados, tu aplicación se ejecutará correctamente (aunque el usuario no comprenda ese idioma; es preferible esto a 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; por ejemplo, layout/ para la orientación horizontal y layout-port/ para la orientación vertical.

Proporcionar recursos predeterminados es importante no solo porque tu aplicación 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 aplicación, 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 fija en 4, y calificas todos tus recursos de elemento 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 se bloqueará. En este caso, probablemente, desees que notnight sean tus recursos predeterminados, por lo cual debes excluir ese calificador para que tus recursos de elemento 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 aplicación 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 aplicación es 4 o superior, no necesitas recursos de elementos de diseño predeterminados cuando proporcionas recursos de elemento 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 el mapa de bits según sea necesario. Sin embargo, a fin de brindar la mejor experiencia en todos los tipos de dispositivos, debes proporcionar elementos de diseño alternativos para los tres tipos de densidad.

Cómo Android encuentra el recurso de coincidencia óptima

Cuando solicitas un recurso para el cual proporcionas alternativas, Android selecciona qué recurso alternativo utilizar en tiempo de ejecución, según la configuración del dispositivo actual. Para demostrar cómo Android selecciona un recurso alternativo, supón que cada uno de los siguientes elementos de diseño contienen versiones diferentes de las mismas imágenes:

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

Y supón que la configuración del dispositivo es la siguiente:

Configuración regional = en-GB
Orientación de la pantalla = port
Densidad de píxeles de la pantalla = hdpi
Tipo de pantalla táctil = notouch
Método principal de entrada de texto = 12key

Al comparar la configuración del dispositivo con los recursos alternativos disponibles, Android selecciona elementos de diseño de drawable-en-port.

Para decidir qué recursos utilizar, el sistema se basa en la siguiente lógica:

Figura 2: Diagrama de flujo de la forma en la cual Android encuentra el recurso de coincidencia óptima.

  1. Eliminar los archivos de recursos que se contradicen con la configuración del dispositivo.

    El directorio drawable-fr-rCA/ se elimina porque se contradice con la configuración regional en-GB.

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

    Excepción: La densidad de píxeles de la pantalla es el único calificador que no se elimina debido a una contradicción. Aunque la densidad de la pantalla del dispositivo es hdpi, drawable-port-ldpi/ no se elimina porque todas las densidades de pantalla se consideran como una coincidencia en este punto. En el documento Admisión de varias pantallas se incluye más información.

  2. Elegir el (próximo) calificador de mayor precedencia de la lista (tabla 2). (Comenzar con MCC y continuar en forma descendente).
  3. ¿Alguno de los directorios de recursos incluye este calificador?
    • Si la respuesta es no, volver al paso 2 y examinar el siguiente calificador. (En el ejemplo, la respuesta es "no" hasta que se alcanza el calificador de idioma).
    • Si la respuesta es sí, continuar con el paso 4.
  4. Eliminar los directorios de recursos que no incluyen este calificador. En el ejemplo, el sistema elimina todos los directorios que no incluyen un calificador de idioma:
  5. drawable/
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    drawable-port-ldpi/
    drawable-port-notouch-12key/
    

    Excepción: Si el calificador en cuestión es la densidad de píxeles de la pantalla, Android selecciona la opción que más coincida con la densidad de la pantalla del dispositivo. En general, Android prefiere reducir una imagen original más grande que ampliar una imagen original más pequeña. Consulta Admisión de varias pantallas.

  6. Volver y repetir los pasos 2, 3 y 4 hasta que solo quede un directorio. En el ejemplo, la orientación de la pantalla es el próximo calificador para el cual existen coincidencias. Por lo tanto, se eliminan los recursos que no especifican una orientación de pantalla:
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    

    El directorio que queda es drawable-en-port.

Si bien este procedimiento se ejecuta para cada recurso solicitado, el sistema optimiza aún más algunos aspectos. Un ejemplo de esta optimización es que una vez que se conoce la configuración del dispositivo, el sistema podría eliminar los recursos alternativos que nunca coinciden. Por ejemplo, si el idioma de configuración es inglés ("en"), los directorios de recursos que tienen un calificador de idioma establecido en otro idioma que no sea inglés nunca se incluyen en el conjunto de recursos comprobados (sin embargo, un directorio de recursos sin el calificador de idioma sí se incluye).

Cuando se seleccionan recursos según los calificadores del tamaño de la pantalla, el sistema utilizará los recursos diseñados para una pantalla más pequeña que la pantalla actual si no existen recursos que coincidan mejor (por ejemplo, una pantalla de tamaño grande utilizará recursos de una pantalla de tamaño normal si es necesario). Sin embargo, si los únicos recursos disponibles presentan un tamaño superior al de la pantalla actual, el sistema no los usará y tu aplicación fallará si ningún otro recurso coincide con la configuración del dispositivo (por ejemplo, si todos los recursos de diseño están etiquetados con el calificador xlarge, pero el dispositivo es una pantalla de tamaño normal).

Nota: La precedencia del calificador (en la tabla 2) es más importante que la cantidad de calificadores que coinciden exactamente con el dispositivo. Por ejemplo, en el paso 4 mencionado anteriormente, la última opción de la lista incluye tres calificadores que coinciden exactamente con el dispositivo (orientación, tipo de pantalla táctil y método de entrada), mientras que drawable-en tiene un solo parámetro que coincide (idioma). Sin embargo, el idioma tiene mayor precedencia que estos otros calificadores, por lo tanto, drawable-port-notouch-12key se elimina.

Para obtener más información sobre la forma de utilizar recursos en tu aplicación, continúa con la sección Acceso a recurso.

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

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

* Required Fields

Hooray!

Browse this site in ?

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

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

This class requires API level or higher

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

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

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