Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion
Depending on the time of the year, it might only be a few months after you release an app that a new version of Android is announced. What does that mean for your app though — is everything going to break?
You’ll be happy to know that forward compatibility is a strong focus of Android — existing apps built against prior SDKs should not break when the user updates to a new version of Android. This is where compileSdkVersion, minSdkVersion, and targetSdkVersion come in: they control what APIs are available, what the required API level is, and what compatiblity modes are applied, respectively.
compileSdkVersion
compileSdkVersion is your way to tell Gradle what version of the Android SDK to compile your app with. Using the new Android SDK is a requirement to use any of the new APIs added in that level.
It should be emphasized that changing your compileSdkVersion does not change runtime behavior. While new compiler warnings/errors may be present when changing your compileSdkVersion, your compileSdkVersion is not included in your APK: it is purely used at compile time. (You should really fix those warnings though — they were added for a reason!)
Therefore it is strongly recommended that you always compile with the latest SDK. You’ll get all the benefits of new compilation checks on existing code, avoid newly deprecated APIs, and be ready to use new APIs.
Note that if you use the Support Library, compiling with the latest SDK is a requirement for using the latest Support Library releases. For example, to use the 23.1.1 Support Library, you must have a compileSdkVersion of at least 23 (those first numbers need to match!). In general, a new version of the Support Library is released alongside a new platform version, providing compatibility shims to newly added APIs as well as new features.
minSdkVersion
If compileSdkVersion sets the newest APIs available to you, minSdkVersion is the lower bound for your app. The minSdkVersion is one of the signals the Google Play Store uses to determine which of a user’s devices an app can be installed on.
It also plays an important role during development: by default lint runs against your project, warning you when you use any APIs above your minSdkVersion, helping you avoid the runtime issue of attempting to call an API that doesn’t exist. Checking the system version at runtime is a common technique when using APIs only on newer platform versions.
Keep in mind that libraries you use, such as any of the Support Libraries or Google Play services, may have their own minSdkVersion — your app’s minSdkVersion must be at least as high as your dependencies’ minSdkVersion — if you have libraries that require 4, 7, and 9, your minSdkVersion must be at least 9. In rare cases where you want to continue to use a library with a higher minSdkVersion than your app (and deal with all edge cases/ensure the library is only used on newer platform versions), you can use the tools:overrideLibrary marker, but make sure to test thoroughly!
When deciding on a minSdkVersion, you should consider the stats on the Dashboards, which give you a global look on all devices that visited the Google Play Store in the prior 7 days — that’s your potential audience when putting an app on Google Play. It is ultimately a business decision on whether supporting an additional 3% of devices is worth the development and testing time required to ensure the best experience.
Of course, if a new API is key to your entire app, then that makes the minSdkVersion discussion quite a bit easier. Just remember that even 0.7% of 1.4 billion devices is a lot of devices.
targetSdkVersion
The most interesting of the three, however, is targetSdkVersion. targetSdkVersion is the main way Android provides forward compatibility by not applying behavior changes unless the targetSdkVersion is updated. This allows you to use new APIs (as you did update your compileSdkVersion right?) prior to working through the behavior changes.
Much of the behavior changes that targetSdkVersion implies are documented directly in the VERSION_CODES, but all of the gory details are also listed on the each releases’ platform highlights, nicely linked in the API Levels table.
For example, the Android 6.0 changes talk through how targeting API 23 transitions your app to the runtime permissions model and the Android 4.4 behavior changes detail how targeting API 19 or higher changes how alarms set with set() and setRepeating() work.
With some of the behavior changes being very visible to users (the deprecation of the menu button, runtime permissions, etc), updating to target the latest SDK should be a high priority for every app. That doesn’t mean you have to use every new feature introduced nor should you blindly update your targetSdkVersion without testing — please, please test before updating your targetSdkVersion! Your users will thank you.
Gradle and SDK versions
So setting the correct compileSdkVersion, minSdkVersion, and targetSdkVersion is important. As you might imagine in a world with Gradle and Android Studio, these values are integrated into the tools system through inclusion in your module’s build.gradle file (also available through the Project Structure option in Android Studio):
The compileSdkVersion, being a compile time thing (who would have guessed!), is one of the android settings alongside with your build tools version. The other two are slightly differently in that they are declared at the build variant level — the defaultConfig is the base for all build variants and where’d you put default values for these, but you could imagine a more complicated system where specific versions of your app have a different minSdkVersion for example.
minSdkVersion and targetSdkVersion also differ from compileSdkVersion in that they are included in your final APK — if you were to look at the generated AndroidManifest.xml, you’d see a tag such as:
You’ll find if you manually put this in your manifest, it’ll be ignored when you build with Gradle (although other build systems might certainly rely on it being there).
Putting it all together
If you made it through the bolded notes, you’ll notice a relationship between the three values:
This intuitively makes sense — if compileSdkVersion is your ‘maximum’ and minSdkVersion is your ‘minimum’ then your maximum must be at least as high as your minimum and the target must be somewhere in between.
Ideally, the relationship would look more like this in the steady state:
You’ll hit the biggest audience with a low minSdkVersion and look and act the best by targeting and compiling with the latest SDK — a great way to #BuildBetterApps.
Join the discussion on the Google+ post and follow the Android Development Patterns Collection for more!
Источник
В чем разница между «min sdk, target sdk и compile with»? В андроиде
В чем разница между «min sdk, target sdk и compile with» в android?
В чем разница между «минимальным sdk, целевым sdk и компиляцией с», которые появляются, когда я пытаюсь создать новый проект приложения для Android! как это ..
Minimun SDK: API 14 Target SDK: API 17 Скомпилируйте с помощью API 14
И мой выбор хороший? Или какие из них я должен выбрать? Извините, я попытался поставить фотографию, но я не могу ..
«Ожидание ваших ответов» plzzz = D!
Minimun SDK: API 14
Что ваше приложение будет работать только на мобильном телефоне с уровнем api 14, то есть (ICS 4.0) или выше. Ваше приложение не сможет работать в предыдущих версиях Android, таких как пряники и фрио.
Целевой SDK: API 17
Относится к версии андроида, для которого вы хотите построить, что является Jellybean на вашем деле. Рекомендуется максимально обновлять, насколько это возможно (api 20 Kitkat в настоящем контексте).
Скомпилировать с помощью API 14
Относится к версии andriod, которую вы тестируете. Уступка api 14 означает, что вы собираетесь протестировать свое приложение на ICS.
Вы также можете посмотреть это видео:
андроид: minSdkVersion
Целое число, обозначающее минимальный уровень API, необходимый для запуска приложения. Система Android не позволит пользователю установить приложение, если уровень API системы ниже, чем значение, указанное в этом атрибуте. Вы всегда должны объявлять этот атрибут.
андроид: targetSdkVersion
Целое число, обозначающее уровень API, на который нацелено приложение. Если значение не задано, значение по умолчанию равно значению minSdkVersion. Этот атрибут информирует систему о том, что вы протестировали ее с целевой версией, и система не должна включать поведение совместимости для поддержания передовой совместимости вашего приложения с целевой версией. Приложение все еще может работать в более старых версиях (вплоть до minSdkVersion).
Поскольку Android развивается с каждой новой версией, некоторые изменения поведения и даже появление могут измениться. Однако, если уровень API на платформе выше, чем версия, объявленная целевымSDKVersion вашего приложения, система может включить поведение совместимости, чтобы ваше приложение продолжало работать так, как вы ожидаете. Вы можете отключить такое поведение совместимости, указав targetSdkVersion в соответствии с уровнем API на платформе, на которой он запущен. Например, при установке этого значения на «11» или выше система может применять новую тему по умолчанию (Holo) к вашему приложению при работе на Android 3.0 или выше, а также отключает режим совместимости с экраном при работе на больших экранах (поскольку поддержка API Уровень 11 неявно поддерживает более крупные экраны).
Существует много способов совместимости, которые система может включить на основе значения, установленного для этого атрибута. Некоторые из этих типов поведения описываются соответствующими версиями платформы в ссылке Build.VERSION_CODES.
Чтобы поддерживать приложение вместе с каждой версией Android, вы должны увеличить значение этого атрибута в соответствии с последним уровнем API, а затем тщательно протестировать свое приложение на соответствующей версии платформы. Представлен в: API Level 4
андроид: maxSdkVersion
Целое число, обозначающее максимальный уровень API, на котором приложение предназначено для запуска. В Android 1.5, 1.6, 2.0 и 2.0.1 система проверяет значение этого атрибута при установке приложения и повторной проверки приложения после обновления системы. В любом случае, если атрибут maxSdkVersion приложения ниже уровня API, используемого самой системой, система не сможет установить приложение. В случае повторной проверки после обновления системы это эффективно удаляет ваше приложение с устройства.
Пожалуйста, перейдите по этой ссылке для получения более подробной информации
Попытка максимально упростить его, я могу объяснить три условия следующим образом:
Min Required SDK: показывает устройство с минимальной версией Android, которую вы хотите, чтобы ваше приложение поддерживало. Например, если вы выберете API 11: Honey Comb в раскрывающемся списке. Это покажет, что ваше приложение не будет поддерживать / не будет работать на любом устройстве Android, имеющем версию для Android ниже, чем Honey Comb.
Target SDK: это всегда должно быть как можно более высоким, так как оно указывает максимальную версию Android, с которой вы нацеливали или тестировали свое приложение. Итак, если вы сохраните свой minReqSDK >> 11 (honey comb) и targetSDK >> 21 (Lollipop), это покажет, что ваше приложение будет работать на всех версиях Android от сотовых до Lollipop без проблем совместимости, поскольку вы установили целевой SDK> > 21 версия Lollipop.
Compile With: Это не имеет никакого отношения к андроиду, поддерживающему любые устройства. Вы можете выбрать любую версию Android, которую вы установили, используя диспетчер SDK для компиляции и запуска приложения для целей разработки.
В вашем случае: min sdk version: 14 target sdk: 17 compile with: 14
Ваше устройство будет поддерживать все версии Android с уровнем 14 (сэндвич с мороженым) до уровня api 17 (Jelly Bean 4.2). И вы используете api level 14 (ICS) для компиляции и запуска приложения для разработки.
Надеюсь это поможет.
Короче говоря, вот цель объявления другого targetSDK из minSDK: это означает, что вы используете функции с SDK более высокого уровня, чем ваш минимум, но вы обеспечили обратную совместимость . Другими словами, представьте, что вы хотите использовать функцию, которая была только недавно введена, но это не критично для вашего приложения. Затем вы установили бы targetSDK в версию, где была введена эта новая функция, а минимальная – на что-то ниже, чтобы все могли использовать ваше приложение.
Например, скажем, вы пишете приложение, которое широко использует обнаружение жестов. Тем не менее, каждая команда, которая может быть распознана жестом, также может быть выполнена с помощью кнопки или из меню. В этом случае жесты являются «отличными», но не требуются. Поэтому вы должны установить целевой sdk в 7 («Eclair», когда была введена библиотека GestureDetection), а минимальная SDK до уровня 3 («Cupcake»), чтобы даже люди с действительно старыми телефонами могли использовать ваше приложение. Все, что вам нужно сделать, это убедиться, что ваше приложение проверило версию Android, на которой она работала, прежде чем пытаться использовать библиотеку жестов, чтобы не пытаться использовать ее, если она не существует. (По общему признанию, это датированный пример, поскольку вряд ли у кого по-прежнему есть телефон v1.5, но было время, когда поддержание совместимости с v1.5 было действительно важно.)
Чтобы привести еще один пример, вы можете использовать это, если хотите использовать функцию из Gingerbread или Honeycomb. Некоторые люди скоро получат обновления, но многие другие, особенно со старыми аппаратными средствами, могут остаться в комплекте с Eclair, пока не приобретут новое устройство. Это позволит вам использовать некоторые из новых интересных функций, но не исключая часть вашего возможного рынка.
В блоге разработчика Android есть действительно хорошая статья о том, как использовать эту функцию, и, в частности, как разработать код «проверить, существует ли функция перед его использованием», упомянутый выше.
Для OP: я написал это в основном в интересах любого, кто случайно наткнется на этот вопрос в будущем, поскольку я понимаю, что ваш вопрос был задан давно. Вот сообщение
Android: minSdkVersion Целое число, определяющее минимальный уровень API, необходимый для запуска приложения. Система Android не позволит пользователю установить приложение, если уровень API системы ниже, чем значение, указанное в этом атрибуте. Вы всегда должны объявлять этот атрибут. Внимание: если вы не объявляете этот атрибут, система принимает значение по умолчанию «1», что означает, что ваше приложение совместимо со всеми версиями Android. Если ваше приложение несовместимо со всеми версиями (например, оно использует API-интерфейсы, введенные в API-уровень 3), и вы не объявили надлежащую minSdkVersion, а затем, когда они установлены в системе с уровнем API менее 3, приложение будет аварийно завершено во время Во время попытки доступа к недоступным API. По этой причине обязательно объявите соответствующий уровень API в атрибуте minSdkVersion.
Android: targetSdkVersion Целое число, обозначающее уровень API, на который нацелено приложение. Если значение не задано, значение по умолчанию равно значению minSdkVersion. Этот атрибут информирует систему о том, что вы протестировали ее с целевой версией, и система не должна включать поведение совместимости для поддержания передовой совместимости вашего приложения с целевой версией. Приложение все еще может работать в более старых версиях (вплоть до minSdkVersion).
Поскольку Android развивается с каждой новой версией, некоторые изменения поведения и даже появление могут измениться. Однако, если уровень API на платформе выше, чем версия, объявленная целевымSDKVersion вашего приложения, система может включить поведение совместимости, чтобы ваше приложение продолжало работать так, как вы ожидаете. Вы можете отключить такое поведение совместимости, указав targetSdkVersion в соответствии с уровнем API на платформе, на которой он запущен. Например, при установке этого значения на «11» или выше система может применять новую тему по умолчанию (Holo) к вашему приложению при работе на Android 3.0 или выше, а также отключает режим совместимости с экраном при работе на больших экранах (поскольку поддержка API Уровень 11 неявно поддерживает более крупные экраны).
Существует много способов совместимости, которые система может включить на основе значения, установленного для этого атрибута. Некоторые из этих типов поведения описываются соответствующими версиями платформы в ссылке Build.VERSION_CODES.
Чтобы поддерживать приложение вместе с каждой версией Android, вы должны увеличить значение этого атрибута в соответствии с последним уровнем API, а затем тщательно протестировать свое приложение на соответствующей версии платформы.
Представлен в: API Level 4
Android: maxSdkVersion Целое число, определяющее максимальный уровень API, на котором приложение предназначено для запуска. В Android 1.5, 1.6, 2.0 и 2.0.1 система проверяет значение этого атрибута при установке приложения и повторной проверки приложения после обновления системы. В любом случае, если атрибут maxSdkVersion приложения ниже уровня API, используемого самой системой, система не сможет установить приложение. В случае повторной проверки после обновления системы это эффективно удаляет ваше приложение с устройства.
Чтобы проиллюстрировать, как этот атрибут может повлиять на ваше приложение после обновления системы, рассмотрите следующий пример:
Приложение, объявляющее maxSdkVersion = «5» в своем манифесте, публикуется в Google Play. Пользователь, чье устройство работает под управлением Android 1.6 (API Level 4), загружает и устанавливает приложение. Через несколько недель пользователь получит обновление системы на Android 2.0 (API Level 5). После установки обновления система проверяет maxSdkVersion приложения и успешно повторно проверяет его. Приложение функционирует как обычно. Однако через некоторое время устройство получит еще одно обновление системы, на этот раз до Android 2.0.1 (API Level 6). После обновления система больше не может повторно проверять приложение, потому что собственный уровень API (6) системы теперь выше максимального, поддерживаемого приложением (5). Система предотвращает видимость приложения для пользователя, фактически удаляя его с устройства.
Предупреждение. Объявление этого атрибута не рекомендуется. Во-первых, нет необходимости устанавливать атрибут как средство блокировки развертывания вашего приложения на новые версии платформы Android по мере их выпуска. По дизайну новые версии платформы полностью совместимы с обратной связью. Ваше приложение должно работать должным образом в новых версиях, при условии, что оно использует только стандартные API-интерфейсы и следует лучшим методам разработки. Во-вторых, обратите внимание, что в некоторых случаях объявление атрибута может привести к удалению вашего приложения с устройств пользователей после обновления системы до более высокого уровня API. Большинство устройств, на которых может быть установлено ваше приложение, будут получать периодические системные обновления по воздуху, поэтому перед установкой этого атрибута следует учитывать их влияние на ваше приложение.
Представлен в: API Level 4
Будущие версии Android (помимо Android 2.0.1) больше не будут проверять или применять атрибут maxSdkVersion во время установки или повторной проверки. Google Play будет продолжать использовать этот атрибут в качестве фильтра, однако при представлении пользователям приложений, доступных для загрузки.
Подробнее об этом читайте здесь: используйте sdk
Источник
