Download Understanding Android app architecture

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Understanding Android app architecture
As an Android developer, it's good to have at least a basic understanding of the architecture of
the operating system and the rest of the platform.
Let’s start with a simple image:
The base of Android is 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 that it works well
on devices that have very seriously constrained CPU and memory capabilities. On top of the
Kernel is the Android Runtime. A set of libraries that enable the behavior of the operating
system itself.
The next level is the Application Framework which sits on top of the Android Runtime and the
associated libraries. And then finally, at the top are the apps including those that are included
with the operating system. And custom apps, that you might download from the Google Play
store or build yourself. Let's break down each of these layers. The Linux Kernel, again, starts
with Linux itself, but then also has a set of drivers.
And each driver is designed to interface with an element of the hardware. A phone, or a tablet
for example. You'll have drivers for audio, camera, display, the keypad, to manage flash
memory, power, wi-fi, and so on. It's up to the OEMs, that is, the manufacturers of the
devicesthemselves, to customize these drivers, and make them work for those devices. So 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 delivers.
The next layer is the Android Runtime. And this includes a setup of core libraries and critically,
the Dalvik virtual machine. The Dalvik virtual machine or JVM, replaces the JVM that's used in
conventional Java-based applications. Dalvik, again, is highly optimized for very small
devices. And the byte code that it reads is different in many ways from the byte code that's
generated by conventional Java compilers.
So, to get Dalvik byte code, you have to use the Dalvik compatible compiler that's included
with the Android developer tools. The associated libraries include libraries to manage all sorts
of features of Android, including graphics, databases, encryption, typefaces, and so on. These
libraries work at the same level of the software stack as the core Runtime, but they're
expandable. And so, device makers can add their own libraries to this layer.
The next level is the application framework. And it has modules for controlling all the different
components of your apps. Including activities, which represent the screens that the user sees,
content providers, to manage data and move that data between apps, locations, notifications,
windows, resources, telephone management, and so on. And finally there are the apps. Each
version of Android has been delivered with an expanded set of included apps, but at minimum,
every version of Android has had a home screen, a browser, contact management, phone
management, and a few other things.
As of the most use version of Android, Android 4.4 or Kit-kat, there's a full productivity suite
now included. So more and more new apps are included with each new version of the
operating system, but you can add as many apps to this layer as you want. Once again
including both those apps that you can get from the store, but also the apps that you build
yourself. As a developer, you'll be putting together your apps based on components.
And there are four major types of components that you'll be working with. Activities are the
screens themselves. This is what the users sees. A single activity can either take up an entire
screen or a portion of a screen. As you'll see in the next lesion topic, an activity is represented
by a Java class in your programming, but what the user sees is just an application screen. A
widget is a smaller component. Each widget can be used to manage display and user
interactivity and either to display or to collect data.
But if you take many widgets put together, you end up with a screen. And you'll see how
activities use layouts, and how layouts use widgets. Services are a special kind of component
that perform background jobs. Services, by their nature, are invisible. The user doesn't see
them, but they can run in the background even while the user is running an app in the
foreground. And broadcast receivers can react to system messages. Messages that are
dispatched by the operating system and by other apps.
Each component in an Android app is implemented as a Java class. You'll have both the Java
classes that are included in the SDK, and your own custom Java classes. Here's an example. As
I've previously mentioned, an activity represents a screen or a portion of a screen in an
Android app, and it's an instance of a Java class named android.app.activity. And here's
another example: a button.
When you add a button to a screen, it's because you want the user to be able to touch or click
it. And a button in Android is an instance of a Java class named android.widget.Button. This
just scratches the surface. There are thousands of different Java classes in the Android SDK.
And again you'll be creating your own Java classes to represent the components of your app.
The next topic lession you will learn to create your first application.