Это все в значительной степени в названии. Хотя я вижу <uses-sdk>, указанный во всем примере библиотеки библиотеки AndroidManifest.xml, который я видел, у меня такое чувство, что оно не имеет значения.
На самом деле, я подозреваю, что <uses-permission> также не имеет значения, как и все атрибуты <manifest>, кроме package.
Кто-нибудь может подтвердить?
Библиотечные манифесты могут быть объединены с основным манифестом приложения. Это включено в сборке ant, указав свойство
manifestmerger.enabled=true
[Я не уверен, как включить его в других (например, maven) сборках; пожалуйста, прокомментируйте здесь, если вы это выясните. Я предполагаю, что это переводит в аргумент командной строки aapt.]
Различные правила управляют конфликтами и преобладающим поведением.
Относительно конкретных вопросов, поднятых здесь (слияние < uses-sdk > и < uses-permission > ), правилами для < uses-sdk > являются:
Правило для < uses-permission > : добавляет разрешения библиотеки к месту назначения, если они еще не присутствуют там. Это нормально, если одно и то же разрешение в обоих.
Я создал небольшой тестовый библиотечный проект и тестовое приложение, которое его использует, чтобы самому разобраться. Я предоставил < uses-sdk > и < uses-permission > в манифесте проекта библиотеки и пропустил оба из манифеста приложения.
Результат заключался в том, что значения проекта библиотеки < uses-sdk > и < uses-permission > НЕ были объединены в приложение во время сборки, о чем свидетельствует проверка установленного приложения на моем устройстве с помощью AppXplore.
Мой тестовый код доступен в https://github.com/adennie/android-library-project-manifest-test.
Мое заключение заключается в том, что указание < uses-sdk > и < uses-permission > в манифесте проекта библиотеки Android не влияет на объединенный манифест приложения-потребителя.
возможное использование манифеста в библиотечных проектах:
Вы пробовали линт? он может предупредить вас, если ваш проект использует слишком новые классы/методы, которые не могут работать на min-sdk, который вы установили в манифесте. Хотите проверить это? просто нажмите кнопку V-checkbox рядом с менеджером sdk, как показано ниже: http://tools.android.com/tips/lint/lint-toolbar.png?attredirects=0
манифест может дать понять другим людям, что требуется для использования проекта.
вы также можете добавить некоторые тестовые действия, внутри которых можно было бы быстро переключить проект из проекта библиотеки в обычный проект и провести некоторое тестирование на нем.
как предположил Google в прошлом, проекты библиотеки могут использовать некоторое использование манифеста в будущем, объединившись со всеми из тех, которые используют проект библиотеки.
Короче говоря, манифест не лишен смысла. это может помочь вам.
Если ваш проект библиотеки не зависит от конкретной версии Android, вы можете опустить этот тег.
Потому что uses-sdk будет определять версию sdk и т.д.
Как документация, она говорит для <uses-sdk>
Обязательно требуется атрибут android:minSdkVersion, и если вы его не пройдете, он примет значение 1 - приложение будет поддерживать все api-версии android, а затем вам нужно будет приложить все свои приложения, если вы не пройдете статически.
Внимание: если вы не объявляете этот атрибут, система предполагает значение по умолчанию "1", что указывает на то, что ваше приложение совместимый со всеми версиями Android. Если ваше приложение не совместимый со всеми версиями (например, он использует API, введенные в API Level 3), и вы не указали правильную minSdkVersion, затем при установке в системе с уровнем API менее 3, приложение будет сбой во время выполнения при попытке получить доступ к недоступные API. По этой причине обязательно объявите соответствующий уровень API в атрибуте minSdkVersion.
Атрибут android:maxSdkVersion немного сложнее понять. doc говорит,
Предупреждение. Объявление этого атрибута не рекомендуется. Во-первых, существует нет необходимости устанавливать атрибут как средство блокировки развертывания вашего приложения на новые версии платформы Android, поскольку они выпущенный. По дизайну новые версии платформы полностью обратная совместимость. Ваше приложение должно работать правильно на новом версий, если он использует только стандартные API и следует за разработкой лучшие практики. Во-вторых, обратите внимание, что в некоторых случаях, объявляя атрибут может привести к удалению вашего приложения из-за того, устройств после обновления системы до более высокого уровня API. Большинство устройств на которые ваше приложение, вероятно, будет установлено, будут получать периодические обновления системы по воздуху, поэтому вы должны учитывать их влияние на ваше приложение перед установкой этого атрибута.
и
Будущие версии Android (помимо Android 2.0.1) больше не будут проверять или применять атрибут maxSdkVersion во время установки или повторно проверка. Google Play будет продолжать использовать этот атрибут как фильтр, однако, при представлении пользователям приложений, доступных для скачать.
Это предупреждение указывает на Отрицательные точки, которые могут произойти, если вы объявляете эти атрибуты. Но когда вы смотрите на другую сторону Если вы разрабатываете что-либо, поддерживающее определенную версию Android, тогда ATTRIBUTE наиболее полезно для вас.
Шаг, предпринятый для удаления этого атрибута, должен побудить разработчика сделать свое приложение доступным для любой другой (более новой) версии.
Только если вы разрабатываете версию 2.0.1 ^, вы можете сказать, что ее не нужно писать, но если вы пишете, что Google paly будет использовать это как фильтр для представления пользователя
Итак Мой вывод и советы
используйте элемент <uses-sdk> с наименьшим атрибутом android:minSdkVersion
