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.
- Navbar que superpone el último elemento ListView (Android)
- ¿Cómo actualizar el emulador de Android sin Android Studio?
- No se puede ejecutar android / sdk / build-tools / 23.0.2 / aapt
- ¿Cómo puedo incluir la biblioteca de soporte de Android GridLayout en mi proyecto de Android?
- Eclipse no genera MainActivity.java & activity_main.xml
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="<init>()V" /> </class> <class name="package/path/ClassB" since="14"> <extends name="java/lang/Object" /> <method name="<init>()V" /> </class> <class name="package/path/ClassC" since="18"> <extends name="java/lang/Object" /> <method name="<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.
- Cordova emula no se ejecuta en Genymotion después de actualización de SDK
- ¿Cuál es la diferencia entre algunos "Android Development / SDK tools"?
- Error Phonegap android sdk build.xml: 950: nulo devuelto: 1
- Android Studio está atascado en la descarga de componentes
- Reaccionar Nativo: objetivo con cadena de hash 'android-X' no encontrado
- Error con Eclipse y API de Android Nivel 22
- Android DDMS No se pueden iniciar estadísticas de red con el emulador
- Error al encontrar el destino con la cadena de hash 'android-25', aunque android-25 está realmente instalado
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.