permisos - Para los proyectos de la biblioteca de Android, ¿es<uses-sdk> significativo en manifiesto?

uses permission android internet (4)

Todo está más o menos en el título. Aunque veo <uses-sdk> especificado en todo el proyecto de biblioteca de ejemplo AndroidManifest.xml que he visto, tengo la sensación de que es irrelevante.

De hecho, sospecho que <uses-permission> también es irrelevante, como lo son todos los atributos de <manifest> , además del package .

¿Alguien puede confirmar?

A partir de ADT r20 vista previa 3

Los manifiestos de biblioteca se pueden combinar con el manifiesto de aplicación principal. Esto se habilita en una compilación de hormigas especificando la propiedad

manifestmerger.enabled=true

[No estoy seguro de cómo habilitarlo en otras compilaciones (por ejemplo, maven); Por favor comenta aquí si lo averiguas. Supongo que se traduce en un argumento de línea de comando aapt.]

Una variedad de reglas gobiernan los conflictos y el comportamiento dominante.

En relación con las preguntas específicas planteadas aquí (la fusión de <uses-sdk> y <uses-permission>), las reglas para <uses-sdk> son:

minSdkVersion: error si el manifiesto de destino contiene un valor menor que el valor de lib; deje el valor de destino que sea igual o mayor que el valor de lib, almacene el valor de lib en el destino solo si no se especificó allí (el valor predeterminado es 1 si no se especifica en ninguno).
targetSdkVersion: advertencia si el manifiesto de destino contiene un valor menor que el valor de lib; deje el valor de destino que es igual o mayor que el valor de lib, almacene el valor de lib en el destino solo si no se especificó allí (de manera predeterminada, el valor minSdkVersion fusionado, si no se especifica en ninguno de los dos).

La regla para <uses-permission> es: agregar permisos de biblioteca a destino si aún no están presentes allí. Está bien si el mismo permiso está en ambos.

Si está utilizando ADT r20 preview 2 o anterior, se aplica lo siguiente:

Creé un pequeño proyecto de biblioteca de prueba y una aplicación de prueba que lo usa, para llegar al fondo de esto. Proporcioné un <uses-sdk> y un <uses-permission> en el manifiesto del proyecto de la biblioteca, y los omití en el manifiesto de la aplicación.

El resultado fue que los valores <uses-sdk> y <uses-permission> del proyecto de la biblioteca NO se fusionaron con la aplicación en el momento de la compilación, como lo demuestra el examen de la aplicación instalada en mi dispositivo con la herramienta AppXplore .

Mi código de prueba está disponible en https://github.com/adennie/android-library-project-manifest-test .

Mi conclusión es que la especificación de <uses-sdk> y <uses-permission> en el manifiesto de un Proyecto de Biblioteca de Android no tiene ningún efecto en el manifiesto combinado de la aplicación consumidora.

Posibles usos del manifiesto en proyectos bibliotecarios:

¿Has probado la pelusa? puede advertirle si su proyecto está utilizando clases / métodos demasiado nuevos que no pueden funcionar en el min-sdk que ha establecido en el manifiesto. ¿Quieres comprobarlo? simplemente presione el botón V-checkbox cerca del administrador de SDK, como se muestra aquí: http://tools.android.com/tips/lint/lint-toolbar.png?attredirects=0
El manifiesto podría dar una pista a otras personas de lo que se requiere para el proyecto que se utilizará.
También puede agregar algunas actividades de prueba en el interior que podrían permitirle alternar rápidamente el proyecto de proyecto de biblioteca a proyecto normal y realizar algunas pruebas en él.
Como Google sugirió en el pasado, los proyectos de la biblioteca podrían tener algún uso del manifiesto en el futuro al fusionarse con todos aquellos que usan el proyecto de la biblioteca.

En resumen, lo manifiesto no tiene sentido. Te puede ayudar mucho.

Según la documentación , dice para <uses-sdk>

El atributo android:minSdkVersion seguramente se requiere y si no pasa ninguno, tomará 1 significado. La aplicación admitirá todas las versiones de Android de api y luego tendrá que hacer que su aplicación sea compatible con todas ellas si no pasa ninguna estática. .

Precaución: si no declara este atributo, el sistema asume un valor predeterminado de "1", lo que indica que su aplicación es compatible con todas las versiones de Android. Si su aplicación no es compatible con todas las versiones (por ejemplo, utiliza las API introducidas en el nivel 3 de API) y no ha declarado la minSdkVersion adecuada, entonces, cuando se instala en un sistema con un nivel de API inferior a 3, la aplicación se bloqueará durante en tiempo de ejecución al intentar acceder a las API no disponibles. Por este motivo, asegúrese de declarar el nivel de API adecuado en el atributo minSdkVersion.

El atributo android:maxSdkVersion es un poco difícil de entender ... dice android:maxSdkVersion ,

Advertencia: no se recomienda declarar este atributo. En primer lugar, no es necesario establecer el atributo como medio para bloquear la implementación de su aplicación en las nuevas versiones de la plataforma Android a medida que se lanzan. Por diseño, las nuevas versiones de la plataforma son totalmente compatibles con versiones anteriores. Su aplicación debería funcionar correctamente en las nuevas versiones, siempre que use solo API estándar y siga las mejores prácticas de desarrollo. En segundo lugar, tenga en cuenta que, en algunos casos, la declaración del atributo puede hacer que su aplicación sea eliminada de los dispositivos de los usuarios después de una actualización del sistema a un nivel de API más alto. La mayoría de los dispositivos en los que es probable que se instale su aplicación recibirán actualizaciones periódicas del sistema por el aire, por lo que debe considerar su efecto en su aplicación antes de establecer este atributo.

Las versiones futuras de Android (más allá de Android 2.0.1) ya no verifican ni imponen el atributo maxSdkVersion durante la instalación o la re-validación. Sin embargo, Google Play continuará utilizando el atributo como filtro al presentar a los usuarios aplicaciones disponibles para descargar.

Esa advertencia es para indicar los puntos negativos que pueden suceder si declara esos atributos. Pero al mirar hacia el otro lado, si está desarrollando algo que sea compatible con alguna versión específica de Android, entonces ATTRIBUTE es lo más útil para usted.

El paso dado para eliminar ese atributo es animar al desarrollador a hacer que su aplicación sea compatible con todas las versiones diferentes (más nuevas).

Solo si está desarrollando con la versión 2.0.1 ^, entonces puede decir que no es necesario escribir eso, pero si lo escribe, Google Paly lo usará como filtro para presentar al usuario.

Así que mi conclusión y consejo

use el elemento <uses-sdk> con al menos un atributo android:minSdkVersion

Si el proyecto de su biblioteca no depende de la versión específica de Android, puede omitir esta etiqueta.

Porque usa-sdk definirá la versión sdk, etc.