Android está diseñado para ejecutarse en muchos tipos de dispositivos diferentes, desde teléfonos hasta tablets y televisores. Como desarrollador, la variedad de dispositivos te ofrece un gran público potencial para tu app. Para que tu app sea exitosa en todos estos dispositivos, debe tolerar cierta variabilidad de funciones y ofrecer una interfaz de usuario flexible que se adapte a diferentes configuraciones de pantalla.
Para facilitar tu esfuerzo hacia ese objetivo, Android ofrece un dinámico marco de trabajo para apps en el que puedes proporcionar recursos de apps específicos de configuración en archivos estáticos (como diferentes diseños XML para distintos tamaños de pantalla). Luego, Android carga los recursos adecuados según la configuración del dispositivo actual. Con un poco de previsión para el diseño de tu app y algunos recursos adicionales, puedes publicar un solo paquete de la aplicación (APK) que ofrece una experiencia de usuario optimizada en una variedad de dispositivos.
Sin embargo, si es necesario, puedes especificar los requisitos de las funciones de tu app y controlar qué tipos de dispositivos pueden instalarla desde Google Play Store. En esta página, se explica cómo puedes controlar qué dispositivos tienen acceso a tus apps y cómo prepararlas para asegurarte de que lleguen al público correcto. Para obtener más información sobre cómo puedes hacer que tu app se adapte a diferentes dispositivos, consulta Compatibilidad con diferentes dispositivos .
¿Qué significa "compatibilidad"?
A medida que leas más sobre el desarrollo de Android, probablemente encontrarás el término "compatibilidad" en diversas situaciones. Existen dos tipos de compatibilidad: la compatibilidad con dispositivos y la compatibilidad con apps.
Debido a que Android es un proyecto de código abierto, cualquier fabricante de hardware puede crear un dispositivo que ejecute el sistema operativo Android. Sin embargo, un dispositivo es "compatible con Android" solo si puede ejecutar correctamente aplicaciones escritas para el entorno de ejecución de Android. El Programa de compatibilidad de Android define los detalles exactos del entorno de ejecución de Android y cada dispositivo debe aprobar el Conjunto de pruebas de compatibilidad (CTS) para que se considere compatible.
Como desarrollador de apps, no tienes que preocuparte acerca de si un dispositivo es compatible con Android, ya que solo los dispositivos que lo son incluyen Google Play Store. Por lo tanto, puedes estar seguro de que los usuarios que instalan tu app desde Google Play Store están usando un dispositivo compatible con Android.
Sin embargo, debes considerar si tu app es compatible con cada posible configuración del dispositivo. Como Android se ejecuta en una gran variedad de configuraciones de dispositivos, algunas funciones no están disponibles en todos los dispositivos. Por ejemplo, es posible que algunos dispositivos no incluyan sensor de brújula. Si la funcionalidad principal de tu app requiere el uso de un sensor de brújula, tu app solo es compatible con dispositivos que lo incluyen.
Cómo controlar la disponibilidad de tu app para los dispositivos
Android es compatible con una variedad de funciones que tu app puede aprovechar a través de las API de la plataforma. Algunas funciones están basadas en hardware (como un sensor de brújula), otras están basadas en software (como los widgets de apps) y otras dependen de la versión de la plataforma. No todos los dispositivos son compatibles con todas las funciones, por lo que es posible que debas controlar la disponibilidad de tu app para los dispositivos según las funciones que requiera tu app.
Para lograr la mayor base de usuarios posible para tu app, debes esforzarte por ofrecer compatibilidad con tantas configuraciones de dispositivos como sea posible usando un solo APK. En la mayoría de las situaciones, puedes hacerlo inhabilitando las funciones opcionales en tiempo de ejecución y proporcionando recursos de la app con alternativas para diferentes configuraciones (como distintos diseños para distintos tamaños de pantalla). Sin embargo, si es necesario, puedes restringir la disponibilidad de tu app para los dispositivos a través de Google Play Store según las siguientes características del dispositivo:
Funciones del dispositivo
A fin de que puedas administrar la disponibilidad de tu app según las funciones del dispositivo, Android define los ID de función para cualquier función de hardware o software que puede no estar disponible en todos los dispositivos. Por ejemplo, el ID de función para el sensor de brújula es FEATURE_SENSOR_COMPASS y el ID de función para los widgets de app es FEATURE_APP_WIDGETS.
Si es necesario, puedes evitar que los usuarios instalen tu app cuando sus dispositivos no ofrezcan una función determinada al declararla con un elemento <uses-feature> en el archivo de manifiesto de tu app.
Por ejemplo, si tu app no tiene sentido en un dispositivo que carece de un sensor de brújula, puedes declarar el sensor de brújula según sea necesario con la siguiente etiqueta de manifiesto:
<manifest ... >
<uses-feature android:name="android.hardware.sensor.compass"
android:required="true" />
...
</manifest>
Google Play Store compara las funciones que requiere tu app con las funciones disponibles en el dispositivo de cada usuario para determinar si tu app es compatible con cada uno de ellos. Si el dispositivo no ofrece todas las funciones que requiere tu app, el usuario no podrá instalarla.
Sin embargo, si la funcionalidad principal de tu app no requiere una función del dispositivo, debes configurar el atributo required en "false" y verificar la función del dispositivo en tiempo de ejecución. Si la función de la app no está disponible en el dispositivo actual, se degrada la función de la app correspondiente de forma elegante. Por ejemplo, puedes consultar si una función está disponible llamando a hasSystemFeature() de esta manera:
Kotlin
if (!packageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
// This device does not have a compass, turn off the compass feature
disableCompassFeature()
}
Java
PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
// This device does not have a compass, turn off the compass feature
disableCompassFeature();
}
Para obtener información sobre todos los filtros que puedes usar a fin de controlar la disponibilidad de tu app para los usuarios a través de Google Play Store, consulta el documento Filtros en Google Play.
Nota: Algunos permisos del sistema requieren implícitamente la disponibilidad de una función del dispositivo. Por ejemplo, si tu app solicita permiso para acceder a BLUETOOTH, esto implícitamente requiere la función de dispositivo FEATURE_BLUETOOTH. Puedes inhabilitar el filtrado basado en esta función y hacer que tu app esté disponible para dispositivos sin Bluetooth configurando el atributo required en "false" en la etiqueta <uses-feature>.
Para obtener más información sobre las funciones del dispositivo requeridas implícitamente, consulta Permisos que implican requisitos de funciones.
Versión de plataforma
Los diferentes dispositivos pueden ejecutar diferentes versiones de la plataforma de Android, como Android 4.0 o Android 4.4. Cada versión sucesiva de la plataforma suele agregar nuevas API que no están disponibles en la versión anterior. Para indicar qué conjunto de API está disponible, cada versión de la plataforma especifica un nivel de API. Por ejemplo, Android 1.0 es una API nivel 1 y Android 4.4 es una API nivel 19.
El nivel de API te permite declarar la versión mínima con la que es compatible tu app, usando la etiqueta de manifiesto <uses-sdk> y su atributo minSdkVersion. Por ejemplo, las API del Proveedor de calendario se agregaron en Android 4.0 (API nivel 14). Si tu app no puede funcionar sin estas API, debes declarar que la API nivel 14 es la versión mínima compatible con tu app.
El atributo minSdkVersion declara la versión mínima compatible con tu app y el atributo targetSdkVersion declara la versión máxima a la que optimizaste tu app.
Sin embargo, ten en cuenta que los atributos del elemento <uses-sdk> son anulados por las propiedades correspondientes del archivo build.gradle.
Entonces, si estás usando Android Studio, debes especificar los valores minSdkVersion y targetSdkVersion allí:
android {
defaultConfig {
applicationId 'com.example.myapp'
// Defines the minimum API level required to run the app.
minSdkVersion 15
// Specifies the API level used to test the app.
targetSdkVersion 28
...
}
}
Para obtener más información sobre el archivo build.gradle, lee acerca de cómo configurar tu compilación.
Cada versión sucesiva de Android ofrece compatibilidad para las apps compiladas con las API de versiones anteriores de la plataforma, por lo que tu app siempre debe ser compatible con versiones futuras de Android mientras usas las API de Android documentadas.
Nota: El atributo targetSdkVersion no impide que tu app se instale en versiones de la plataforma que son superiores al valor especificado, pero es importante porque indica al sistema si tu app debe heredar los cambios de comportamiento en las versiones más recientes. Si no actualizas targetSdkVersion a la versión más reciente, el sistema asume que tu app requiere algunos comportamientos de retrocompatibilidad cuando se ejecuta en la última versión.
Por ejemplo, entre los cambios de comportamiento en Android 4.4, las alarmas creadas con las API AlarmManager ahora son inexactas de forma predeterminada, por lo que el sistema puede agrupar las alarmas de la app y conservar la energía del sistema, pero el sistema retendrá el comportamiento de API anterior para tu app si tu nivel objetivo de API es inferior a "19".
Sin embargo, si tu app usa API agregadas en una versión de plataforma más reciente, pero no las requiere para su funcionalidad principal, debes verificar el nivel de API en tiempo de ejecución y degradar las características correspondientes de forma elegante cuando el nivel de API sea demasiado bajo. En este caso, configura minSdkVersion en el valor más bajo posible para la funcionalidad principal de tu app y, luego, compara la versión del sistema actual, SDK_INT, con una de las constantes de nombre interno en Build.VERSION_CODES que corresponda al nivel de API que deseas verificar. Por ejemplo:
Kotlin
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that use <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
disableDragAndDrop()
}
Java
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that use <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
disableDragAndDrop();
}
Configuración de pantalla
Android se ejecuta en dispositivos de varios tamaños, desde teléfonos hasta tablets y televisores. A fin de categorizar los dispositivos por tipo de pantalla, Android define dos características para cada uno: tamaño de pantalla (el tamaño físico) y densidad de pantalla (la densidad física de los píxeles, conocida como DPI). Para simplificar las diferentes configuraciones, Android generaliza estas variantes en grupos que las hacen más fáciles de orientar:
- Cuatro tamaños generalizados: pequeño, normal, grande y muy grande.
- Y varias densidades generalizadas: mdpi (media), hdpi (alta), xhdpi (muy alta), xxhdpi (muy muy alta) y otras.
De forma predeterminada, tu app es compatible con todos los tamaños y densidades de pantalla porque el sistema realiza los ajustes adecuados a tu diseño de IU y recursos de imagen según sea necesario para cada pantalla. Sin embargo, debes optimizar la experiencia del usuario para cada configuración de pantalla agregando diseños especializados para diferentes tamaños de pantalla e imágenes de mapa de bits optimizadas para densidades de pantalla comunes.
Para obtener información sobre cómo crear recursos alternativos para diferentes pantallas y cómo restringir tu app a determinados tamaños de pantalla cuando sea necesario, consulta Compatibilidad con diferentes pantallas.
Cómo controlar la disponibilidad de tu app por razones comerciales
Además de restringir la disponibilidad de tu app según las características del dispositivo, es posible que debas restringir su disponibilidad por razones comerciales o legales. Por ejemplo, es poco probable que una app que muestra horarios de trenes para el metro de Londres sea útil para usuarios fuera del Reino Unido. Para este tipo de situación, Google Play Store ofrece opciones de filtrado en Play Console que te permiten controlar la disponibilidad de tu app por razones no técnicas, como la configuración regional del usuario o el proveedor de servicios inalámbricos.
El filtrado de la compatibilidad técnica (como los componentes de hardware obligatorios) siempre se basa en la información contenida en el archivo APK. Sin embargo, el filtrado por motivos no técnicos (como la configuración regional geográfica) siempre se procesa en Google Play Console.
Sigue leyendo sobre:
- Cómo proveer recursos
- Información sobre cómo se estructuran las apps para Android a fin de separar los recursos de la app de su código, incluido cómo puedes proporcionar recursos alternativos para configuraciones específicas de dispositivos.
- Filtros en Google Play
- Información sobre las diferentes formas en que Google Play Store puede evitar que tu app se instale en diferentes dispositivos.
También podría interesarte lo siguiente:
- Permisos del sistema
- Cómo Android restringe el acceso de la app a ciertas API con un sistema de permisos que requiere el consentimiento del usuario para que tu app use esas API.