Android: Consecuencias de tener targetSDK> BuildTarget

Quería saber las consecuencias de tener targetSDK > buildTarget .

Hace poco observé que si mantengo la buildTarget=16 y targetSDK=17 las pestañas de mi tableta (en ejecución 4.1.1 , API Level 16) se mueve al centro de la barra de acción. No pude racionalizar el comportamiento. ¿Puede alguien arrojar alguna luz sobre por qué sucedió esto?

¡Buena pregunta! Tuve un comportamiento similar hace algún tiempo, cuando buildTarget y targetSDK diferían de la manera descrita. Me tomó un tiempo, para entenderlo, pero intentaré resumir mi comprensión.

Hay que distinguir entre tres valores importantes:

  1. minSdkVersion :

    Esta es la versión más baja disponible, en la que la aplicación se ejecutará (o debería!). Al instalar un .apk en Android, se comprobará el valor y si la versión de Android en la que se está ejecutando es inferior a la versión especificada, no se instalará.

  2. buildTarget :

    Ese es el SDK en el que se compilará .apk de la aplicación (y Eclipse también tendrá ese valor, para comprobar errores de compilación). Si el buildTarget es más alto que el minSdkVersion , podrá instalar la aplicación incluso si la versión de Android no admite todos los métodos. De forma predeterminada, se establece en la versión más reciente de Android disponible en su SDK. Todavía puede crear su aplicación para admitir versiones anteriores, pero si establece el destino de compilación en la última versión, podrá habilitar nuevas funciones y optimizar su aplicación para disfrutar de una gran experiencia de usuario en los dispositivos más recientes.

    Necesita comprobar si los métodos que está utilizando están presentes en tiempo de ejecución si se ejecutan en un nivel de API inferior, de lo contrario la aplicación podría bloquearse!

  3. targetSdkVersion :

    targetSdkVersion especifica en qué plataforma de SDK debe funcionar su aplicación targetSdkVersion . Por lo tanto, si ha probado con API 17, puede agregar API 17 como targetSdkVersion . Si utiliza una versión de Android> targetSdkVersion , el sistema Android entrará en algún tipo de modo de compatibilidad hacia adelante para garantizar el soporte para la aplicación. Este comportamiento de compatibilidad se introducirá para asegurarse de que su aplicación siga funcionando de la manera que usted espera, ya que puede haber algunos cambios en el comportamiento entre los niveles de API nunca ( aquí están algunos de los cambios más importantes ). Por lo tanto, cualquier aplicación desarrollada para un nivel API inferior podrá ejecutarse en una versión superior, ya que el comportamiento anterior (como valores obsoletos) podría ser "simulado" dentro del modo de compatibilidad.

    Por ejemplo:

    Si establece targetSdkVersion en HONEYCOMB (API 11), el tema predeterminado cambiará a Theme_Holo (que es la interfaz de usuario holográfica oscura). El establecimiento de targetSdkVersion a un valor inferior afectará al sistema para permanecer en el tema de luz predeterminado, sin importar qué API de compilación utilizará.

    En su caso, no parece haber muchos cambios notables entre API 16 y 17, que deberían afectar en un cambio de diseño, pero supongo que el targetSdkVersion mayor afectará en algunos cambios adicionales en tiempo de compilación (como incluir clases adicionales, Temas, valores, …), que afectarán en un comportamiento diferente, al igual que en el ejemplo del tema anterior.

Espero, que te ayudó un poco, para averiguar el comportamiento extraño. Aquí hay más información relacionada para leer en la documentación para desarrolladores de Android .

PS: Hay algún tipo de infierno hacia adelante: El sistema Android es compatible con versiones anteriores, de modo que la compatibilidad hacia adelante de las aplicaciones de Android está garantizada. Esto significa: Si actualiza su versión de Android a través de OTA, por ejemplo, todas las aplicaciones antiguas deben permanecer en ejecución (para que se mantengan compatibles con la versión anterior).

El objetivo de creación es para el desarrollo de aplicaciones, el SDK de destino es para la compatibilidad de aplicaciones.

El objetivo de compilación especifica a qué API tiene acceso al implementar la aplicación. Al igual que si estableció el taget de construcción en el nivel 10 de la API de Android, en lo que respecta a su código, no existe tal cosa como una ActionBar. La API que se utiliza durante el desarrollo es sólo una implementación de stub de Android, así es como debe emularse o ejecutarse en un dispositivo real. Por lo tanto, el objetivo de creación define (para el compilador y su IDE) la interfaz de Android que está utilizando. Una vez compilado, no debe haber ninguna diferencia basada en la meta de compilación (el sistema Android no ve la meta de compilación, es un indicador de tiempo de compilación). Este es un contrato estricto entre usted y el compilador android (y su IDE) que define qué componentes en Android puede utilizar en su aplicación, ya que obtendrá errores de compilación si intenta utilizar algo que está más allá del conjunto de versiones de Android Como objetivo de construcción.

El SDK de destino es un contrato que firmas con el sistema Android, asegurándote que su aplicación está preparada para funcionar correctamente desde tu SDK mínimo hasta el SDK de destino (el SDK máximo es efectivo, ya que la configuración SDK máxima debe evitarse). Creo que hay algunas cosas que no salen adelante: la compatibilidad, como algunos de los cambios de seguridad (probablemente los cambios vienen de más allá del desarrollo de la aplicación y son de todo el sistema). Este contrato es un acuerdo que significa que ha realizado medidas para asegurarse de que su aplicación se encarga de cualquier cambio en la API de Android en ese rango, de modo que proporcione el comportamiento que espera en todas las situaciones. El otro extremo del contrato es del sistema Android, está de acuerdo en usar la implementación de Android que no exceda el SDK de destino, incluso cuando se ejecuta en una versión superior de Android (esto excluye los pocos cambios que mencioné anteriormente).

La nota sobre la compatibilidad hacia adelante implica que el objetivo de creación siempre debe coincidir al menos con su SDK de destino. Usted está diciendo que ha probado su aplicación para que se ejecute en su SDK de destino, así que ¿por qué crearlo contra un nivel de API inferior?

Ejemplo real de creación de destino y SDK de destino en acción: ActionBarSherlock proporciona ActionBar compatible con versiones anteriores. Aquí hay citas de los requisitos para usar la biblioteca en este momento.

La propia biblioteca debe estar construida contra Android 4.0 (API nivel 14). Su proyecto debe construirse utilizando la última versión del SDK, siempre y cuando sea 4.0 o posterior.

Es necesario apuntar el API nivel 11 o más reciente, ya que hará que Android añada automáticamente la barra de acción nativa cuando se ejecute en dispositivos más nuevos. Dado que va a compilar contra nuevas API pero es probable que su aplicación se ejecute en dispositivos con versiones anteriores de Android, se debe tener cuidado para evitar el uso o verificar y llamar a cualquier método introducido después de la versión mínima de SDK.

El primer párrafo muestra que se requiere un destino de compilación que contenga la API ActionBar 4.0, ya que la biblioteca hace uso de ella y no puede compilar sin ella. El segundo párrafo muestra que se requiere un SDK de destino que contenga la API de ActionBar 3.0, ya que la biblioteca utiliza la ActionBar nativa en dichos dispositivos, pero el sistema Android no proporcionará la ActionBar si el SDK de destino es inferior a 3.0 ya que no lo indica Para usar algo más nuevo que su destino (como el ActionBar 3.0).

Algunas referencias:

Crear objetivo

SDK de destino

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.