What Android is

What Android is

 

Link: http://www.tbray.org/ongoing/When/201x/2010/11/14/What-Android-Is

Being an unsupported strated run through the basics.

What happened was, for our recent South American tour I wanted an android architecture overview graphic. I ran into SS, among the android SDK documentation, a page entitled What
Is android ?, And it's perfectly OK. Wait t for, I really disliked the picture-On Purely aesthetic grounds, just not my kind of lettering and gradients and layouts-so I decided to make another one.

I thought I 'd run it here and, since I 've been spending a lot of time recently explaining what Android is to people, I thought I 'd provide my version of that as well, in narrative rather than point
Form.

First of all, as Dan Morrill memorably explained in on Android compatibility, "Android is not a specification,
Or a distribution in the traditional Linux sense. It's not a collection of replaceable components. Android is a chunk of software that you port to a device ."

 

 

Linux ·Underneath everything is a reasonably up-to-date Linux kernel (2.6.32 in
My current Nexus One running froyo), with some power-saving extensions we cooked up; the process of trying to merge this stuff into upstream Linux has been extended and public and is by no means over.

Android runs on Linux, but I 'd be nervous about calling it a distro because it leaves out so much that people have CT in one of those:
Libraries and shells and editors and guis and programming frameworks. It's a pretty naked kernel, which becomes obvious the first time you find yourself using a shell on an Android device.

If it were a distro it 'd be one of the higher-volume ones, shipping at 200 K units a day in late 2010. but nobody counts these things, and then there are a ton of embedded flavors of Linux Shipping
In unremarkable pieces of consumer electronics, so there's a refreshing absence of anyone claiming to be "the most popular Linux". I like that.

Dalvik ·
The next big piece is Dalvik, comprising the VM and a whole bunch of basic runtime essential. Its design is fairly unique, and judging by recent history, seems to be working out pretty well
As a mobile-device app substrate.

All the standard APIs that you use to create Android apps are defined in terms of Dalvik classes and interfaces and objects and methods. In fact, some of them are thin layers of Dalvik code over native
Implementations.

It's possible, and common practice, to call back and forth between Dalvik and native code using the JNI protocol, which is a neat trick
Since what's running on Dalvik isn't anything like Java bytecodes on a Java VM.

How it's generated ·Native code is currently produced more or less exclusively by compiling C or C ++ code; but there's no reason it has
To be that way. Dalvik code is currently produced by generating Java bytecodes and translating them; but there's no reason it has to be that way.

I want to emphasize this point a little. android apps are defined as code that runs on the platform and uses the APIs. as long as an app does these things properly, it's really nobody's concern how
It got generated.

Special apps ·The picture is a little misleading, because some of those Dalvik-based apps are provided by Google and sometimes are seen
As "part of Android ". i'm talking about the Dialer and contacts and calendar and Gmail and chat and so on. most of them are open-source and replaceable (and have been replaced by handset makers); a few are closed-source and proprietary, like Google Maps and
Android Market.

That open-source thing·In the big picture above, most of the stuff in green is Apache-licensed. The rest is a mixture
Of GPL and lgpl and BSD, with some Apache in there too. This excludes some low-level device drivers and of course the majority of non-Google Apps, which are closed-source.

 

 

The framework ·
This is the stuff that uniquely defines android; more or less everything that Google wrote and you wouldn't expect CT to find on a reasonably-configured GNU/Linux box. its proper use is the subject of all the available pages on display at Alibaba .android.com and
Of endless mailing lists, sample sites, and a growing number of books.

I like it; but you already knew that.

 

 

Libraries ·The word "standard" here means "generally available to programmers working in an open-source environment". The picture isn' t
Comprehensive.

Quite a few people, including me, have over-emphasized the role of the harmony libraries. To start with, the android selection excludes lots of stuff,
Example awtand swing and omg corba; all superfluous
For apps using the android framework.

Also, just counting roughly by code bulk of all the sort of stuff in this picture, the harmony Code comprises less than half the total. I don't want to diss harmony, they're a wonderful project and
I'm a huge fan; but it's inaccurate to give the impression that android is just Dalvik plus harmony.

 

 

 

What's in an app? ·
An Android app lives in what's called an APK, which is simply a zip file, with a particle internal file layout that allows it to be run in place, without unpacking. there's nothing magic
About them, you can email them around and drop them on USB keys and extract pieces with unzip.

The android manifest is the interface between an app and the Android system, and that's all I'm going to say here
Because it's a key piece of the puzzle and deserves lengthy discussion if any at all.

The resource bundle contains your audio and video and graphics and so on, the pieces that come with the app as opposed to being fetched over the network.

Native or not ·Most apps these days are written for Dalvik. When I say "Most apps" I mean "everything that isn't a game"; game developers
Typically want to code in C/C ++ and that's it. dalvik offers a nice fast gateway to OpenGL and all the phone's hardware, but game Devs just don't want to hear about virtual machines, so they use the android
Ndk.

If you're writing code in the Java programming language you can use eclipse and a pretty nice toolchain that makes the barrier to entry remarkably low. if you're coding to the ndk, you're going
Be doing a lot of the Build-time machinery yourself and living without some of the Nice debugging and profiling candy, not to mention signing up to port your code to other CPU ubuntures if they run Android and have lots of users. but game developers revel
In pain.

And that's what Android is ·Hope you liked the pictures.

 

Certificate ------------------------------------------------------------------------------------------------------------------------------------

 

English: http://www.lupaworld.com/article-208095-1.html

Good luck!