Elegir su compileSdkVersion, minSdkVersion, y targetSdkVersion

Ian Lake

Follow

6 de enero, 2016 – 5 min read

Dependiendo de la época del año, puede que sólo unos meses después de lanzar una aplicación se anuncie una nueva versión de Android. Sin embargo, ¿qué significa esto para tu aplicación – se va a romper todo?

Te alegrará saber que la compatibilidad hacia adelante es un fuerte enfoque de Android – las aplicaciones existentes construidas con SDKs anteriores no deben romperse cuando el usuario actualiza a una nueva versión de Android. Aquí es donde entran en juego compileSdkVersion, minSdkVersion y targetSdkVersion: controlan qué APIs están disponibles, cuál es el nivel de API requerido y qué modos de compatibilidad se aplican, respectivamente.

compileSdkVersion es tu forma de decirle a Gradle con qué versión del SDK de Android debe compilar tu aplicación. Usar el nuevo SDK de Android es un requisito para utilizar cualquiera de las nuevas APIs añadidas en ese nivel.

Hay que destacar que cambiar tu compileSdkVersion no cambia el comportamiento en tiempo de ejecución. Mientras que las nuevas advertencias/errores del compilador pueden estar presentes al cambiar su compileSdkVersion, su compileSdkVersion no se incluye en su APK: se utiliza puramente en tiempo de compilación. (Sin embargo, debería arreglar esas advertencias – ¡se añadieron por una razón!)

Por lo tanto, se recomienda encarecidamente que siempre compile con el último SDK. Obtendrá todos los beneficios de las nuevas comprobaciones de compilación en el código existente, evitará las nuevas APIs obsoletas y estará preparado para utilizar las nuevas APIs.

Tenga en cuenta que si utiliza la biblioteca de soporte, compilar con el último SDK es un requisito para utilizar las últimas versiones de la biblioteca de soporte. Por ejemplo, para utilizar la biblioteca de soporte 23.1.1, debe tener una compileSdkVersion de al menos 23 (los primeros números deben coincidir). En general, una nueva versión de la biblioteca de apoyo se publica junto con una nueva versión de la plataforma, proporcionando calzos de compatibilidad a las APIs recién añadidas, así como nuevas características.

minSdkVersion

Si compileSdkVersion establece las APIs más nuevas disponibles para usted, minSdkVersion es el límite inferior para su aplicación. La minSdkVersion es una de las señales que utiliza Google Play Store para determinar en qué dispositivos de un usuario se puede instalar una aplicación.

También juega un papel importante durante el desarrollo: por defecto lint se ejecuta contra tu proyecto, advirtiéndote cuando utilizas cualquier API por encima de tu minSdkVersion, ayudándote a evitar el problema en tiempo de ejecución de intentar llamar a una API que no existe. Comprobar la versión del sistema en tiempo de ejecución es una técnica común cuando se utilizan APIs sólo en las versiones más nuevas de la plataforma.

Tenga en cuenta que las bibliotecas que utiliza, como cualquiera de las bibliotecas de soporte o los servicios de Google Play, pueden tener su propio minSdkVersion – el minSdkVersion de su aplicación debe ser al menos tan alto como el minSdkVersion de sus dependencias – si tiene bibliotecas que requieren 4, 7 y 9, su minSdkVersion debe ser al menos 9. En los raros casos en los que quieras seguir utilizando una biblioteca con una minSdkVersion superior a la de tu aplicación (y lidiar con todos los casos límite/asegurarte de que la biblioteca sólo se utiliza en las versiones más recientes de la plataforma), puedes utilizar el marcador tools:overrideLibrary, ¡pero asegúrate de hacer pruebas a fondo!

Cuando decidas una minSdkVersion, debes tener en cuenta las estadísticas de los Dashboards, que te dan una visión global de todos los dispositivos que visitaron la Google Play Store en los 7 días anteriores – esa es tu audiencia potencial al poner una aplicación en Google Play. En última instancia, es una decisión de negocios sobre si el apoyo a un 3% adicional de los dispositivos vale la pena el desarrollo y el tiempo de prueba necesario para garantizar la mejor experiencia.

Por supuesto, si una nueva API es clave para toda su aplicación, entonces eso hace que la discusión minSdkVersion bastante más fácil. Sólo recuerde que incluso el 0,7% de 1,4 mil millones de dispositivos es un montón de dispositivos.

targetSdkVersion

El más interesante de los tres, sin embargo, es targetSdkVersion. targetSdkVersion es la principal forma en que Android proporciona compatibilidad hacia adelante al no aplicar los cambios de comportamiento a menos que se actualice el targetSdkVersion. Esto permite utilizar las nuevas APIs (ya que actualizaste tu compileSdkVersion, ¿verdad?) antes de trabajar con los cambios de comportamiento.

Muchos de los cambios de comportamiento que implica targetSdkVersion están documentados directamente en VERSION_CODES, pero todos los detalles sangrientos también se enumeran en los aspectos destacados de la plataforma de cada versión, muy bien vinculados en la tabla de niveles de API.

Por ejemplo, los cambios de Android 6.0 hablan de cómo la orientación de la API 23 transiciones de su aplicación para el modelo de permisos en tiempo de ejecución y los cambios de comportamiento de Android 4.4 detalle cómo la orientación de la API 19 o superior cambia el funcionamiento de las alarmas establecidas con set() y setRepeating().

Con algunos de los cambios de comportamiento que son muy visibles para los usuarios (la desaparición del botón de menú, permisos en tiempo de ejecución, etc), la actualización para orientar el último SDK debe ser una alta prioridad para cada aplicación. Esto no significa que tengas que utilizar todas las nuevas características introducidas ni que debas actualizar ciegamente tu targetSdkVersion sin hacer pruebas – ¡por favor, haz pruebas antes de actualizar tu targetSdkVersion! Sus usuarios se lo agradecerán.

Gradle y las versiones del SDK

Así que establecer la compileSdkVersion, minSdkVersion y targetSdkVersion correctas es importante. Como puedes imaginar en un mundo con Gradle y Android Studio, estos valores están integrados en el sistema de herramientas a través de la inclusión en el archivo build.gradle de tu módulo (también disponible a través de la opción de Estructura del Proyecto en Android Studio):

android {
compileSdkVersion 23
buildToolsVersion "23.0.1"
defaultConfig {
applicationId "com.example.checkyourtargetsdk"
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
}

La compileSdkVersion, al ser una cosa de tiempo de compilación (¡quién lo hubiera imaginado!), es una de las configuraciones de android junto con la versión de tus herramientas de construcción. Los otros dos son ligeramente diferentes en que se declaran en el nivel de la variante de construcción – el defaultConfig es la base para todas las variantes de construcción y donde se ponen los valores por defecto para estos, pero se podría imaginar un sistema más complicado donde las versiones específicas de su aplicación tienen un minSdkVersion diferente, por ejemplo.

minSdkVersion y targetSdkVersion también se diferencian de compileSdkVersion en que se incluyen en tu APK final – si miraras el AndroidManifest.xml generado, verías una etiqueta como:

<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />

Te darás cuenta de que si pones esto manualmente en tu manifiesto, será ignorado cuando construyas con Gradle (aunque otros sistemas de construcción podrían ciertamente confiar en que esté allí).

Poniendo todo junto

Si has conseguido leer las notas en negrita, te darás cuenta de que existe una relación entre los tres valores:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Esto tiene sentido intuitivamente – si compileSdkVersion es tu ‘máximo’ y minSdkVersion es tu ‘mínimo’ entonces tu máximo debe ser al menos tan alto como tu mínimo y el objetivo debe estar en algún punto intermedio.

En realidad, la relación se vería más como esto en el estado estacionario:

minSdkVersion (lowest possible) <= 
targetSdkVersion == compileSdkVersion (latest SDK)

Alcanzarás la mayor audiencia con un minSdkVersion bajo y te verás y actuarás mejor al apuntar y compilar con el último SDK – una gran manera de #BuildBetterApps.

¡Únete a la discusión en el post de Google+ y sigue la Colección de Patrones de Desarrollo Android para más!

Deja una respuesta

Tu dirección de correo electrónico no será publicada.