Escribir un código para Android compatible con versiones anteriores

Estoy escribiendo una aplicación que utiliza algunas funciones y clases sólo disponibles en el último nivel de API – 16, pero quiero que se ejecute sin errores en los dispositivos con API de nivel 15.

Vamos a usar un par de ejemplos. Una nueva clase: Android.widget.Advanceable y un método nuevo / renombrado: View.setBackground() :

Puedo hacer algo como esto:

 Advanceable myAdvanceable = ...; if (android.os.Build.VERSION.SDK_INT >= 16) { myView.setBackground(...); myAdvanceable.advance(); } else { myView.setBackgroundDrawable(...); // The old function name. // Don't bother advancing advanceables. } 

Y si establezco un minSdk de 15, pero un objetivo de compilación de 16 (es decir, en Propiedades del proyecto-> Android), en realidad se compilará sin errores. Al menos una parte del tiempo. Eclipse es un poco estocástico acerca de los errores y a veces dirá "setBackground () sólo está disponible en el nivel de la API> = 16" o similar, pero si acabo de limpiar el proyecto esos errores mágicamente desaparecen.

Así que mi pregunta es, ¿estoy autorizado a hacer esto? ¿No se bloqueará el código si lo ejecuto en un dispositivo API de nivel 15? ¿Se bloqueará si llega al código 16? ¿Por qué Eclipse no me impide construirlo?

Editar 1

Gracias por las respuestas, supongo que la pregunta debe ser: ¿Por qué no pelusa me advierto sobre el uso de nuevas API?

Tengo esto en mi manifiesto, y estoy utilizando API de nivel 16 funciones, pero todavía no me advierte:

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

También todavía no estoy seguro acerca de cuándo clases enteras son nuevas en un nivel de API, como Advanceable . Específicamente si las utilizo como variables miembro.

Editar 2

La respuesta resultó ser "Eclipse es buggy como el infierno", pero la respuesta de Nico también fue muy útil.

Los errores de Api en línea son nuevos para ADT, Eclipse ejecuta Lint (y supongo que algo más tal vez) para analizar su código y poner los errores / advertencias en línea. Lo mismo se aplica al diseño de xml cuando tiene advertencias o sugerencias sobre optimizaciones o prácticas recomendadas. Puede utilizar Anotaciones para suprimir esos errores en la clase o en un método en particular.

@TargetApi (16)
@SuppressLint ("NewApi")

Hay un problema en el código de ejemplo que pones aquí, al lado de la comprobación de nivel de API tienes una instancia de Advanceable en el código que no funcionará en API <16, por lo que comprobar el nivel de API solo es útil cuando llamas a nuevos métodos pero no puedes Referencia nuevas clases API fuera del bloque IF.

Un enfoque que encontré aceptable es crear una clase abstracta y dos implementaciones, a continuación, para instanciar la implementación correcta se puede utilizar una clase de fábrica con métodos estáticos.

Por ejemplo, para crear una vista que utilice algunas clases y métodos de API nuevos internamente, es necesario:

1 – Crear clase abstracta:

 public abstract class CustomView { public abstract void doSomething(); } 
  • Implementación común compatible con todas las API
  • Definir el método abstracto aquí para dividir la implementación

2 – Implementación de legado

 public class CustomLegacyView extends CustomView { public void doSomething(){ //implement api < 16 } } 
  • Implementar el método abstracto para API <16

3 – Implementación de la API 16

 @TargetApi(16) public class CustomL16View extends CustomView { Advanceable myAdvanceable; public void doSomething(){ //implement api >= 16 } } 
  • Utilice la anotación @TargetApi (16)
  • Implementar el método abstracto para API> = 16
  • Puede referenciar clases de nivel 16 aquí (pero no en CustomView)

4 – Clase de fábrica

 public class ViewFactory { public static CustomView getCustomView(Context context) { if (android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) { return new CustomL16View(context); }else{ return new CustomLegacyView(context); } } } 

Es una práctica común usar un objetivo de compilación más reciente y garantizar que se llamará API más reciente en las circunstancias correctas. Google incluso añadió la anotación @TargetApi() desde ADT 17 para especificar las sustituciones locales para el código cargado condicionalmente.

Consulte Comprobación API Lint para obtener más detalles.

1. Tiene Atributos de Target Api y Atributos Minimum SDK para definir qué tipo de dispositivo está dirigiendo y cuál será la versión menos Api en la que se ejecutará.

2. Target Api será el que se ejecuta en la aplicación con características completas , mientras que Minimum SDK hará que la aplicación se ejecuta en ella con algunos Compromisos ya que puede haber posibilidades de que la versión inferior de la API no tienen las características que están en sus versiones superiores .

  • Android mercado dice que no compatible con dispositivos?
  • No obtener onActivityResult () de una subclase ActionBarActivity
  • XmlPullParserException: vector de etiqueta desplegable no válido
  • Compatibilidad hacia adelante o hacia atrás en Android?
  • Android Market - ¿Esta aplicación está disponible para más de 0 dispositivos?
  • Cómo tratar las clases obsoletas en Android para mantener la compatibilidad
  • ¿Cada dispositivo Android contiene todas las versiones anteriores de SDK?
  • No se puede agregar el paquete de compatibilidad al proyecto android
  • Aplicación de Android compatible con 0 dispositivos
  • Android: Tono con DrawableCompat
  • Inhabilitar aceleración de hardware, compatibilidad con versiones anteriores
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.