Manifeste de la bibliothèque Android vs manifeste de l’application

J’ai lu des questions similaires ici, mais je ne suis toujours pas sûr de certaines choses. Utiliser un projet de bibliothèque signifie que mon projet global aura deux manifestes – l’un pour la bibliothèque et l’autre pour le projet d’application «principal» – et je ne sais pas exactement ce qui se passe ou s’il ya une redondance.

Je développe un widget d’application avec des versions “lite” et “payantes”, donc presque tout le code dans un projet de bibliothèque. En tant que widget, la bibliothèque aura au moins un récepteur, un service, une activité de configuration et quelques autres activités. Alors, où les déclarations complètes de ces composants – y compris les intentions, les filtres, etc. – doivent-elles être déclarées? Est-ce qu’ils vont dans le manifeste pour la bibliothèque, ou dans le manifeste pour le package d’application lui-même, référençant les classes de la bibliothèque (par exemple, android: name = “com.foo.mylibrary.MyService”)?

Certains exemples que j’ai examinés semblent les déclarer dans les deux manifestes, mais je soupçonne que les mettre dans l’un ou l’autre est un non-op.

Utiliser un projet de bibliothèque signifie que mon projet global aura deux manifestes – l’un pour la bibliothèque et l’autre pour le projet d’application «principal» – et je ne sais pas exactement ce qui se passe ou s’il ya une redondance.

~~Le manifeste du projet de bibliothèque n’est pas utilisé actuellement.~~

Gradle pour Android, et par conséquent Android Studio, prennent en charge les projets de bibliothèque et les AAR publiant un manifeste. Cela peut inclure des éléments tels que les déclarations d’activité, les permissions ou fonctionnalités requirejses ou les niveaux de SDK Android pris en charge minimum.

Les règles relatives à la façon dont les manifestes de bibliothèque sont fusionnés avec le manifeste de l’application – en particulier lorsque vous prenez en compte les types de construction et les variantes de produit – sont un peu complexes .

Alors, où les déclarations complètes de ces composants – y compris les intentions, les filtres, etc. – doivent-elles être déclarées?

~~Dans le projet hôte.~~

La bibliothèque peut publier ces composants et le projet hôte Android Studio peut ensuite les supprimer si nécessaire.

Est-ce qu’ils vont dans le manifeste pour la bibliothèque, ou dans le manifeste pour le package d’application lui-même, référençant les classes de la bibliothèque (par exemple, android: name = “com.foo.mylibrary.MyService”)?

~~Le dernier.~~

Dans l’un ou l’autre (avec Gradle pour Android et Android Studio). En théorie, il est plus facile pour la bibliothèque de publier les composants, de sorte que l’auteur de l’application n’est pas obligé. Personnellement, je ne suis pas un grand fan de cela, car trop de développeurs finiront par expédier des entrées de manifeste inutiles.

Depuis ADT r20 Preview 3, il est maintenant possible de fusionner des manifestes. Donc, la configuration commune peut maintenant être placée dans le manifeste de la bibliothèque. Voir https://stackoverflow.com/a/10400355/262789 pour plus d’informations.

La version 13 d’Intellij IDEA est nécessaire pour la prise en charge de la fusion de manifestmerger.enabled=true ( manifestmerger.enabled=true ). De plus, le système de génération basé sur Grade semble être nécessaire pour le support Android Studio.

Tous les éléments Android référencés tels que les activités, les récepteurs, les services, etc. DOIVENT figurer dans le manifeste de votre application ou ne seront pas reconnus par le système d’exploitation. Comme vous l’avez deviné, le fichier manifeste de la bibliothèque est quasiment une implémentation vide

METTRE À JOUR

Comme le souligne CommonsWare ci-dessus, les outils de compilation Android vont maintenant tenter de fusionner les divers manifestes en votre nom. Laisser la réponse originale pour la postérité