41

I've read similar questions here, but am still not clear on a couple of things. Using a Library Project means that my overall project will have two manifests -- one for the library and the other for the "main" app project -- and I'm not clear what goes in which or if there is some redundancy.

I'm developing an app widget with "lite" and "paid" versions, so will have almost all code in a library project. Being a widget, the library will have at least a receiver, a service, a configuration activity, plus a couple of other activities. So where should the full declarations of these components -- including intents, filters, etc. -- be declared? Do they go in the manifest for the library, or in the manifest for the application package itself, referencing the classes in the library (e.g. android:name="com.foo.mylibrary.MyService")?

Some examples I've looked at seem to declare them in both manifests, but I suspect that putting these in one or the other is a no-op.

erdemlal
  • 491
  • 5
  • 21
gordonwd
  • 4,537
  • 9
  • 37
  • 53

3 Answers3

44

Using a Library Project means that my overall project will have two manifests -- one for the library and the other for the "main" app project -- and I'm not clear what goes in which or if there is some redundancy.

The library project manifest is not presently used.

Gradle for Android, and therefore Android Studio, support library projects and AARs publishing a manifest. This can include things like activity declarations, required permissions or features, or minimum supported Android SDK levels.

The rules for how library manifests are merged with the app's own manifest -- particularly when you take build types and product flavors into account -- is a bit complex.

So where should the full declarations of these components -- including intents, filters, etc. -- be declared?

In the host project.

The library could publish those components, and the Android Studio host project can then remove them if needed.

Do they go in the manifest for the library, or in the manifest for the application package itself, referencing the classes in the library (e.g. android:name="com.foo.mylibrary.MyService")?

The latter.

In either (with Gradle for Android and Android Studio). In theory, it is easier for the library to publish the components, so the app author does not have to. Personally, I am not a huge fan of this, as too many developers will wind up shipping unnecessary manifest entries.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks. This does make the most sense (not that making sense always applies!). – gordonwd Apr 17 '12 at 20:04
  • 2
    @CommonsWare - I always love your direct answers. And in this case it helped me! – Matt Mar 13 '13 at 12:23
  • 4
    @CommonsWare as of ADT r20 preview 3 it is now possible to merge manifests. So common configuration can now be put into the library manifest. http://stackoverflow.com/a/10400355/262789 – Jade Nov 06 '13 at 16:37
9

As of ADT r20 Preview 3 it is now possible to merge manifests. So common configuration can now be put into the library manifest. See https://stackoverflow.com/a/10400355/262789 for more information.

Version 13 of Intellij IDEA is necessary for manifest merging support (manifestmerger.enabled=true). Also the Grade based build system appears to be necessary for Android Studio support.

Community
  • 1
  • 1
Jade
  • 3,156
  • 1
  • 34
  • 44
5

Any referenced android elements like activities, receivers, services, etc. MUST go into your Application manifest or they won't be recognized by the OS. As you guessed, the Library manifest file is pretty much an empty implementation

UPDATE

As CommonsWare points out above, the Android build tools will now attempt to merge the various manifests on your behalf. Leaving up the original answer for posterity

JRaymond
  • 11,625
  • 5
  • 37
  • 40
  • Thanks. To read some articles, it sounded like the manifests would be merged or something like that. Nice to get it clarified. – gordonwd Apr 17 '12 at 20:06
  • Since this answer is four years old it's perhaps good to point out that it is now incorrect. See Commonsware's updated answer above. – JHH Oct 26 '16 at 07:41