23

It's all pretty much in the title. Although I see <uses-sdk> specified in all the example library project's AndroidManifest.xml I've seen, I have a feeling it's irrelevant.

In fact, I suspect that <uses-permission> is also irrelevant, as are all of the attributes of <manifest>, other than package.

Can anyone confirm?

Macarse
  • 91,829
  • 44
  • 175
  • 230
Andy Dennie
  • 6,012
  • 2
  • 32
  • 51
  • And while I'm at it, contrary to what http://developer.android.com/guide/topics/manifest/manifest-element.html says, it is not true that manifest.xml "MUST CONTAIN" an element -- library project manifests don't need this if the library project doesn't contain an application. – Andy Dennie Feb 29 '12 at 17:35

4 Answers4

22

As of ADT r20 preview 3

Library manifests can be merged with the main application manifest. This is enabled in an ant build by specifying the property 

manifestmerger.enabled=true

[I'm not sure how to enable it in other (e.g. maven) builds; please comment here if you figure it out. I'm guessing it translates into an aapt command line argument.]

A variety of rules govern conflicts and overriding behavior.

Relative to the specific questions raised here (merging of <uses-sdk> and <uses-permission>), the rules for <uses-sdk> are:

  • minSdkVersion: error if destination manifest contains a value less than the lib value; leave destination value it is same or greater than lib value, store lib value in destination only if none was specified there (defaulting to 1 if not specified in either).
  • targetSdkVersion: warning if destination manifest contains a value less than the lib value; leave destination value it is same or greater than lib value, store lib value in destination only if none was specified there (defaulting to merged minSdkVersion value if not specified in either).

The rule for <uses-permission> is: add library permissions to destination if they are not already present there. It's OK if the same permission is in both.

If you are using ADT r20 preview 2 or earlier, the following applies:

I created a little test library project and a test app that uses it, in order to get to the bottom of this myself. I provided a <uses-sdk> and a <uses-permission> in the library project's manifest, and omitted both of them from the application's manifest.

The result was that the library project's <uses-sdk> and <uses-permission> values were NOT merged into the application at build time, as evidenced by examining the installed app on my device using the AppXplore tool.

My test code is available at https://github.com/adennie/android-library-project-manifest-test.

My conclusion is that specifying <uses-sdk> and <uses-permission> in an Android Library Project's manifest has no effect on the merged manifest of the consuming application.

Andy Dennie
  • 6,012
  • 2
  • 32
  • 51
  • I've tested both your sample project and my own one. I would agree with you, in library project is a verbose declaration. – yorkw May 02 '12 at 00:05
  • 3
    Correct, it does nothing. Android platform developer Xav Ducrochet states this in this news group post: https://groups.google.com/group/android-developers/msg/9db36f18521fca7d – nmr May 05 '12 at 00:28
  • In fairness, the answer from "android developer" does describe some use cases where you might still want specify values for these attributes. – Andy Dennie May 11 '12 at 16:42
  • Using the default built provided by android-eclipse I guess that is enabled by default (in at least r21) because I keep getting `Unable to execute dex: Multiple dex files define Lcom/mypackage/name/Manifest$permission;` for a permission (`com.mypackage.name.permission.PERMISSION_NAME`) inserted both on library and on project code. Please correct me if the error is irrelevant. – madlymad Mar 11 '13 at 13:17
  • @AndyDennie When i'm using this line in my application (that using a library), whole project get errors! What's wrong?! – Dr.jacky Jun 02 '15 at 13:42
1

possible uses of the manifest in library projects:

  1. have you tried lint? it can warn you if your project is using too-new classes/methods which cannot work on the min-sdk that you've set on the manifest. wanna check it out? just press the V-checkbox button near the sdk manager , as shown here: http://tools.android.com/tips/lint/lint-toolbar.png?attredirects=0

  2. the manifest could give a clue for other people of what is required for the project to be used.

  3. you can also add some test activities inside which could allow you to quickly toggle the project from library project to normal project , and do some testing on it.

  4. as google has suggested in the past , library projects might have some use of the manifest in the future by being merged with all of those that use the library project.

in short , the manifest is not meaningless . it can help you a lot .

android developer
  • 114,585
  • 152
  • 739
  • 1,270
  • I never said that the manifest was meaningless for a library project. I said that specifying and in a library project's manifest is meaningless. – Andy Dennie May 04 '12 at 13:27
  • well i just proved now that both of them are not meaningless . – android developer May 05 '12 at 12:30
  • Fair enough, the word "meaningless" was overkill. I've referenced your answer from mine. – Andy Dennie May 11 '12 at 16:43
  • yes, do note that google considers making the manifests of the library projects to have some kind of merging behavior with the project/s that use the . for now , they usually have a very small purpose , if at all . – android developer May 12 '12 at 12:42
  • the new adt (20 preview 3) now supports merging of manifest files for the libraries . more info here: http://tools.android.com/download/adt-20-preview – android developer Jun 04 '12 at 22:57
  • yes, I noticed that too. Looks interesting. I updated my answer with some details, as best as I could determine at this point. – Andy Dennie Jun 05 '12 at 13:28
0

If your library project doesn't depend on Specific android version then you can omit this tag.

Because uses-sdk will define the sdk version etc..

Maneesh
  • 6,098
  • 5
  • 36
  • 55
  • But isn't the information from the containing application project's manifest what really matters? – Andy Dennie Feb 29 '12 at 17:38
  • yes it is the containing project which will define uses-sdk for its own project not for library but also there is only one menifest file for one project. Don't know much about library projects. – Maneesh Feb 29 '12 at 17:44
-1

As per the documentation, It says for <uses-sdk>

The attribute android:minSdkVersion is surely required and if you don't pass any then it will take 1 meaning - App will support all api versions of android and then you will have to make your app support all of them if you dont pass any statically.

Caution: If you do not declare this attribute, the system assumes a default value of "1", which indicates that your application is compatible with all versions of Android. If your application is not compatible with all versions (for instance, it uses APIs introduced in API Level 3) and you have not declared the proper minSdkVersion, then when installed on a system with an API Level less than 3, the application will crash during runtime when attempting to access the unavailable APIs. For this reason, be certain to declare the appropriate API Level in the minSdkVersion attribute.

The attribute android:maxSdkVersion is little bit tricky to understand..doc says,

Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.

And,

Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.

That warning is to indicate Negative points that can happen if you declare that attributes But as you look into other side If you are developing anything that supports some specific Android Version then The ATTRIBUTE is most useful to you.

The step taken to remove that attribute is to encourage developer to make their app supportive to all different(newer) version.

Only if you developing with the version 2.0.1^ then you can say Its not needed to write that but If you write that Google paly will use that as filter for presenting user

So My Conclusion and Advice

use the element <uses-sdk> with atleast one attribute android:minSdkVersion

MKJParekh
  • 34,073
  • 11
  • 87
  • 98
  • 3
    Thanks for your answer, however it doesn't seem to address the main point of the question, which is with regard to the significance of in the context of a library project's manifest. – Andy Dennie May 01 '12 at 15:59