Android compile sdk version

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!

Источник

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. Но, конечно, только после того, как вы проверите, что каждое изменение, внесенное в эту версию, правильно работает с вашим приложением!

Источник

SDK Platform Tools release notes

Android SDK Platform-Tools is a component for the Android SDK. It includes tools that interface with the Android platform, such as adb , fastboot , and systrace . These tools are required for Android app development. They’re also needed if you want to unlock your device bootloader and flash it with a new system image.

Although some new features in these tools are available only for recent versions of Android, the tools are backward compatible, so you need only one version of the SDK Platform-Tools.

Downloads

If you’re an Android developer, you should get the latest SDK Platform-Tools from Android Studio’s SDK Manager or from the sdkmanager command-line tool. This ensures the tools are saved to the right place with the rest of your Android SDK tools and easily updated.

But if you want just these command-line tools, use the following links:

• Download SDK Platform-Tools for Windows
• Download SDK Platform-Tools for Mac
• Download SDK Platform-Tools for Linux

Although these links do not change, they always point to the most recent version of the tools.

Revisions

31.0.3 (August 2021)

• fastboot
  • Support flashing vbmeta_vendor.img for fastboot flashall / update.

31.0.2 (April 2021)

• adb
  • Support forwarding to vsock on linux.
  • Fix bug in adb track-devices where devices over wireless debugging wouldn’t immediately receive updates.
  • Implement preliminary support for mDNS device discovery without a separately installed mDNS service. This is currently disabled by default, and can be enabled by setting the environment variable ADB_MDNS_OPENSCREEN to 1 when starting the adb server.
• fastboot
  • Don’t fail when unable to get boot partition size.
  • Derive device locked state from property instead of parsing the kernel command line.

31.0.1 (March 2021)

• adb
  • Reduce TCP keepalive interval.
  • Improve incremental installation performance.
• fastboot
  • Add support for compressed snapshot merges.
  • Restore legacy A/B support.

31.0.0 (February 2021)

• adb
  • Disable compression on pull by default.

30.0.5 (November 2020)

• adb
  • Improve performance of adb push when pushing many files over a high-latency connection.
  • Improve adb push/pull performance on Windows.
  • Fix adb push —sync with multiple inputs.
  • Improve performance of incremental apk installation.
  • Improve error handling for incremental apk installation.

30.0.4 (July 2020)

• adb
  • Fix fallback to non-incremental apk installation on pre-Android 11 devices.
  • Fix adb install-multi-package .
  • Fix some more crashes related to adb wireless pairing.
  • Improve some error messages.
• fastboot
  • Improve console output on fastboot oem commands.
  • Fix fastboot flashall on older devices such as Nexus 7.

30.0.3 (June 2020)

• adb
  • Fix installation of APKs signed with v4 signature scheme on pre-Android 11 devices.
  • Fix crash when authenticating without ADB_VENDOR_KEYS .
  • Fix crash when using adb -H .

30.0.2 (June 2020)

• adb
  • Improve adb wireless pairing.
  • Fix hang in adb logcat when run before a device is connected.
  • Add adb transport-id to allow scripts to safely wait for a device to go away after root/unroot/reboot.

30.0.1 (May 2020)

• adb
  • Disable adb mdns auto-connection by default. This can be reenabled with the ADB_MDNS_AUTO_CONNECT environment variable.
  • Improve performance of adb install-multi on Android 10 or newer devices.
  • Fix timeout when using adb root/unroot on a device connected over TCP.
  • Update support for wireless pairing.

30.0.0 (April 2020)

• adb
  • Add initial support for wireless pairing.
  • Add support for incremental APK installation.
  • Implement client-side support for compression of adb when used with an Android 11 device.
  • Improve performance of adb push on high-latency connections.
  • Improve push/pull performance on Windows.

29.0.6 (February 2020)

• adb
  • 64-bit size/time support for adb ls when used with an Android 11 device.
  • Support listening on ::1 on POSIX.
  • Client support for WinUSB devices that publish a WinUSB descriptor (required for Android 11) should no longer require a USB driver to be installed.
  • Fix hang when using adb install on something that isn’t actually a file.

29.0.5 (October 2019)

• adb
  • Slight performance improvement on Linux when using many simultaneous connections.
  • Add —fastdeploy option to adb install , for incremental updates to APKs while developing.

29.0.4 (September 2019)

• adb
  • Hotfix for native debugging timeout with LLDB (see issue #134613180). This also fixes a related bug in the Android Studio Profilers that causes an AdbCommandRejectedException , which you can see in the idea.log file.

29.0.3 (September 2019)

• adb
  • adb forward —list works with multiple devices connected.
  • Fix devices going offline on Windows.
  • Improve adb install output and help text.
  • Restore previous behavior of adb connect without specifying port.

29.0.2 (July 2019)

• adb
  • Fixes a Windows heap integrity crash.
• fastboot
  • Adds support for partition layout of upcoming devices.

29.0.1 (June 2019)

• adb
  • Hotfix for Windows crashes (https://issuetracker.google.com/134613180)

29.0.0 (June 2019)

• adb
  • adb reconnect performs a USB reset on Linux.
  • On Linux, when connecting to a newer adb server, instead of killing the server and starting an older one, adb attempts to launch the newer version transparently.
  • adb root waits for the device to reconnect after disconnecting. Previously, adb root; adb wait-for-device could mistakenly return immediately if adb wait-for-device started before adb noticed that the device had disconnected.
• fastboot
  • Disables an error message that occurred when fastboot attempted to open the touch bar or keyboard on macOS.

28.0.2 (March 2019)

• adb
  • Fixes flakiness of adb shell port forwarding that leads to «Connection reset by peer» error message.
  • Fixes authentication via ADB_VENDOR_KEYS when reconnecting devices.
  • Fixes authentication—when the private key used for authentication does not match the public key—by calculating the public key from the private key, instead of assuming that they match.
• fastboot
  • Adds support for dynamic partitions.
• Updated Windows requirements
  • The platform tools now depend on the Windows Universal C Runtime, which is usually installed by default via Windows Update. If you see errors mentioning missing DLLs, you may need to manually fetch and install the runtime package.

28.0.1 (September 2018)

• adb
  • Add support for reconnection of TCP connections. Upon disconnection, adb will attempt to reconnect for up to 60 seconds before abandoning a connection.
  • Fix Unicode console output on Windows. (Thanks to external contributor Spencer Low!)
  • Fix a file descriptor double-close that can occur, resulting in connections being closed when an adb connect happens simultaneously.
  • Fix adb forward —list when used with more than one device connected.
• fastboot
  • Increase command timeout to 30 seconds, to better support some slow bootloader commands.

28.0.0 (June 2018)

• adb:
  • Add support for checksum-less operation with devices running Android P, which improves throughput by up to 40%.
  • Sort output of adb devices by connection type and device serial.
  • Increase the socket listen backlog to allow for more simulataneous adb commands.
  • Improve error output for adb connect .
• fastboot:
  • Improve output format, add a verbose output mode ( -v ).
  • Clean up help output.
  • Add product.img and odm.img to the list of partitions flashed by fastboot flashall .
  • Avoid bricking new devices when using a too-old version of fastboot by allowing factory image packages to require support for specific partitions.

27.0.1 (December 2017)

• adb: fixes an assertion failure on MacOS that occurred when connecting devices using USB 3.0.
• Fastboot: On Windows, adds support for wiping devices that use F2FS (Flash-Friendly File System).

27.0.0 (December 2017)

• Re-fixes the macOS 10.13 fastboot bug first fixed in 26.0.1, but re-introduced in 26.0.2.

26.0.2 (October 2017)

• Add fastboot support for Pixel 2 devices.

26.0.1 (September 2017)

• Fixed fastboot problems on macOS 10.13 High Sierra (bug 64292422).

26.0.0 (June 2017)

• Updated with the release of Android O final SDK (API level 26).

25.0.5 (April 24, 2017)

Fixed adb sideload of large updates on Windows, manifesting as «std::bad_alloc» (bug 37139736).

Fixed adb problems with some Windows firewalls, manifesting as «cannot open transport registration socketpair» (bug 37139725).

Both adb —version and fastboot —version now include the install path.

Changed adb to not resolve localhost to work around misconfigured VPN.

Changed adb to no longer reset USB devices on Linux, which could affect other attached USB devices.

25.0.4 (March 16, 2017)

• Added experimental libusb support to Linux and Mac adb

To use the libusb backend, set the environment variable ADB_LIBUSB=true before launching a new adb server. The new adb host-features command will tell you whether or not you’re using libusb.

To restart adb with libusb and check that it worked, use adb kill-server; ADB_LIBUSB=1 adb start-server; adb host-features . The output should include «libusb».

In this release, the old non-libusb implementation remains the default.

fastboot doesn’t hang 2016 MacBook Pros anymore (bug 231129)

Fixed Systrace command line capture on Mac

25.0.3 (December 16, 2016)

• Fixed fastboot bug causing Android Things devices to fail to flash

25.0.2 (December 12, 2016)

• Updated with the Android N MR1 Stable release (API 25)

25.0.1 (November 22, 2016)

• Updated with the release of Android N MR1 Developer Preview 2 release (API 25)

25.0.0 (October 19, 2016)

• Updated with the release of Android N MR1 Developer Preview 1 release (API 25)

24.0.4 (October 14, 2016)

• Updated to address issues in ADB and Mac OS Sierra

Download Android SDK Platform-Tools

Before downloading, you must agree to the following terms and conditions.

Terms and Conditions

1. Introduction

2. Accepting this License Agreement

3. SDK License from Google

4. Use of the SDK by You

5. Your Developer Credentials

6. Privacy and Information

7. Third Party Applications

8. Using Android APIs

9. Terminating this License Agreement

10. DISCLAIMER OF WARRANTIES

11. LIMITATION OF LIABILITY

12. Indemnification

13. Changes to the License Agreement

14. General Legal Terms

Download Android SDK Platform-Tools

Before downloading, you must agree to the following terms and conditions.

Terms and Conditions

1. Introduction

2. Accepting this License Agreement

3. SDK License from Google

4. Use of the SDK by You

5. Your Developer Credentials

6. Privacy and Information

7. Third Party Applications

8. Using Android APIs

9. Terminating this License Agreement

10. DISCLAIMER OF WARRANTIES

11. LIMITATION OF LIABILITY

12. Indemnification

13. Changes to the License Agreement

14. General Legal Terms

Download Android SDK Platform-Tools

Before downloading, you must agree to the following terms and conditions.

Источник