Android sdk list targets

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!

Источник

Prerequisites

To properly follow this material, you must have the following in place:

(1) You have installed the latest Java Development Kit (JDK) from Oracle. (java.com/download)

(2) You must have installed Android SDK. If you have not done so yet, you can download the Android SDK here: developer.android.com/sdk

(The Android SDK can be downloaded separately as a stand alone installer, or as part of the bigger Android Studio installer)

The Android SDK and the associated commands work roughly exactly the same way on Windows, Mac OS X and Linux. Therefore, the instructions given here should be applicable regardless of your operating system.

The «android» command

If you have the Android SDK in place, you can locate the «android» command inside the tools directory. To try it, open up your command line, and issue the following kind of command (obviously replacing the beginning with the complete path to the actual directory where you have installed the SDK files):

Then press ENTER. By default, the Android SDK Manager will be displayed:

The Android SDK Manager lets you download and install, uninstall, and update necessary packages (SDK tools and platforms) that you need to develop an Android app. Full information about this GUI tool can be found on the Android developer site:

Going back to the command line, to list some of the things that can be done with the android tool, try this:

You should see commands with corresponding descriptions like the following below:

List Targets

To display the list of available Android target(s) / SDK versions that are available on the current system, try this:

You should see available targets like the following:

(Followed by other targets, if available)

Take note of the «id» line in this list, as that is the value that you can use in other places to refer to the specific version of an Android SDK target.

List Devices

To display a list of available Android device(s) that are currently configured, try this:

You should see available device definitions like the following:

(Followed by other devices, if available)

The Android Emulator

The Android Emulator emulates a complete Android device in software on a desktop computer. Therefore, to do Android development, you will not necessarily need to have an actual physical device at your disposal. You can locate the Android emulator tool as part of the Android SDK here:

Creating an Android Virtual Device

To run an instance of the Android operating system inside the emulator, you will first need to create an Android Virtual Device. You can do this with the following kind of a command:

Type the entire command on one line. Then press ENTER in the end. You should see something like this:

Cool! You have successfully created your Android Virtual Device.

Running your virtual device

To execute your new Android Virtual Device in an emulator, you can simply do this:

You should see and Android Emulator starting up and something like below in the terminal window:

The emulator itself should have opened in a new window, running a complete copy of the Android operating system.

Creating a new Android application

To create the initial source code for a new Android application, try this:

Again, the entire command would be written on one line. In the end, press ENTER. You should see something like this in your terminal window:

Awesome! You have successfully created an Android project.

Project Directory Contents

After successfully creating a project, navigate to your project directory. You should have the following files and directories in place:

Adjust the created project

It appears that the project creation script is stuck in an older version of Gradle, which is no longer compatible with newer versions of the overall Android build system. To address the problem, we will need to edit the «gradle-wrapper.properties» file under the «wrapper» subdirectory of the «gradle» directory in the created project source. In that file, by default, you find a line like this:

This can be changed to this:

(essentially, we change gradle version from 1.12 to 2.2.1, as it should be).

Likewise, in the generated «build.gradle» file, you should change the line that says «runProguard false» to «minifyEnabled true» (apparently, the syntax for this was changed at a point during the Android build system development cycle, but the «android create project» script is yet to be updated accordingly).

Compiling an Android Project

Before you compile your project, you must be connected to the internet in order for the gradle wrapper script to download the appropriate gradle software components. Once ready, to compile your Android project, navigate to your project directory on your command line (change directory), and do this:

For Mac or Linux:

The «gradlew» script is a wrapper script that then downloads all the necessary components that are needed to run the complete Gradle build. Once any necessary downloading is completed, the wrapper continues to execute the actual build. In the end, you should find the final APK installer in the «build» -> «outputs» -> «apk» directory under your project directory:

The installer to use is the second one in the list above (*-debug.apk).

The APK file

The Android Application Package, most commonly known as APK, is the installer and distribution file format for Android apps. Once your Gradle build has successfully completed, you should have an APK file that was generated from your source code.

The Android Debug Bridge

Android Debug Bridge (adb) is a command line tool used to communicate with a connected android device or emulator. It is commonly used for installation and debugging of apps during development.

You can locate the Android Debug Bridge executable (adb or adb.exe) here:

For complete official information about Android Debug Bridge, refer to the link below:

Bear in mind that before you install and debug an app, you must have one of the following in place:

(1) Connected Android device

(2) Running Android Emulator

Select the appropriate device

If you have a device connected, or an emulator running, to check if it is connected, try this:

This command will list all physical Android gadgets (tablets, phones, etc.) that you have connected to your development computer (via USB or otherwise), as well as any Android emulator instances that you may have running. If ever you plug in several devices, and/or run several emulators simultaneously, observing this list becomes increasingly important in selecting which one of them you would wish to interact with.

You should see something like the following:

To select a specific Android instance (whether device or emulator) to use, you can use the -s parameter of adb to specify which device to use, followed by the device ID from the list above. For example:

Installing an Android app

If this is your first time to install the particular app on the device or emulator, you can simply do this:

Then press ENTER and the following kind of information should be displayed in your terminal window:

Congratulations. You have successfully installed your Android app. It should now appear in the application menu of the device or emulator.

Replacing or reinstalling an app

To replace a previously installed app, the -r parameter of adb can be used. Try this:

Take note that the -r parameter means to replace an existing application. So, doing this ..

.. would generate an error, as shown below, since you are trying to install the same version of the app without using the -r parameter.

Debugging with adb logcat

The logcat command of adb is used to display system messages of a running Android OS (whether device or emulator). This is extremely useful to find out what is happening to an application or a device. Any and all messages generated by the device are shown here, giving a wealth of information for any kind of troubleshooting requirements.

You should see logs in your terminal window something like the following:

The logcat command of adb is commonly used by app developers and testers to trace the cause of crashes in an Android app during development.

Filtering logs

To filter logs using the logcat command of adb. You can do this:

The asterisk (*) character means ALL logs and the hash (#) character is the filter, which can be one of the following:

For example, doing this .

. would result to something like the following:

When filtering logs, a priority is followed from top to bottom. If *:W is used, Warnings are displayed first followed by Errors then Fatal logs. Like in the sample above. Thus, filtering with Verbose (default) will display the logs starting from Verbose down to Fatal.

Furthermore, you can also filter logs with a keyword. Try this (this only works on a Unix-like environment, such as Mac OS X or Linux):

For example, doing this .

. would result to something like the following:

The pipe (|) character means that logs from the logcat command of adb will be an input for grep (a command used to search for strings). The -i parameter of grep means ignore case.

Interrupting logcat

You can at any time interrupt the logcat command by pressing Ctrl+C in your terminal window. You should then have returned to your command line.

Congratulations!

You have completed this tutorial. You have successfully created an Android application purely on the command line.

Источник