Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


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

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

7 Solutions collect form web for “Versión Min SDK de Android vs. SDK de destino”

Android: minSdkVersion

Un número entero que designa el nivel mínimo de API necesario 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. Debe declarar siempre este atributo.

Android: targetSdkVersion

Un número entero que designa el nivel de API al que se dirige la aplicación.

Con este atributo establecido, la aplicación dice que es capaz de ejecutar en versiones anteriores (hasta minSdkVersion), pero fue explícitamente probado para trabajar con la versión especificada aquí. La especificación de esta versión de destino permite a la plataforma deshabilitar los ajustes de compatibilidad que no son necesarios para la versión de destino (que de lo contrario pueden activarse para mantener la compatibilidad hacia adelante) o habilitar funciones más recientes 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 hacia adelante con la versión de destino.

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

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

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) es totalmente incorrecto! Siento ser contundente.

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 a su mínimo, pero se ha asegurado la compatibilidad con versiones anteriores . En otras palabras, imagine que desea utilizar una función que sólo se introdujo recientemente, pero eso no es crítico para su aplicación. A continuación, establezca el targetSDK en la versión en la que se introdujo esta nueva característica y el mínimo en algo inferior para que todos puedan seguir utilizando 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 puede ser reconocido por un gesto también se puede hacer con un botón o desde el menú. En este caso, los gestos son un "extra fresco" pero no son necesarios. Por lo tanto, establecería el sdk objetivo en 7 ("Eclair" cuando se introdujera la biblioteca GestureDetection) y el mínimo en el nivel 3 ("Cupcake") para que incluso las personas con teléfonos antiguos pudieran usar su aplicación. Todo lo que tendría que hacer es asegurarse de que su aplicación compruebe la versión de Android en la que se estaba ejecutando antes de intentar utilizar la biblioteca de gestos, para evitar tratar de usarla 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 mantener la compatibilidad con v1.5 era realmente importante).

Para dar otro ejemplo, puedes usarlo si quieres usar una función de Gingerbread o Honeycomb. Algunas personas obtendrán las actualizaciones pronto, pero muchas otras, particularmente con hardware más antiguo, podrían quedarse atascadas con Eclair hasta que compran un nuevo dispositivo. Esto le permitirá utilizar algunas de las nuevas características, pero sin excluir parte de su posible mercado.

Hay un artículo realmente bueno del blog del desarrollador de Android acerca de cómo usar esta característica y, en particular, cómo diseñar el código "comprobar que la característica existe antes de usarlo" que mencioné anteriormente.

Para el OP: He escrito esto principalmente para el beneficio de cualquier persona que pasa a tropezar en esta cuestión en el futuro, como me doy cuenta de que su pregunta fue hecha hace mucho tiempo.

Cuando estableces targetSdkVersion = "xx", estás certificando que tu aplicación funciona correctamente (p. Ej., Se ha probado minuciosamente y con éxito) al nivel API xx.

Una versión de Android que se ejecute en un nivel de API superior a xx aplicará automáticamente el código de compatibilidad para admitir cualquier característica que pueda estar confiando en que estuviera disponible en o antes del nivel xx de la API, pero que ahora están obsoletas en el nivel superior de esa versión de Android.

Por el contrario, si está utilizando cualquier característica que se convirtió en obsoleto en o antes de nivel xx, el código de compatibilidad no será aplicado automáticamente por versiones de SO a niveles API más altos (que ya no incluyen esas características) para admitir dichos usos. En esa situación, su propio código debe tener cláusulas de caso especial que prueban el nivel de API y, si el nivel de sistema operativo detectado es mayor que ya no tiene la característica de API dada, su código debe utilizar características alternativas que están disponibles en el sistema operativo en ejecución Nivel de API.

Si no lo hace, es posible que algunas características de la interfaz no aparezcan normalmente, lo que normalmente desencadenaría eventos dentro de su código, y puede que le falte una característica de interfaz crítica que el usuario necesita para activar esos eventos y para acceder a su funcionalidad. Ejemplo a continuación).

Como se indica en otras respuestas, puede establecer targetSdkVersion más alto que minSdkVersion si desea utilizar algunas características de API definidas inicialmente en niveles API más altos que su minSdkVersion y ha tomado medidas para asegurarse de que su código podría 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 necesario para utilizar una característica, el compilador emitirá un error (no sólo una advertencia) si el código contiene una llamada a cualquier método que se definió en un nivel API posterior a minSdkVersion, Incluso si targetSdkVersion es mayor o igual al nivel de API en el que se ha puesto a disposición por primera vez ese método. Para eliminar este error, la directiva del compilador

@TargetApi(nn) 

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 código siguiente 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 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 mayor si ha probado en ese nivel superior y todo funcionó, incluso si no estaba utilizando ninguna característica de un nivel de API superior a su minSdkVersion. Esto sería sólo para evitar la sobrecarga de acceso al código de compatibilidad destinado a adaptar desde el nivel de objetivo hasta el nivel mínimo, ya que habría confirmado (a través de pruebas) que no se requiere tal adaptación.

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 o superior. Si su aplicación tiene una targetSdkVersion de 10 o menos, se supone que la interfaz de la aplicación depende de la existencia de un botón de menú dedicado y, por lo tanto, el botón de tres puntos aparece para 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 superior para el que ya no se asume un botón de menú dedicado en el dispositivo. Sin embargo, si establece la variable targetSdkVersion de la aplicación en 11 o superior, se supone que ha aprovechado las funciones introducidas a ese nivel que reemplazan el botón de menú dedicado (por ejemplo, la barra de acciones) o que de otro modo evitó la necesidad de Tener un botón del 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 el comando onCreateOptionsMenu (menú) de su actividad podría nunca ser invocado, lo que, de nuevo, significa que Una parte significativa 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 acciones 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 SO 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 tu aplicación cuando se encuentra en la tienda de aplicaciones de Google Play (y posiblemente en otras tiendas de aplicaciones). Es una forma de indicar que su aplicación depende de las características de sistema operativo (API u otras) que se establecieron en ese nivel y no tiene una forma aceptable de tratar la ausencia de esas características.

Un ejemplo de uso de minSdkVersion para asegurar la presencia de una característica que no está relacionada con la API sería establecer minSdkVersion en 8 para asegurar que su aplicación se ejecute sólo en una versión compatible con JIT del intérprete Dalvik (desde que se introdujo JIT Al intérprete de Android en el nivel API 8). Dado que el rendimiento de un intérprete habilitado para JIT puede ser hasta cinco veces el de uno que carezca de esa característica, si su aplicación utiliza mucho el procesador, es posible que desee requerir API de nivel 8 o superior para garantizar un rendimiento adecuado.

Un concepto puede ser mejor entregado con ejemplos, siempre . Tuve problemas en la comprensión de este concepto hasta que cavar en Android código fuente del marco, y hacer algunos experimentos, incluso después de leer todos los documentos en los sitios de desarrollo de Android y relacionados stackoverflow hilos. 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 ponga en el archivo 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á como derecho, con el mismo código .

DatePickerDialog buscar con targetSDKversion 10 o inferiorLook de DatePickerDialog con targetSDKversion 11 o superior

El código que usé 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 los looks de activity_main.xml :

 <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. Ése es realmente cada código que necesito probar esto.

Y este cambio de aspecto es muy claro cuando ves el código fuente de Android framework . 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 se puede ver, el marco obtiene targetSDKversion actual y establecer 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 acerca de la clase WebView . Los métodos públicos de la clase Webview deben ser llamados en el subproceso principal y, si no, el sistema runtime lanza 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 documento para Android dice: " A medida que Android evolucione con cada nueva versión, algunos comportamientos e incluso apariciones podrían cambiar ". Por lo tanto, hemos visto el comportamiento y el cambio de apariencia, y cómo se lleva a cabo ese cambio.

En resumen, el documento de Android dice: " Este atributo (targetSdkVersion) informa al sistema que has probado en contra de la versión de destino y el sistema no debe habilitar ningún comportamiento de compatibilidad para mantener la compatibilidad hacia adelante de tu aplicación con la versión de destino ". Esto es realmente claro con el caso de WebView. Estaba OK hasta que JELLY_BEAN_MR2 liberado para llamar al método público de la clase WebView en el subproceso no principal. No tiene sentido que el marco de Android lance una excepción de Runtime en dispositivos JELLY_BEAN_MR2. Simplemente no debe permitir que los comportamientos recién introducidos por su interés, que causan resultados fatales. 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 mayor targetSDKversion, pero viene con responsabilidad.

EDIT: descargo de responsabilidad. El constructor DatePickerDialog que estableció diferentes temas basados ​​en targetSDKversion actual (que mostré anteriormente) en realidad se ha cambiado en commit posterior . Sin embargo, he utilizado ese ejemplo, porque la lógica no se ha cambiado, y los fragmentos de código muestra claramente targetSDKversion concepto.

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 versión inferior de Android, la aplicación no se instalará.

mientras,

 android:targetSdkVersion 

Es el nivel API hasta el que se ha diseñado para ejecutar tu aplicación. Medios, el sistema de su teléfono no es necesario utilizar cualquier compatibilidad de compatibilidad para mantener la compatibilidad hacia adelante porque ha probado en contra hasta esta API. Además, esto le permite usar algunas pero no todas las características de esta versión de destino.

Freebie –

android:maxSdkVersion

Si la versión de API del dispositivo es mayor, 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á en un mínimo de 1.6, pero también he utilizado características que sólo se admiten en 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.

Referencia más pequeña

Referencia explicada

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

Usted obtiene el error de compilación:

El campo requiere el nivel 11 de API (el min 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 @TargetApi que puede arreglar esto muy fácilmente. Añádelo antes del método que contiene 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á!

EDIT: Esto resultará en 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 que llama a este método en una ruta de ejecución protegida por la comprobación de versión. TargetApi sólo le permite compilar, pero lo ejecuta en su propio riesgo.

android:minSdkVersion y android:targetSdkVersion ambos son Integer valor que tenemos que declarar en el archivo de manifiesto android, pero ambos tienen diferentes propiedades.

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

android:targetSdkVersion: objetivo de la versión sdk es establecer el nivel de la API de destino de la aplicación. Si este atributo no está declarado en el manifiesto, la versión de minSdk será su versión de TargetSdk. Esto siempre es cierto que "app soporta la instalación en todas las versiones superiores de API que hemos declarado como TargetSdk Version". Para hacer objetivo limitado de la aplicación tenemos que declarar maxSdkVersion en nuestro archivo de manifiesto …

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.