Explore the Android app framework - Android Tutorial

- [Instructor] Android developers need at least a basic understanding of the architecture of the operating system and the rest of the platform. Android is designed around a kernel that's built around Linux. It's a version of Linux that's highly optimized for mobile operating systems, made as small as possible so it works well on devices that have constrained CPU and memory capabilities. On top of the kernel, there's the Android Runtime, and a set of Libraries that enable the operating system's behaviors. The next level up is the application framework, which sits on top of the Android Runtime and the associated Libraries. And finally at the top there are the apps themselves. Including both those that are included with the operating system and those that the user installs. Let's break down each of these layers. The Linux Kernel, again, starts with Linux itself, but then it also has a set of drivers and these drivers are tuned to the particular hardware that the operating system is running on. There are drivers for audio, camera display, the keypad, flash memory management, power, wifi, and so on. It's up to the OEMs or the manufacturers of the devices to customize these drivers and make them work for their own hardware. If you're holding an android device in your hand, the version of android that's on that device will be a combination of what Google delivers and what the vendor customizes. The next layer is the Android Runtime. This includes a collection of core libraries and critically the virtual machine, known as ART for Android Runtime. Older devices might have an older virtual machine that was known as Dalvik but you don't have to do anything special when you compile and package your apps. Your app will run on both virtual machines. The contemporary Android Runtime, or ART, uses ahead of time compilation. So apps are complied into machine code upon installation in older versions of android, but in newer versions, starting with android seven, they're recompiled into machine language the first time you open the app. To build and package an android app, you use the compiler that's included with the android SDK. The compiler looks at your code and at libraries that are provided with the android SDK. These libraries manage all sorts of features, including graphics, databases, and so on. They work at the same level of the software stack as the core runtime but their extensible. So device makers can add their own libraries to this layer. Next is the application framework with modules for controlling all the different components of your apps, but then there are the apps themselves. Each version of android, as packaged by Google, has been delivered with an expanded set of default apps. If a device is licensed to use Google's G-Suite app collection, it'll have Gmail, Hangouts, GoogleMaps, and so on. Devices that used customized versions of android, such as Amazon's Kindle Fire lineup, will have a different set of default apps, but at minimum, every version of android typically has a home or launcher screen, a browser, contact and calendar management, and photo and camera management. An app is made up of components, and there are many different kinds of components, but I'll be focusing on the basics. Activities, which represent screens on phones and tablets, views, which are individual visual components, and view groups. Each of these components is implemented in the SDK as a Java class. So for example, an activity, or a screen is an instance of a class named android.app.Activity or some subclass of that class. And a button, or a text view, or other visual widget, is also an instance of a class. The button is an instance of android.widget.Button. And you can use these classes either using Java code or Kotlin. For example, if you wanted to create an instance of a button class in Java, the code might look like this. In Kotlin it would be a bit shorter and would eliminate extraneous syntax such as semi-colons. Either way you're still using the same components that are packaged with the SDK and it's up to you as the developer to decide how to put those components together to create your own apps.