Welcome to the final part of this review of the Pluralsight course Android for .NET Developers: 1 Getting Started by Jim Wilson

Jim has over 30 years of software engineering experience, with the past 15 years heavily focused on creating mobile device and location-based solutions. He has co-founded multiple software-related startups and has served in a consulting role at several more.

After nearly a decade as a Microsoft Device Application Development MVP, Jim now focuses on developing Android and iOS device applications. Jim’s passion is mentoring software developers. He blogs at hedgehogjim.wordpress.com.

Also in this series:

Part 1 – Series Overview
Part 2 – Setting up your environment
Part 3 – Android Toolset Fundamentals
Part 4 – Dalvik Debug Monitor Server
Part 5 – Understanding Android Projects
Part 6 – Android Studio
Part 7 – Understanding Android Versioning

Understanding Android Versioning

Android version identity

Each Android release has two separate identities: the Platform version and the API level.

The Platform version, which is a decimal based versioning. At the time I write this, the latest Android platform version is 7.0, which is also known as Nougat.

Jim explains each release also has an API level. This is the set of SDK features and capabilities exposed to application developers.

Each platform version supports a specific API level.

However, there many be multiple platform versions with the same API level. Jim gives the example of Android 2.3 and Android 2.3.2 which both run API level 9.

As developers we are concerned primarily with the API level.

Jim shows us some of the Android documentation to demonstrate how the API Levels affect the features that are available.

See the WallpaperInfo documentation. In the top right hand corner it says Added in API level 7. API levels are backward compatible so if we target API level 7 then our program will work on that level or above.

However, Jim explains some classes get deprecated, and uses the example of TabActivity. New applications should use Fragments instead.

Deprecated features usually remain available but might be taken away at some point.

Android has the ability to prevent new applications from accessing something that is deprecated, but allow older applications to keep using it.

Jim demonstrates the effect of changing the API level by choosing a new drop down option on the left hand side of the Android documentation:

We see some of the features are grayed out. These are the features that we added in a API level that is after our selected level.

Selecting Android platform and API level

We need to decide the minimum API level that we want to support when we build our application.

Jim talks about all of the versions of Android up until May 2013.

He says the platform v1.x releases we just getting started, v2.x was much more user friendly, v3.x was tablet only with very limited adoption, and v4.x has a much better user experience and widespread adoption.

I am currently working on an Android App where the minimum version is 4.1 Ice cream sandwich (API level 16). In my opinion there is generally very little reason to support versions that are older than that.

At the time of Jim’s recording you could reach 55.9% of users by targeting API level 15. But as you’re already thinking, we can’t use that information anymore.

Today, that % figure is in the high 90s. You may want to target the later Marshmallow, Lollipop or even Nougat today.

For the latest information on version usages see Google’s dashboards.

Managing API Level

Android provides two ways to manage the API level:

1. AndroidManifest.xml uses-sdk element
2. Compiler

Inside Eclipse, Jim demonstrates how to use the manifest to control our API levels. There are three textboxes:

• Min SDK version
• Target SDK version
• Max SDK version

He explains the target SDK version indicates the highest API that you’ve tested your app with. Any newer Android versions will adapt if necessary to assure compatibility.

Jim says we don’t use Max SDK version very often, and it means the highest API level that we allow the app to be installed on.

This can be useful if we decide to write one version of our application for one set of API levels and another version for different API levels. Google Play can manage this for us.

Also in this lesson is a demonstration of a hello world app in the emulator. We see that it looks very basic on old API level 10. If we change the Target SDK version from 10 to 14 we get the improved UI rendering.

SDK Manager

Android SDK Manager manages the SDK installation for developers. It installs, updates, and removes features of your development environment. Tools, SDKs for each API Level and extras.

You are responsible to check for updates. It does not automatically keep your installation current.

Jim demonstrates opening the Android SDK Manager from the IDE. Be aware that the Revision numbers have nothing to do with API levels. We see the affect that checking options has on the Install packages and Delete packages buttons.

You need to accept the license agreements. You can just click the top of the group and click “Accept License”.

The end

That’s the end of this course. But soon I will be reviewing Jim’s next course in the series: Android for .NET Developers: 2 Building Apps With Android Studio