Android was designed from the ground up as an operating system (OS) for mobile devices. Its built-in application and memory-management systems were engineered with battery life as one of the most critical concerns.
The Android OS does not work like a desktop operating system. On a desktop OS, like Windows, Mac OS X, or Ubuntu Linux, the user is responsible for closing programs in order to keep a reasonable amount of memory available. On Android, this is not the case. The OS itself automatically removes programs from memory as memory is needed. The OS may also preload applications into memory which it thinks might soon be needed.
Under the Hood of Google Android
The easiest way I can think of to visualize Android's structure is by imagining a house with five rooms
The house represents Android in general. The rooms inside, however, represent the five key features in Android's structure: * Applications * The Application Framework * Libraries * Android Runtime * Linux Kernel.
Now, imagine that each of these rooms hold a certain number of people. Each person represents an element of that room. Different rooms hold different amounts of people.
Applications
This first room is a doozy. It's "people" represent all the applications that you have in Android.
Games, SMS a calendar, maps, a browser, and your contacts. All applications are written in Java ,so you can add or take away as many of these as you like.
The Application Framework
As a developer, you'll have full acces to the APIs used by the core apps. Android is designed so that any application can publish its capabilities. In turn, any other application can use those capabilities, as well. It has some security constraints, as is expected, but still. That's pretty awesome.
Along with all that, you get a Content Provider (which allows apps to share information), a Resource Manager (to help you with graphics, layout files, etc), a Notification Manager