قالب وردپرس درنا توس
Home / IOS Development / Android SDK Versions Tutorial With Kotlin

Android SDK Versions Tutorial With Kotlin



Update note : Kevin Moore updated this tutorial. The original tutorial was
written by Eunice Obugyei and Eric Crawford, who updated it to Kotlin.

Since the first release of Android, the range of supported devices has grown to represent a wide variety of phones, smart watches, cars, Android Internet and more. All that is needed to start developing Android apps for these devices falls under a specification called Android SDK (software development kit). New SDK versions are released with each new version of Android, and that's the focus of this tutorial.

These new SDK versions take advantage of the increased processing power available on the latest devices to provide great new features. Awesome, right? The flipping side is, of course, that Android developers face the challenge of ensuring that an app will work on a variety of devices running different versions of the Android SDK.

There are some best practice guidelines and tools to get the job done without sacrificing UX or deadlines.

Note: This guide for Android SDK Versions assumes that you are already familiar with the basics of Android development and Kotlin. If you're brand new in Android development, read Beginning Android Development and our other Android and Kotlin tutorials to familiarize yourself with the basics.

In this Android SDK Version tutorial, you learn about:

  • Android SDK Versions and API Levels
  • Android Support Libraries and Their Importance
  • How to Use the Android Support Library to Make an App Compatible
  • How to use the CardView Support Library

To put the theory into practice, you will be playing with a simple app called Continents . Continents provide brief descriptions for all continents.

Note: This tutorial requires Android Studio 3.3.2 or later.

Getting Started

Click the button Download materials at the top or bottom of this tutorial to get your hands on the start project for this tutorial and unzip the downloaded .zip file to get the project .

Select Open an existing Android Studio project from Quickstart menu to open startup project:

If you are on a Windows machine, You can also select File ne Open . Navigate to and select the start project folder.

Emulate different SDK versions

We will try to run the trial file on different Android versions. However, it is unlikely that anyone has an Android device for each API level on the SDK. So first, learn how to set up emulators with different SDK versions.

To configure an emulator, find AVD (Android Virtual Device) Manager on Android Studio Toolbar

Creating a Virtual Device

If Toolbar Does Not Appear , select See je Toolbar to display it. You can also choose to select Tools ▸ Android ▸ AVD Manager to open AVD Manager.

Click Create a virtual device button. It will open Select Hardware in the Virtual Device Configuration window.

Select a device you want and click Next . It opens System Image which currently displays recommended system images.

x86 tab displays all the x86 emulator images. Other Images tab will display both ARM and x86 emulator images.

Note : It is recommended that you always use x86 images. These will run fastest on most PCs and Macs

Download a system image

To download a system image that you have not already installed, click the Download link at the release name . [19659003]

Note that the Android platform currently has twenty-five major versions of the SDK. Starting with Android 1.5, large versions of the SDK have been developed under a confection-themed code name. Google has managed to select these tags in alphabetical order. They haven't run out of sweets yet. :]

Each version (smaller or larger) of the Android SDK has an integer that uniquely identifies it. This unique identifier is referred to as the API level. The higher the API level, the later the version. For developers, API level is important because it is what determines the number of devices that an app can run on.

Look at an example, the Android 9.0 edition. You can see it:

  • That's the latest version of the Android SDK
  • The version number is 9.0
  • The code name is Pie
  • It has an API level of 28

For this tutorial, you must have at least two emulators, one with API level 16 and another with API level 28.

Return to the System Image screen in Android Studio, click Download button for each of the SDK versions you need for this tutorial that you have not already downloaded (Level 16 and Level 28) . Then select the level 28 system image and click Next .

On the next screen, click Finish .

Repeat the same steps to configure an emulator with API level 16.

Running Sample App

Try running the sample counter on the emulator running API Level 28:

Everything looks good, right? But if you were trying to run the app on a device with API level lower than 28, it wouldn't run. This is because the app only runs on devices running Android API level 28 and up, which is not good for older devices. Later, you learn how to expand the app's support from Android API level 28 to as little as Android API level 16.

SDK versions and API levels

As mentioned earlier, API level is a unique integer that identifies one specific version of the Android SDK. Take a look at how to set API levels in Android Studio to compile and drop an app.

Open build.gradle for the app module:

Here you can see three key attributes:

  • minSdkVersion is the smallest API level that the app is compatible with. The Android system will prevent a user from installing the app if the system's API level is lower than the value specified in this attribute. Android requires that mySdkVersion attribute should always be set.
  • targetSdkVersion is the API level that the app targets. This feature informs the system you have tested against the target version. TargetDkVersion is standard for minSdkVersion if not specified.
  • compileSdkVersion sets the API level to compile the app against.

These attributes can be adjusted in the app modules build.gradle file.

Preview of the SDK : It is important to know that when you set compileSdkVersion to a preview of in the Android frame, Android Studio will force minSdkVersion and targetSdkVersion to correspond to exactly the same string as compileSdkVersion . This policy is required to prevent situations where you can upload your app to the Google Play Store. As a result, you can only run apps where compileSdkVersion is set to a preview solution for emulators with exactly the same preview and you will not be able to run it on older devices.

Backward Compatibility

By default, the Android SDK is forward compatible but not backward compatible – this means that an app that is built with and supports a minimum SDK version 3.0 can be installed on any device running Android version 3.0 and up – but not on devices running Android versions below 3.0.

Since the Android SDK is not backward compatible, you should select the minimum SDK carefully. This implies a balance between supporting a wide range of devices and designing an app that implements useful features in later SDK versions.

When Android 3.0 was released in 2011, Action Bar was released on the Android community. Since the action bar was only supported in Android 3.0 and later, using a cool user interface or supporting devices that ran older versions of the SDK, using it in an app, sometimes you can't have your gingerbread and eat it as well. : [

Or can you? To help with the action line problem, Android Support Library introduced a backward-compatible version in the v7 appcompat support library. So it will allow developers to support older versions of the SDK and still use the latest Action Bar APIs in their apps. Sweet! Honeycomb for everyone!

Take a deeper look at what the support library is doing and how it works.

Note to pick the minimum sdk version: Google provides a Dashboard that breaks down the user allocation percentage per api level. You can use this to target a good percentage of users. There is also information provided when you create your project and choose your minimum API level that shows the percentage of devices your app will run on.

Android Support Libraries

A wide range of components make up what is called "Support Library" or "Support Libraries" and they can be categorized into two groups:

  • AppCompat AppCompat library: The purpose here is to Make sure that all (or most) latest APIs framework programs have been reverted to previous versions and are available in this single library. The first version of AppCompat was released on Google I / O 2013.

    The goal of this first release was to allow developers to backport ActionBar to units running Ice Cream Sandwich level. This provided API parity to the frame across as many API levels as possible. Since then, the AppCompat library has continued to evolve. And with Android Lollipop, the support library is now at the point where the API is similar to the frame itself – the first time ever happened. :]

  • Others : The rest of the libraries that make up the Support Library, provide essentially new functionality with the same consideration for backward compatibility (palette, gridview, grid layout, recycling view, material design widgets).

When you break these into independent libraries, you can choose and choose the ones you need in your project. It is important to note that each support library is backward compatible to a particular API level. And they are usually called based on which API level they are backward compatible with. For example, v7 appcompat provides backward compatibility to API level 7.

Find the complete list of components that belong to the Support Library in the Android documentation.

AndroidX Support Libraries

] Google has decided to reorganize their support libraries and has called them AndroidX or Jetpack. We will not go into detail about these libraries, as they are not all out of the alpha scene. A future version of this tutorial will discuss them. For more information, see: AndroidX Support Libraries

Using an Android Support Library

Time to See an Android Support Library in Action! Open MainActivity.kt . As you may have noticed in the onCreate () method, the app uses a toolbar (which is part of the material design pattern) instead of a action bar

The toolbar was added to API 21 (Android Lollipop) as a flexible widget that can be used anywhere in layouts, animated and resized, as opposed to the action bar.

Thanks to AppCompat, that feature has been fully backed to API 14, which is codenamed Ice Cream Sandwich (are you still hungry?). You must use the v7 appcompat support library to extend the app's compatibility to a minSdkVersion of 16.

Update build file

First, add google () to the Maven repositories in your project level build.gradle file, if not already there:

  repositories {
center ()
Google ()
}

Now, open build.gradle for the app module and add the following to the dependency part:

  implementation "com.android.support:appcompat-v7:28.0.0"

When adding this you declare the appcompat-v7 support library as an addiction to your app. You can ignore the warning about using a newer version of the Support Library. Although you can update, it is recommended that you stick to it in this tutorial.

Then change the minSdkVersion attribute to 16.

  minSdkVersion 16 

Here you declare that the app should be able to run on devices with Android SDK version 4.1.2. Now try running your app on an API level 16 with emulator. You should see the following exceptions in logcat:

The important line to look for is:

  Caused by: java.lang. ClassNotFoundException: android.widget.Toolbar 

The error ClassNotFoundException indicates that there is no such class in the SDK version you are running the program against. In fact, it is only available in API level 21 while you are currently running API level 16.

Backward Compatibility Update

You should update the code to use the backward compatible version of the toolbar. Open MainActivity.kt and update android.widget.Toolbar the import setup to match the following:

  import android.support.v7.widget.Toolbar 

This replaces the SDK imported with one from the AppCompat library.

Then AppCompatActivity imports from the AppCompat library:

  import android.support.v7.app.AppCompatActivity 

Next update of MainActivity class definition line to inherit from AppCompatActivity :

  class MainActivity: AppCompatActivity (), ContinentSelectedListener 

Finally, replace a class from the latest SDKs with one found in the Support Library.

You must now work through the class and replace some metal conversations with their Support Library equivalents:

  • Find the call to setActionBar (toolbar) at the end of onCreate () method body an update it to setSupportActionBar (toolbar) .
  • Find the calls to actionBar? in onContinentSelected () goToContinentList () and at BackPressed () and replacing both with supportActionBar? .
  • Replace the calls to fragmentManager () in onContinentSelected () and goToContinentList () with supportFragmentManager () .
  • Change the code in goToContinentList () to fix the error by replacing the fragment:
     ] selection fragment = MainFragment.newInstance (continentNames)
support fragment manager
.beginTransaction ()
.replace (Rid.frameLayout, snippet)
.commit()
mainFragment = fragment

Update of fragmentation classes

Open DescriptionFragment.kt and MainFragment.kt find the following line:

  import android.app.Fragment 

And update to match with the following:

  import android.support.v4.app.Fragment 

Here you use the support version of the class Fragment instead of the main SDK. The latter can only be used in apps with minkDkVersion of 14 and above.

Note : AppCompat v7 depends on the v4 support library. Therefore, you can also use all the APIs in the package android.support.v4.app .

So far, you have replaced all the major API calls with similar methods from the Support Library. Then, update your layout files to use the support library.

In the res / layout folder, open toolbar_custom.xml and do the following:

  • Change android.widget.Toolbar to android. support.v7.widget.Toolbar
  • Change ? Android: attract / actionBarSize to ? Attr / actionBarSize

Again, all this is done, changing the package name from android to v7 appcompat.

Now that all the compilation time errors have been checked and fixed, try running the app again. You will now get the following run-time error:

 java.lang.RuntimeException: Cannot start activity ComponentInfo {com.raywenderlich.continents / com.raywenderlich.continents.MainActivity}: java.lang.IllegalStateException: You must use one theme.AppCompat theme (or descendant) with this activity.

Updating styles

The error message is quite self-explanatory, but why do you need to use the AppCompat theme? A feature of the Lollipop release of AppCompat is the different approach to the theme. One of the interesting things about this is the ability to get an L-friendly version of your app on previous versions. If an app uses the frame version of everything ( Activity instead of AppCompatActivity for example), it will only get the material theme on phones with the L release. Units with previous releases would get the standard theme for these releases. The goal of the AppCompat theme feature is to have a consistent experience on all devices.

In the folder res open styles.xml and change android: Theme.Black.NoTitleBar to Theme.AppCompat. NoActionBar .

Well, build and run. You can test the app on an API 16 device or emulator as well.

Well done! The sample app is now backwards compatible.

Now you throw in some cards to make the detail look better.

Using CardView Support Library

Open build.gradle for the app module and add the following to the addiction section:

  implementation "com.android.support:cardview-v7:28.0.0" 

Now synchronize your project. When you add this, the v7 map view support library is declared as an addiction to the app.

Open the file fragment_description.xml and place ImageView in a CardView:


 

Note that when using widgets from the Support Library, some XML attributes ( cardBackgroundColor and cardElevation for CardView are not prefixes with "android." That's because they come from Support Library API Unlike Android Frame Press Option-Return (or Alt-Enter on PC) if you need to set up card_view namespace in .xml

build and run the project:

Cool, you've added this new CardView to your app and use the compatibility library that works from modern versions of Android, right back to the old API level 16

Have you said material design?

You have successfully completed the AppCompat theme to give the app the Android Lollipop look of a wide range of SDK versions. In addition to these items, the Material Design specification contains many more patterns and widgets not fine in the AppCompat. This is where the design library comes into play. It provides widgets such as navigation drawers, floating action buttons, snack bars and tabs. Let's include it in the project and add a floating action button.

build.gradle add the following in dependencies :

  implementation "com.android. Support: design: 28.0.0" 

Then add the following XML element over the FrameLayout closing code in fragment_description.xml :

 

Build and run. You will see the floating button as expected.

 fab-button

Where should I go from here?

Congratulations! Finally, you have learned about Android SDK versions and their cute code names. You have created an API Level 28 app, backwards compatible with API Level 16, and used CardView and Design Library to add more components. may also have a sugar requirement:]

  Blame Android.

Blame Android.

The final project for this guide for Android SDK Versions can be downloaded by clicking the Download Materials button at the top or bottom of this tutorial.

If you are interested in the Android SDK version history, check out this wikipedia page or version page on the Android Developer's website. You can also read more about mySdkVersion and targetSdkVersion attributes from the manifest site on the developer site. Finally, you can check out the developer pages on Support Libraries and its feature list.

We hope you enjoyed this Android SDK version tutorial, and if you have any questions or comments, please join the forum discussion below!


Source link