Anotación de nivel de API de Android para bibliotecas de Android

Estoy escribiendo una librería de Android. La gran mayoría de la interfaz de la lbirary admite la API de Android nivel 10 o superior. Sin embargo, algunas funcionalidades requieren un nivel de API más alto. Por ejemplo, parte de la biblioteca requiere API 18 para Bluetooth Low Energy.

En aras de la concreción, digamos que la biblioteca produce tres clases ClassA , ClassB y ClassC . ClassA utiliza la funcionalidad disponible en API 10, ClassB utiliza la funcionalidad disponible en API 14 y ClassC utiliza la funcionalidad disponible en API 18.

Quiero ser capaz de activar un problema de pelusa (advertencia / error) cada vez que alguien usa una clase de mi biblioteca sin tener el nivel de API requerido en su proyecto (a menos que supriman la advertencia con la anotación apropiada), similar a la ya construida- En NewApi tema utilizado por pelusa.

Después de buscar, he encontrado las siguientes posibles soluciones:

1) Esta solución no es en líneas de pelusa: Dividir la biblioteca en tres archivos .jar, digamos lib_10.jar que incluye todas las clases usando la funcionalidad disponible en API 10 (ClassA en el ejemplo), lib_14.jar que incluye todas las Usando la funcionalidad disponible en API 14 (ClassB en el ejemplo) y lib_18.jar que incluye todas las clases usando la funcionalidad disponible en API 18 (ClassC en el ejemplo). Esta solución permite la portabilidad, pero complicaría la capacidad de mantenimiento posterior de la base de código y potencialmente requeriría también la duplicación de código.

2) Cree mi propia anotación (por ejemplo, @RequireAndroidApi(API_LEVEL) indica el nivel mínimo de API requerido por la clase anotada / method / etc …) y use el lint-api.jar ( http://tools.android.com/tips/lint-custom-rules ) para crear una regla de pelusa personalizada que compruebe el uso de cualquier clase anotada / métodos / etc … con una API menor que la requerida. Algo que más tarde se vería así:

 @RequireAndroidApi(10) Class ClassA { } @RequireAndroidApi(14) Class ClassB { } @RequireAndroidApi(18) Class ClassC { } 

El problema es que no pude encontrar una buena documentación para la API de pelusa y parece que esto es reinventar la rueda para una funcionalidad que ya es compatible con pelusa (la pelusa ya comprueba el problema "NewApi").

3) Finalmente, logré editar <SDK>/platform-tools/api/api-versions.xml para indicar el nivel de API requerido por cada clase de la siguiente manera:

 <api version="1"> ... <class name="package/path/ClassA" since="10"> <extends name="java/lang/Object" /> <method name="&lt;init>()V" /> </class> <class name="package/path/ClassB" since="14"> <extends name="java/lang/Object" /> <method name="&lt;init>()V" /> </class> <class name="package/path/ClassC" since="18"> <extends name="java/lang/Object" /> <method name="&lt;init>()V" /> </class> </api> 

Lo que hizo que pelusa activara el problema de NewApi de la misma manera que lo haría con las API de Android. Me gusta este tipo de solución porque no reinventa la rueda y además cualquier error lanzado de esta manera utilizaría las soluciones sugeridas programadas en Eclipse o Android Studio para manejar el problema (es decir, "arreglos rápidos" en Eclipse). El problema con esta solución es que requiere la edición de api-versions.xml que viene con el SDK de Android, lo que hace que esta solución no sea muy portátil para liberar la biblioteca por varias razones, incluyendo: a) el archivo api-versions.xml no es local A un proyecto y cambia el comportamiento de la pelusa para todos los proyectos de androide, incluyendo los que no utilizan la biblioteca; Y b) api-versions.xml se sobrescribirá cada vez que se actualice el SDK desde el gestor SDK de Android, que sobrescribiría cualquier cambio realizado.

Me preguntaba si hay una solución más simple para lograr este "mínimo API errores / advertencias" o si hay una manera de escribir un archivo separado similar a api-versions.xml que se puede colocar en el directorio del proyecto que puede ser leído por Lint siempre que el pelusa se ejecuta en el proyecto en cuestión (algo similar a lint.xml ).

Gracias por llevar conmigo durante esta larga descripción del problema y agradezco cualquier ayuda por adelantado.

No es necesario crear tu propia anotación, la anotación @RequiresApi la biblioteca de soporte de @RequiresApi es lo que estás buscando. Por ejemplo:

 @RequiresApi(Build.VERSION_CODES.LOLLIPOP) public void someMethod() {} 

Esta anotación le dice a lint que advierta si someMethod() se usa en un contexto que puede tener un nivel API más bajo.

Tenga en cuenta que @TargetApi es diferente: Se utiliza para asegurar que el método anotado sólo se llamará con la API de destino, en una situación en la que de lo contrario le advirtió de no utilizar ese método. Así que @TargetApi se puede usar para silenciar la advertencia de pelusa activada por @RequiresApi .

Hace poco he hecho esto en una clase de vista personalizada, que necesitaba un constructor especial para algunos niveles de api.

Lo he hecho con la anotación @TargetApi .

Si un método está disponible sólo desde api nivel 16:

 @TargetApi(16) public void someMethod () {} 

Esto debería hacer el truco, incluyendo errores de pelusa.

  • He actualizado Android de targetSdk 22 a 23 y estoy recibiendo un NoSuchMethodError. ¿Cómo podría solucionar esto?
  • Actualización de SDK OTA
  • Luchando con "Estilos que faltan. ¿Es el tema correcto elegido para este diseño? "
  • Instale el paquete: 'Android Support Library'
  • No se puede iniciar un nuevo proyecto con Android Studio
  • SDK Manager no tiene imágenes de sistema Android más antiguas para el emulador
  • Emulador de Android se estrella en Mac
  • Android Hello-World compilación error: Intellij no puede encontrar aapt
  • Consejos para cambiar de App Inventor a Eclipse
  • ¿Cómo instalar Android Lolipop en eclipse?
  • Proguard falla con la versión 25.1.6 de las herramientas de Android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.