que - Android Min SDK Version vs. Target SDK Version

target version android

Question

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

Answer 1

Android: minSdkVersion

Un entero que designa el nivel de API mínimo 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 debes declarar este atributo.

Android: targetSdkVersion

Un entero que designa el nivel de API al que se dirige 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 trabajar con la versión especificada aquí. La especificación de esta versión de destino permite que la plataforma deshabilite la configuración de compatibilidad que no se requiere para la versión de destino (que de lo contrario podría estar activada para mantener la compatibilidad hacia adelante) o habilitar funciones más nuevas que no están disponibles para aplicaciones anteriores. Esto no significa que pueda programar diferentes funciones para diferentes versiones de la plataforma; simplemente informa a la plataforma que ha probado en comparación 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 más información consulte esta URL:

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

Answer 2

¡El comentario publicado por el OP a la pregunta (que básicamente indica que targetSDK no afecta la compilación de una aplicación) es totalmente erróneo! Siento ser contundente.

En resumen, este es el propósito de declarar un targetSDK diferente del minSDK: significa que está utilizando características de un SDK de nivel más alto que su mínimo, pero 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 fundamental para su aplicación. Luego, debe establecer targetSDK en la versión donde se introdujo esta nueva característica y el mínimo a algo más bajo para que todos puedan usar su aplicación.

Para dar un ejemplo, digamos que está escribiendo una aplicación que hace un uso extensivo de la detección de gestos. Sin embargo, cada comando que puede ser reconocido por un gesto también puede hacerse con un botón o desde el menú. En este caso, los gestos son un "extra genial" pero no son necesarios. Por lo tanto, debe establecer el sdk objetivo en 7 ("Eclair" cuando se introdujo la biblioteca GestureDetection), y el número mínimo de SDK en el nivel 3 ("Cupcake") para que incluso las personas con teléfonos realmente antiguos puedan usar su aplicación. Todo lo que tendría que hacer es asegurarse de que su aplicación verificara la versión de Android en la que se estaba ejecutando antes de intentar usar la biblioteca de gestos, para evitar tratar de usarla si no existiera. (Es cierto que este es un ejemplo antiguo, ya que casi nadie tiene un teléfono v1.5, pero hubo un momento en que era realmente importante mantener la compatibilidad con v1.5).

Para dar otro ejemplo, podrías usar esto si quisieras usar una característica de Gingerbread o Honeycomb. Algunas personas recibirán las actualizaciones pronto, pero muchas otras, particularmente con hardware más antiguo, podrían quedarse estancadas con Eclair hasta que compren un nuevo dispositivo. Esto le permitiría usar algunas de las nuevas y geniales funciones, pero sin excluir parte de su posible mercado.

Hay un artículo realmente bueno del blog del desarrollador de Android sobre cómo usar esta función y, en particular, cómo diseñar el código "Verifique que exista la función 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.

Answer 3

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 por encima de xx aplicará automáticamente el código de compatibilidad para admitir las funciones en las que podría confiar que estaban disponibles en o antes del nivel de API xx, pero que ahora están obsoletas en el nivel superior de esa versión de Android.

A la inversa, si está utilizando alguna función que se haya quedado obsoleta en el nivel xx o anterior al mismo, las versiones del sistema operativo no aplicarán automáticamente el código de compatibilidad en niveles de API más altos (que ya no incluyen esas funciones) para admitir esos usos. En esa situación, su propio código debe tener cláusulas de casos especiales que prueben el nivel de la API y, si el nivel del sistema operativo detectado es uno más alto que ya no tiene la función API dada, su código debe usar funciones alternativas que estén disponibles en los sistemas operativos en ejecución. Nivel de API

Si no lo hace, entonces es posible que algunas características de la interfaz simplemente no aparezcan y que normalmente desencadenen eventos dentro de su código, y es posible que le falte una función de interfaz crítica que el usuario necesita para desencadenar 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 quisiera usar algunas funciones de API definidas inicialmente en niveles de API más altos que su minSdkVersion, y tomó medidas para garantizar que su código pueda detectar y manejar la ausencia de esas características 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 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 un 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();
    }
}

También es posible que desee declarar un targetSdkVersion más alto si lo probó en ese nivel superior y todo funcionó, incluso si no estaba usando ninguna característica de un nivel de API más alto que su minSdkVersion. Esto sería solo para evitar la sobrecarga de acceso 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 requería tal adaptación.

Un ejemplo de una característica de UI 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 inferior, 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 reemplazar el 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 de API más alto para el cual ya no se asume un botón de menú dedicado en el dispositivo. Sin embargo, si configura targetSdkVersion de su aplicación en 11 o superior, se supone que ha aprovechado las características introducidas en ese nivel que reemplazan al botón del menú dedicado (por ejemplo, la Barra de acciones), o que de otro modo ha evitado 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 su anulación OnCreateOptionsMenu (menú) de su actividad nunca se puede invocar, 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 que, por supuesto, 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 el 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 los dispositivos que pueden ver y descargar su aplicación cuando está en la tienda de aplicaciones 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 SO (API u otras) que se establecieron a ese nivel, y no tiene una manera 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 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 de Dalvik (desde que se introdujo JIT al intérprete de Android en el nivel de API 8). Dado que el rendimiento de un intérprete habilitado para JIT puede ser hasta cinco veces mayor que el de una que carece de esa función, si su aplicación hace un uso intensivo del procesador, es posible que desee un nivel de API 8 o superior para garantizar un rendimiento adecuado.

Answer 4

Para aquellos que quieren un resumen,

android:minSdkVersion

Es la versión mínima hasta que su aplicación soporta. 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 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 hacia adelante porque ha probado hasta esta API.

Su aplicación aún se ejecutará en versiones de Android superiores a las de targetSdkVersion pero el comportamiento de compatibilidad con Android se activará.

Freebie -

android:maxSdkVersion

Si la versión API de su dispositivo es más alta, 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 la versión 2.2, que estarán visibles si están instaladas en un dispositivo 2.2. Además, para maxSDK - 8, esta aplicación no se instalará en los 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í

Answer 5

Si está creando aplicaciones que requieren permisos peligrosos y configura targetSDK a 23 o más , debe tener cuidado. Si no verifica los permisos en tiempo de ejecución, obtendrá una excepción SecurityException y si está usando un código dentro de un bloque try, por ejemplo, abrir la cámara, puede ser difícil detectar un error si no marca Logcat.

Answer 6

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 error de compilación:

El campo requiere el nivel 11 de API (el min actual es 10): android.graphics.BitmapFactory $ Opciones # inBitmap

Desde la versión 17 de las Herramientas de desarrollo de Android (ADT), hay una nueva y muy útil anotación @TargetApi que puede solucionar esto muy fácilmente. Agréguelo antes del método que está adjuntando 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 resultará en 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 usted lo ejecuta bajo su propio riesgo.

Answer 7

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

Answer 8

android:minSdkVersion y android:targetSdkVersion 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 instalaremos la misma aplicación en una versión de API más baja, aparecerá el error del analizador y aparecerá el problema de la aplicación no compatible.

android:targetSdkVersion: versión de Target android:targetSdkVersion: es para establecer el nivel de API de destino de la aplicación. Si este atributo no está declarado en el 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 versión TargetSdk". Para hacer un destino limitado de la aplicación debemos declarar maxSdkVersion en nuestro archivo de manifiesto ...

Answer 9

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

Un DatePickerDialog tendrá un aspecto diferente según el nivel que haya puesto en targetSDKversion del archivo AndroidManifest.xml ( <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 utilicé para crear esta muestra es super simple. MainActivity.java :

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 la activity_main.xml ve:

<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 la apariencia es muy claro cuando se ve 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 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 de WebView . Los métodos públicos de la clase Webview deben llamarse en el hilo principal y, de no ser así, el sistema en tiempo de ejecución lanza una RuntimeException , cuando establece targetSDKversion 18 o superior. Este comportamiento puede ser entregado claramente con su código fuente . Sólo 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 evolucione con cada nueva versión, algunos comportamientos e incluso las apariencias podrían cambiar ". Por lo tanto, 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 ha probado con la versión de destino y el sistema no debe permitir ningún comportamiento de compatibilidad para mantener la compatibilidad de su aplicación con la versión de destino ". 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 hilo no principal. No tiene sentido si el marco de Android lanza una excepción RuntimeException en dispositivos JELLY_BEAN_MR2. Simplemente no debe permitir los 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 targetSDKversion superior, pero viene con responsabilidad.

EDITAR: descargo de responsabilidad. El constructor DatePickerDialog que configuró diferentes temas basados ​​en targetSDKversion actual (que mostré anteriormente) en realidad se ha cambiado en la confirmación posterior . Sin embargo, utilicé ese ejemplo, porque la lógica no se ha cambiado y el fragmento de código muestra claramente el concepto targetSDKversion.