Versión de Android Min SDK vs. Versión de Target SDK

Cuando se trata de desarrollar aplicaciones para Android, ¿cuál es la diferencia entre la versión Min y Target SDK? ¡Eclipse no me permitirá crear un nuevo proyecto a menos que las versiones Min y Target sean las mismas!

android: minSdkVersion

Un entero que designa el nivel mínimo de API requerido para que se ejecute la aplicación. El sistema Android evitará que el usuario instale la aplicación si el nivel de API del sistema es inferior al valor especificado en este atributo. Siempre debe declarar este atributo.

android: targetSdkVersion

Un entero que designa el nivel API al que apunta la aplicación.

Con este conjunto de atributos, la aplicación dice que puede ejecutarse en versiones anteriores (hasta minSdkVersion), pero se probó explícitamente para funcionar con la versión especificada aquí. La especificación de esta versión de destino permite que la plataforma desactive la configuración de compatibilidad que no es necesaria para la versión de destino (que de otro modo podría activarse para mantener la compatibilidad con versiones anteriores) o habilitar funciones más nuevas que no están disponibles para aplicaciones más antiguas. Esto no significa que pueda programar diferentes funciones para diferentes versiones de la plataforma: simplemente informa a la plataforma que ha probado con la versión de destino y la plataforma no debe realizar ningún trabajo adicional para mantener la compatibilidad con la versión de destino.

Para obtener más información, consulte esta URL:

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

¡El comentario publicado por el OP a la pregunta (básicamente afirmando que el targetSDK no afecta la compilación de una aplicación) está completamente equivocado! Perdón por ser contundente.

En resumen, este es el propósito de declarar un targetSDK diferente del minSDK: significa que está utilizando funciones de un SDK de nivel superior al mínimo, pero se ha asegurado la compatibilidad con versiones anteriores . En otras palabras, imagine que desea utilizar una función que se introdujo recientemente, pero que no es crítica para su aplicación. Luego, establecería el targetSDK en la versión donde se introdujo esta nueva característica y el mínimo en algo más bajo para que todos puedan seguir usando su aplicación.

Para dar un ejemplo, supongamos que está escribiendo una aplicación que hace un uso extensivo de la detección de gestos. Sin embargo, cada comando que se puede reconocer mediante un gesto también se puede hacer con un botón o desde el menú. En este caso, los gestos son un "extra genial" pero no son obligatorios. Por lo tanto, establecería el SDK de destino en 7 ("Eclair" cuando se introdujo la biblioteca GestureDetection) y el SDK mínimo en el nivel 3 ("Cupcake") para que incluso las personas con teléfonos realmente viejos puedan usar su aplicación. Todo lo que tendría que hacer es asegurarse de que su aplicación verificó la versión de Android en la que se estaba ejecutando antes de intentar usar la biblioteca de gestos, para evitar intentar usarla si no existiera. (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 se mantenía la compatibilidad con v1.

Para dar otro ejemplo, podría usar esto si quisiera usar una función de Gingerbread o Honeycomb. Algunas personas recibirán las actualizaciones pronto, pero muchas otras, particularmente con hardware antiguo, pueden quedarse con Eclair hasta que compren un nuevo dispositivo. Esto le permitiría utilizar algunas de las nuevas funciones interesantes, pero sin excluir parte de su posible mercado.

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

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

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.

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

Un DatePickerDialog se verá diferente en función del nivel que coloque en el destino de archivo AndroidManifest.xml targetSDKversion ( <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>). Si establece el valor 10 o inferior, su DatePickerDialog se verá como a la izquierda. Por otro lado, si establece el valor 11 o superior, un DatePickerDialog se verá bien, con el mismo código .

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

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 se activity_main.xmlve:

<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 claro como el cristal cuando ves el código fuente del marco 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 marco obtiene la versión actual de targetSDK 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 llamarse en el hilo principal, y si no, el sistema de tiempo de ejecución arroja un RuntimeException, cuando configura targetSDKversion 18 o superior. Este comportamiento se puede entregar claramente con su código fuente . Simplemente está escrito así.

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

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

El documento de Android dice: " A medida que Android evoluciona con cada nueva versión, algunos comportamientos e incluso apariencias pueden cambiar ". Entonces, hemos observado cambios en el comportamiento y la apariencia, y cómo se logra ese cambio.

En resumen, el documento de Android dice " Este atributo (targetSdkVersion) informa al sistema que has probado con la versión de destino y el sistema no debe habilitar ningún comportamiento de compatibilidad para mantener la compatibilidad con la versión de destino de tu aplicación ". Esto es realmente claro con el caso de WebView. Estuvo bien hasta que JELLY_BEAN_MR2 se lanzó para llamar al método público de la clase WebView en un subproceso no principal. No tiene sentido si el marco de Android lanza una RuntimeException en dispositivos JELLY_BEAN_MR2. Simplemente no debería permitir comportamientos recientemente introducidos por su interés, que causan resultados fatales. Entonces, lo que tenemos que hacer es verificar si todo está bien en ciertas versiones de targetSDK. Obtenemos beneficios como la mejora de la apariencia con la configuración de una versión más alta

EDITAR: descargo de responsabilidad. El constructor DatePickerDialog que establece diferentes temas basados ​​en la versión actual de targetSDK (que mostré arriba) en realidad se ha cambiado en commit posterior . Sin embargo, utilicé ese ejemplo, porque la lógica no ha cambiado y esos fragmentos de código muestran claramente el concepto targetSDKversion.

Para aquellos que quieren un resumen,

android:minSdkVersion

es la versión mínima hasta que su aplicación lo admita. Si su dispositivo tiene una versión inferior de Android, la aplicación no se instalará.

mientras,

android:targetSdkVersion

es el nivel de API hasta el cual su aplicación 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 directa porque ha probado hasta esta API.

Su aplicación aún se ejecutará en versiones de Android superiores a las proporcionadas, targetSdkVersionpero se iniciará el comportamiento de compatibilidad de Android.

Freebie -

android:maxSdkVersion

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

es decir. para MinSDK -4, maxSDK - 8, targetSDK - 8 Mi aplicación funcionará con un mínimo de 1.6 pero también he usado funciones que solo son compatibles con 2.2, que serán visibles si está instalado en un dispositivo 2.2. Además, para maxSDK - 8, esta aplicación no se instalará en teléfonos que utilicen API> 8.

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

Si obtiene 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**
        //...
    }

Obtiene un error de compilación:

El campo requiere API nivel 11 (el mínimo actual es 10): android.graphics.BitmapFactory $ Options # inBitmap

Desde la versión 17 de las Herramientas de desarrollo de Android (ADT), hay una anotación nueva y muy útil @TargetApique puede solucionarlo muy fácilmente. Agréguelo 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**
            //...
      }
    }

No hay errores de compilación ahora y se ejecutará.

EDITAR: Esto provocará un error de tiempo de ejecución en el 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:minSdkVersiony android:targetSdkVersionambos son valores enteros que debemos declarar en el archivo de manifiesto de Android, pero ambos tienen propiedades diferentes.

android:minSdkVersion:Este es el nivel mínimo de API requerido para ejecutar una aplicación de Android. Si instalamos la misma aplicación en una versión de API inferior, aparecerá el error del analizador y aparecerá un problema de 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 manifiesto, la versión minSdk será su versión TargetSdk. Esto siempre es cierto que "la instalación de soporte de aplicaciones en todas las versiones superiores de API que declaramos como TargetSdk Version". Para hacer que la aplicación tenga un objetivo limitado, debemos declarar maxSdkVersion en nuestro archivo de manifiesto ...

Si está creando aplicaciones que requieren permisos peligrosos y establece targetSDK en 23 o superior , debe tener cuidado. Si no verifica los permisos en tiempo de ejecución, obtendrá una excepción de seguridad y si está utilizando código dentro de un bloque de prueba, por ejemplo, abrir la cámara, puede ser difícil detectar un error si no verifica logcat.

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