seguro - que es root en android

Android: Consecuencias de tener targetSDK> BuildTarget (2)

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

Recientemente observé que si mantenía buildTarget=16 y targetSDK=17 las pestañas de mi tableta (en ejecución 4.1.1 , nivel API 16) se mueven al centro de la barra de acción. No pude racionalizar el comportamiento. ¿Alguien puede arrojar algo de luz sobre por qué sucedió esto?

¡Buena pregunta! Tuve un comportamiento similar hace algún tiempo, cuando buildTarget y targetSDK diferían en la forma descrita. Me tomó algo de tiempo resolverlo, pero trataré de resumir mi entendimiento.

Hay que distinguir tres valores importantes:

minSdkVersion :
Esta es la versión más baja disponible, en la que se ejecutará (¡o debería!) La aplicación. 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á.
buildTarget :
Ese es el SDK en el que se compilará el .apk de la aplicación (y Eclipse también tendrá como objetivo ese valor, para verificar los errores de compilación). Si buildTarget es más alto que minSdkVersion , podrás instalar la aplicación incluso si tu versión de Android no es compatible con todos los métodos. De forma predeterminada, está configurado con la última versión de Android disponible en su SDK. Aún puede crear su aplicación para admitir versiones anteriores, pero configurar el objetivo de compilación a la última versión le permite habilitar nuevas funciones y optimizar su aplicación para una excelente experiencia de usuario en los últimos dispositivos.
Debe comprobar si los métodos que está utilizando están presentes en tiempo de ejecución si se ejecutan en un nivel de API más bajo, de lo contrario, la aplicación podría fallar.
targetSdkVersion :
targetSdkVersion especifica en qué plataforma de SDK su aplicación debería funcionar targetSdkVersion . Por lo tanto, si probó contra 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 la compatibilidad con la aplicación. Este comportamiento de compatibilidad se ingresará para asegurar que su aplicación continúe funcionando de la manera que espera, ya que podría haber algunos cambios en el comportamiento entre niveles de API nunca (estos son algunos de los cambios más importantes ). Por lo tanto, cualquier aplicación desarrollada para un nivel de 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 configura targetSdkVersion en HONEYCOMB (API 11), el tema predeterminado se cambiará a Theme_Holo (esa es la IU holográfica oscura). Establecer targetSdkVersion en un valor más bajo afectará al sistema para que permanezca en el tema light predeterminado, sin importar qué API de compilación usará.
En su caso, no parece haber muchos cambios notables entre las API 16 y 17, que deberían afectar un cambio de diseño, pero supongo que la mayor targetSdkVersion afectará a algunos cambios adicionales en tiempo de compilación (como incluir clases adicionales, Temas, valores, ...), que afectarán en un comportamiento diferente, como en el ejemplo del tema anterior.

Espero que eso te haya ayudado un poco, a descubrir el comportamiento extraño. Aquí hay más información relacionada para leer en la documentación de Android Developer .

PD: Hay algún tipo de infierno hacia atrás: el sistema Android es compatible con versiones anteriores, por lo que se garantiza la compatibilidad hacia adelante de las aplicaciones de Android. Eso significa que: si actualizas tu versión de Android a través de OTA, por ejemplo, todas las aplicaciones antiguas deberían seguir funcionando (para que se mantengan compatibles).

El objetivo de compilació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 mientras implementa la aplicación. Al igual que si configuras el taget de compilación en el nivel 10 de la API de Android, en lo que respecta a tu código, no existe una barra de acción. La API que utiliza durante el desarrollo es solo una implementación de código auxiliar de Android, así es como debe ser emulada o ejecutada en un dispositivo real. Por lo tanto, el objetivo de compilación define (para el compilador y su IDE) la interfaz de Android que está utilizando. Una vez compilado, no debería haber ninguna diferencia en función del objetivo de compilación (el sistema Android no ve el objetivo de compilación, es un indicador de tiempo de compilación). Este es un contrato estricto entre usted y el compilador de Android (y su IDE) que define qué componentes de Android puede usar en su aplicación, ya que obtendrá errores de compilación si intenta usar algo que está más allá del conjunto de versiones de Android. como tu objetivo de construcción.

El SDK de destino es un contrato que firma con el sistema Android, asegurándose de que su aplicación esté preparada para funcionar correctamente desde su SDK mínimo hasta el SDK de destino (a partir del SDK máximo, ya que generalmente se debe evitar la configuración máxima de SDK). Creo que hay algunas cosas que no consiguen compatibilidad hacia adelante, como algunos de los cambios de seguridad (probablemente los cambios provienen de más allá del desarrollo de la aplicación y abarcan todo el sistema). Este contrato es un acuerdo que significa que ha realizado medidas para asegurarse de que su aplicación maneje cualquier cambio en la API de Android en ese rango, de manera que proporcione el comportamiento que espera en todas las situaciones. El otro extremo del contrato es del sistema Android, acepta usar una implementación de Android que no exceda su SDK de destino, incluso cuando se encuentre en un dispositivo con una versión superior de Android (esto excluye los pocos cambios que mencioné anteriormente).

La nota sobre compatibilidad hacia adelante implica que su objetivo de compilación siempre debe al menos coincidir con su SDK de destino. Está diciendo que ha probado su aplicación para ejecutarse en su SDK de destino, entonces ¿por qué compilarla en un nivel de API más bajo?

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

La biblioteca en sí debe construirse contra Android 4.0 (nivel de API 14). Su proyecto debe construirse utilizando la última versión del SDK en la medida de lo posible siempre y cuando sea 4.0 o más reciente.
Se requiere una API de nivel 11 o superior, ya que hará que Android agregue automáticamente la barra de acción nativa cuando se ejecute en dispositivos más nuevos. Ya que compilará contra nuevas API, pero es probable que su aplicación se ejecute en dispositivos con versiones anteriores de Android, se debe tener mucho cuidado ya sea para evitar el uso o para verificar y llamar adecuadamente a cualquier método que se introdujo después de su versión mínima de SDK.

El primer párrafo muestra que se requiere un destino de compilación que contenga la API de ActionBar 4.0, ya que la biblioteca lo utiliza y no puede compilar sin él. El segundo párrafo muestra que se requiere un SDK de destino que contenga la API de la barra de acción 3.0 ya que la biblioteca usa la barra de acción nativa en dichos dispositivos, pero el sistema Android no proporcionará la barra de acción si su SDK de destino es inferior a la 3.0, ya que eso indica que no para usar cualquier cosa más nueva que tu objetivo (como la barra de acción 3.0).

Algunas referencias:

Construir objetivo

SDK de destino