Skip to content

Most visited

Recently visited

Results for

navigation

Compatibilidad con diferentes pantallas

Android se ejecuta en distintos dispositivos que ofrecen diferentes tamaños y densidades de pantallas. Para las aplicaciones, el sistema Android proporciona un entorno de desarrollo uniforme en todos los dispositivos y se encarga de la mayor parte del trabajo para adecuar la interfaz de usuario de cada aplicación a la pantalla en la que se muestra. Al mismo tiempo, el sistema proporciona las API que te permiten controlar la IU de tu aplicación para densidades y tamaños específicos de las pantallas, a fin de optimizar tu diseño de IU para configuraciones de pantalla diferentes. Por ejemplo, tal vez desees para las tablets una IU que se diferencie de la IU para teléfonos móviles.

Aunque el sistema realiza ajustes y cambios de tamaños para que tu aplicación funcione en diferentes pantallas, debes hacer el esfuerzo de optimizarla para diferentes tamaños y densidades de pantalla. Al hacer eso, maximizarás la experiencia del usuario en todos los dispositivos y tus usuarios creerán que tu aplicación en realidad está diseñada para sus dispositivos y no simplemente adaptada para ajustarse a las pantallas de sus dispositivos.

Al seguir las prácticas descritas en este documento, a través de un único archivo .apk podrás crear una aplicación que se visualice de manera apropiada y proporcione una experiencia de usuario optimizada en todas las configuraciones de pantalla compatibles.

Nota: En la información de este documento se da por sentado que tu aplicación está diseñada para Android 1.6 (nivel 4 de API) o versiones posteriores. Si tu aplicación admite Android 1.5 o versiones anteriores, lee las estrategias para Android 1.5.

Además, ten en cuenta que en Android 3.2 se presentaron API nuevas que te permiten controlar de un modo más preciso los recursos de diseño empleados por tu aplicación para diferentes tamaños de pantallas. Estas funciones nuevas son especialmente importantes si desarrollas una aplicación optimizada para tablets. Para obtener información detallada, consulta la sección Declaración de diseños de tablets para Android 3.2.

Información general sobre la compatibilidad de pantallas

En esta sección se proporciona información general sobre la compatibilidad de Android con pantallas múltiples. Se incluyen una introducción a los términos y conceptos usados en este documento y en la API, un resumen de las configuraciones de pantalla que el sistema admite e información general sobre la API y las funciones de compatibilidad de pantalla subyacentes.

Términos y conceptos

Tamaño de pantalla
Tamaño físico real para cuya medición se considera la diagonal de la pantalla.

Por cuestiones de simplicidad, en Android se agrupa todos los tamaños de pantallas reales en cuatro categorías generalizadas: pequeño, normal, grande y extragrande.

Densidad de pantalla
Cantidad de píxeles dentro de un área física de la pantalla, a la que en general se hace referencia como “dpi” (puntos por pulgada). Por ejemplo, una pantalla con “baja” densidad tiene menos píxeles dentro de un área física dada en comparación con una pantalla con densidad “normal” o “alta”.

Por cuestiones de simplicidad, en Android se agrupan todas las densidades de pantallas en seis categorías generalizadas: baja, media, alta, extraalta, extra extraalta y extra extra extraalta.

Orientación
Orientación de la pantalla desde el punto de vista del usuario. Es horizontal o vertical, lo cual significa que la relación de aspecto se considera a lo ancho o a lo alto, respectivamente. Ten en cuenta que no solo diferentes dispositivos funcionan en diferentes orientaciones de manera predeterminada. La orientación puede cambiar en tiempo de ejecución cuando el usuario gira el dispositivo.
Resolución
Número total de píxeles físicos en una pantalla. Cuando se agrega compatibilidad para pantallas múltiples, las aplicaciones no tienen una interacción directa con la resolución; se centran únicamente en la densidad y el tamaño de pantalla, como se especifica en los grupos de densidad y tamaño generalizados.
Píxeles independientes de la densidad (dp)
Unidad de píxeles virtuales que debes usar al definir el diseño de IU, para expresar las dimensiones o la posición del diseño con independencia de la densidad.

El píxel independiente de la densidad es equivalente a un píxel físico en una pantalla de 160 dpi, valor que representa la densidad de referencia que considera el sistema para una pantalla de densidad “media”. En el tiempo de ejecución, el sistema maneja de forma transparente cualquier ajuste de las unidades dp, cuando resulta necesario, según la densidad actual de la pantalla en uso. La conversión de unidades dp a píxeles de pantalla es simple: px = dp * (dpi / 160). Por ejemplo, en una pantalla de 240 dpi, 1 dp es igual a 1,5 píxeles físicos. Siempre debes usar unidades dp cuando defines la IU de tu aplicación, para asegurarte de que tu IU se muestre de manera apropiada en pantallas con diferentes densidades.

Variedad de pantallas compatibles

A partir de Android 1.6 (nivel de API 4), Android proporciona compatibilidad con diferentes tamaños y densidades de ventanas, lo cual refleja la variedad de configuraciones de pantalla que un dispositivo puede tener. Puedes usar las funciones del sistema Android a fin de optimizar la interfaz de usuario de tu aplicación para la configuración de cada pantalla y asegurarte de que tu aplicación no solo se represente de forma apropiada, sino también proporcione la mejor experiencia de usuario posible para cada pantalla.

Para facilitar el diseño de las interfaces de usuario con diferentes pantallas, Android divide la variedad de densidades y tamaños de pantalla reales en:

Las densidades y los tamaños generalizados se organizan conforme a una configuración de referencia que contempla un tamaño normal y una densidad mdpi (media). Esta referencia se basa en la configuración de pantalla del primer dispositivo con tecnología Android, el T-Mobile G1, que tiene una pantalla HVGA (hasta Android 1.6, esta fue la única configuración de pantalla compatible con Android ).

Cada densidad y tamaño generalizados se extienden en un rango de tamaños y densidades de la pantalla real. Por ejemplo, dos dispositivos que informan un tamaño de pantalla normal pueden tener en realidad tamaños de pantalla y relaciones de aspecto ligeramente diferentes cuando se miden de forma manual. De modo similar, dos dispositivos que transmiten una densidad de pantalla en hdpi puede tener densidades reales de píxeles ligeramente diferentes. Android hace que estas diferencias sean abstractas para las aplicaciones, de modo que puedes proporcionar una IU diseñada para densidades y tamaños generalizados, y dejar que el sistema se encargue de cualquier ajuste final cuando sea necesario. En la figura 1 se ejemplifica la manera en que los tamaños y las densidades diferentes se categorizan de un modo aproximado en diferentes grupos de tamaño y densidad.

Figura 1: Ilustración de la forma en que Android asigna de modo aproximado densidades y tamaños reales a densidades y tamaños generalizados (las cifras no son exactas).

Al diseñar tu IU para diferentes tamaños de pantalla, descubrirás que cada diseño requiere una cantidad mínima de espacio. Por lo tanto, cada tamaño de pantalla generalizado tiene una resolución mínima asociada definida por el sistema. Estos tamaños mínimos son en unidades “dp” (las mismas unidades que debes usar cuando defines tus diseños), lo cual permite que el sistema no deba tener en cuenta cambios en la densidad de pantalla.

Nota: Estos tamaños mínimos de pantalla no estaban bien definidos antes de Android 3.0, de modo que puedes encontrar algunos dispositivos mal clasificados entre el tamaño normal y el grande. Estos también se basan en la resolución física de la pantalla, de modo que pueden variar de un dispositivo a otro; por ejemplo, una tablet de 1024 x 720 con una barra de sistema tiene un poco menos de espacio disponible para la aplicación, ya que lo usa la barra de sistema.

A fin de optimizar la IU de tu aplicación para diferentes tamaños y densidades de pantallas, puedes proporcionar recursos alternativos para cualquiera de las densidades y los tamaños generalizados. Por lo general, debes proporcionar diseños alternativos para alguno de los diferentes tamaños de pantalla e imágenes de mapa de bits alternativas para diferentes densidades de pantalla. En el tiempo de ejecución, el sistema usa los recursos correspondientes para tu aplicación, según la densidad o el tamaño generalizados de la pantalla del dispositivo en cuestión.

No es necesario que proporciones recursos alternativos para cada combinación de tamaño y densidad de pantalla. El sistema proporciona funciones de compatibilidad sólidas que pueden manejar la mayor parte del trabajo de representación de tu aplicación en cualquier pantalla de dispositivo, siempre que implementes tu IU aplicando técnicas que le permitan cambiar el tamaño correctamente (como se describe en Prácticas recomendadas, a continuación).

Nota: Las características que definen la densidad y el tamaño generalizados de la pantalla de un dispositivo son independientes el uno del otro. Por ejemplo, una pantalla de alta densidad WVGA se considera como una pantalla de tamaño normal porque su tamaño físico es casi idéntico al de T-Mobile G1 (el primer dispositivo de la plataforma Android y la configuración de pantalla de referencia). Por otra parte, una pantalla WVGA de densidad media se considera como una pantalla de tamaño grande. Aunque ofrece la misma resolución (el mismo número de píxeles), la pantalla WVGA de densidad media tiene una densidad de pantalla inferior, lo cual significa que cada píxel es físicamente más grande y, por lo tanto, toda la pantalla es más grande que la pantalla de referencia (tamaño normal).

Independencia de la densidad

Tu aplicación alcanza la “independencia de densidad” cuando preserva el tamaño físico (desde el punto de vista del usuario) de los elementos de la interfaz de usuario cuando se muestran en pantallas con diferentes densidades.

Es importante mantener la independencia de la densidad, ya que sin ella misma un elemento de IU (como un botón) aparece con un tamaño físico más grande en una pantalla de baja densidad y más pequeño en una pantalla de alta densidad. Dichos cambios relacionados con la densidad pueden causar problemas en el diseño y la usabilidad de tu aplicación. En las figuras 2 y 3 se muestra la diferencia entre una aplicación que no proporciona independencia de densidad y una que sí lo hace, respectivamente.

Figura 2: El ejemplo de aplicación es incompatible con diferentes densidades, como se muestra en las pantallas de baja, media y alta densidad.

Figura 3: El ejemplo de aplicación tiene buena compatibilidad con las diferentes densidades (es independiente de la densidad), como se muestra en pantallas de densidad baja, media y alta.

El sistema Android permite que tu aplicación alcance la independencia de la densidad de dos maneras:

En la figura 2, la vista del texto y el elemento de diseño del mapa de bits tienen dimensiones especificadas en píxeles (unidades px), por lo cual son físicamente más grandes en una pantalla de densidad baja y más pequeñas en una de densidad alta. Esto se debe a que, si bien los tamaños de pantalla actuales pueden ser los mismos, la pantalla de alta densidad tiene más píxeles por pulgada (la misma cantidad de píxeles caben en un área más pequeña). En la figura 3, las dimensiones de diseño se especifican en píxeles independientes de la densidad (unidades dp). Debido a que la referencia para los píxeles independientes de la densidad es una pantalla de densidad media, la visualización en el dispositivo con pantalla de densidad media es igual que en la figura 2. Sin embargo, para las pantallas de baja y alta densidad, el sistema ajusta hacia arriba y hacia abajo los valores de píxeles independientes de la densidad, respectivamente, a fin de regular la pantalla según corresponda.

En la mayoría de los casos, puedes asegurar la independencia de la densidad en tu aplicación simplemente especificando todos los valores de dimensión de diseño en píxeles independientes de la densidad (unidades dp) o con "wrap_content", según corresponda. Luego, el sistema ajusta los elementos de diseño del mapa de bits según corresponda para mostrarlo en el tamaño apropiado, según el factor de ajuste apropiado para la densidad de la pantalla actual.

Sin embargo, el ajuste del mapa de bits puede dar como resultado mapas de bits borrosos o pixelados, como puedes observar en las capturas de pantalla anteriores. A fin de evitar estas alteraciones, debes proporcionar recursos de mapas de bits alternativos para densidades diferentes. Por ejemplo, debes proporcionar mapas de bits de resolución más alta para las pantallas de alta densidad. El sistema usará estos en lugar de cambiar el mapa de bits diseñado para pantallas de densidad media. En la siguiente sección se describe en mayor detalle la manera de proporcionar recursos alternativos para las diferentes configuraciones de pantalla.

Cómo admitir pantallas múltiples

El aspecto básico de la compatibilidad de Android con pantallas múltiples es su capacidad para manejar la representación del diseño y de los elementos de diseño de mapa de bits de una aplicación de manera apropiada según la configuración de la pantalla actual. El sistema se encarga de la mayor parte del trabajo para representar tu aplicación de modo apropiado en la configuración de cada pantalla ajustando diseños para que se adecuen al tamaño y a la densidad de la pantalla, y también los elementos de diseño del mapa de bits según la densidad de pantalla, según corresponda. Sin embargo, para manejar correctamente las diferentes configuraciones también debes hacer lo siguiente:

Nota: Ubica todos los íconos lanzadores en las carpetas res/mipmap-[density]/ en lugar de las carpetas res/drawable-[density]/. El sistema de Android retiene los recursos en estas carpetas de densidad específica, como mipmap-xxxhdpi, sin importar la resolución de pantalla del dispositivo donde se instala tu app. Este comportamiento permite que las apps de lanzador elijan el ícono con mejor resolución para que tu app se muestre en la pantalla principal. Para obtener más información sobre el uso de las carpetas mipmap, consulta Información general sobre la administración de proyectos.

Los calificadores de la configuración de densidad y tamaño se corresponden con los tamaños y las densidades generalizados que se describen en Variedad de pantallas compatibles, arriba.

Nota: Si no conoces los calificadores de configuración ni el modo en que el sistema los usa para aplicar recursos alternativos, lee Proporcionar recursos alternativos para obtener más información.

En el tiempo de ejecución, el sistema garantiza la mejor visualización posible en la pantalla en cuestión con el siguiente procedimiento para cualquier recurso dado:

  1. El sistema usa el recurso alternativo correspondiente

    Según el tamaño y la densidad de la pantalla actual, el sistema usa cualquier recurso específico de tamaño y densidad proporcionado en tu aplicación. Por ejemplo, si el dispositivo tiene una pantalla de densidad alta y la aplicación solicita un recurso de elemento de diseño, el sistema busca un directorio de recursos de elementos de diseño que coincida mejor con la configuración del dispositivo. Según los demás recursos alternativos disponibles, un directorio de recursos con el calificador hdpi (como drawable-hdpi/) puede ser la mejor coincidencia, de modo que el sistema usa el recurso del elemento de diseño de este directorio.

  2. Si no hay disponibles recursos de coincidencia, el sistema usa el predeterminado y lo aumenta o reduce según sea necesario para adaptarlo a la densidad y al tamaño de la pantalla en cuestión.

    Los recursos “predeterminados” son aquellos que no se etiquetan con un calificador de configuración. Por ejemplo, los recursos de drawable/ son los recursos de elementos de diseño predeterminados. El sistema da por sentado que los recursos predeterminados están diseñados para la densidad y el tamaño de pantalla de referencia, que representan un tamaño normal y una densidad media. Como tal, el sistema aumenta los recursos de densidad predeterminados para las pantallas de densidad alta y los disminuye para las pantallas de densidad baja, según corresponda.

    Sin embargo, cuando el sistema busque un recurso específico de densidad y no lo encuentre en el directorio específico de densidad, no siempre usará los recursos predeterminados. En cambio, puede usar uno de los demás recursos específicos de densidad para proporcionar mejores resultados durante el ajuste. Por ejemplo, cuando se busca un recurso de densidad baja y este no se encuentra disponible, el sistema opta por disminuir la versión de densidad alta del recurso, ya que sistema puede disminuir con facilidad un recurso de densidad alta a uno de densidad baja por un factor de 0,5, con menos alteraciones, en comparación con el ajuste de un recurso de densidad media por un factor de 0,75.

Para obtener más información sobre cómo Android selecciona recursos alternativos adecuando los calificadores de configuración a la configuración del dispositivo, lee Cómo Android encuentra el recurso de coincidencia óptima.

Uso de calificadores de configuración

Android admite varios calificadores de configuración que te permiten controlar la forma en que el sistema selecciona tus recursos alternativos según las características de la pantalla del dispositivo en cuestión. Un calificador de configuración es una string que puedes anexar al directorio de recursos de tu proyecto de Android y especifica la configuración para la cual se diseñan los recursos incluidos.

Para usar un calificador de configuración:

  1. Crea un directorio nuevo en el directorio de tu proyecto res/ y llámalo usando el formato <resources_name>-<qualifier>.
    • <resources_name> es el nombre del recurso estándar (como drawable o layout).
    • <qualifier> es un calificador de configuración de la tabla 1, a continuación, que especifica la configuración de pantalla para la cual se usan estos recursos (como hdpi o xlarge).

    Puedes usar más de un <qualifier> a la vez (simplemente separando cada calificador con un guión).

  2. Guarda los recursos específicos de configuración en este directorio nuevo. Los archivos de recursos deben llevar exactamente el mismo nombre que los archivos de recursos predeterminados.

Por ejemplo, xlarge es un calificador de configuración para pantallas extragrandes. Cuando anexas esta string a un nombre de directorio de recursos (como layout-xlarge), esta indica al sistema que los recursos deben usarse en dispositivos que cuenten con una pantalla extragrande.

Tabla 1: Calificadores de configuración que te permiten proporcionar recursos especiales para diferentes configuraciones de pantalla.

Características de la pantalla Calificador Descripción
Tamaño small Recursos para pantallas de tamaño pequeño.
normal Recursos para pantallas de tamaño normal. (Este es el tamaño de referencia).
large Recursos para pantallas de tamaño grande.
xlarge Recursos para pantallas de tamaño extragrande.
Densidad ldpi Recursos para pantallas de densidad baja (ldpi) (~120 dpi).
mdpi Recursos para pantallas de densidad media (mdpi) (~160 dpi). (Esta es la densidad de referencia).
hdpi Recursos para pantallas de densidad alta (hdpi) (~240 dpi).
xhdpi Recursos para pantallas de densidad extraalta (xhdpi) (~320 dpi).
xxhdpi Recursos para pantallas de densidad extra extraalta (xxhdpi) (~480 dpi).
xxxhdpi Recursos para usos de densidad extra extra extraalta (xxxhdpi) (~640 dpi). Usa esto únicamente para el ícono lanzador, consulta la nota anterior.
nodpi Recursos para todas las densidades. Estos son recursos independientes de la densidad. El sistema no ajusta recursos que reciben etiquetas con este calificador, independientemente de la densidad de pantalla actual.
tvdpi Recursos para pantallas entre mdpi y hdpi; aproximadamente 213 dpi. Este no se considera un grupo de densidad “primario”. Se usa principalmente para televisiones, y la mayoría de las aplicaciones no lo necesitarán; con recursos mdpi y hdpi será suficiente para la mayoría de las apps y el sistema los ajustará según corresponda. Si crees necesario proporcionar recursos tvdpi, debes ajustar su tamaño con un factor de 1,33*mdpi. Por ejemplo, una imagen de 100 x 100 px para pantallas mdpi debe ser de 133 x 133 px para tvdpi.
Orientación land Recursos para pantallas con orientación horizontal (relación de aspecto ancha).
port Recursos para pantallas con la orientación vertical (relación de aspecto alta).
Relación de aspecto long Recursos para pantallas con una relación de aspecto considerablemente más alta o ancha (con orientación vertical u horizontal, respectivamente) que la configuración de pantalla de referencia.
notlong Recursos para pantallas con una relación de aspecto similar a la configuración de pantalla de referencia.

Nota: Si desarrollas tu aplicación para Android 3.2 y versiones posteriores, consulta la sección Declaración de diseños de tablets para Android 3.2 para obtener información acerca de los calificadores nuevos de configuración que debes usar cuando declares recursos de diseño para tamaños de pantalla específicos (en lugar de usar los calificadores de tamaño en la tabla 1).

Para obtener más información sobre cómo estos calificadores se corresponden aproximadamente con las densidades y los tamaños de la pantalla real, consulta la sección anterior Variedad de pantallas compatibles de este documento.

Por ejemplo, en los siguientes directorios de recursos de la aplicación se proporcionan diferentes diseños para diferentes tamaños de pantalla y diferentes elementos de diseño. Usa las carpetas mipmap/ para los íconos lanzadores.

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

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

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

Para obtener más información sobre cómo usar recursos alternativos y una lista completa de calificadores de configuración (no solo para configuraciones de pantalla), consulta Provisión de recursos alternativos.

Ten en cuenta que el sistema Android, cuando elige los recursos que usará en el tiempo de ejecución, usa cierta lógica para determinar los recursos de “coincidencia óptima”. Es decir, no es necesario que los calificadores que usas deban coincidir exactamente con la configuración de pantalla actual en todos los casos para que el sistema los use. Cuando se seleccionen recursos según los calificadores de tamaño de la pantalla, el sistema usará los recursos diseñados para una pantalla más pequeña que la actual si no existen recursos que coincidan mejor (por ejemplo, para una pantalla de tamaño grande se usarán 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). Para obtener más información sobre cómo el sistema selecciona recursos, lee Cómo Android encuentra el recurso de coincidencia óptima.

Sugerencia: Si en tu caso hay algunos recursos de elementos de diseño que el sistema no debe ajustar nunca (tal vez porque realizas tú mismo algunos ajustes en la imagen en el tiempo de ejecución), debes ubicarlos en un directorio con el calificador de configuración nodpi. Los recursos con este calificador se consideran independientes de la densidad y el sistema nos los ajustará.

Creación diseños y elementos de diseño alternativos

Los tipos de recursos alternativos que debes crear dependen de las necesidades de tu aplicación. Por lo general, debes usar los calificadores de tamaño y orientación para proporcionar recursos alternativos de diseño, y los calificadores de densidad para proporcionar recursos alternativos de elementos de diseño de mapa de bits.

En las siguientes secciones, se resume la manera en que probablemente te convenga usar los calificadores de tamaño y densidad para proporcionar diseños y elementos de diseño alternativos, respectivamente.

Diseños alternativos

En general, sabrás si necesitas diseños alternativos para diferentes tamaños de pantalla una vez que pruebes tu aplicación en diferentes configuraciones de pantalla. Por ejemplo:

En resumen, debes asegurarte de que el diseño de tu aplicación:

Si la IU usa mapas de bits que necesitan adecuarse al tamaño de una vista incluso después de que el sistema se ajusta al diseño (como la imagen de fondo para un botón), debes usar archivos de mapas de bits nine-patch. Un archivo nine-patch es básicamente un archivo PNG en el que se especifican dos regiones dimensionales que se pueden estirar. Cuando el sistema necesita ajustar la vista en la que se usa el mapa de bits, estira el mapa de bits nine-patch, pero solo lo hace en las secciones específicas. Por lo tanto, no necesitas proporcionar diferentes elementos de diseño para diferentes tamaños de pantalla, ya que el mapa de bits nine-patch se puede ajustar a cualquier tamaño. Sin embargo, debes proporcionar versiones alternativas de tus archivos nine-patch para diferentes densidades de pantallas.

Elementos de diseño alternativos

Figura 4: Tamaños relativos para elementos de diseño de mapa de bits que admiten la densidad.

Casi todas las aplicaciones deben tener recursos alternativos de elementos de diseño para diferentes densidades de pantalla, porque en casi todas hay un ícono lanzador y ese ícono debe verse bien en todas las densidades de pantalla. Del mismo modo, si incluyes otros elementos de diseño de mapa de bits en tu aplicación (como para íconos del menú u otros gráficos en de esta), debes proporcionar versiones alternativas de cada uno para diferentes densidades.

Nota: Solo debes proporcionar elementos de diseño específicos de densidad para archivos de mapa de bits (.png, .jpg, o .gif) y archivos nine-patch (.9.png). Si usas archivos XML para definir formas, colores u otros recursos de elementos de diseño, debes disponer una copia en el directorio de elementos de diseño predeterminados (drawable/).

Si deseas crear elementos de diseño alternativos de mapa de bits para diferentes densidades, debes seguir la relación de ajuste de escala 3:4:6:8:12:16 entre las seis densidades generalizadas. Por ejemplo, si tienes un elemento de diseño de mapa de bits de 48 x 48 píxeles para pantallas de densidad media, todos los tamaños diferentes deben ser:

Para obtener más información acerca del diseño de íconos, consulta las Pautas para el diseño de íconos, en las que se incluye información sobre tamaño para varios elementos de diseño de mapa de bits, como íconos lanzadores, de menú, de barra de estado y de pestañas, entre otros.

Declaración de diseños de tablets para Android 3.2

Para la primera generación de tablets con Android 3.0, la manera apropiada de declarar los diseños para tablets fue disponerlos en un directorio con el calificador de configuración xlarge (por ejemplo, res/layout-xlarge/). Para contemplar tablets y pantallas de otros tamaños (en particular, las tablets de 7”), en Android 3.2 se introdujo un modo nuevo de especificar recursos para tamaños de pantalla más discretos. La técnica nueva se centra en el espacio que necesita tu diseño (por ejemplo, 600 dp de ancho) en lugar de la adaptación de tu diseño a los grupos de tamaño generalizados (como grande o extragrande).

La razón por la cual el diseño para tablets de 7” es engañoso cuando se usan grupos de tamaños generalizados es que una tablet de 7” se encuentra técnicamente en el mismo grupo que un teléfono móvil de 5” (el grupo grande). Aunque estos dos dispositivos parecen tener tamaños parecidos, el espacio para la IU de una aplicación es considerablemente distinto, como lo es el estilo de interacción con el usuario. Por lo tanto, una pantalla de 7 y 5” no debe usar siempre el mismo diseño. A fin de que puedas proporcionar diferentes diseños para estos dos tipos de pantallas, ahora Android te permite especificar tus recursos de diseño según el ancho o alto disponible para el diseño de tu aplicación, especificado en unidades dp.

Por ejemplo, después de realizar el diseño que desees usar para dispositivos similares a las tablets, puedes determinar que el diseño deje de funcionar bien cuando la pantalla mida menos de 600 dp de ancho. Por lo tanto, este límite se convertirá en el tamaño mínimo que requieres para el diseño de tu tablet. Es por eso que ahora podrás especificar que estos recursos de diseño se deban usar solo cuando haya al menos 600 dp de ancho disponible para la IU de tu aplicación.

Puedes elegir un ancho y tomarlo como el tamaño mínimo para el diseño o probar el ancho más pequeño que admita tu diseño una vez que esté completo.

Nota: Recuerda que todas las figuras que se usan con estos nuevos tamaños de API son valores de píxeles independientes de la densidad (dp) y tus dimensiones de diseño también se deben definir usando unidades dp, porque lo importante es la cantidad de espacio de pantalla disponible una vez que el sistema da cuenta de la densidad de pantalla (en contraposición al uso de la resolución en píxeles sin procesar). Para obtener más información sobre los píxeles independientes de la densidad, lee la sección previa Términos y conceptos en este documento.

Uso de calificadores de tamaños nuevos

Las diferentes configuraciones de recursos que puedes especificar según el espacio disponible para tu diseño se resumen en la tabla 2. Estos calificadores nuevos te ofrecen un mayor control sobre los tamaños de pantalla específicos que admite tu aplicación, en comparación con los grupos de tamaño de pantalla tradicionales (pequeño, normal, grande y extragrande).

Nota: Los tamaños que especificas usando estos calificadores son los tamaños de pantalla reales. En cambio, los tamaños son para el ancho y alto en unidades dp disponibles para la ventana de tu actividad. El sistema Android puede usar una parte de la pantalla para la IU del sistema (como la barra de estado en la parte inferior o superior de la pantalla). Por ello, es probable que parte de la pantalla no esté disponible para tu diseño. Por lo tanto, los tamaños que declaras deben estar específicamente relacionados con los tamaños que necesita tu actividad; el sistema da cuenta de cualquier espacio usado por la IU del sistema cuando se declara el espacio que proporciona para tu diseño. También ten en cuenta que la barra de acciones se considera como parte del espacio de la ventana de tu aplicación, aunque no se declare en tu diseño, de modo que reduce el espacio disponible para tu diseño y debes contemplarlo en este.

Tabla 2: Calificadores de la configuración nueva para el tamaño de pantalla (presentado en Android 3.2).

Configuración de la pantallaValores de calificadoresDescripción
smallestWidth sw<N>dp

Ejemplos:
sw600dp
sw720dp

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.

Esta es una alternativa para los calificadores de tamaño de pantalla generalizados (pequeño, normal, grande y extragrande) que te permite definir un número discreto para el tamaño efectivo disponible para tu IU. El uso de smallestWidth 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 también se desplazará en sentido vertical, pero tiene restricciones bastante difíciles en el espacio mínimo que requiere 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 para cada dispositivo.
Ancho de pantalla disponible w<N>dp

Ejemplos:
w720dp
w1024dp

Especifica un ancho de pantalla mínimo disponible, en unidades “dp”, a la que se deben usar los recursos (definido por el valor <N>). El valor correspondiente del sistema para el ancho cambia cuando la orientación de la pantalla se alterna entre los modos horizontal y vertical, a fin de reflejar el ancho actual disponible para tu IU.

Esto a menudo resulta útil para determinar si debe usarse un diseño de varios paneles, ya que incluso en una tablet a menudo no te convendrá para la orientación vertical el mismo diseño de varios paneles que desees para la horizontal. Por lo tanto, puedes usar esto para especificar el ancho mínimo que se requiere para el diseño, en lugar de usar el tamaño de pantalla y los calificadores de orientación juntos.
Altura de pantalla disponible h<N>dp

Ejemplos:
h720dp
h1024dp
etc.

Especifica un altura de pantalla mínima, en unidades “dp”, a la que se deben usar los recursos (definida por el valor <N>). El valor correspondiente del sistema para la altura cambia cuando la orientación de la pantalla se alterna entre los modos horizontal y vertical, a fin de reflejar la altura actual disponible para tu IU.

El uso de esto para definir la altura que requiere tu diseño tiene la misma utilidad que la de w<N>dp para definir el ancho requerido, en lugar de usar los calificadores de tamaño y orientación de pantalla. Sin embargo, la mayoría de las apps no necesitarán este tipo de calificadores, considerando que las IU a menudo se desplazan en sentido vertical y son más flexibles con la altura disponible, mientras que el ancho es más rígido.

Aunque usar estos calificadores puede parecer más complicado que usar grupos de tamaños de pantalla, en realidad debe ser más simple una vez que determinas los requisitos para tu IU. Cuando diseñas tu IU, lo que probablemente más te importe sea el tamaño real en el que tu aplicación cambie entre una IU para teléfonos móviles y una IU para tablet que usa varios paneles. El punto exacto de este cambio dependerá de tu diseño particular; tal vez necesites un ancho de 720 dp para el diseño de tu tablet, tal vez 600 dp sean suficientes o 480 dp, o un número entre estos. Al usar estos calificadores en la tabla 2, tienes el control del tamaño preciso en el que cambia tu diseño.

Para obtener más información acerca de estos calificadores de configuración de tamaño, consulta el documento de Provisión de recursos.

Ejemplos de configuración

Con el propósito de ayudarte a alcanzar algunos de tus diseños para diferentes tipos de dispositivos, a continuación se ofrecen algunos números para los anchos típicos de la pantalla:

Al usar los calificadores de tamaño de la tabla 2, tu aplicación puede cambiar entre tus diferentes recursos de diseño para teléfonos móviles y tablets usando cualquier número que desees para el ancho o la altura. Por ejemplo, si 600 dp es el ancho mínimo disponible que admite el diseño de tu tablet, puedes proporcionar estos dos conjuntos de diseños:

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

En este caso, el ancho mínimo del espacio de pantalla disponible debe ser de 600 dp para que se aplique el diseño de la tablet.

Para otro casos en los cuales desees personalizar más tu IU a fin de diferenciar los tamaños, como los de tablets de 7 y 10”, puedes definir diseños adicionales de anchos mínimos:

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

Ten en cuenta que en los dos conjuntos de recursos de ejemplos anteriores se usa el calificador de “ancho mínimo”, sw<N>dp, que especifica el más pequeño de los dos lados de la pantalla, sin importar la orientación actual del dispositivo. Entonces, usar sw<N>dp es una manera simple de especificar el tamaño de pantalla general disponible para tu diseño ignorando la orientación de la pantalla.

Sin embargo, en algunos casos, lo que puede ser importante para tu diseño es conocer con exactitud el ancho o la altura actualmente disponibles. Por ejemplo, si tienes un diseño de dos paneles con dos fragmentos uno al lado del otro, tal vez te convenga usarlo cada vez que la pantalla proporcione al menos 600 dp de ancho, independientemente de que la orientación del dispositivo sea horizontal o vertical. En este caso, tus recursos podrían verse de la siguiente manera:

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

Ten en cuenta que en el segundo conjunto se usa el calificador de “ancho disponible” w<N>dp. De esta manera, un dispositivo puede en realidad usar ambos diseños según la orientación de la pantalla (si el ancho disponible es de al menos 600 dp en una orientación y de menos de 600 dp en la otra orientación).

Si la altura disponible es importante para ti, puedes hacer lo mismo usando el calificador h<N>dp. También puedes, incluso, combinar los calificadores w<N>dp y h<N>dp si necesitas ser realmente específico.

Declaración de compatibilidad con tamaños de pantalla

Una vez que implementes tus diseños para diferentes tamaños de pantalla, tendrá la misma importancia declarar en tu archivo de manifiesto las pantallas compatibles con tu aplicación.

Además de los calificadores de los nuevos calificadores de configuración para el tamaño de pantalla, en Android 3.2 se introducen atributos nuevos para el elemento de manifiesto <supports-screens>:

android:requiresSmallestWidthDp
Especifica el smallestWidth mínimo obligatorio. El valor smallestWidth es la dimensión más corta del espacio de la pantalla (en unidades dp) que deben estar disponibles para la IU de tu aplicación; es decir, la más corta de las dos dimensiones de pantalla disponibles. Por lo tanto, para que un dispositivo se considere compatible con tu aplicación, el valor smallestWidth del dispositivo debe ser igual o superior a este valor. (Por lo general, el valor que proporciones para esto será el “ancho mínimo” que tu diseño admita, independientemente de la orientación actual de la pantalla).

Por ejemplo, si tu aplicación es solo para dispositivos como tablets con el mínimo ancho disponible de 600 dp:

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

Sin embargo, si tu aplicación admite todos los tamaños de pantalla compatibles con Android (hasta 426 x 320 dp), no necesitarás declarar este atributo porque el ancho mínimo que requiere tu aplicación es el mínimo posible en cualquier dispositivo.

Advertencia: El sistema Android no tiene en cuenta este atributo, por lo cual no afecta el comportamiento de tu aplicación en el tiempo de ejecución. Como alternativa, se usa para habilitar el filtrado de tu aplicación en servicios como Google Play. Sin embargo, actualmente Google Play no admite este atributo para el filtrado (en Android 3.2). Por ello, debes continuar usando los otros atributos de tamaño si tu aplicación no es compatible con pantallas pequeñas.

android:compatibleWidthLimitDp
Este atributo te permite habilitar el modo de compatibilidad de pantalla como una función opcional del usuario especificando el máximo “ancho mínimo” que admite tu aplicación . Si el lado más pequeño de una pantalla disponible del dispositivo es mayor que tu valor aquí, los usuarios pueden de todos modos instalar tu aplicación, pero se les ofrece ejecutarla en el modo de compatibilidad de pantalla. De forma predeterminada , el modo de compatibilidad de pantalla está inhabilitado y se ajusta el tamaño de tu diseño para que quepa en la pantalla como de costumbre, pero hay un botón disponible en la barra del sistema que permite a los usuarios activar o desactivar el modo de compatibilidad de pantalla.

Nota: Si el tamaño del diseño de tu aplicación se ajusta de manera apropiada para pantallas grandes, no es necesario que uses este atributo. Te recomendamos evitar usar este atributo y, como alternativa, asegurarte de que el tamaño de tu diseño se ajuste para pantallas más grandes siguiendo las recomendaciones de este documento.

android:largestWidthLimitDp
Este atributo te permite forzar la habilitación del modo de compatibilidad de pantalla especificando el máximo “ancho mínimo” que admite tu aplicación. Si el lado más pequeño de la pantalla disponible de un dispositivo es superior a tu valor aquí, la aplicación se ejecuta en el modo de compatibilidad de pantalla y el usuario no tiene manera de inhabilitarlo.

Nota: Si el tamaño del diseño de tu aplicación se ajusta de manera apropiada para pantallas grandes, no es necesario que uses este atributo. Te recomendamos evitar usar este atributo y, como alternativa, asegurarte de que el tamaño de tu diseño se ajuste para pantallas más grandes siguiendo las recomendaciones de este documento.

Advertencia: Cuando realices desarrollos para Android 3.2 y versiones posteriores, no debes usar atributos de tamaño de pantalla anteriores combinados con los atributos mencionados arriba. El uso simultáneo de los atributos nuevos y los atributos de tamaño anteriores puede causar un comportamiento inesperado.

Para obtener más información sobre cada uno de estos atributos, sigue los vínculos respectivos antes mencionados.

Prácticas recomendadas

El objetivo de la compatibilidad con varias pantallas es crear una aplicación que pueda funcionar de manera apropiada y verse bien en cualquiera de las configuraciones generalizadas de pantalla compatibles con Android. En las secciones previas de este documento, se proporciona información sobre cómo Android adapta tu aplicación a las configuraciones de la pantalla y cómo puedes personalizar la apariencia de la aplicación en diferentes configuraciones de pantalla. En esta sección se proporcionan algunos consejos adicionales e información general sobre técnicas que garantizan que tu aplicación se ajuste de manera apropiada en diferentes configuraciones de pantalla.

A continuación, se ofrece una lista de comprobación que te permitirá asegurarte de que tu aplicación se muestre de manera apropiada en diferentes pantallas:

  1. Usa wrap_content, match_parent o unidades dp al especificar las dimensiones en un archivo de diseño XML.
  2. No uses valores de píxeles codificados en el código de tu aplicación.
  3. No uses AbsoluteLayout (dejó de estar disponible).
  4. Proporciona diferentes elementos de diseño de mapa de bits para diferentes densidades de pantalla.

En las siguientes secciones se proporciona más información.

1. Usa wrap_content, match_parent o la unidad dp para dimensiones de diseño.

Al definir android:layout_width y android:layout_height para visualizaciones en un archivo de diseño XML, el uso de "wrap_content", "match_parent" o unidades dp garantiza que se asigne a la vista un tamaño apropiado en la pantalla del dispositivo en cuestión.

Por ejemplo, una visualización con layout_width="100dp" mide 100 píxeles de ancho en una pantalla de densidad media y el sistema la amplía a 150 en una pantalla de densidad alta, de modo que la visualización ocupe aproximadamente el mismo espacio físico en la pantalla.

Asimismo, tal vez prefieras sp (píxeles independientes de la escala) para definir los tamaños de textos. El factor de escala sp depende de la configuración del usuario y el sistema ajusta el tamaño como lo hace para dp.

2. No uses valores de píxeles codificados en el código de tu aplicación

Por cuestiones de rendimiento y para que el código sea más simple, el sistema Android usa píxeles como la unidad estándar para expresar la dimensión o coordinar los valores. Eso significa que las dimensiones de una visualización siempre se expresan en el código usando píxeles, pero siempre según la densidad de la pantalla en cuestión. Por ejemplo, si myView.getWidth() muestra 10, la visualización es de 10 píxeles de ancho en la pantalla, pero en un dispositivo con una pantalla con densidad más alta, el valor que se muestra puede ser 15. Si usas valores de píxeles en el código de tu aplicación para trabajar con los mapas de bits que no se ajusten previamente para la densidad de pantalla actual, tal vez necesites ajustar los valores de píxeles que uses en tu código para que coincidan con la fuente de mapa de bits sin ajustar.

Si tu aplicación manipula mapas de bits o aplica valores de píxeles en el tiempo de ejecución, consulta la sección Consideraciones adicionales sobre la densidad, a continuación.

3. No uses AbsoluteLayout

A diferencia de otros widgets de diseño, AbsoluteLayout refuerza el uso de posiciones fijas para distribuir sus vistas secundarias, lo cual puede fácilmente impedir el correcto funcionamiento de las interfaces de usuario en diferentes pantallas. Por este motivo, AbsoluteLayout dejó de estar disponible en Android 1.5 (nivel de API 3).

Como alternativa, debes usar RelativeLayout, que aplica posicionamiento relativo para distribuir las vistas secundarias. Por ejemplo, puedes especificar que un widget de botón aparezca “a la derecha de” un widget de texto.

4. Usa recursos específicos de densidad y tamaño

Aunque el sistema ajuste tus recursos de elementos de diseño según la configuración de la pantalla en cuestión, te convendrá realizar ajustes en la IU en diferentes tamaños de pantallas y proporcionar elementos de diseño del mapa de bits que se optimicen para diferentes densidades. Aquí prácticamente se reitera la información antes presentada en este documento.

Si necesitas controlar exactamente el aspecto que tendrá tu aplicación en diferentes configuraciones de pantalla, ajusta tus diseños y elementos de diseño en los directorios de recursos específicos de configuración. Por ejemplo, ten en cuenta un ícono que desees mostrar en pantallas de densidad alta y media. Simplemente, crea tu ícono en dos tamaños diferentes (por ejemplo, 100 x 100 para la densidad media y 150 x 150 para la alta) y dispón las dos variaciones en los directorios correspondientes usando los calificadores adecuados:

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

Nota: Si un calificador de densidad no se define en un nombre de directorio, el sistema supone que los recursos de ese directorio no están diseñados para la densidad media de referencia y se ajustará para otras densidades, según corresponda.

Para obtener más información sobre los calificadores válidos de configuración, consulta la sección anterior Uso de calificadores de configuración en este documento.

Consideraciones adicionales sobre la densidad

En esta sección se ofrece más información sobre cómo Android realiza ajustes para elementos de diseño del mapa de bits en diferentes densidades de pantalla y cómo puedes controlar más la manera en que se dibujan los mapas de bits en diferentes densidades. La información en esta sección no debe ser importante para la mayoría de las aplicaciones, a menos que hayas encontrado problemas en tu aplicación al ejecutarla con diferentes densidades de pantalla o cuando esta manipule gráficos.

Para entender mejor la manera de admitir varias densidades cuando se manipulan gráficos en el tiempo de ejecución, debes tener claro que el sistema ayuda a garantizar la escala apropiada para los mapas de bits de las siguientes maneras:

  1. Ajuste previo de los recursos (como elementos de diseño del mapa de bits)

    Según la densidad de la pantalla en cuestión, el sistema usa cualquier tamaño o densidad de recursos específicos de tu aplicación y los muestra sin ajustes. Si los recursos no se encuentran disponibles en la densidad correcta, el sistema carga los recursos predeterminados y los amplía o reduce para hacerlos coincidir con la densidad de la pantalla actual. El sistema prevé que los recursos predeterminados (los de un directorio sin calificadores de configuración) están diseñados para la densidad de referencia de la pantalla (mdpi), a menos que se carguen desde un directorio de recursos específicos de densidad. El ajuste previo, por lo tanto, es lo que el sistema hace cuando se cambia el tamaño de un mapa de bits al tamaño apropiado para la densidad de la pantalla en cuestión.

    Si solicitas las dimensiones de un recurso previamente ajustado, el sistema muestra valores que representan las dimensiones después del ajuste. Por ejemplo, un mapa de bits con un diseño de 50 x 50 píxeles para una pantalla mdpi se ajusta a 75 x 75 píxeles en una pantalla hdpi (si no hay un recurso alternativo para hdpi) y el sistema informa el tamaño como tal.

    Hay algunas situaciones en las cuales tal vez no te convenga que Android ajuste previamente un recurso. La manera más sencilla de evitar el ajuste previo es disponer el recurso en un directorio de recursos con el nodpi calificador de configuración. Por ejemplo:

    res/drawable-nodpi/icon.png

    Cuando el sistema usa el mapa de bits icon.png de esta carpeta, no lo ajusta según la densidad del dispositivo actual.

  2. El ajuste automático de dimensiones y coordenadas de píxeles

    Una aplicación puede inhabilitar el ajuste previo fijando android:anyDensity en "false" en el manifiesto o, de manera programática para un Bitmap, fijando inScaled en "false". En este caso, el sistema ajusta de manera automática cualquier coordenada absoluta de píxeles y valores de dimensión de píxeles en el momento de la representación. Hace esto para garantizar que los elementos de pantalla definidos por píxeles se muestren, de todos modos, en el mismo tamaño físico que tendrían en la densidad de pantalla de referencia (mdpi). El sistema maneja este ajuste de forma transparente en la aplicación e informa las dimensiones de píxeles ajustados para la aplicación, en lugar de las dimensiones de píxeles físicos.

    Por ejemplo, supongamos que un dispositivo tiene una pantalla de densidad alta WVGA, que tiene 480 x 480 y cerca del mismo tamaño que una pantalla HVGA tradicional, pero ejecuta una aplicación que inhabilita el ajuste previo. En este caso, el sistema le “mentirá” a la aplicación cuando consulte las dimensiones de pantalla y transmitirá un valor de 320 x 533 (la traducción mdpi aproximada para la densidad de la pantalla. Luego, cuando la aplicación realice las operaciones de dibujos, como la invalidación del rectángulo de (10, 10) a (100, 100), el sistema transforma las coordenadas aplicándoles el ajuste correspondiente e invalida la región (15, 15) a (150, 150). Esta discrepancia puede generar un comportamiento inesperado si tu aplicación manipula de manera directa el mapa de bits ajustado, pero esto se considera como un intercambio razonable para que el rendimiento de las aplicaciones sea lo mejor posible. Si te encuentras ante esta situación, lee la sección Conversión de unidades dp a unidades de píxel, a continuación.

    Generalmente, no debes inhabilitar el preajuste. La mejor manera de admitir pantallas múltiples es seguir las técnicas básicas antes descritas en Cómo admitir pantallas múltiples .

Si tu aplicación manipula mapas de bits o interactúa de manera directa con píxeles en la pantalla de alguna otra manera , tal vez necesites dar algunos pasos más para admitir diferentes densidades de pantalla. Por ejemplo, si respondes a gestos táctiles contando el número de píxeles que recorre un dedo, debes usar los valores correspondientes de píxeles independientes de la densidad, en lugar de los píxeles reales.

Ajuste de objetos del mapa de bits creados en tiempo de ejecución

Figura 5: Comparación de mapas de bits ajustados previamente y de manera automática.

Si tu aplicación crea un mapa de bits en la memoria (un objeto Bitmap), el sistema supone que el mapa de bits está diseñado para la pantalla de densidad media de referencia, de forma predeterminada, y ajusta de manera automática el mapa de bits en el momento de la representación. El sistema aplica el “ajuste automático” a Bitmap cuando el mapa de bits tiene propiedades de densidad no especificadas. Si no das cuenta de manera apropiada de la densidad de la pantalla del dispositivo en cuestión y especificas las propiedades de la densidad de mapa de bits, el ajuste automático puede derivar en el ajuste de alteraciones del mismo modo que cuando no proporcionas recursos alternativos.

Para verificar si un Bitmap creado en el tiempo de ejecución se ajusta o no, puedes especificar la densidad del mapa de bits con setDensity() pasando una constante de densidad de DisplayMetrics, como DENSITY_HIGH o DENSITY_LOW.

Si creas un Bitmap usando BitmapFactory, como desde un archivo o un flujo, puedes usar BitmapFactory.Options para definir propiedades del mapa de bits tal como existe, las cuales determinan si el sistema lo ajustará o la manera en que lo hará. Por ejemplo, puedes usar el campo inDensity a fin de definir la densidad para la cual el mapa de bits se diseña y el campo inScaled para especificar si el mapa de bits se debe ajustar para que coincida con la densidad de la pantalla del dispositivo actual.

Si fijas el campo inScaled en false, inhabilitarás cualquier ajuste previo que el sistema pueda aplicar en el mapa de bits. Luego, el sistema lo ajustará de modo automático en el momento de la representación. El uso de ajustes automáticos en lugar de ajustes previos puede implicar más exigencias para la CPU, pero consume menos memoria.

En la figura 5, se demuestran los resultados de los mecanismos de ajuste previo y automático cuando se cargan mapas de bits de densidad baja (120), media (160) y alta (240) en una pantalla de densidad alta. Las diferencias son sutiles, ya que todos los mapas de bits se ajustan para coincidir con la densidad de la pantalla actual. Sin embargo, el aspecto de los mapas de bits ajustados se diferencia ligeramente según se ajusten o no de manera previa o automática en el momento de la representación.

Nota: Debido a las mejoras en el framework de gráficos, en Android 3.0 y versiones posteriores no debe haber diferencias perceptibles entre mapas de bits ajustados de manera previa o automática.

Conversión de unidades dp en unidades de píxeles

En algunos casos, necesitarás expresar dimensiones en dp y convertirlas en píxeles. Imagina una aplicación en la que un gesto de desplazamiento o lanzamiento se reconozca después de que el dedo del usuario haya recorrido al menos 16 píxeles. En una pantalla de referencia, un desplazamiento obligatorio del usuario de 16 pixels / 160 dpi, que equivale a un décimo de pulgada (o 2,5 mm) antes de que se reconozca el gesto. En un dispositivo con una pantalla de alta densidad (240 dpi), el dedo del usuario debe desplazarse 16 pixels / 240 dpi, que equivale a un quinceavo de pulgada (o 1,7 mm). La distancia es mucho más corta y la aplicación parece ser más sensible para el usuario.

Para solucionar este problema, el límite del gesto se debe expresarse en dp en el código y luego convertirse en píxeles actuales. Por ejemplo:

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

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

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

En el campo DisplayMetrics.density se especifica el factor de la escala que debes usar para convertir unidades dp a píxeles, según la densidad de pantalla actual. En una pantalla de densidad media, DisplayMetrics.density equivale a 1,0, en una de densidad alta a 1,5, en una de densidad extraalta a 2,0, y en de densidad baja, a 0,75. Esta figura es el factor por el cual debes multiplicar las unidades dp a fin de obtener la cantidad real de píxeles para la pantalla actual. (Luego agrega 0.5f para redondear el número al valor entero más cercano, al realizar la conversión a un valor entero). Consulta la clase DisplayMetrics para obtener más información.

Sin embargo, en lugar de definir un límite arbitrario para esta clase de evento, debes usar valores de configuración ajustados previamente que estén disponibles a través de ViewConfiguration.

Uso de valores de configuración ajustados previamente

Puedes usar la clase ViewConfiguration para acceder a las distancias, las velocidades y los tiempos normales que usa el sistema Android. Por ejemplo, la distancia en píxeles que usa el framework como el límite de desplazamiento se puede obtener con getScaledTouchSlop():

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

Los métodos en ViewConfiguration que comienzan con el prefijo getScaled son garantía para mostrar un valor en píxeles que se mostrarán de modo apropiado sin importar la densidad de pantalla actual.

Cómo probar tu aplicación en pantallas múltiples

Figura 6: Conjunto de AVD para probar la compatibilidad de pantallas.

Antes de publicar tu aplicación, debes probarla completamente en todos los tamaños y todas las densidades de pantallas compatibles. El Android SDK incluye máscaras de emulador que puedes usar, las cuales replican los tamaños y las densidades de configuraciones comunes de pantalla en las cuales tu app probablemente funcione. También puedes modificar el tamaño, la densidad y la resolución predeterminados de las máscaras de emulador para replicar las características de cualquier pantalla específica. El uso de las máscaras de emulador y las configuraciones personalizadas adicionales te permite probar cualquier configuración de pantalla, de modo que no será necesario que compres varios dispositivos solo para probar la compatibilidad de la pantalla de tu aplicación.

A fin de establecer un entorno para probar la compatibilidad con pantallas de tu aplicación, debes crear una serie de AVD (Android Virtual Device), usando las máscaras de emulador y las configuraciones de pantalla que emulan los tamaños y las densidades de pantalla que deseas admitir en tu aplicación. Para hacerlo, puedes usar el administrador de AVD a fin de crear los AVD e iniciarlos con una interfaz gráfica.

Para lanzar Android SDK Manager, ejecuta SDK Manager.exe desde tu directorio de Android SDK (solo en Windows) o ejecuta android desde el directorio <sdk>/tools/ (en todas las plataformas). En la figura 6, se muestra el administrador de AVD con una selección de AVD para probar varias configuraciones de pantallas.

En la 3, se muestran varias máscaras de emulador disponibles en el Android SDK, que puedes usar para emular algunas de las configuraciones de pantalla más comunes.

Si deseas obtener más información sobre la creación y el uso de AVD para probar tu aplicación, consulta la sección de administración de AVD con el administrador de AVD.

Tabla 3: Varias configuraciones de pantalla disponibles a través de las máscaras del emulador en el Android SDK (indicado en negrita) y otras resoluciones representativas.

Densidad baja (120), ldpi Densidad media (160), mdpi Densidad alta (240), hdpi Densidad extraalta (320), xhdpi
Pantalla pequeña QVGA (240 x 320) 480 x 640
Pantalla normal WQVGA400 (240 x 400)
WQVGA432 (240 x 432)		 HVGA (320 x 480) WVGA800 (480 x 800)
WVGA854 (480 x 854)
600 x 1024		 640 x 960
Pantalla grande WVGA800** (480 x 800)
WVGA854** (480 x 854)		 WVGA800* (480 x 800)
WVGA854* (480 x 854)
600 x 1024
Pantalla extragrande 1024 x 600 WXGA (1280 x 800)†
1024 x 768
1280 x 768		 1536 x 1152
1920 x 1152
1920 x 1200		 2048 x 1536
2560 x 1536
2560 x 1600
* Para emular esta configuración, especifica una densidad personalizada de 160 al crear un AVD que use una máscara WVGA800 o WVGA854.
* Para emular esta configuración, especifica una densidad personalizada de 120 al crear un AVD que use una máscara WVGA800 o WVGA854.
† Esta máscara está disponible en la plataforma Android 3.0

Para ver los números relativos de dispositivos activos que sean compatibles con cualquier configuración de pantalla, consulta el panel de tamaños y densidades de pantalla.

Figura 7: Opciones de densidad y tamaño que puedes configurar al iniciar un AVD desde el administrador de AVD.

También te recomendamos probar tu aplicación en un emulador configurado para funcionar con un tamaño físico que tenga una alta coincidencia con un dispositivo real. Esto facilita mucho la comparación de los resultados en diferentes tamaños y densidades. Para hacer eso debes saber la densidad aproximada, en dpi, del monitor de tu computadora (por ejemplo, un monitor Dell 30” tiene una densidad de aproximadamente 96 dpi). Cuando inicias un AVD desde el administrador de AVD, puedes especificar el tamaño de la pantalla para el emulador y los dpi de tu monitor en Launch Options, como se muestra en la figura 7.

Si deseas probar tu aplicación en una pantalla con una resolución o densidad que no sea compatible con las máscaras integradas, puedes crear un AVD que use una resolución o densidad personalizadas. Al crear un AVD desde el administrador de AVD, especifica la resolución en lugar de seleccionar una máscara integrada.

Si lanzas tu AVD desde la línea de comandos, puedes especificar la escala para el emulador con la opción -scale. Por ejemplo:

emulator -avd <avd_name> -scale 96dpi

Para definir mejor el tamaño del emulador, puedes en cambio pasar a la opción -scale un número entre 0,1 y 3 que representa el factor de ajuste deseado.

Para obtener más información acerca de la creación de AVD desde la línea de comandos, consulta Manejo de AVD desde la línea de comandos.

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

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

* Required Fields

Hooray!

Browse this site in ?

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

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

This class requires API level or higher

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

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

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