Cuando configura targetSdkVersion = "xx", está certificando que su aplicación funciona correctamente (por ejemplo, se ha probado exhaustivamente y con éxito) en el nivel de API xx.
Una versión de Android que se ejecute en un nivel de API superior a xx aplicará el código de compatibilidad automáticamente para admitir cualquier característica en la que pueda confiar que esté disponible en el nivel de API xx o antes, pero que ahora está obsoleta en el nivel superior de esa versión de Android.
Por el contrario, si está utilizando alguna característica que quedó obsoleta en el nivel xx o antes , las versiones del sistema operativo en niveles superiores de API (que ya no incluyen esas características) no aplicarán automáticamente el código de compatibilidad para admitir esos usos. En esa situación, su propio código debe tener cláusulas de casos especiales que prueba el nivel de la API y, si el nivel de sistema operativo detectado es uno más alto que ya no tiene la función de API dado, su código debe utilizar características alternativas que están disponibles en los que se ejecutan sistemas operativos Nivel API
Si no lo hace, es posible que algunas funciones de la interfaz simplemente no aparezcan que normalmente desencadenarían eventos dentro de su código, y es posible que le falte una función de interfaz crítica que el usuario necesita para activar esos eventos y acceder a su funcionalidad (como en el ejemplo a continuación).
Como se indicó en otras respuestas, puede establecer targetSdkVersion más alto que minSdkVersion si desea utilizar algunas características API inicialmente definidas en niveles API más altos que su minSdkVersion, y ha tomado medidas para asegurarse de que su código pueda detectar y manejar la ausencia de esas características en niveles más bajos que targetSdkVersion.
Para advertir a los desarrolladores que prueben específicamente el nivel mínimo de API requerido para usar una función, el compilador emitirá un error (no solo una advertencia) si el código contiene una llamada a cualquier método que se definió en un nivel de API posterior a minSdkVersion, incluso si targetSdkVersion es mayor o igual que el nivel de API en el que ese método se puso a disposición por primera vez. Para eliminar este error, la directiva del compilador
@TargetApi(nn)
le dice al compilador que el código dentro del alcance de esa directiva (que precederá a un método o una clase) se ha escrito para probar un nivel de API de al menos nn antes de llamar a cualquier método que dependa de tener al menos ese nivel de API . Por ejemplo, el siguiente código define un método que se puede llamar desde el código dentro de una aplicación que tiene una minSdkVersion de menos de 11 y una targetSdkVersion de 11 o más:
@TargetApi(11)
public void refreshActionBarIfApi11OrHigher() {
//If the API is 11 or higher, set up the actionBar and display it
if(Build.VERSION.SDK_INT >= 11) {
//ActionBar only exists at API level 11 or higher
ActionBar actionBar = getActionBar();
//This should cause onPrepareOptionsMenu() to be called.
// In versions of the API prior to 11, this only occurred when the user pressed
// the dedicated menu button, but at level 11 and above, the action bar is
// typically displayed continuously and so you will need to call this
// each time the options on your menu change.
invalidateOptionsMenu();
//Show the bar
actionBar.show();
}
}
Es posible que también desee declarar una targetSdkVersion más alta si se había probado en ese nivel más alto y todo lo trabajado, incluso si estuviera no está usando cualquier característica de una API de nivel más alto que su minSdkVersion. Esto sería solo para evitar la sobrecarga de acceder al código de compatibilidad destinado a adaptarse desde el nivel objetivo hasta el nivel mínimo, ya que habría confirmado (a través de las pruebas) que no se requería tal adaptación.
Un ejemplo de una función de interfaz de usuario que depende de la targetSdkVersion declarada sería el botón de menú de tres puntos verticales que aparece en la barra de estado de las aplicaciones que tienen una targetSdkVersion menor que 11, cuando esas aplicaciones se ejecutan bajo API 11 y superior. Si su aplicación tiene una TargetSdkVersion de 10 o menos, se supone que la interfaz de su aplicación depende de la existencia de un botón de menú dedicado, por lo que el botón de tres puntos parece ocupar el lugar del hardware dedicado anterior y / o las versiones en pantalla de ese botón (por ejemplo, como se ve en Gingerbread) cuando el sistema operativo tiene un nivel API más alto para el cual ya no se supone un botón de menú dedicado en el dispositivo. Sin embargo, si establece targetSdkVersion de su aplicación en 11 o superior, se supone que ha aprovechado las funciones introducidas en ese nivel que reemplazan el botón de menú dedicado (e. g., la barra de acción), o que de otro modo ha eludido la necesidad de tener un botón de menú del sistema; en consecuencia, el "botón de compatibilidad" del menú de tres puntos verticales desaparece. En ese caso, si el usuario no puede encontrar un botón de menú, no puede presionarlo, y eso, a su vez, significa que la anulación onCreateOptionsMenu (menú) de su actividad podría nunca invocarse, lo que, a su vez, significa que Una parte importante de la funcionalidad de su aplicación podría verse privada de su interfaz de usuario. A menos, por supuesto, que haya implementado la Barra de acción o algún otro medio alternativo para que el usuario acceda a estas funciones. Si no encuentra un botón de menú, no puede presionarlo, y eso, a su vez, significa que la anulación onCreateOptionsMenu (menú) de su actividad podría nunca ser invocada, lo que, a su vez, significa que una parte importante de la funcionalidad de su aplicación podría ser privado de su interfaz de usuario. A menos, por supuesto, que haya implementado la Barra de acción o algún otro medio alternativo para que el usuario acceda a estas funciones. Si no encuentra un botón de menú, no puede presionarlo, y eso, a su vez, significa que la anulación onCreateOptionsMenu (menú) de su actividad podría nunca ser invocada, lo que, a su vez, significa que una parte importante de la funcionalidad de su aplicación podría ser privado de su interfaz de usuario. A menos, por supuesto, que haya implementado la Barra de acción o algún otro medio alternativo para que el usuario acceda a estas funciones.
minSdkVersion, por el contrario, establece un requisito de que la versión del sistema operativo de un dispositivo tenga al menos ese nivel de API para ejecutar su aplicación. Esto afecta qué dispositivos pueden ver y descargar su aplicación cuando está en la tienda de aplicaciones de Google Play (y posiblemente también en otras tiendas de aplicaciones). Es una forma de afirmar que su aplicación se basa en las características del sistema operativo (API u otras) que se establecieron en ese nivel, y no tiene una forma aceptable de lidiar con la ausencia de esas características.
Un ejemplo de uso de minSdkVersion para garantizar la presencia de una función que no esté relacionada con la API sería establecer minSdkVersion en 8 para garantizar que su aplicación se ejecute solo en una versión habilitada para JIT del intérprete Dalvik (desde que se introdujo JIT al intérprete de Android en el nivel de API 8). Dado que el rendimiento para un intérprete habilitado para JIT puede ser hasta cinco veces mayor que el que carece de esa característica, si su aplicación hace un uso intensivo del procesador, es posible que desee requerir un nivel de API 8 o superior para garantizar un rendimiento adecuado.
