Subscribe to News
Android
Author : Jbuenol
From TechnologicalWiki
Contents |
[edit] What is Android?
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language. In Android there are not differentiate between the phone's basic and third-party applications -- even the dialer or home screen can be replaced.
[edit] Introduction & Concepts
[edit] Features
- Application framework enabling reuse and replacement of components
- Dalvik virtual machine ( WAP Version ) optimized for mobile devices
- Integrated browser based on the open source WebKit engine
- Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
- SQLite for structured data storage
- Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
- GSM Telephony (hardware dependent)
- Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
- Camera, GPS, compass, and accelerometer (hardware dependent)
- Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE
[edit] Android Architecture
The following diagram shows the major components of the Android operating system. Each section is described in more detail below.
- Applications: Basis applications will include a client of email, SMS program, calendar, maps, browser, contacts, and others. All applications will be write in Java.
- Framework Applications: The developers have full access to APIs of the same framework used by applications basis. The architecture is designed to simplify the reuse of components and any application can publish their capabilities and other applications can then use those capabilities (subject to safety rules of the framework). The same mechanism allows the components are replaced by the user.
- Libraries: Android includes a set of libraries C / C + + used by several components of the system Android. These capabilities are exposed to developers through the framework of applications Android.
- Some of them are:
- System C library - a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices
- Media Libraries - based on PacketVideo's OpenCORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
- Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications
- LibWebCore - a modern web browser engine which powers both the Android browser and an embeddable web view
- SGL - the underlying 2D graphics engine
- 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer
- FreeType - bitmap and vector font rendering
- SQLite - a powerful and lightweight relational database engine available to all applications
- Android Runtime : Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language. Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool. The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.
- Linux Kernel : Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.
[edit] Anatomy of an Android Application
There are four building blocks to an Android application:
- Activity
- Intent Receiver
- Service
- Content Provider
Not every application needs to have all four, but your application will be written with some combination of these.
Once you have decided what components you need for your application, you should list them in a file called AndroidManifest.xml. This is an XML file where you declare the components of your application and what their capabilities and requirements are.
[edit] Activity
Activities are the most common of the four Android building blocks. An activity is usually a single screen in your application. Each activity is implemented as a single class that extends the Activity base class. Your class will display a user interface composed of Views and respond to events.
Most applications consist on multiple screens. Moving from one to another screen is accomplished by starting of a new activity. In some cases an activity may return a value to the previous activity --
As an example, a text messaging application has one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact and another screen to review old messages or change settings. Each of these screens have to be implemented as an activity.
When a new screen opens, the previous screen is paused and put onto a history stack. The user can navigate backward through previously opened screens in the history. Screens can also be removed from the history stack when they are inappropriate for them to remain. Android retains history stacks for each application launched from the home screen.
[edit] Intent and Intent Filters
Android uses a special class called an Intent to move from screen to screen. An intent describes what an application wants to do. The two most relevant parts of the intent data structure are the action and the data to act upon. Typical values for action are MAIN (the front door of the application), VIEW, PICK, EDIT, etc. The data is expressed as a URI. For example, to view contact information for a person, you create an intent with the VIEW action and the data set to a URI that represent that person.
There is a related class called an IntentFilter. While an intent is effectively a request to do something, an intent filter is a description of what an activity tries to do (or intent receiver, see below) and is capable of handling. An activity, that is able to display contact information of a person, publish an IntentFilter. This IntentFilter shows how to handle the action VIEW when applied to data representing a person. Activities publish their IntentFilters in the AndroidManifest.xml file.
Navigating from screen to screen is accomplished by resolving intents. To navigate forward, an activity calls startActivity(myIntent). The system then looks at the intent filters of all installed applications and picks the activity which best matches myIntent. The system notifies to the new activity about the intent. So that, the new activity is launched. The process of resolving intents happens at run time when startActivity is called and offers two key benefits:
- Activities can reuse functionality from other components simply by making a request by an Intent.
- Activities can be replaced at any time by a new Activity with an equivalent IntentFilter.
[edit] Intent Receiver
You can use an IntentReceiver when you want code in your application to execute in reaction to an external event, for example, when the phone rings, or when the data network is available, or when it's midnight. Intent receivers do not display a UI, although they may use the NotificationManager to alert the user if something interesting has happened. Intent receivers are registered in AndroidManifest.xml, but you can also register them from code using Context.registerReceiver(). Your application does not have to be running for its intent receivers to be called; the system will start your application, if necessary, when an intent receiver is triggered. Applications can also send their own intent broadcasts to others with Context.broadcastIntent().
[edit] Service
A Service is code that is long-lived and runs without a UI. A good example of this is a media player playing songs from a play list. In a media player application, there would probably be one or more activities that allow the user to choose songs and start playing them. However, the music playback itself should not be handled by an activity because the user will expect the music to keep playing even after navigating to a new screen. In this case, the media player activity could start a service using Context.startService() to run in the background to keep the music going. The system will then keep the music playback service running until it has finished. (You can learn more about the priority given to services in the system by reading Life Cycle of an Android Application.) Note that you can connect to a service (and start it if it's not already running) with the Context.bindService() method. When connected to a service, you can communicate with it through an interface exposed by the service. For the music service, this might allow you to pause, rewind, etc.
[edit] Content Provider
Applications can store their data in files, an SQLite database, or any other mechanism that makes sense. A content provider, however, is useful if you want your application's data to be shared with other applications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.
[edit] Life Cycle of an Android Application
In most cases, every Android application runs in its own Linux process. This process is created for the application when some of its code needs to be run, and will remain running until it is no longer needed and the system needs to reclaim its memory for use by other applications.
An unusual and fundamental feature of Android is that an application process's lifetime is not directly controlled by the application itself. Instead, it is determined by the system through a combination of the parts of the application that the system knows are running, how important these things are to the user, and how much overall memory is available in the system. It is important that application developers understand how different application components (in particular Activity, Service, and IntentReceiver) impact the lifetime of the application's process. Not using these components correctly can result in the system killing the application's process while it is doing important work.
A common example of a process life-cycle bug is an IntentReceiver that starts a thread when it receives an Intent in its onReceiveIntent() method, and then returns from the function. Once it returns, the system considers that IntentReceiver to be no longer active, and thus its hosting process no longer needed (unless other application components are active in it).
Thus, it may kill the process at any time to reclaim memory, terminating the spawned thread that is running in it.
The solution to this problem is to start a Service from the IntentReceiver, so the system knows that there is still active work being done in the process.
To determine which processes should be killed when low on memory, Android places them into an "importance hierarchy" based on the components running in them and the state of those components. These are, in order of importance:
1. A foreground process is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold:
- It is running an Activity at the top of the screen that the user is interacting with (its onResume() method has been called).
- It has an IntentReceiver that is currently running (its IntentReceiver.nReceiveIntent() method is executing).
- It has a Service that is currently executing code in one of its callbacks (Service.onCreate(), Service.onStart(), or Service.onDestroy()).
There will only ever be a few such processes in the system, and these will only be killed as a last resort if memory is so low that not even these processes can continue to run. Generally at this point the device has reached a memory paging state, so this action is required in order to keep the user interface responsive.
2. A visible process is one holding an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground activity has been displayed with a dialog appearance that allows the previous activity to be seen behind it. Such a process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
3. A service process is one holding a Service that has been started with the startService() method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.
4. A background process is one holding an Activity that is not currently visible to the user (its onStop() method has been called). These processes have no direct impact on the user experience. Provided they implement their activity life cycle correctly (see Activity for more details), the system can kill such processes at any time to reclaim memory for one of the three previous processes types. Usually there are many of these processes running, so they are kept in an LRU list to ensure the process that was most recently seen by the user is the last to be killed when running low on memory.
5. An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component of its application needs to run. As such, the system will often kill these processes in order to balance overall system resources between these empty cached processes and the underlying kernel caches.
When deciding how to classify a process, the system picks the most important level of all the components currently active in the process. See the Activity, Service, and IntentReceiver documentation for more detail on how each of these components contribute to the overall life cycle of a process. The documentation for each of these classes describes in more detail how they impact the overall life cycle of their application.
A process's priority may also be increased based on other dependencies a process has to it. For example, if process A has bound to a Service with the Context.BIND_AUTO_CREATE flag or is using a ContentProvider in process B, then process B's classification will always be at least as important as process A's.
[edit] Installing the SDK
After downloading the SDK, unpack the .zip archive to a suitable location on your machine. By default, the SDK files are unpacked into a directory named android_sdk_<platform>_<release>_<build>. The directory contains the subdirectories tools/, samples/, and others.
Make a note of the name and location of the unpacked SDK directory on your system — you will need to refer to the SDK directory later, when setting up the Android plugin or using SDK tools.
Optionally, you can add the path to the SDK tools directory to your path. As mentioned above, the tools/ directory is located in the SDK directory.
- On Linux, edit your ~/.bash_profile or ~/.bashrc file. Look for a line that sets the PATH environment variable and add the full path to the tools/ directory to it. If you don't see a line setting the path, you can add one:
export PATH=${PATH}:<your_sdk_dir>/tools
- On a Mac, look in your home directory for .bash_profile and proceed as for Linux. You can create the .bash_profile, if you haven't already set one up on your machine.
- On Windows, right click on My Computer, and select Properties. Under the Advanced tab, hit the Environment Variables button, and in the dialog that comes up, double-click on Path under System Variables. Add the full path to the tools/ directory to the path.
Adding tools to your path lets you run Android Debug Bridge (adb) and the other command line tools without needing to supply the full path to the tools directory. Note that, if you update your SDK, you should remember to update your PATH settings to point to the new location, if different.
[edit] Options to develop in Android
If you will be using the Eclipse IDE as your environment for developing Android applications, you can install a custom plugin called Android Development Tools (ADT), which adds integrated support for Android projects and tools. The ADT plugin includes a variety of powerful extensions that make creating, running, and debugging Android applications faster and easier.
[edit] How to get started with Android
[edit] Android Community
The Android Community is compound by all types of developers. Exist several groups in which developers can be classified. Beginners, experienced developers and all types of people can find answers to its questions.
| Group - Web Access | Description | Subscribe by email |
|---|---|---|
| android-beginners | New to Android development? Start here. Open to any discussion around beginner-type questions; this is a great way to get up and running with your new App on the Android platform. | android-beginners |
| android-developers | Discuss developing Android applications using the Android framework. Get help with troubleshooting apps, advice on implementation, and strategies for improving your app's speed and user experience. | android-developers |
| android-internals | For "hackers" interested in discussing the innards of Android or exploring its use on various hardware. | android-internals |
| android-challenge | Discuss the Android Developer Challenge, including questions on contest details. You can also seek other developers to join a team effort. | android-challenge |
| android-discuss | The "water cooler" of Android discussion. Free-wheeling discussion from ideas about the Android platform to your announcements on other Android resources. | android-discuss |
http://es.youtube.com/user/androiddevelopers
[edit] Android Developer Challenges
Android Developer Challenge is a competition for the most innovative application for Android. Google offers prizes totaling 10 million US dollars, to be distributed equally between two phases of the competition. The first phase accepted submissions from January 2 to April 14, 2008. The 50 most promising entries, announced on 12 May 2008, each received a $25,000 award to fund further development. Those winners are now eligible for ten $275,000 awards and ten $100,000 awards. The second phase is to launch after the first handsets built on the platform become available in the second half of 2008.
[edit] Hardware & Devices
Google has unveiled at least three prototypes for Android, at the Mobile World Congress on February 12, 2008. One prototype at the ARM booth displayed several basic Google applications. A 'd-pad' controls zooming of items in the dock with a relatively quick response.
A prototype at the Google IO conference on May 28, 2008 had a 528 MHz Qualcomm processor and a Synaptics capacitive touchscreen, and used the UMTS cellular standard. It had 128 MB of RAM and 256 MB of flash. The demo was carried out using a 3.6 Mbit/s HSDPA connection.
[edit] Main Android Projects
- Androidscan - Jeffrey Sharkey Androidscan can process pictures of barcodes into valuable information.
- Beetaun - Sergey Gritsyuk and Dmitri Shipilov
- BioWallet - Jose Luis Huertas Fernandez
- BreadCrumbz - Amos Yoffe - Navigate-by-Pictures: Navigate your route using pictures instead of a map (there's also a map, if you like). Users Create Routes: Easily record routes using your smartphone. Share them with your friends, share them with the world.
- CallACab - Konrad Huebner and Henning Boeger
- City Slikkers - PoroCity Media and Virtual Logic Systems
- Commandro - Alex Pisarev, Andrey Tapekha
- Cooking Capsules - Mary Ann Cotter and Muthuselvam Ramadoss
- Diggin - Daniel Johansson, Aramis Waernbaum, Andreas Hedin
- Dyno - Virachat Boondharigaputra
- e-ventr - Michael Zitzelsberger
- Eco2go - Taneem Talukdar, Gary Pong, Jeff Kao and Robert Lam
- Em-Radar - Jack Kwok
- fingerprint - Robert Mickle
- FreeFamilyWatch - Navee Technologies LLC
- goCart - Rylan Barnes
- GolfPlay - Inizziativa Networks
- gWalk - Prof. Dr.-Ing. Klaus ten Hagen, Christian Klinger, Marko Modsching, Rene Scholze
- HandWx - Weathertop Consulting LLC
- IMEasy - Yan Shi
- Jigsaw - Mikhail Ksenzov
- JOYity - Zelfi AG
- LifeAware - Gregory Moore, Aaron L. Obrien, Jawad Akhtar
- Locale - Clare Bayley, Christina Wright, Jasper Lin, Carter Jernigan
- LReady Emergency Manager - Chris Hulls, Dilpreet Singh, Luis Carvalho, Phuong Nguyen
- Marvin - Pontier Laurent
- Mobeedo - Sengaro GmbH
- Multiple Facets Instant Messenger - Virgil Dobjanschi
- MyCloset - Mamoru Tokashiki
- PedNav - RouteMe2 Technologies Inc.
- Phonebook 2.0 - Voxmobili
- PicSay - Eric Wijngaard
- PiggyBack - Christophe Petit and Sebastien Petit
- Pocket Journey - Anthony Stevens and Rosie Pongracz
- Rayfarla - Stephen Oldmeadow
- Safety Net - Michael DeJadon
- SocialMonster - Ben Siu-Lung Hui and Tommy Ng
- SplashPlay
- Sustain - Keeping Your Social Network Alive - Niraj Swami
- SynchroSpot - Shaun Terry
- Talkplay - Sung Suh Park
- Teradesk - José Augusto Athayde Ferrarini
- The Weather Channel for Android - The Weather Channel Interactive Inc.
- TuneWiki - TuneWiki Inc.
- Wikitude-the Mobile Travel Guide - Philipp Breuss
- Writing Pad - ShapeWriter Inc
