Android Min SDK Version vs Diana Versión del SDK

El comentario publicado por el OP a la pregunta (básicamente indicando que el targetSdk no afecta a la compilación de una aplicación) está completamente equivocado! Siento ser franco.

En resumen, aquí está el propósito de declarar un targetSdk diferente del minSdk: Significa que está utilizando características de un SDK de nivel superior al mínimo, pero tiene compatibilidad con versiones anteriores garantizada. En otras palabras, imagine que desea usar una función que solo se introdujo recientemente, pero eso no es crítico para su aplicación. A continuación, establecería el targetSdk a la versión donde se introdujo esta nueva característica y el mínimo a algo más bajo para que todos pudieran seguir usando su aplicación.

Para dar un ejemplo, digamos que estás escribiendo una aplicación que hace un uso extensivo de la detección de gestos. Sin embargo, cada comando que se puede reconocer por un gesto también se puede hacer por un botón o desde el menú. En este caso, los gestos son un "extra genial", pero no son necesarios. Por lo tanto establecería el sdk de destino en 7 ("Eclair" cuando se introdujo la biblioteca GestureDetection), y el minimumSDK en nivel 3 ("Cupcake") para que incluso las personas con teléfonos realmente antiguos pudieran usar su aplicación. Todo lo que tendría que hacer es asegurarse de que su aplicación comprobó la versión de Android en la que se estaba ejecutando antes de intentar usar la biblioteca de gestos, para evitar tratar de usarlo si no existía. (Es cierto que este es un ejemplo anticuado ya que casi nadie todavía tiene un teléfono v1. 5, pero hubo un momento en el que el mantenimiento la compatibilidad con la v1. 5 fue realmente importante.)

Para dar otro ejemplo, podría usar esto si desea usar una característica de Pan de jengibre o Panal. Algunas personas recibirán las actualizaciones pronto, pero muchas otras, particularmente con hardware más antiguo, podrían quedarse atascadas con Eclair hasta que compren un nuevo dispositivo. Esto le permitiría utilizar algunas de las nuevas características interesantes, pero sin excluir parte de su mercado posible.

Hay un muy buen artículo de la desarrollador de Android blog sobre cómo usar esta característica, y en particular, cómo diseñar el código "comprobar que la característica existe antes de usarla" que mencioné anteriormente.

A la OP: He escrito esto principalmente para el beneficio de cualquiera que se tropiece con esta pregunta en el futuro, ya que me doy cuenta de que su pregunta se hizo hace mucho tiempo.

Cuando establece targetSdkVersion="xx", certifica que su aplicación funciona correctamente (por ejemplo, se ha probado a fondo y con éxito) a nivel de API xx.

Una versión de Android que se ejecute en un nivel de API anterior a xx aplicará el código de compatibilidad automáticamente para admitir cualquier función en la que pueda confiar que estuviera 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 se volvió obsoleto en o antes de al nivel xx, el código de compatibilidad no se aplicará automáticamente por las versiones del sistema operativo en niveles de API más altos (que ya no incluyen esas características) para soportar esos usos. En esa situación, su propio código debe tener cláusulas de caso especiales que prueben el nivel de API y, si el nivel de sistema operativo detectado es uno más alto que ya no tiene la característica de API dada, su código debe usar características alternativas que están disponibles en la API del sistema operativo en ejecución nivel.

Si no logra hacer esto, entonces algunas características de la interfaz pueden simplemente no aparecer que normalmente desencadenarían eventos dentro de su código, y puede que le falte una característica crítica de la interfaz que el usuario necesita para desencadenar esos eventos y acceder a su funcionalidad (como en el ejemplo a continuación).

Como se indica en otras respuestas, puede establecer targetSdkVersion más alto que minSdkVersion si desea usar algunas características de la API definidas inicialmente en niveles de API más altos que su minSdkVersion, y había tomado medidas para asegurar que su código pudiera 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 de API mínimo requerido para usar una característica, el compilador emitirá un error (no solo una advertencia) si el código contiene una llamada a cualquier método que se haya definido en un nivel de API posterior a minSdkVersion, incluso si targetSdkVersion es mayor o igual al nivel de API en el que el 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 código dentro de una aplicación que tiene una minSdkVersion de menos de 11 targetSdkVersion de 11 o superior:

@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 superior si ha probado en ese nivel superior y todo funcionó, incluso si estuviera no utilizando cualquier característica de un nivel de API superior a 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 pruebas) que no se requerir.

Un ejemplo de una característica 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 inferior a 11, cuando esas aplicaciones se ejecutan bajo API 11 y superior. Si su aplicación tiene una targetSdkVersion de 10 o inferior, se asume 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 tomar el lugar del anterior dedicado hardware y / o versiones en pantalla de ese botón (por ejemplo, como se ve en Gingerbread) cuando el sistema operativo tiene un nivel de API más alto para el que ya no se asume un botón de menú dedicado en el dispositivo. Sin embargo, si establece la targetSdkVersion de su aplicación en 11 o superior, se asume que ha aprovechado las características introducidas en ese nivel que reemplazan el botón de menú dedicado (por ejemplo, la Barra de acciones), o que de otra manera ha eludido la necesidad de tener un botón de menú del sistema; en consecuencia, el menú de tres puntos verticales" botón de compatibilidad " 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 de onCreateOptionsMenu(menú) de su actividad podría nunca ser invocada, lo que, de nuevo, a su vez, significa que una parte significativa 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 acciones o algún otro medio alternativo para que el usuario acceda a estos función.

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 a qué dispositivos pueden ver y descargar tu 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 función.

Un ejemplo de uso de minSdkVersion para garantizar la presencia de una característica 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 (ya que JIT se introdujo en el intérprete de Android a nivel de API 8). Dado que el rendimiento de un intérprete habilitado para JIT puede ser hasta cinco veces mayor que el de uno que carece de esa característica, si su aplicación hace un uso intensivo del procesador, entonces usted es posible que desee requerir el nivel de API 8 o superior para garantizar un rendimiento adecuado.

Un concepto se puede entregar mejor con ejemplos, siempre. Tuve problemas para comprender estos conceptos hasta que profundicé en el código fuente del marco de trabajo de Android y realicé algunos experimentos, incluso después de leer todos los documentos en los sitios de desarrolladores de Android y los hilos de stackoverflow relacionados. Voy a compartir dos ejemplos que me ayudaron mucho a entender completamente estos conceptos.

Un DatePickerDialog se verá diferente según el nivel que pongas en AndroidManifest.XML targetSdkVersion (<uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>). Si establece el valor 10 o inferior, su DatePickerDialog se verá como la izquierda. Por otro lado, si establece el valor 11 o superior, un DatePickerDialog se verá como correcto, con el mismo código.

El código que usé para crear este ejemplo es súper simple. MainActivity.java looks:

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    public void onClickButton(View v) {
        DatePickerDialog d = new DatePickerDialog(this, null, 2014, 5, 4);
        d.show();       
    }
}

Y activity_main.xml looks:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
<Button
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="onClickButton"
    android:text="Button" />
</RelativeLayout>

Eso es. Eso es realmente cada código que necesito para probar esto.

Y este cambio en el aspecto es muy claro cuando ves el código fuente del marco de trabajo de Android. Va como :

public DatePickerDialog(Context context,
    OnDateSetListener callBack,
    int year,
    int monthOfYear,
    int dayOfMonth,
    boolean yearOptional) {
        this(context, context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB
                ? com.android.internal.R.style.Theme_Holo_Light_Dialog_Alert
                : com.android.internal.R.style.Theme_Dialog_Alert,
        callBack, year, monthOfYear, dayOfMonth, yearOptional);
}

Como puede ver, el framework obtiene targetSdkVersion actual y establece un tema diferente. Este tipo de fragmento de código(getApplicationInfo().targetSdkVersion >= SOME_VERSION) se puede encontrar aquí y allá en el marco de Android.

Otro ejemplo es sobre la clase WebView. Los métodos públicos de la clase Webview deben ser llamados en el hilo principal, y si no, el sistema en tiempo de ejecución lanza un RuntimeException, cuando se establece targetSdkVersion 18 o superior. Este comportamiento se puede entregar claramente con su código fuente. Está escrito así.

sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >=
            Build.VERSION_CODES.JELLY_BEAN_MR2;

if (sEnforceThreadChecking) {
    throw new RuntimeException(throwable);
}

El Android doc dice, " A medida que Android evoluciona con cada nueva versión, algunos comportamientos e incluso apariencias podrían cambiar."Por lo tanto, hemos mirado el cambio de comportamiento y apariencia, y cómo se logra ese cambio.

En resumen, el documento de Android dice " Esto el atributo (targetSdkVersion) informa al sistema que ha realizado pruebas con la versión de destino y el sistema no debe habilitar ningún comportamiento de compatibilidad para mantener la compatibilidad directa de su aplicación con la versión de destino.". Esto es muy claro con el caso WebView. Estaba bien hasta que se liberó JELLY_BEAN_MR2 para llamar al método público de la clase WebView en el hilo no-main. No tiene sentido si el marco de Android lanza una excepción RuntimeException en dispositivos JELLY_BEAN_MR2. Simplemente no debe permitir comportamientos recién introducidos para su interés, que causan resultado fatal. Por lo tanto, lo que tenemos que hacer es comprobar si todo está bien en ciertas targetSDKversions. Obtenemos beneficios como la mejora de la apariencia con el establecimiento de targetSdkVersion más alto, pero viene con la responsabilidad.

EDITAR : descargo. El constructor DatePickerDialog que estableció diferentes temas basados en targetSdkVersion actual (que mostré anteriormente) en realidad se ha cambiado en más tarde commit. Sin embargo usé ese ejemplo, porque la lógica no se ha cambiado, y ese fragmento de código muestra claramente el concepto targetSdkVersion.

Para aquellos que quieren un resumen,

android:minSdkVersion

Es la versión mínima hasta que su aplicación sea compatible. Si su dispositivo tiene una versión más baja de Android , la aplicación no se instalará.

Mientras,

android:targetSdkVersion

Es el nivel de API hasta el cual tu app está diseñada para ejecutarse. Significa que el sistema de su teléfono no necesita usar ningún comportamiento de compatibilidad para mantener la compatibilidad hacia adelante porque ha probado contra hasta esta API.

Tu aplicación seguirá ejecutándose en versiones de Android superiores a dado targetSdkVersion pero el comportamiento de compatibilidad de Android se activará.

Freebie -

android:maxSdkVersion

Si la versión de la API de su dispositivo es superior, la aplicación no se instalará. IE. esta es la API máxima hasta la que permite que su aplicación se instale.

Ie. para minSdk -4, maxSDK - 8, targetSdk - 8 Mi aplicación funcionará en mínimo 1.6, pero también he utilizado características que solo son compatibles con 2.2, que serán visibles si se instala en un dispositivo 2.2. Además, para maxSDK-8, esta aplicación no se instalará en teléfonos usando API > 8.

En el momento de escribir esta respuesta, la documentación de Android no estaba haciendo un gran trabajo para explicarlo. Ahora está muy bien explicado. Compruébalo aquí

Si obtienes algunos errores de compilación, por ejemplo:

<uses-sdk
            android:minSdkVersion="10"
            android:targetSdkVersion="15" />

.

private void methodThatRequiresAPI11() {
        BitmapFactory.Options options = new BitmapFactory.Options();
                options.inPreferredConfig = Config.ARGB_8888;  // API Level 1          
                options.inSampleSize = 8;    // API Level 1
                options.inBitmap = bitmap;   // **API Level 11**
        //...
    }

Obtienes un error de compilación:

Campo requiere API nivel 11 (min actual es 10): androide.gráficos.BitmapFactory Options Options#inBitmap

Desde la versión 17 de Android Development Tools (ADT) hay una nueva y muy útil anotación @TargetApi que puede solucionar esto muy fácilmente. Añádalo antes del método que encierra la declaración problemática:

@TargetApi
private void methodThatRequiresAPI11() {            
  BitmapFactory.Options options = new BitmapFactory.Options();
      options.inPreferredConfig = Config.ARGB_8888;  // API Level 1          
      options.inSampleSize = 8;    // API Level 1

      // This will avoid exception NoSuchFieldError (or NoSuchMethodError) at runtime. 
      if (Integer.valueOf(android.os.Build.VERSION.SDK) >= android.os.Build.VERSION_CODES.HONEYCOMB) {
        options.inBitmap = bitmap;   // **API Level 11**
            //...
      }
    }

Ahora no hay errores de compilación y se ejecutará !

EDITAR: Esto dará lugar a un error de tiempo de ejecución en un nivel de API inferior a 11. En 11 o superior se ejecutará sin problemas. Por lo tanto, debe asegurarse de llamar a este método en una ruta de ejecución protegida por la verificación de versión. TargetApi solo le permite compilarlo, pero lo ejecuta bajo su propio riesgo.

android:minSdkVersion y android:targetSdkVersion ambos son valores enteros que necesitamos declarar en el archivo de manifiesto de Android, pero ambos tienen propiedades diferentes.

android:minSdkVersion: Este es el nivel de API mínimo requerido para ejecutar una aplicación de Android. Si vamos a instalar la misma aplicación en la versión más baja de la API aparecerá el error del analizador, y aparecerá el problema de la aplicación no compatible.

android:targetSdkVersion: La versión de sdk de destino es establecer el nivel de API de destino de la aplicación. si este atributo no se declara en manifest, minSdk la versión será la versión de targetSdk. Esto siempre es cierto que "instalación de soporte de aplicaciones en todas las versiones superiores de la API que declaramos como versión targetSdk". Para hacer app limited target necesitamos declarar maxSdkVersion en nuestro archivo de manifiesto...

Target sdk es la versión a la que desea dirigirse, y min sdk es la mínima.

Si está creando aplicaciones que requieren permisos peligrosos y establece targetSdk en 23 o superior debe tener cuidado. Si no comprueba los permisos en tiempo de ejecución, obtendrá una SecurityException y si está utilizando código dentro de un bloque de prueba, por ejemplo, open camera, puede ser difícil detectar errores si no comprueba logcat.