Android compilesdkversion что это

compileSdkVersion и targetSdkVersion: в чем разница?

6 месяцев назад

В этой статье мы более подробно рассмотрим два значения, которые задаются в файле build.gradle: compileSdkVersion и targetSdkVersion.

Обычно мы автоматически обновляем оба этих значения уровня API после выпуска новой версии Android SDK. Но почему это так важно? И почему их два, ведь мы все равно обычно устанавливаем для них одно и то же значение?

Оба compileSdkVersion и targetSdkVersion имеют решающее значение для обработки прямой совместимости в Android, поэтому они оба связаны с тем, что делать, когда появится новая версия Android SDK. Но как именно они работают?

compileSdkVersion

compileSdkVersion определяет, какая версия Android SDK будет использоваться gradle для компиляции вашего приложения.

Например:

В Android 12, в SDK версии 31, был представлен новый API, который позволяет нам легко реализовать сплэш-скрин. В этом новом API заставку можно настроить с помощью следующих свойств:

Если вы хотите использовать этот API в своем приложении, вам сначала необходимо:

• скачать SDK версии 31 в Android Studio, а затем
• обновить compileSdkVersion до 31 в вашем приложении.

Только тогда вы сможете увидеть эти новые свойства. И только после этого вы можете использовать этот новый API экрана-заставки в своем коде.

А как насчет старых устройств?

Это, конечно, не означает, что вы можете использовать только этот новый API и забыть о пользователях, у которых есть более старые версии Android, где этот API недоступен.

Если minSdkVersion в вашем приложении ниже 31, вам также необходимо предоставить альтернативный способ отображения экрана-заставки для тех старых устройств, которые не имеют доступа к этому новому API.

Точно так же некоторые методы или свойства могут быть объявлены устаревшими в этой версии Android SDK, а некоторые даже удалены. Вот почему после обновления compiledSdkVersion в своем приложении вы часто будете видеть некоторые предупреждения и ошибки во время компиляции, которые необходимо устранить.

Но изменение только compileSdkVersion на самом деле не меняет поведения созданного вами приложения.

Как Android узнает, может ли он использовать новые функции с вашим приложением или нет? Вот где в игру вступает targetSdkVersion.

targetSdkVersion

targetSdkVersion — это свойство, которое сообщает системе, для какой версии Android было разработано и протестировано приложение.

Если пользователь запускает ваше приложение на устройстве с версией Android, которая выше, чем targetSdkVersion, заданный в вашем приложении, то система может запустить некоторое функции обратной совместимости, чтобы ваше приложение по-прежнему выглядело и работало таким образом, каким вы задумывали.

Например:

В Android 12 изменен внешний вид пользовательских уведомлений. Раньше они могли использовать всю область уведомлений, но в системе Android 12 стандартный шаблон применяется ко всем настраиваемым уведомлениям, чтобы они выглядели более согласованными.

Если значение targetSdkVersion меньше 31, система предположит, что вы не тестировали эту функцию, и будет отображать уведомления по-старому, чтобы минимизировать риск того, что уведомление не будет отображаться должным образом. Только после обновления целевой версии SDK до 31 будет использоваться новый вид уведомлений.

Все ли изменения в Android SDK обрабатываются таким образом?

Нет, не все изменения, представленные в новых версиях Android, являются целевыми и используют эти механизмы обратной совместимости. В документации вы можете видеть, что для каждого выпуска версии Android изменения разделены на две группы:

• поведенческие изменения для приложений, ориентированных на определенные версии Android
• и изменения для всех приложений, независимо от того, какой targetSdkVersion они имеют.

Примером последнего может быть введение одноразовых разрешений в Android 11. Когда устройство использует Android версии 11 или выше и приложение запрашивает разрешение на определение местоположения, пользователь может предоставить временный доступ к этим данным, и приложение должно обработать этот выбор, независимо от того, нацелено ли оно на SDK версии 30 или нет.

Связь между компилируемой и целевой версиями SDK

Даже если compileSdkVersion и targetSdkVersion имеют совершенно разные значения, они явно не независимы.

targetSdkVersion не может быть выше compileSdkVersion просто потому, что мы не можем нацеливаться на вещи, о которых мы ничего не знаем во время компиляции.

В идеале compileSdkVersion и targetSdkVersion должны быть одинаковыми и указывать на последнюю версию SDK. Но, конечно, только после того, как вы проверите, что каждое изменение, внесенное в эту версию, правильно работает с вашим приложением!

Источник

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!

Источник

В чем разница между минимальной версией SDK / целевой версией SDK и версией компиляции SDK?

В чем различия между «min sdk version / target sdk version» и «compile sdk version»? Я знаю, что означает min и target sdk, но что означает версия sdk для компиляции?

В Eclipse у меня есть min / max и целевой SDK, но в Android Studio есть эти три настройки.

Версия min sdk — это самая ранняя версия Android SDK, на которой может работать ваше приложение. Обычно это происходит из-за проблемы с более ранними API, отсутствия функциональности или из-за других поведенческих проблем.

Версия целевой SDK является версия ваша заявка была направлена работать на. В идеале это из-за каких-то оптимальных условий работы. Если бы вы должны были «сделать ваше приложение для версии 19», это то, где это будет указано. Он может работать на более ранних или более поздних выпусках, но это то, к чему вы стремились. Это в основном указывает на то, насколько актуально ваше приложение для использования на рынке и т. Д.

Версия компиляции SDK является версией андроида ваш IDE (или другие средства компиляции я предполагаю) использует , чтобы сделать ваше приложение , когда вы публикуете .apk файл. Это полезно для тестирования вашего приложения, так как это общая необходимость для компиляции вашего приложения по мере его разработки. Так как это будет версия для компиляции в APK, это, естественно, будет версия вашего выпуска. Также желательно, чтобы это соответствовало вашей целевой версии SDK.

minSdkVersion Runtime Permissions были введены. Если вы установили targetSdkVersion 22 или ниже, ваше приложение не запрашивает у пользователя разрешения во время выполнения.

Начиная с Android 8.0 (уровень API 26), все notifications должны быть назначены каналу, иначе он не появится. На устройствах под управлением Android 7.1 (уровень API 25) и ниже пользователи могут управлять уведомлениями только для каждого приложения (фактически каждое приложение имеет только один канал на Android 7.1 и ниже).

Начиная с Android 9 (уровень API 28) Web-based data directories separated by process . Если targetSdkVersion 28+ и вы создаете несколько WebView в разных процессах, вы получите java.lang.RuntimeException

compileSdkVersion — фактически это версия платформы SDK и сообщает Gradle, какой Android SDK использует для компиляции. Если вы хотите использовать новые функции или отлаживать .java файлы из Android SDK, вам следует позаботиться о compileSdkVersion. Еще один пример — использование AndroidX, которое вынуждает использовать compileSdkVersion — уровень 28. compileSdkVersion не включен в ваш APK : он используется исключительно на compile time . Изменение вашего compileSdkVersion не меняет поведение во время выполнения. Он может генерировать, например, новые предупреждения / ошибки компилятора. Поэтому настоятельно рекомендуется всегда компилировать с последним SDK. Вы получите все преимущества новых проверок компиляции в существующем коде, избежите новых устаревших API и будете готовы использовать новые API. Еще один факт compileSdkVersion >= Support Library version

Вы можете прочитать больше об этом здесь . Также я бы порекомендовал вам взглянуть на пример перехода на Android 8.0.

Источник