Android Versioning & APIs

[00:00:00]
>> Before actually writing some Codes, and creating an app, we need to discuss a little bit about Android versioning. So today Android goes from version one, the first one, to version 13. Of course, we might have the latest version still in Beta or when developer preview. But that's roughly how it works.

[00:00:21]
And today at least we tend to have one major number per year of the operating system. We used to have code names. Probably you have heard about this, like Froyo, Gingerbread Ice Cream Sandwich, like every Android version used to have the surname. Then names were deprecated from version ten to kind of 12, but they're still there.

[00:00:47]
And even today, it seems like they're coming back. So these names, but this is just a codename, and it's actually not so important for us. Actually, the version number, the one that says 12.1, It's also not important to us developers, okay? We will care about something known as the API number, also known as the SDK number.

[00:01:13]
That's what we care about. This is actually an integer, a consecutive integer that express the current version of the API. Every time there is a new Android version change in the API. So they have more things, less things. They have renamed some methods or classes, they have a new number.

[00:01:36]
Sometimes there really a new Android version, but they don't change the API. So for now, for us it's just the same in that case. It's just I'm building for API 32, I don't care if it's 12 or 12.1 or 12.1.3, it's just the same, okay? So we are going to care about the API number.

[00:01:57]
Just remember that we are going to see the API number a couple of times during app development. So we won't see the code name. We won't see, let's say the end-user version number. We will talk about the API number. And to make things more complicated for us, every app contains three different API definitions or API declarations.

[00:02:23]
We have the minimum SDK version that defines installability. That means when we are building an APK an android application, we will pick the minimum API number that we're going to support. So I can say my app is compatible from API 15. So in that case, you're making yourself responsible of using APIs only available in version 15 or if you're using an API that is only available on later versions, you have a conditional that won't execute those APIs on all other devices.

[00:02:59]
Because if not, the app will crash. And if you try to use an API that is not on the phone, the app will crash. We don't want that, okay? By the way, if your app crashes it will reduce some kind of score within the Play Store. If your app is published in the Play Store, okay?

[00:03:18]
So it's important to reduce the amount of crashes and bugs because that improves some kind of, it's like SEO, search engine optimization. So it improves your ranking in the Playstore. So we don't want crashes. Crashes happen, but we need to monitor crashes and solve them. So that's the first definition that we need to make, okay?

[00:03:40]
The minimum SDK version. Then we have the target SDK version, that at first, it's a little weird to follow. But let me tell you this. It's actually the version of the of the API or the SDK that you tested your app on. So you're making sure that I mean, right now let's say that we are building with API 30.

[00:04:05]
That means that we we are testing our app in API 30. And we are telling the OS that with API 30, my app works okay. Because what happens in the future, when we have API 40. Well I don't know what will happen today in the future. So I wanna let the OS know that this was working fine on 30.

[00:04:30]
And if it chases behavior. For example, let's say that foldable phones were not part of the Android SDK until API 30, okay? So if we compile the app with a target 28, that means we didn't know about foldables at the time. So we are not foldable compatible. So even if you run your app on a foldable device, the phone will know that your app is not compatible with the idea of a foldable, okay?

[00:05:03]
With that in mind, the OS will change behavior. For example, it won't offer the app the ability to split the screen in two halves or something like that, okay? If you are defining your target from a minimum SDK that supports foldables, the OS will expect you to know how to live with that.

[00:05:26]
Think about the future. Let's say that in Android, in the SDK 40, they will support holograms, okay? But we are building the app today. We don't know about holograms or how to render holographics UIs. Well, because we are building on set setting the target SDK as 32. The holographic OS will know that we are not holographic compatible, so they will render or app in some kind of 2D emulator, okay?

[00:05:57]
Something like that. So that makes sense? And finally we have the compiler. So this is actually not shipping with the app, that definition is just a compiler we are using. The more modern compiler typically the more efficient and the better output that we have. And typically, we use the latest available.

[00:06:19]
Unless there is a bug or something special that we need to where we need to use an older compiler. We're going to use the latest available. Okay, so these are decisions that we need to make every time we make an app, okay? And we will see in a minute where we're going to make those definitions.

[00:06:38]
Okay, typically, this is a relationship between these SDK. So the compiler is the latest one, the target SDK most of the time, you use the same one as the compiler. So most of the time, they are the same and the minimum SDK it typically goes back to the past.

[00:06:56]
And I will tell you why in a minute, okay? In fact, before moving on with somewhere, I have a couple of more slides and then we will jump directly into lingo. I'm going to open Andrea Stewart. You don't need to follow me at this point. I'm going to create a new project, just to show you something really quick.

[00:07:17]
When you create a new project, it doesn't matter what I'm picking here. It's not the important part. I wanna show you this. When we are building the app, when we are creating the project, I can pick here the minimum best SDK, okay? So it's actually suggesting me to start with API 21.

[00:07:34]
API 21 is Android 5.0. And why picking the minimum SDK is important? Maybe you're saying, hey, why are you going to start with API one? I wanna be compatible with everyone. The problem is that the further you go back, the less APIs you have available, okay? And here we have a link that says help me choose.

[00:07:58]
If you click there, you have this nice diagram that will tell you based on the current active users, how many users are going to be covering, if you set that as a minimum. So if I set API 21 as my minimum, it's 98% of the android users out there.

[00:08:17]
That means there are still 2% with android 4, okay? That's eight years ago. So there are still ADRO OLED devices out there in the market. But if you peek 28, okay? You are losing 30% or more than 30% of your user. So they won't be able to install your app If you set that as your minimum, okay?

[00:08:43]
So this is a decision that you need to make. Of course, there are more versions that you are covering. That means more testing, as well, more UI testing, because you need to make sure that all the users in all those versions are using your app properly. And the app is working properly on their devices.

[00:09:05]
Do you have any question at this point? Yeah.
>> So are you making a prediction that holograms will holographic UI will be available in 40?
>> I don't know maybe yeah, maybe or maybe AR mean, you put your glasses and the app will pop up in 3D, in the environment.

[00:09:23]
I mean, that can happen every time. I mean in the next few years, but yeah. The thing is that when we are working with the app, we need to understand that our app will be compatible. So Android tries to be always future proof. And with that in mind, if you're building your app today, and you're selecting the target with today's maximum target, future Android devices will know that and they will do their best to actually make your app work great even in future Hower.

[00:09:54]
So, that's kind of the idea, right? That we are going to, I mean there is no guarantee. But it's kind of they're trying to push this idea of future proof. That if, I mean in the Play Store, there are still a lot of apps out in the Play Store that were built ten years ago.

[00:10:14]
And you're still downloading the same APK. And the idea is that even if you run this in a high resolution, foldable device, the app should work fine. And Android will try to match whatever expectation you had as a developer two years ago. That kind of idea, okay? Makes sense?

[00:10:36]
Okay, so just have in mind that those are decisions that we need to make, okay? So in terms of API is available, as we mentioned before, every new version of the Android operating system includes new API. API to Bluetooth to use wherever new technology is available, it may have to do with something software based, like a new background surveys in the OS or hardware based.

[00:11:06]
The latest big sample is foldable devices, okay? The ability to support more than one screen or a screen that can fold itself and detect the events while that's one of the latest big additions on Android. If we target users on that new version, it will take years to get to the majority of users.

[00:11:26]
So if I'm building my app using target API 32, the latest one is to the a 0% of the users. 0.5 probably.. And it will take years to actually get 50%, okay? So, because this is a problem, because I wanna use the latest technologies,. But also I need to support all my user folder, okay?

[00:11:55]
So Google create the I mean, the Android team created something known as Support Libraries. So Support Library is a framework, okay? So that we need to import an ad in our code that will let us use latest abilities with some kind of emulation or polyfill on older devices, okay?

[00:12:17]
Because if not, I'm always stuck with all APIs, okay? Does it make sense? So it's like on the web when you're using polyfills to fill a gap in a browser that is not supporting an API or something like that. Well, the Support Libraries today were were renamed under the name under the JetPack name.

[00:12:36]
So JetPack is actually a set of libraries that are adding Support Libraries and many other things. So when we hear about Jetpack, it's just these set of libraries is a backpack. In fact, the logo of Jetpack is an Android little guy with a backpack. So it's the set of tools that we actually need to create an app.

[00:13:01]
And in terms of color architecture, the official SDK, the one that we are using is based on a Java built on machine and is pure written in Java. So I know, let's say the official SDK means the baton the geolocation service, the service that goes to the network.

[00:13:22]
Every API that we're using from the OS is written in Java and runs in your Java built on machine Java VM, okay? But it's not the Oracle or the Sun built on machine. It's own engines, in fact they went to a legal fight, Oracle and Google because of this, okay?

[00:13:45]
And so we write Java, we compile Java but then, it's not actually going to Java intermediate language. And there is no Java virtual machine on the Android phone as we know it it's a different machine. And it's called Dalvik an ART, that we have to run times their visual, the original word called Dalvik.

[00:14:08]
It doesn't matter. And the other one is Android Runtime. Again, it doesn't matter about the names but in case you heard about those names, these are the runtimes that are executing Dalvik code. What's Dalvik code? So let's say if you write Java and now we will talk about Kotlin as well.

[00:14:28]
If you're writing Java, we compile Java into Java, intermediate language. And that intermediate language is compiling to Dalvik executable code. And that's like an Android format. And then there are the BM will run that Dalvik executable code. So we don't compile native code on Android, unless we are using C, okay?

[00:14:52]
And that's known as the NDK. The Native Development kit, but we are using the SDK. And with the SDK, we don't use C we use Java or Kotlin. In that case, we don't write native code, we actually write Dalbec executable code. This is transparent to us developers. But I want you to know how that works.

[00:15:13]
Because someone who had a problem he will talk about the dex file and you'll know what the dex file is. Dex is Dalvik executable. So we compiled to Java bytecode that has garbage collector like Java. And here comes Kotlin, Kotlin also compiles to Java bytecode. So we are going to write Kotlin.

[00:15:35]
And the Kotlin code that we're going to write is going to be compiled into Java into Dalvik executable code. That is the same as if we're building Java. In fact probably that you can on executables you can actually decompile executables, okay? We need to see if it's legal in your country and in some situations but you can decompile code.

[00:15:59]
When you decompile Kotlin applications, you originally get Java because it's the same intermediate language. It's like.net with T sharp visual basic that they were both compiling to net intermediate language. Well, this is the same. We have Java on Android, we have Kotlin and Android both are combined into the same built on machine code.

[00:16:27]
So they are 100% interoperable because it's just the same.