The Bluetooth Special Interest Group (SIG) said on Wednesday that version 4.0 of the wireless specification may be incorporated into devices by the end of the year. The new spec will bring Bluetooth to a whole new set of gadgets including watches, pedometers, and all other low-power devices that run on coin-cell batteries.
This is a huge step considering that Bluetooth only resided in devices that used triple-A or larger capacity batteries. Michael Foley, executive director of the Bluetooth SIG, said that 4.0 combines both the high-speed data transfer capabilities provided by Bluetooth 3.0 with the new ability to transmit small bursts of data over short ranges.
The IGD News Service reports that Bluetooth 4.0 won't offer users a major improvement in actual battery life-- only a nominal improvement at best. Foley provided an example, saying that Bluetooth 4.0 radios will see the same battery drain as Bluetooth 3.0 radios when used to sync headphones to music players, or to connect smartphones to laptops.
Charles Golvin, principal analyst at Forrester Research, said that Bluetooth 4.0 will be better than the competition because it can be deployed across a wide variety of devices, giving the tech a head start over the other technologies. Unfortunately, the data transfer rate hasn't improved: Bluetooth still shoots data from device to device at a maximum rate of 24Mb/s (BT 3.0 + HS).
http://www.tomshardware.com/news/Blu...sfer,9812.html
Thursday, January 13, 2011
Thursday, January 6, 2011
How to build Android application package (.apk) Manually.
he good thing about building manually your apk is that you don’t have to name your resources directory to res, you can name it anything you want.
You can find ant scripts in:\platforms\android-1.5\templates\android-rules.xml
Step 1: Generate Resource java code and packaged Resources
aapt package -f -M ${manifest.file} -F ${packaged.resource.file} -I ${path.to.android-jar.library} -S ${android-resource-directory} [-m -J ${folder.to.output.the.R.java}]
Step 2: Compile java source codes + R.java
use javac
Step 3: Convert classes to Dalvik bytecodes
use dx.bat
dx.bat –dex –output=${output.dex.file} ${compiled.classes.directory} ${jar files..}
Step 4: Create unsigned APK
use apkbuilder
apkbuilder ${output.apk.file} -u -z ${packagedresource.file} -f ${dex.file}
or
apkbuilder ${output.apk.file} -u -z ${packagedresource.file} -f ${dex.file} -rf ${source.dir} -rj ${libraries.dir}
-rf = resources required for compiled source files?
-rj = resources required for jar files
Step 6: Generate a key
use keytool
Step 7: Sign APK
use jarsigner
jarsigner -keystore ${keystore} -storepass ${keystore.password} -keypass ${keypass} -signedjar ${signed.apkfile} ${unsigned.apkfile} ${keyalias}
Step 8: Publish
use adb
adb -d install -r ${signed.apk}
Inspecting your APK file:
aapt list -v latest.apk
You can find ant scripts in:
Step 1: Generate Resource java code and packaged Resources
aapt package -f -M ${manifest.file} -F ${packaged.resource.file} -I ${path.to.android-jar.library} -S ${android-resource-directory} [-m -J ${folder.to.output.the.R.java}]
Step 2: Compile java source codes + R.java
use javac
Step 3: Convert classes to Dalvik bytecodes
use dx.bat
dx.bat –dex –output=${output.dex.file} ${compiled.classes.directory} ${jar files..}
Step 4: Create unsigned APK
use apkbuilder
apkbuilder ${output.apk.file} -u -z ${packagedresource.file} -f ${dex.file}
or
apkbuilder ${output.apk.file} -u -z ${packagedresource.file} -f ${dex.file} -rf ${source.dir} -rj ${libraries.dir}
-rf = resources required for compiled source files?
-rj = resources required for jar files
Step 6: Generate a key
use keytool
Step 7: Sign APK
use jarsigner
jarsigner -keystore ${keystore} -storepass ${keystore.password} -keypass ${keypass} -signedjar ${signed.apkfile} ${unsigned.apkfile} ${keyalias}
Step 8: Publish
use adb
adb -d install -r ${signed.apk}
Inspecting your APK file:
aapt list -v latest.apk
Tuesday, January 4, 2011
Is Java an Object Oriented Programming Language?
A type of programming in which programmers define not only the data type of a data structure, but also the types of operations (functions) that can be applied to the data structure. In this way, the data structure becomes an object that includes both data and functions. In addition, programmers can create relationships between one object and another. For example, objects can inherit characteristics from other objects.
One of the principal advantages of object-oriented programming techniques over procedural programming techniques is that they enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify.
To perform object-oriented programming, one needs an object-oriented programming language (OOPL). Java, C++ and Smalltalk are three of the more popular languages, and there are also object-oriented versions of Pascal.
In a Simple way ..
As per the definition of Object Oriented Programming, a language can be categorized as PURE OOP based on following criteria:
1.
The language must have inbuilt support for encapsulation and abstraction.
2.
The language must have inbuilt support for Inheritance.
3.
The language must have inbuilt support for Polymorphism.
4.
All system defined types must be objects.
5.
All user defined types must be object.
6.
The only way of communication between objects is through the methods exposed on the same.
Criteria 1 to 3 are self explanatory and don’t require further clarification. So I am escaping those. Now consider criteria 4.
Criteria 4 states that all predefined types in the systems must be objects only. This means there can’t be anything other than objects defined by system. This is the first requirement where Java fails to fulfill the criteria to be categorized as pure Object Oriented Programming. Java has primitive types, which are not objects and thus violates this rule.
Criteria 5 suggests that all user defined types must also be objects only. This means users can’t define or create anything other than objects. This restriction is not applicable in using system defined types. Java successfully follows this rule where user can’t create or define anything other than objects.
Criteria 6 suggest that whenever objects communicate with each other, they communicate using the methods exposed on other objects. And this should be the only way of communication. Java violets this rule by using various operators. Consider the ‘+’ operator on String literals which can be used to add 2 or more string objects. By using this operator java violets the rule of object communication using methods. This holds true for other operators on primitive types as well.
Summing up the above points, java fulfils the criteria 1,2,3,5 but fails in 4 and 6. Failing of these 2 criteria deprived java from being categorized as PURE Object Oriented Programming Language. But still the programming community categorizes Java as OOP (although not Pure). In theory such languages are called ‘Hybrid OOP’ languages.
One of the principal advantages of object-oriented programming techniques over procedural programming techniques is that they enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify.
To perform object-oriented programming, one needs an object-oriented programming language (OOPL). Java, C++ and Smalltalk are three of the more popular languages, and there are also object-oriented versions of Pascal.
In a Simple way ..
As per the definition of Object Oriented Programming, a language can be categorized as PURE OOP based on following criteria:
1.
The language must have inbuilt support for encapsulation and abstraction.
2.
The language must have inbuilt support for Inheritance.
3.
The language must have inbuilt support for Polymorphism.
4.
All system defined types must be objects.
5.
All user defined types must be object.
6.
The only way of communication between objects is through the methods exposed on the same.
Criteria 1 to 3 are self explanatory and don’t require further clarification. So I am escaping those. Now consider criteria 4.
Criteria 4 states that all predefined types in the systems must be objects only. This means there can’t be anything other than objects defined by system. This is the first requirement where Java fails to fulfill the criteria to be categorized as pure Object Oriented Programming. Java has primitive types, which are not objects and thus violates this rule.
Criteria 5 suggests that all user defined types must also be objects only. This means users can’t define or create anything other than objects. This restriction is not applicable in using system defined types. Java successfully follows this rule where user can’t create or define anything other than objects.
Criteria 6 suggest that whenever objects communicate with each other, they communicate using the methods exposed on other objects. And this should be the only way of communication. Java violets this rule by using various operators. Consider the ‘+’ operator on String literals which can be used to add 2 or more string objects. By using this operator java violets the rule of object communication using methods. This holds true for other operators on primitive types as well.
Summing up the above points, java fulfils the criteria 1,2,3,5 but fails in 4 and 6. Failing of these 2 criteria deprived java from being categorized as PURE Object Oriented Programming Language. But still the programming community categorizes Java as OOP (although not Pure). In theory such languages are called ‘Hybrid OOP’ languages.
Tuesday, December 14, 2010
Synergy Steps to Configure
Synegry is a awesome sofware for interacting 2 pc in the network(for eg: linux & windows)
it like your key board & mouse acts same for bothe PC's like host & client.
one we have to make host and second one need to use as client.
Steps you can see from the below like.
http://www.mattcutts.com/blog/how-to-configure-synergy-in-six-steps/
I enjoying a lot using this software. i configured it its working well.
it like your key board & mouse acts same for bothe PC's like host & client.
one we have to make host and second one need to use as client.
Steps you can see from the below like.
http://www.mattcutts.com/blog/how-to-configure-synergy-in-six-steps/
I enjoying a lot using this software. i configured it its working well.
Monday, December 6, 2010
Android 2.3 Platform -GingerBread
For developers, the Android 2.3 platform is available as a downloadable component for the Android SDK. The downloadable platform includes an Android library and system image, as well as a set of emulator skins and more. The downloadable platform includes no external libraries.
API Overview
The sections below provide a technical overview of what's new for developers in 2.3, including new features and changes in the framework API since the previous version.
SIP-based VoIP
The platform now includes a SIP protocol stack and framework API that lets developers build internet telephony applications. Using the API, applications can offer voice calling features without having to manage sessions, transport-level communication, or audio — these are handled transparently by the platform's SIP API and services.
The SIP API is available in the android.net.sip package. The key class is SipManager, which applications use to set up and manage SIP profiles, then initiate audio calls and receive audio calls. Once an audio call is established, applications can mute calls, turn on speaker mode, send DTMF tones, and more. Applications can also use the SipManager to create generic SIP connections.
The platform’s underlying SIP stack and services are available on devices at the discretion of the manufacturer and associated carrier. For this reason, applications should use the isApiSupported() method to check whether SIP support is available, before exposing calling functionality to users.
To use the SIP API, applications must request permission from the user by declaring and
in their manifest files.
Additionally, developers can request filtering on Android Market, such that their applications are not discoverable to users whose devices do not include the platform’s SIP stack and services.
To request filtering,
add and to the application manifest.
Near Field Communications (NFC)
Android 2.3 includes an NFC stack and framework API that lets developers read NDEF tags that are discovered as a user touches an NFC-enabled device to tag elements embedded in stickers, smart posters, and even other devices.
The platform provides the underlying NFC services that work with the device hardware to discover tags when they come into range. On discovering a tag, the platform notifies applications by broadcasting an Intent, appending the tag's NDEF messages to the Intent as extras. Applications can create Intent filters to recognize and handle targeted tags and messages. For example, after receiving a tag by Intent, applications extract the NDEF messages, store them, alert the user, or handle them in other ways.
The NFC API is available in the android.nfc package. The key classes are:
NfcAdapter, which represents the NFC hardware on the device.
NdefMessage, which represents an NDEF data message, the standard format in which "records" carrying data are transmitted between devices and tags. Applications can receive these messages from ACTION_TAG_DISCOVERED Intents.
NdefRecord, delivered in an NdefMessage, which describes the type of data being shared and carries the data itself.
NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers. To determine the NFC support on the current device, applications can call isEnabled() to query the NfcAdapter. The NFC API is always present, however, regardless of underlying hardware support.
To use the NFC API, applications must request permission from the user by declaring in their manifest files.
Additionally, developers can request filtering on Android Market, such that their applications are not discoverable to users whose devices do not support NFC.
To request filtering, add to the application's manifest.
Gyroscope and other sensors
Android 2.3 adds platform and API support for several new sensor reading types — gyroscope, rotation vector, linear acceleration, gravity, and barometer. Developers can use the new sensor readings to create applications that respond quickly and smoothly to precise changes in device position and motion. The Sensor API reports gyroscope and other sensor changes to interested applications, whether they are running on the application framework or in native code.
Note that the specific set of hardware sensors available on any given device varies at the discretion of the device manufacturer.
Developers can request filtering in Android Market, such that their applications are not discoverable to users whose devices do not offer a gyroscope sensor.
To do so, add to the application manifest.
Multiple cameras support
Applications can now make use of any cameras that are available on a device, for either photo or video capture. The Camera lets applications query for the number of cameras available and the unique characteristics of each.
New Camera.CameraInfo class stores a camera's positional characteristics (orientation, front-facing or back-facing).
New getNumberOfCameras(), getCameraInfo(), and getNumberOfCameras() methods in the Camera class let applications query for the cameras available and open the camera that they need.
New get() method lets applications retrieve a CamcorderProfile for a specific camera.
New getJpegEncodingQualityParameter() lets applications obtain the still-image capture quality level for a specific camera.
The Camera API also adds:
New parameters for cameras, including focus distance, focus mode, and preview fps maximum/minimum. New getFocusDistances(), getPreviewFpsRange(), and getSupportedPreviewFpsRange() for getting camera parameters, as well as setPreviewFpsRange() for setting preview framerate.
Mixable audio effects
The platform's media framework adds support for new per-track or global audio effects, including bass boost, headphone virtualization, equalization, and reverb.
New android.media.audiofx package provides the API to access audio effects.
New AudioEffect is the base class for controlling audio effects provided by the Android audio framework.
New audio session ID that lets an application associate a set of audio effects with an instance of AudioTrack or MediaPlayer.
New AudioTrack class constructor that lets you create an AudioTrack with a specific session ID. New attachAuxEffect(), getAudioSessionId(), and setAuxEffectSendLevel() methods.
New attachAuxEffect(), getAudioSessionId(), setAudioSessionId(int), and setAuxEffectSendLevel() methods and supporting types.
The media framework also adds:
New support for altitude tag in EXIF metadata for JPEG files. New method getAltitude() method to retrieve the value of the EXIF altitude tag.
New setOrientationHint() method lets an application tell MediaRecorder of the orientation during video capture.
Download manager
The platform includes a new DownloadManager system service that handles long-running HTTP downloads. Applications can request that a URI be downloaded to a particular destination file. The DownloadManager will conduct the download in the background, taking care of HTTP interactions and retrying downloads after failures or across connectivity changes and system reboots.
Applications can obtain an instance of the DownloadManager class by calling getSystemService(String) and passing DOWNLOAD_SERVICE.
Applications that request downloads through this API should register a broadcast receiver for ACTION_NOTIFICATION_CLICKED, to appropriately handle when the user clicks on a running download in a notification or from the Downloads UI.
The DownloadManager Request class lets an application provide all the information necessary to request a new download, such as request URI and download destination. A request URI is the only required parameter. Note that the default download destination is a shared volume where the system can delete your file if it needs to reclaim space for system use. For persistent storage of a download, specify a download destination on external storage (see setDestinationUri(Uri)).
The DownloadManager.Query class provides methods that let an application query for and filter active downloads.
StrictMode
To help developers monitor and improve the performance of their applications, the platform offers a new system facility called StrictMode. When implemented in an application, StrictMode catches and notifies the developer of accidental disk or network activity that could degrade application performance, such as activity taking place on the application's main thread (where UI operations are received and animations are also taking place). Developers can evaluate the network and disk usages issues raised in StrictMode and correct them if needed, keeping the main thread more responsive and preventing ANR dialogs from being shown to users.
StrictMode is the core class and is the main integration point with the system and VM. The class provides convenience methods for managing the thread and VM policies that apply to the instance.
StrictMode.ThreadPolicy and StrictMode.VmPolicy hold the policies that you define and apply to thread and VM instances.
UI Framework
Support for overscroll
New support for overscroll in Views and Widgets. In Views, applications can enable/disable overscroll for a given view, set the overscoll mode, control the overscroll distance, and handle the results of overscrolling.
In Widgets, applications can control overscroll characteristics such as animation, springback, and overscroll distance. For more information, see android.view.View and android.widget.OverScroller.
ViewConfiguration also provides methods getScaledOverflingDistance() and getScaledOverscrollDistance().
New overScrollMode, overScrollFooter, and overScrollHeader attributes for elements, for controlling overscroll behavior.
Support for touch filtering
New support for touch filtering, which lets an application improve the security of Views that provide access to sensitive functionality. For example, touch filtering is appropriate to ensure the security of user actions such as granting a permission request, making a purchase, or clicking on an advertisement. For details, see the
View class documentation.
New filterTouchesWhenObscured attribute for view elements, which declares whether to filter touches when the view's window is obscured by another visible window. When set to "true", the view will not receive touches whenever a toast, dialog or other window appears above the view's window. Refer to View security documentation for details.
To look at sample code for touch filtering, see SecureView.java in the ApiDemos sample application.
Improved event management
New base class for input events, InputEvent. The class provides methods that let applications determine the meaning of the event, such as by querying for the InputDevice from which the event orginated. The KeyEvent and MotionEvent are subclasses of InputEvent.
New base class for input devices, InputDevice. The class stores information about the capabilities of a particular input device and provides methods that let applications determine how to interpret events from an input device.
Improved motion events
The MotionEvent API is extended to include "pointer ID" information, which lets applications to keep track of individual fingers as they move up and down. The class adds a variety of methods that let an application work efficiently with motion events.
The input system now has logic to generate motion events with the new pointer ID information, synthesizing identifiers as new pointers are down. The system tracks multiple pointer IDs separately during a motion event, and ensures proper continuity of pointers by evaluating at the distance between the last and next set of pointers.
Text selection controls
A new setComposingRegion method lets an application mark a region of text as composing text, maintaining the current styling. A getSelectedText method returns the selected text to the application. The methods are available in BaseInputConnection, InputConnection, and InputConnectionWrapper.
New textSelectHandle, textSelectHandleLeft, textSelectHandleRight, and textSelectHandleWindowStyle attributes for, for referencing drawables that will be used to display text-selection anchors and the style for the containing window.
Activity controls
ActivityInfo adds new constants for managing Activity orientation: SCREEN_ORIENTATION_FULL_SENSOR, SCREEN_ORIENTATION_REVERSE_LANDSCAPE, SCREEN_ORIENTATION_REVERSE_PORTRAIT, SCREEN_ORIENTATION_SENSOR_LANDSCAPE, and SCREEN_ORIENTATION_SENSOR_PORTRAIT.
New constant IMPORTANCE_PERCEPTIBLE for the importance field in ActivityManager.RunningAppProcessInfo. The value indicates that a specific process is running something that is considered to be actively perceptible to the user. An example would be an application performing background music playback.
The setPersistent(boolean) method to mark an Activity as persistent is now deprecated and the implementation is a no-op.
Notification text and icon styles
New TextAppearance.StatusBar.EventContent,
TextAppearance.StatusBar.EventContent.Title, TextAppearance.StatusBar.Icon, and
TextAppearance.StatusBar.Title for managing notification style.
WebView
New setUseWebViewBackgroundForOverscrollBackground() method lets a WebView specify whether to use its own background for the overscroll background.
Extra Large Screens
The platform now supports extra large screen sizes, such as those that might be found on tablet devices. Developers can indicate that their applications are designed to support extra large screen sizes by adding a element to their manifest files. Applications can use a new resource qualifier, xlarge, to tag resources that are specific to extra large screens. For details on how to support extra large and other screen sizes, see Supporting Multiple Screens.
Graphics
Adds remaining OpenGL ES 2.0 methods glDrawElements() and glVertexAttribPointer() in the android.opengl.GLES20 class.
Adds support for YV12 pixel format, a planar 4:2:0 YCrCb format.
Content Providers
New AlarmClock provider class for setting an alarm or handling an alarm. The provider contains a ACTION_SET_ALARM Intent action and extras that can be used to start an Activity to set a new alarm in an alarm clock application. Applications that wish to receive the SET_ALARM Intent should create an activity that requires the the SET_ALARM permission. Applications that wish to create a new alarm should use Context.startActivity(), so that the user has the option of choosing which alarm clock application to use.
MediaStore supports a new Intent action, PLAY_FROM_SEARCH, that lets an application search for music media and automatically play content from the result when possible. For example, an application could fire this Intent as the result of a voice recognition command to listen to music.
MediaStore also adds a new MEDIA_IGNORE_FILENAME flag that tells the media scanner to ignore media in the containing directory and its subdirectories. Developers can use this to avoid having graphics appear in the Gallery and likewise prevent application sounds and music from showing up in the Music app.
The Settings provider adds the new Activity actions APPLICATION_DETAILS_SETTINGS and MANAGE_ALL_APPLICATIONS_SETTINGS, which let an application show the details screen for a specific application or show the Manage Applications screen.
The ContactsContract provider adds the ContactsContract.CommonDataKinds.SipAddress data kind, for storing a contact's SIP (Internet telephony) address.
Location
The LocationManager now tracks application requests that result in wake locks or wifi locks according to WorkSource, a system-managed class that identifies the application.
The LocationManager keeps track of all clients requesting periodic updates, and tells its providers about them as a WorkSource parameter, when setting their minimum update times. The network location provider uses WorkSource to track the wake and wifi locks initiated by an application and adds it to the application's battery usage reported in Manage Applications.
The LocationManager adds several new methods that let an Activity register to receive periodic or one-time location updates based on specified criteria (see below).
A new Criteria class lets an application specify a set of criteria for selecting a location provider. For example, providers may be ordered according to accuracy, power usage, ability to report altitude, speed, and bearing, and monetary cost.
Storage
Android 2.3 adds a new StorageManager that supports OBB (Opaque Binary Blob) files. Although platform support for OBB is available in Android 2.3, development tools for creating and managing OBB files will not be availble until early 2011.
The Android 2.3 platform adds official support for devices that do not include SD cards (although it provides virtual SD Card partition, when no physical SD card is available). A convenience method, isExternalStorageRemovable(), lets applications determine whether a physical SD card is present.
Package Manager
New constants for declaring hardware and software features. See the list in the New Feature Constants section, below.
PackageInfo adds new firstInstallTime and lastUpdateTime fields that store the time of the package installation and last update.
New getProviderInfo() method for retrieving all of the information known about a particular content provider class.
Telephony
The TelephonyManager adds the constant NETWORK_TYPE_EVDO_B for specifying the CDMA EVDO Rev B network type.
New getPsc() method returns the primary scrambling code of the serving cell on a UMTS network.
Native access to Activity lifecycle, windows
Android 2.3 exposes a broad set of APIs to applications that use native code. Framework classes of interest to such applications include:
NativeActivity is a new type of Activity class, whose lifecycle callbacks are implemented directly in native code. A NativeActivity and its underlying native code run in the system just as do other Activities — specifically they run in the Android application's system process and execute on the application's main UI thread, and they receive the same lifecycle callbacks as do other Activities.
New InputQueue class and callback interface lets native code manage event queueing.
New SurfaceHolder.Callback2 interface lets native code manage a SurfaceHolder.
New takeInputQueue and takeSurface() methods in Window let native code manage events and surfaces.
For full information on working with native code or to download the NDK, see the Android NDK page.
Dalvik Runtime
dalvik.system removes several classes that were previously deprecated.
Dalvik core libraries:
New collections: ArrayDeque, NavigableMap, ConcurrentSkipListMap, LinkedBlockingDeque
New Arrays utilities: binarySearch(), copyOf(), copyOfRange(), and others.
CookieManager for HttpURLConnection.
More complete network APIs: InterfaceAddress, NetworkInterface and IDN
File read and write controls
String.isEmpty()
Normalizer and Normalizer.Form
Improved javax.net.ssl server sockets.
New manifest elements and attributes
New xlargeScreens attribute for element, to indicate whether the application supports extra large screen form-factors.
For details, see Supporting
Multiple Screens.
New values for android:screenOrientation attribute of element:
"reverseLandscape" — The Activity would like to have the screen in landscape orientation, turned in the opposite direction from normal landscape.
"reversePortait" — The Activity would like to have the screen in portrait orientation, turned in the opposite direction from normal portrait.
"sensorLandscape" — The Activity would like to have the screen in landscape orientation, but can use the sensor to change which direction the screen is facing.
"sensorPortrait" — The Activity would like to have the screen in portrait orientation, but can use the sensor to change which direction the screen is facing.
"fullSensor" — Orientation is determined by a physical orientation sensor: the display will rotate based on how the user moves the device. This allows any of the 4 possible rotations, regardless of what the device will normally do (for example some devices won't normally use 180 degree rotation).
New Permissions
com.android.permission.SET_ALARM — Allows an application to broadcast an Intent to set an alarm for the user. An Activity that handles the SET_ALARM Intent action should require this permission.
android.permission.USE_SIP — Allows an application to use the SIP API to make or receive internet calls.
android.permission.NFC — Allows an application to use the NFC API to read NFC tags.
New Feature Constants
The platform adds several new hardware features that developers can declare in their application manifests as being required by their applications. This lets developers control how their application is filtered, when published on Android Market.
android.hardware.audio.low_latency — The application uses a low-latency audio pipeline on the device and is sensitive to delays or lag in sound input or output.
android.hardware.camera.front — The application uses a front-facing camera on the device.
android.hardware.nfc — The application uses NFC radio features in the device.
android.hardware.sensor.barometer — The application uses the device's barometer.
android.hardware.sensor.gyroscope — The application uses the device's gyroscope sensor.
android.software.sip — The application uses the SIP API on the device.
android.software.sip.voip — The application uses a SIP-based VoIP service on the device.
android.hardware.touchscreen.multitouch.jazzhand — The application uses advanced multipoint multitouch capabilities on the device screen, for tracking five or more points fully independently.
API Overview
The sections below provide a technical overview of what's new for developers in 2.3, including new features and changes in the framework API since the previous version.
SIP-based VoIP
The platform now includes a SIP protocol stack and framework API that lets developers build internet telephony applications. Using the API, applications can offer voice calling features without having to manage sessions, transport-level communication, or audio — these are handled transparently by the platform's SIP API and services.
The SIP API is available in the android.net.sip package. The key class is SipManager, which applications use to set up and manage SIP profiles, then initiate audio calls and receive audio calls. Once an audio call is established, applications can mute calls, turn on speaker mode, send DTMF tones, and more. Applications can also use the SipManager to create generic SIP connections.
The platform’s underlying SIP stack and services are available on devices at the discretion of the manufacturer and associated carrier. For this reason, applications should use the isApiSupported() method to check whether SIP support is available, before exposing calling functionality to users.
To use the SIP API, applications must request permission from the user by declaring
in their manifest files.
Additionally, developers can request filtering on Android Market, such that their applications are not discoverable to users whose devices do not include the platform’s SIP stack and services.
To request filtering,
add
Near Field Communications (NFC)
Android 2.3 includes an NFC stack and framework API that lets developers read NDEF tags that are discovered as a user touches an NFC-enabled device to tag elements embedded in stickers, smart posters, and even other devices.
The platform provides the underlying NFC services that work with the device hardware to discover tags when they come into range. On discovering a tag, the platform notifies applications by broadcasting an Intent, appending the tag's NDEF messages to the Intent as extras. Applications can create Intent filters to recognize and handle targeted tags and messages. For example, after receiving a tag by Intent, applications extract the NDEF messages, store them, alert the user, or handle them in other ways.
The NFC API is available in the android.nfc package. The key classes are:
NfcAdapter, which represents the NFC hardware on the device.
NdefMessage, which represents an NDEF data message, the standard format in which "records" carrying data are transmitted between devices and tags. Applications can receive these messages from ACTION_TAG_DISCOVERED Intents.
NdefRecord, delivered in an NdefMessage, which describes the type of data being shared and carries the data itself.
NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers. To determine the NFC support on the current device, applications can call isEnabled() to query the NfcAdapter. The NFC API is always present, however, regardless of underlying hardware support.
To use the NFC API, applications must request permission from the user by declaring
Additionally, developers can request filtering on Android Market, such that their applications are not discoverable to users whose devices do not support NFC.
To request filtering, add
Gyroscope and other sensors
Android 2.3 adds platform and API support for several new sensor reading types — gyroscope, rotation vector, linear acceleration, gravity, and barometer. Developers can use the new sensor readings to create applications that respond quickly and smoothly to precise changes in device position and motion. The Sensor API reports gyroscope and other sensor changes to interested applications, whether they are running on the application framework or in native code.
Note that the specific set of hardware sensors available on any given device varies at the discretion of the device manufacturer.
Developers can request filtering in Android Market, such that their applications are not discoverable to users whose devices do not offer a gyroscope sensor.
To do so, add
Multiple cameras support
Applications can now make use of any cameras that are available on a device, for either photo or video capture. The Camera lets applications query for the number of cameras available and the unique characteristics of each.
New Camera.CameraInfo class stores a camera's positional characteristics (orientation, front-facing or back-facing).
New getNumberOfCameras(), getCameraInfo(), and getNumberOfCameras() methods in the Camera class let applications query for the cameras available and open the camera that they need.
New get() method lets applications retrieve a CamcorderProfile for a specific camera.
New getJpegEncodingQualityParameter() lets applications obtain the still-image capture quality level for a specific camera.
The Camera API also adds:
New parameters for cameras, including focus distance, focus mode, and preview fps maximum/minimum. New getFocusDistances(), getPreviewFpsRange(), and getSupportedPreviewFpsRange() for getting camera parameters, as well as setPreviewFpsRange() for setting preview framerate.
Mixable audio effects
The platform's media framework adds support for new per-track or global audio effects, including bass boost, headphone virtualization, equalization, and reverb.
New android.media.audiofx package provides the API to access audio effects.
New AudioEffect is the base class for controlling audio effects provided by the Android audio framework.
New audio session ID that lets an application associate a set of audio effects with an instance of AudioTrack or MediaPlayer.
New AudioTrack class constructor that lets you create an AudioTrack with a specific session ID. New attachAuxEffect(), getAudioSessionId(), and setAuxEffectSendLevel() methods.
New attachAuxEffect(), getAudioSessionId(), setAudioSessionId(int), and setAuxEffectSendLevel() methods and supporting types.
The media framework also adds:
New support for altitude tag in EXIF metadata for JPEG files. New method getAltitude() method to retrieve the value of the EXIF altitude tag.
New setOrientationHint() method lets an application tell MediaRecorder of the orientation during video capture.
Download manager
The platform includes a new DownloadManager system service that handles long-running HTTP downloads. Applications can request that a URI be downloaded to a particular destination file. The DownloadManager will conduct the download in the background, taking care of HTTP interactions and retrying downloads after failures or across connectivity changes and system reboots.
Applications can obtain an instance of the DownloadManager class by calling getSystemService(String) and passing DOWNLOAD_SERVICE.
Applications that request downloads through this API should register a broadcast receiver for ACTION_NOTIFICATION_CLICKED, to appropriately handle when the user clicks on a running download in a notification or from the Downloads UI.
The DownloadManager Request class lets an application provide all the information necessary to request a new download, such as request URI and download destination. A request URI is the only required parameter. Note that the default download destination is a shared volume where the system can delete your file if it needs to reclaim space for system use. For persistent storage of a download, specify a download destination on external storage (see setDestinationUri(Uri)).
The DownloadManager.Query class provides methods that let an application query for and filter active downloads.
StrictMode
To help developers monitor and improve the performance of their applications, the platform offers a new system facility called StrictMode. When implemented in an application, StrictMode catches and notifies the developer of accidental disk or network activity that could degrade application performance, such as activity taking place on the application's main thread (where UI operations are received and animations are also taking place). Developers can evaluate the network and disk usages issues raised in StrictMode and correct them if needed, keeping the main thread more responsive and preventing ANR dialogs from being shown to users.
StrictMode is the core class and is the main integration point with the system and VM. The class provides convenience methods for managing the thread and VM policies that apply to the instance.
StrictMode.ThreadPolicy and StrictMode.VmPolicy hold the policies that you define and apply to thread and VM instances.
UI Framework
Support for overscroll
New support for overscroll in Views and Widgets. In Views, applications can enable/disable overscroll for a given view, set the overscoll mode, control the overscroll distance, and handle the results of overscrolling.
In Widgets, applications can control overscroll characteristics such as animation, springback, and overscroll distance. For more information, see android.view.View and android.widget.OverScroller.
ViewConfiguration also provides methods getScaledOverflingDistance() and getScaledOverscrollDistance().
New overScrollMode, overScrollFooter, and overScrollHeader attributes for
Support for touch filtering
New support for touch filtering, which lets an application improve the security of Views that provide access to sensitive functionality. For example, touch filtering is appropriate to ensure the security of user actions such as granting a permission request, making a purchase, or clicking on an advertisement. For details, see the
View class documentation.
New filterTouchesWhenObscured attribute for view elements, which declares whether to filter touches when the view's window is obscured by another visible window. When set to "true", the view will not receive touches whenever a toast, dialog or other window appears above the view's window. Refer to View security documentation for details.
To look at sample code for touch filtering, see SecureView.java in the ApiDemos sample application.
Improved event management
New base class for input events, InputEvent. The class provides methods that let applications determine the meaning of the event, such as by querying for the InputDevice from which the event orginated. The KeyEvent and MotionEvent are subclasses of InputEvent.
New base class for input devices, InputDevice. The class stores information about the capabilities of a particular input device and provides methods that let applications determine how to interpret events from an input device.
Improved motion events
The MotionEvent API is extended to include "pointer ID" information, which lets applications to keep track of individual fingers as they move up and down. The class adds a variety of methods that let an application work efficiently with motion events.
The input system now has logic to generate motion events with the new pointer ID information, synthesizing identifiers as new pointers are down. The system tracks multiple pointer IDs separately during a motion event, and ensures proper continuity of pointers by evaluating at the distance between the last and next set of pointers.
Text selection controls
A new setComposingRegion method lets an application mark a region of text as composing text, maintaining the current styling. A getSelectedText method returns the selected text to the application. The methods are available in BaseInputConnection, InputConnection, and InputConnectionWrapper.
New textSelectHandle, textSelectHandleLeft, textSelectHandleRight, and textSelectHandleWindowStyle attributes for
Activity controls
ActivityInfo adds new constants for managing Activity orientation: SCREEN_ORIENTATION_FULL_SENSOR, SCREEN_ORIENTATION_REVERSE_LANDSCAPE, SCREEN_ORIENTATION_REVERSE_PORTRAIT, SCREEN_ORIENTATION_SENSOR_LANDSCAPE, and SCREEN_ORIENTATION_SENSOR_PORTRAIT.
New constant IMPORTANCE_PERCEPTIBLE for the importance field in ActivityManager.RunningAppProcessInfo. The value indicates that a specific process is running something that is considered to be actively perceptible to the user. An example would be an application performing background music playback.
The setPersistent(boolean) method to mark an Activity as persistent is now deprecated and the implementation is a no-op.
Notification text and icon styles
New TextAppearance.StatusBar.EventContent,
TextAppearance.StatusBar.EventContent.Title, TextAppearance.StatusBar.Icon, and
TextAppearance.StatusBar.Title for managing notification style.
WebView
New setUseWebViewBackgroundForOverscrollBackground() method lets a WebView specify whether to use its own background for the overscroll background.
Extra Large Screens
The platform now supports extra large screen sizes, such as those that might be found on tablet devices. Developers can indicate that their applications are designed to support extra large screen sizes by adding a
Graphics
Adds remaining OpenGL ES 2.0 methods glDrawElements() and glVertexAttribPointer() in the android.opengl.GLES20 class.
Adds support for YV12 pixel format, a planar 4:2:0 YCrCb format.
Content Providers
New AlarmClock provider class for setting an alarm or handling an alarm. The provider contains a ACTION_SET_ALARM Intent action and extras that can be used to start an Activity to set a new alarm in an alarm clock application. Applications that wish to receive the SET_ALARM Intent should create an activity that requires the the SET_ALARM permission. Applications that wish to create a new alarm should use Context.startActivity(), so that the user has the option of choosing which alarm clock application to use.
MediaStore supports a new Intent action, PLAY_FROM_SEARCH, that lets an application search for music media and automatically play content from the result when possible. For example, an application could fire this Intent as the result of a voice recognition command to listen to music.
MediaStore also adds a new MEDIA_IGNORE_FILENAME flag that tells the media scanner to ignore media in the containing directory and its subdirectories. Developers can use this to avoid having graphics appear in the Gallery and likewise prevent application sounds and music from showing up in the Music app.
The Settings provider adds the new Activity actions APPLICATION_DETAILS_SETTINGS and MANAGE_ALL_APPLICATIONS_SETTINGS, which let an application show the details screen for a specific application or show the Manage Applications screen.
The ContactsContract provider adds the ContactsContract.CommonDataKinds.SipAddress data kind, for storing a contact's SIP (Internet telephony) address.
Location
The LocationManager now tracks application requests that result in wake locks or wifi locks according to WorkSource, a system-managed class that identifies the application.
The LocationManager keeps track of all clients requesting periodic updates, and tells its providers about them as a WorkSource parameter, when setting their minimum update times. The network location provider uses WorkSource to track the wake and wifi locks initiated by an application and adds it to the application's battery usage reported in Manage Applications.
The LocationManager adds several new methods that let an Activity register to receive periodic or one-time location updates based on specified criteria (see below).
A new Criteria class lets an application specify a set of criteria for selecting a location provider. For example, providers may be ordered according to accuracy, power usage, ability to report altitude, speed, and bearing, and monetary cost.
Storage
Android 2.3 adds a new StorageManager that supports OBB (Opaque Binary Blob) files. Although platform support for OBB is available in Android 2.3, development tools for creating and managing OBB files will not be availble until early 2011.
The Android 2.3 platform adds official support for devices that do not include SD cards (although it provides virtual SD Card partition, when no physical SD card is available). A convenience method, isExternalStorageRemovable(), lets applications determine whether a physical SD card is present.
Package Manager
New constants for declaring hardware and software features. See the list in the New Feature Constants section, below.
PackageInfo adds new firstInstallTime and lastUpdateTime fields that store the time of the package installation and last update.
New getProviderInfo() method for retrieving all of the information known about a particular content provider class.
Telephony
The TelephonyManager adds the constant NETWORK_TYPE_EVDO_B for specifying the CDMA EVDO Rev B network type.
New getPsc() method returns the primary scrambling code of the serving cell on a UMTS network.
Native access to Activity lifecycle, windows
Android 2.3 exposes a broad set of APIs to applications that use native code. Framework classes of interest to such applications include:
NativeActivity is a new type of Activity class, whose lifecycle callbacks are implemented directly in native code. A NativeActivity and its underlying native code run in the system just as do other Activities — specifically they run in the Android application's system process and execute on the application's main UI thread, and they receive the same lifecycle callbacks as do other Activities.
New InputQueue class and callback interface lets native code manage event queueing.
New SurfaceHolder.Callback2 interface lets native code manage a SurfaceHolder.
New takeInputQueue and takeSurface() methods in Window let native code manage events and surfaces.
For full information on working with native code or to download the NDK, see the Android NDK page.
Dalvik Runtime
dalvik.system removes several classes that were previously deprecated.
Dalvik core libraries:
New collections: ArrayDeque, NavigableMap, ConcurrentSkipListMap, LinkedBlockingDeque
New Arrays utilities: binarySearch(), copyOf(), copyOfRange(), and others.
CookieManager for HttpURLConnection.
More complete network APIs: InterfaceAddress, NetworkInterface and IDN
File read and write controls
String.isEmpty()
Normalizer and Normalizer.Form
Improved javax.net.ssl server sockets.
New manifest elements and attributes
New xlargeScreens attribute for
For details, see Supporting
Multiple Screens.
New values for android:screenOrientation attribute of
"reverseLandscape" — The Activity would like to have the screen in landscape orientation, turned in the opposite direction from normal landscape.
"reversePortait" — The Activity would like to have the screen in portrait orientation, turned in the opposite direction from normal portrait.
"sensorLandscape" — The Activity would like to have the screen in landscape orientation, but can use the sensor to change which direction the screen is facing.
"sensorPortrait" — The Activity would like to have the screen in portrait orientation, but can use the sensor to change which direction the screen is facing.
"fullSensor" — Orientation is determined by a physical orientation sensor: the display will rotate based on how the user moves the device. This allows any of the 4 possible rotations, regardless of what the device will normally do (for example some devices won't normally use 180 degree rotation).
New Permissions
com.android.permission.SET_ALARM — Allows an application to broadcast an Intent to set an alarm for the user. An Activity that handles the SET_ALARM Intent action should require this permission.
android.permission.USE_SIP — Allows an application to use the SIP API to make or receive internet calls.
android.permission.NFC — Allows an application to use the NFC API to read NFC tags.
New Feature Constants
The platform adds several new hardware features that developers can declare in their application manifests as being required by their applications. This lets developers control how their application is filtered, when published on Android Market.
android.hardware.audio.low_latency — The application uses a low-latency audio pipeline on the device and is sensitive to delays or lag in sound input or output.
android.hardware.camera.front — The application uses a front-facing camera on the device.
android.hardware.nfc — The application uses NFC radio features in the device.
android.hardware.sensor.barometer — The application uses the device's barometer.
android.hardware.sensor.gyroscope — The application uses the device's gyroscope sensor.
android.software.sip — The application uses the SIP API on the device.
android.software.sip.voip — The application uses a SIP-based VoIP service on the device.
android.hardware.touchscreen.multitouch.jazzhand — The application uses advanced multipoint multitouch capabilities on the device screen, for tracking five or more points fully independently.
Android 2.3 Platform Highlights
The Android 2.3 platform introduces many new and exciting features for users and developers. This document provides a glimpse at some of the new features and technologies in Android 2.3. For detailed information about the new developer APIs, see the Android 2.3 version notes.
New User Features
New Developer Features
New Platform Technologies
New User Features
UI refinements for simplicity and speed
The user interface is refined in many ways across the system, making it easier to learn, faster to use, and more power-efficient. A simplified visual theme of colors against black brings vividness and contrast to the notification bar, menus, and other parts of the UI. Changes in menus and settings make it easier for the user to navigate and control the features of the system and device.
Faster, more intuitive text input
The Android soft keyboard is redesigned and optimized for faster text input and editing. The keys themselves are reshaped and repositioned for improved targeting, making them easier to see and press accurately, even at high speeds. The keyboard also displays the current character and dictionary suggestions in a larger, more vivid style that is easier to read.
The keyboard adds the capability to correct entered words from suggestions in the dictionary. As the user selects a word already entered, the keyboard displays suggestions that the user can choose from, to replace the selection. The user can also switch to voice input mode to replace the selection. Smart suggestions let the user accept a suggestion and then return to correct it later, if needed, from the original set of suggestions.
New multitouch key-chording lets the user quickly enter numbers and symbols by pressing Shift+ and ?123+, without needing to manually switch input modes. From certain keys, users can also access a popup menu of accented characters, numbers, and symbols by holding the key and sliding to select a character.
One-touch word selection and copy/paste
When entering text or viewing a web page, the user can quickly select a word by press-hold, then copy to the clipboard and paste. Pressing on a word enters a free-selection mode — the user can adjust the selection area as needed by dragging a set of bounding arrows to new positions, then copy the bounded area by pressing anywhere in the selection area. For text entry, the user can slide-press to enter a cursor mode, then reposition the cursor easily and accurately by dragging the cursor arrow. With both the selection and cursor modes, no use of a trackball is needed.
Improved power management
The Android system takes a more active role in managing apps that are keeping the device awake for too long or that are consuming CPU while running in the background. By managing such apps — closing them if appropriate — the system helps ensure best possible performance and maximum battery life.
The system also gives the user more visibility over the power being consumed by system components and running apps. The Application settings provides an accurate overview of how the battery is being used, with details of the usage and relative power consumed by each component or application.
Control over applications
A shortcut to the Manage Applications control now appears in the Options Menu in the Home screen and Launcher, making it much easier to check and manage application activity. Once the user enters Manage Applications, a new Running tab displays a list of active applications and the storage and memory being used by each. The user can read further details about each application and if necessary stop an application or report feedback to its developer.
New ways of communicating, organizing
An updated set of standard applications lets the user take new approaches to managing information and relationships.
Internet calling
The user can make voice calls over the internet to other users who have SIP accounts. The user can add an internet calling number (a SIP address) to any Contact and can initiate a call from Quick Contact or Dialer. To use internet calling, the user must create an account at the SIP provider of their choice — SIP accounts are not provided as part of the internet calling feature. Additionally, support for the platform's SIP and internet calling features on specific devices is determined by their manufacturers and associated carriers.
Near-field communications
An NFC Reader application lets the user read and interact with near-field communication (NFC) tags. For example, the user can “touch” or “swipe” an NFC tag that might be embedded in a poster, sticker, or advertisement, then act on the data read from the tag. A typical use would be to read a tag at a restaurant, store, or event and then rate or register by jumping to a web site whose URL is included in the tag data. NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers.
Downloads management
The Downloads application gives the user easy access to any file downloaded from the browser, email, or another application. Downloads is built on an completely new download manager facility in the system that any other applications can use, to more easily manage and store their downloads.
Camera
The application now lets the user access multiple cameras on the device, including a front-facing camera, if available.
New Developer Features
Android 2.3 delivers a variety of features and APIs that let developers bring new types of applications to the Android platform.
Enhancements for gaming
New forms of communication
Rich multimedia
Enhancements for gaming
Performance
Android 2.3 includes a variety of improvements across the system that make common operations faster and more efficient for all applications. Of particular interest to game developers are:
Concurrent garbage collector — The Dalivik VM introduces a new, concurrent garbage collector that minimizes application pauses, helping to ensure smoother animation and increased responsiveness in games and similar applications.
Faster event distribution — The plaform now handles touch and keyboard events faster and more efficiently, minimizing CPU utilization during event distribution. The changes improve responsiveness for all applications, but especially benefit games that use touch events in combination with 3D graphics or other CPU-intensive operations.
Updated video drivers — The platform uses updated third-party video drivers that improve the efficiency of OpenGL ES operations, for faster overall 3D graphics performance.
Native input and sensor events
Applications that use native code can now receive and process input and sensor events directly in their native code, which dramatically improves efficiency and responsiveness.
Native libraries exposed by the platform let applications handle the same types of input events as those available through the framework. Applications can receive events from all supported sensor types and can enable/disable specific sensors and manage event delivery rate and queueing.
Gyroscope and other new sensors, for improved 3D motion processing
Android 2.3 adds API support for several new sensor types, including gyroscope, rotation vector, linear acceleration, gravity, and barometer sensors. Applications can use the new sensors in combination with any other sensors available on the device, to track three-dimensional device motion and orientation change with high precision and accuracy. For example, a game application could use readings from a gyroscope and accelerometer on the device to recognize complex user gestures and motions, such as tilt, spin, thrust, and slice.
Open API for native audio
The platform provides a software implementation of Khronos OpenSL ES, a standard API that gives applications access to powerful audio controls and effects from native code. Applications can use the API to manage audio devices and control audio input, output, and processing directly from native code.
Native graphics management
The platform provides an interface to its Khronos EGL library, which lets applications manage graphics contexts and create and manage OpenGL ES textures and surfaces from native code.
Native access to Activity lifecycle, window management
Native applications can declare a new type of Activity class, NativeActivity whose lifecycle callbacks are implemented directly in native code. The NativeActivity and its underlying native code run in the system just as do other Activities — they run in the application's system process and execute on the application's main UI thread, and they receive the same lifecycle callbacks as do other Activities.
The platform also exposes native APIs for managing windows, including the ability to lock/unlock the pixel buffer to draw directly into it. Through the API, applications can obtain a native window object associated with a framework Surface object and interact with it directly in native code.
Native access to assets, storage
Applications can now access a native Asset Manager API to retrieve application assets directly from native code without needing to go through JNI. If the assets are compressed, the platform does streaming decompression as the application reads the asset data. There is no longer a limit on the size of compressed .apk assets that can be read.
Additionally, applications can access a native Storage Manager API to work directly with OBB files downloaded and managed by the system. Note that although platform support for OBB is available in Android 2.3, development tools for creating and managing OBB files will not be available until early 2011.
Robust native development environment
The Android NDK (r5 or higher) provides a complete set of tools, toolchains, and libraries for developing applications that use the rich native environment offered by the Android 2.3 platform. For more information or to download the NDK, please see the Android NDK page.
New forms of communication
Internet telephony
Developers can now add SIP-based internet telephony features to their applications. Android 2.3 includes a full SIP protocol stack and integrated call management services that let applications easily set up outgoing and incoming voice calls, without having to manage sessions, transport-level communication, or audio record or playback directly.
Support for the platform's SIP and internet calling features on specific devices is determined by their manufacturers and associated carriers.
Near Field Communications (NFC)
The platform's support for Near Field Communications (NFC) lets developers get started creating a whole new class of applications for Android. Developers can create new applications that offer proximity-based information and services to users, organizations, merchants, and advertisers.
Using the NFC API, applications can respond to NFC tags “discovered” as the user “touches” an NFC-enabled device to elements embedded in stickers, smart posters, and even other devices. When a tag of interest is collected, applications can respond to the tag, read messages from it, and then store the messages, prompting the user as needed.
NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers.
Rich multimedia
Mixable audio effects
A new audio effects API lets developers easily create rich audio environments by adding equalization, bass boost, headphone virtualization (widened soundstage), and reverb to audio tracks and sounds. Developers can mix multiple audio effects in a local track or apply effects globally, across multiple tracks.
Support for new media formats
The platform now offers built-in support for the VP8 open video compression format and the WebM open container format. The platform also adds support for AAC encoding and AMR wideband encoding (in software), so that applications can capture higher quality audio than narrowband.
Access to multiple cameras
The Camera API now lets developers access any cameras that are available on a device, including a front-facing camera. Applications can query the platform for the number of cameras on the device and their types and characteristics, then open the camera needed. For example, a video chat application might want to access a front-facing camera that offers lower-resolution, while a photo application might prefer a back-facing camera that offers higher-resolution.
New Platform Technologies
Media Framework
New media framework fully replaces OpenCore, maintaining all previous codec/container support for encoding and decoding.
Integrated support for the VP8 open video compression format and the WebM open container format
Adds AAC encoding and AMR wideband encoding
Linux Kernel
Upgraded to 2.6.35
Networking
SIP stack, configurable by device manufacturer
Support for Near Field Communications (NFC), configurable by device manufacturer
Updated BlueZ stack
Dalvik runtime
Dalvik VM:
Concurrent garbage collector (target sub-3ms pauses)
Adds further JIT (code-generation) optimizations
Improved code verification
StrictMode debugging, for identifying performance and memory issues
Core libraries:
Expanded I18N support (full worldwide encodings, more locales)
Faster Formatter and number formatting. For example, float formatting is 2.5x faster.
HTTP responses are gzipped by default. XML and JSON API response sizes may be reduced by 60% or more.
New collections and utilities APIs
Improved network APIs
Improved file read and write controls
Updated JDBC
Updates from upstream projects:
OpenSSL 1.0.0a
BouncyCastle 1.45
ICU 4.4
zlib 1.2.5
New User Features
New Developer Features
New Platform Technologies
New User Features
UI refinements for simplicity and speed
The user interface is refined in many ways across the system, making it easier to learn, faster to use, and more power-efficient. A simplified visual theme of colors against black brings vividness and contrast to the notification bar, menus, and other parts of the UI. Changes in menus and settings make it easier for the user to navigate and control the features of the system and device.
Faster, more intuitive text input
The Android soft keyboard is redesigned and optimized for faster text input and editing. The keys themselves are reshaped and repositioned for improved targeting, making them easier to see and press accurately, even at high speeds. The keyboard also displays the current character and dictionary suggestions in a larger, more vivid style that is easier to read.
The keyboard adds the capability to correct entered words from suggestions in the dictionary. As the user selects a word already entered, the keyboard displays suggestions that the user can choose from, to replace the selection. The user can also switch to voice input mode to replace the selection. Smart suggestions let the user accept a suggestion and then return to correct it later, if needed, from the original set of suggestions.
New multitouch key-chording lets the user quickly enter numbers and symbols by pressing Shift+
One-touch word selection and copy/paste
When entering text or viewing a web page, the user can quickly select a word by press-hold, then copy to the clipboard and paste. Pressing on a word enters a free-selection mode — the user can adjust the selection area as needed by dragging a set of bounding arrows to new positions, then copy the bounded area by pressing anywhere in the selection area. For text entry, the user can slide-press to enter a cursor mode, then reposition the cursor easily and accurately by dragging the cursor arrow. With both the selection and cursor modes, no use of a trackball is needed.
Improved power management
The Android system takes a more active role in managing apps that are keeping the device awake for too long or that are consuming CPU while running in the background. By managing such apps — closing them if appropriate — the system helps ensure best possible performance and maximum battery life.
The system also gives the user more visibility over the power being consumed by system components and running apps. The Application settings provides an accurate overview of how the battery is being used, with details of the usage and relative power consumed by each component or application.
Control over applications
A shortcut to the Manage Applications control now appears in the Options Menu in the Home screen and Launcher, making it much easier to check and manage application activity. Once the user enters Manage Applications, a new Running tab displays a list of active applications and the storage and memory being used by each. The user can read further details about each application and if necessary stop an application or report feedback to its developer.
New ways of communicating, organizing
An updated set of standard applications lets the user take new approaches to managing information and relationships.
Internet calling
The user can make voice calls over the internet to other users who have SIP accounts. The user can add an internet calling number (a SIP address) to any Contact and can initiate a call from Quick Contact or Dialer. To use internet calling, the user must create an account at the SIP provider of their choice — SIP accounts are not provided as part of the internet calling feature. Additionally, support for the platform's SIP and internet calling features on specific devices is determined by their manufacturers and associated carriers.
Near-field communications
An NFC Reader application lets the user read and interact with near-field communication (NFC) tags. For example, the user can “touch” or “swipe” an NFC tag that might be embedded in a poster, sticker, or advertisement, then act on the data read from the tag. A typical use would be to read a tag at a restaurant, store, or event and then rate or register by jumping to a web site whose URL is included in the tag data. NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers.
Downloads management
The Downloads application gives the user easy access to any file downloaded from the browser, email, or another application. Downloads is built on an completely new download manager facility in the system that any other applications can use, to more easily manage and store their downloads.
Camera
The application now lets the user access multiple cameras on the device, including a front-facing camera, if available.
New Developer Features
Android 2.3 delivers a variety of features and APIs that let developers bring new types of applications to the Android platform.
Enhancements for gaming
New forms of communication
Rich multimedia
Enhancements for gaming
Performance
Android 2.3 includes a variety of improvements across the system that make common operations faster and more efficient for all applications. Of particular interest to game developers are:
Concurrent garbage collector — The Dalivik VM introduces a new, concurrent garbage collector that minimizes application pauses, helping to ensure smoother animation and increased responsiveness in games and similar applications.
Faster event distribution — The plaform now handles touch and keyboard events faster and more efficiently, minimizing CPU utilization during event distribution. The changes improve responsiveness for all applications, but especially benefit games that use touch events in combination with 3D graphics or other CPU-intensive operations.
Updated video drivers — The platform uses updated third-party video drivers that improve the efficiency of OpenGL ES operations, for faster overall 3D graphics performance.
Native input and sensor events
Applications that use native code can now receive and process input and sensor events directly in their native code, which dramatically improves efficiency and responsiveness.
Native libraries exposed by the platform let applications handle the same types of input events as those available through the framework. Applications can receive events from all supported sensor types and can enable/disable specific sensors and manage event delivery rate and queueing.
Gyroscope and other new sensors, for improved 3D motion processing
Android 2.3 adds API support for several new sensor types, including gyroscope, rotation vector, linear acceleration, gravity, and barometer sensors. Applications can use the new sensors in combination with any other sensors available on the device, to track three-dimensional device motion and orientation change with high precision and accuracy. For example, a game application could use readings from a gyroscope and accelerometer on the device to recognize complex user gestures and motions, such as tilt, spin, thrust, and slice.
Open API for native audio
The platform provides a software implementation of Khronos OpenSL ES, a standard API that gives applications access to powerful audio controls and effects from native code. Applications can use the API to manage audio devices and control audio input, output, and processing directly from native code.
Native graphics management
The platform provides an interface to its Khronos EGL library, which lets applications manage graphics contexts and create and manage OpenGL ES textures and surfaces from native code.
Native access to Activity lifecycle, window management
Native applications can declare a new type of Activity class, NativeActivity whose lifecycle callbacks are implemented directly in native code. The NativeActivity and its underlying native code run in the system just as do other Activities — they run in the application's system process and execute on the application's main UI thread, and they receive the same lifecycle callbacks as do other Activities.
The platform also exposes native APIs for managing windows, including the ability to lock/unlock the pixel buffer to draw directly into it. Through the API, applications can obtain a native window object associated with a framework Surface object and interact with it directly in native code.
Native access to assets, storage
Applications can now access a native Asset Manager API to retrieve application assets directly from native code without needing to go through JNI. If the assets are compressed, the platform does streaming decompression as the application reads the asset data. There is no longer a limit on the size of compressed .apk assets that can be read.
Additionally, applications can access a native Storage Manager API to work directly with OBB files downloaded and managed by the system. Note that although platform support for OBB is available in Android 2.3, development tools for creating and managing OBB files will not be available until early 2011.
Robust native development environment
The Android NDK (r5 or higher) provides a complete set of tools, toolchains, and libraries for developing applications that use the rich native environment offered by the Android 2.3 platform. For more information or to download the NDK, please see the Android NDK page.
New forms of communication
Internet telephony
Developers can now add SIP-based internet telephony features to their applications. Android 2.3 includes a full SIP protocol stack and integrated call management services that let applications easily set up outgoing and incoming voice calls, without having to manage sessions, transport-level communication, or audio record or playback directly.
Support for the platform's SIP and internet calling features on specific devices is determined by their manufacturers and associated carriers.
Near Field Communications (NFC)
The platform's support for Near Field Communications (NFC) lets developers get started creating a whole new class of applications for Android. Developers can create new applications that offer proximity-based information and services to users, organizations, merchants, and advertisers.
Using the NFC API, applications can respond to NFC tags “discovered” as the user “touches” an NFC-enabled device to elements embedded in stickers, smart posters, and even other devices. When a tag of interest is collected, applications can respond to the tag, read messages from it, and then store the messages, prompting the user as needed.
NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers.
Rich multimedia
Mixable audio effects
A new audio effects API lets developers easily create rich audio environments by adding equalization, bass boost, headphone virtualization (widened soundstage), and reverb to audio tracks and sounds. Developers can mix multiple audio effects in a local track or apply effects globally, across multiple tracks.
Support for new media formats
The platform now offers built-in support for the VP8 open video compression format and the WebM open container format. The platform also adds support for AAC encoding and AMR wideband encoding (in software), so that applications can capture higher quality audio than narrowband.
Access to multiple cameras
The Camera API now lets developers access any cameras that are available on a device, including a front-facing camera. Applications can query the platform for the number of cameras on the device and their types and characteristics, then open the camera needed. For example, a video chat application might want to access a front-facing camera that offers lower-resolution, while a photo application might prefer a back-facing camera that offers higher-resolution.
New Platform Technologies
Media Framework
New media framework fully replaces OpenCore, maintaining all previous codec/container support for encoding and decoding.
Integrated support for the VP8 open video compression format and the WebM open container format
Adds AAC encoding and AMR wideband encoding
Linux Kernel
Upgraded to 2.6.35
Networking
SIP stack, configurable by device manufacturer
Support for Near Field Communications (NFC), configurable by device manufacturer
Updated BlueZ stack
Dalvik runtime
Dalvik VM:
Concurrent garbage collector (target sub-3ms pauses)
Adds further JIT (code-generation) optimizations
Improved code verification
StrictMode debugging, for identifying performance and memory issues
Core libraries:
Expanded I18N support (full worldwide encodings, more locales)
Faster Formatter and number formatting. For example, float formatting is 2.5x faster.
HTTP responses are gzipped by default. XML and JSON API response sizes may be reduced by 60% or more.
New collections and utilities APIs
Improved network APIs
Improved file read and write controls
Updated JDBC
Updates from upstream projects:
OpenSSL 1.0.0a
BouncyCastle 1.45
ICU 4.4
zlib 1.2.5
Tuesday, November 30, 2010
android.view.WindowManager$BadTokenException & Android – Displaying Dialogs From Background Threads
Having threads to do some heavy lifting and long processing in the background is pretty standard stuff. Very often you would want to notify or prompt the user after the background task has finished by displaying a Dialog.
The displaying of the Dialog has to happen on the UI thread, so you would do that either in the Handler object for the thread or in the onPostExecute method of an AsyncTask (which is a thread as well, just an easier way of implementing it). That is a textbook way of doing this and you would think that pretty much nothing wrong could go with this.
Surprisingly I found out that something CAN actually go wrong with this. After Google updated the Android Market and started giving crash reports to the developers I received the following exception:
android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
at android.view.ViewRoot.setView(ViewRoot.java:468)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:177)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
at android.view.Window$LocalWindowManager.addView(Window.java:424)
at android.app.Dialog.show(Dialog.java:239)
at android.app.Activity.showDialog(Activity.java:2488)
…
at android.os.Handler.dispatchMessage(Handler.java:99)
…
I only got a couple of these exceptions from thousands of installs, so I knew that was not anything that happens regularly or that it was easy to replicate.
Looking at the stack trace above it gives us a pretty good idea why it failed. It started in the Handler object, which naturally was called by a background thread after it finished its processing. The Handler instance tried to show a Dialog and before it could show it, it tried to set the View for it and then it failed with:
android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
The 447a6748 number is just a memory address of an object that no longer exists.
Note- do not get hung up on the exact number. It would be different with every execution.
Now we know why the application crashed, the only thing left is to figure out what caused it?
We know that background threads execute independently of the main UI thread. That means that the user could be interacting with the application during the time that the thread is doing its work under the covers. Well, what happens if the user hits the “Back” button on the device while the background thread is running and what happens to the Dialog that this thread is supposed to show? Well, if the timing is right the application will most likely crash with the above described error.
In other words what happens is that the Activity will be going through its destruction when the background thread finishes its work and tries to show a Dialog.
In this case it is almost certain that this should have been handled by the Virtual Machine. It should have recognized the fact that the Activity is in the process of finishing and not even attempted to show the Dialog. This is an oversight of the Google developers and it will probably be fixed some time in the future, but in the meantime the burden is on us to take care of this.
The fix to this is pretty simple. Just test if the Activity is going through its finishing phase before displaying the Dialog:
private Handler myHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case DISPLAY_DLG:
if (!isFinishing()) {
showDialog(MY_DIALOG);
}
break;
}
}
};
The displaying of the Dialog has to happen on the UI thread, so you would do that either in the Handler object for the thread or in the onPostExecute method of an AsyncTask (which is a thread as well, just an easier way of implementing it). That is a textbook way of doing this and you would think that pretty much nothing wrong could go with this.
Surprisingly I found out that something CAN actually go wrong with this. After Google updated the Android Market and started giving crash reports to the developers I received the following exception:
android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
at android.view.ViewRoot.setView(ViewRoot.java:468)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:177)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
at android.view.Window$LocalWindowManager.addView(Window.java:424)
at android.app.Dialog.show(Dialog.java:239)
at android.app.Activity.showDialog(Activity.java:2488)
…
at android.os.Handler.dispatchMessage(Handler.java:99)
…
I only got a couple of these exceptions from thousands of installs, so I knew that was not anything that happens regularly or that it was easy to replicate.
Looking at the stack trace above it gives us a pretty good idea why it failed. It started in the Handler object, which naturally was called by a background thread after it finished its processing. The Handler instance tried to show a Dialog and before it could show it, it tried to set the View for it and then it failed with:
android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
The 447a6748 number is just a memory address of an object that no longer exists.
Note- do not get hung up on the exact number. It would be different with every execution.
Now we know why the application crashed, the only thing left is to figure out what caused it?
We know that background threads execute independently of the main UI thread. That means that the user could be interacting with the application during the time that the thread is doing its work under the covers. Well, what happens if the user hits the “Back” button on the device while the background thread is running and what happens to the Dialog that this thread is supposed to show? Well, if the timing is right the application will most likely crash with the above described error.
In other words what happens is that the Activity will be going through its destruction when the background thread finishes its work and tries to show a Dialog.
In this case it is almost certain that this should have been handled by the Virtual Machine. It should have recognized the fact that the Activity is in the process of finishing and not even attempted to show the Dialog. This is an oversight of the Google developers and it will probably be fixed some time in the future, but in the meantime the burden is on us to take care of this.
The fix to this is pretty simple. Just test if the Activity is going through its finishing phase before displaying the Dialog:
private Handler myHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case DISPLAY_DLG:
if (!isFinishing()) {
showDialog(MY_DIALOG);
}
break;
}
}
};
Wednesday, November 10, 2010
Host File - Windows
The hosts file is a computer file used in an operating system to map hostnames to IP addresses. The hosts file is a plain-text file and is traditionally named hosts.
The hosts file is one of several system facilities to assist in addressing network nodes in a computer network. It is a common part in a operating system's Internet Protocol (IP) implementation, and serves the function of translating human-friendly hostnames into numeric protocol addresses, called IP addresses, that identify and locate a host in an IP network.
In some operating systems, the host file content is used preferentially over other methods, such as the Domain Name System (DNS), but many systems implement name service switches (.e.g., nsswitch.conf) to provide customization. Unlike the DNS, the hosts file is under the direct control of the local computer's administrator.
#This is an example of the hosts file
127.0.0.1 localhost loopback
::1 localhost
path of host file is:
Windows 95/98/Me c:\windows\hosts
Windows NT/2000/XP Pro c:\winnt\system32\drivers\etc\hosts
Windows XP Home c:\windows\system32\drivers\etc\hosts
The hosts file is one of several system facilities to assist in addressing network nodes in a computer network. It is a common part in a operating system's Internet Protocol (IP) implementation, and serves the function of translating human-friendly hostnames into numeric protocol addresses, called IP addresses, that identify and locate a host in an IP network.
In some operating systems, the host file content is used preferentially over other methods, such as the Domain Name System (DNS), but many systems implement name service switches (.e.g., nsswitch.conf) to provide customization. Unlike the DNS, the hosts file is under the direct control of the local computer's administrator.
#This is an example of the hosts file
127.0.0.1 localhost loopback
::1 localhost
path of host file is:
Windows 95/98/Me c:\windows\hosts
Windows NT/2000/XP Pro c:\winnt\system32\drivers\etc\hosts
Windows XP Home c:\windows\system32\drivers\etc\hosts
Monday, November 8, 2010
List of Running ApplciationS
From the below snippet we can check the list of running applications and check whether your application is in foreground or not.
ActivityManager actvityManager = (ActivityManager)
this.getSystemService( ACTIVITY_SERVICE );
List procInfos = actvityManager.getRunningAppProcesses();
boolean appFound = false;
for(int i = 0; i < procInfos.size(); i++)
{
if(procInfos.get(i).processName == "com.android.camera")
appFound = true;
}
if (appFound)
Toast.makeText(getApplicationContext(), "Camera App is running!!!!", Toast.LENGTH_LONG).show();
else
Toast.makeText(getApplicationContext(), "Camera App is not running!!!!", Toast.LENGTH_LONG).show();
the above snippet shows your camera application is running or not.
ActivityManager actvityManager = (ActivityManager)
this.getSystemService( ACTIVITY_SERVICE );
List
boolean appFound = false;
for(int i = 0; i < procInfos.size(); i++)
{
if(procInfos.get(i).processName == "com.android.camera")
appFound = true;
}
if (appFound)
Toast.makeText(getApplicationContext(), "Camera App is running!!!!", Toast.LENGTH_LONG).show();
else
Toast.makeText(getApplicationContext(), "Camera App is not running!!!!", Toast.LENGTH_LONG).show();
the above snippet shows your camera application is running or not.
Sunday, November 7, 2010
UI/Application Exerciser Monkey
Today i gone through this tutorial from developer site seems to be interesting for UI application performance ,adding basic information on my blog:
---Basically Monkey is a program that runs on you emulator or Device(Mobile) and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events.
---You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.
Description of Monkey Tool:
--The Monkey is a command-line tool that that you can run on any emulator instance or on a device. It sends a pseudo-random stream of user events into the system, which acts as a stress test on the application software you are developing.
Categories:
The Monkey includes a number of options, but they break down into four primary categories:
1.Basic configuration options, such as setting the number of events to attempt.
2.Operational constraints, such as restricting the test to a single package.
3.Event types and frequencies.
4.Debugging options.
****When the Monkey runs, it generates events and sends them to the system. It also watches the system under test and looks for three conditions, which it treats specially:
1.If you have constrained the Monkey to run in one or more specific packages, it watches for attempts to navigate to any other packages, and blocks them.
2.If your application crashes or receives any sort of unhandled exception, the Monkey will stop and report the error.
3.If your application generates an application not responding error, the Monkey will stop and report the error.
Depending on the verbosity level you have selected, you will also see reports on the progress of the Monkey and the events being generated.
Basic Use Steps for Monkey:
****You can launch the Monkey using a command line on your development machine or from a script. Because the Monkey runs in the emulator/device environment, you must launch it from a shell in that environment. You can do this by prefacing adb shell to each command, or by entering the shell and entering Monkey commands directly.
The basic syntax is:
$ adb shell monkey [options]
With no options specified, the Monkey will launch in a quiet (non-verbose) mode, and will send events to any (and all) packages installed on your target. Here is a more typical command line, which will launch your application and send 500 pseudo-random events to it:
$ adb shell monkey -p your.package.name -v 500
Command Options Reference
The below lists all options you can include on the Monkey command line.
1. --help : Prints a simple usage guide.
2. -v : Each -v on the command line will increment the verbosity level. Level 0 (the default) provides little information beyond startup notification, test completion, and final results. Level 1 provides more details about the test as it runs, such as individual events being sent to your activities. Level 2 provides more detailed setup information such as activities selected or not selected for testing.
3. -s : Seed value for pseudo-random number generator. If you re-run the Monkey with the same seed value, it will generate the same sequence of events.
4. --throttle : Inserts a fixed delay between events. You can use this option to slow down the Monkey. If not specified, there is no delay and the events are generated as rapidly as possible.
5. --wait-dbg : Stops the Monkey from executing until a debugger is attached to it.
etc., command for debugging, constraints, events & general commands refer android developer site for more information.
---Basically Monkey is a program that runs on you emulator or Device(Mobile) and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events.
---You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.
Description of Monkey Tool:
--The Monkey is a command-line tool that that you can run on any emulator instance or on a device. It sends a pseudo-random stream of user events into the system, which acts as a stress test on the application software you are developing.
Categories:
The Monkey includes a number of options, but they break down into four primary categories:
1.Basic configuration options, such as setting the number of events to attempt.
2.Operational constraints, such as restricting the test to a single package.
3.Event types and frequencies.
4.Debugging options.
****When the Monkey runs, it generates events and sends them to the system. It also watches the system under test and looks for three conditions, which it treats specially:
1.If you have constrained the Monkey to run in one or more specific packages, it watches for attempts to navigate to any other packages, and blocks them.
2.If your application crashes or receives any sort of unhandled exception, the Monkey will stop and report the error.
3.If your application generates an application not responding error, the Monkey will stop and report the error.
Depending on the verbosity level you have selected, you will also see reports on the progress of the Monkey and the events being generated.
Basic Use Steps for Monkey:
****You can launch the Monkey using a command line on your development machine or from a script. Because the Monkey runs in the emulator/device environment, you must launch it from a shell in that environment. You can do this by prefacing adb shell to each command, or by entering the shell and entering Monkey commands directly.
The basic syntax is:
$ adb shell monkey [options]
With no options specified, the Monkey will launch in a quiet (non-verbose) mode, and will send events to any (and all) packages installed on your target. Here is a more typical command line, which will launch your application and send 500 pseudo-random events to it:
$ adb shell monkey -p your.package.name -v 500
Command Options Reference
The below lists all options you can include on the Monkey command line.
1. --help : Prints a simple usage guide.
2. -v : Each -v on the command line will increment the verbosity level. Level 0 (the default) provides little information beyond startup notification, test completion, and final results. Level 1 provides more details about the test as it runs, such as individual events being sent to your activities. Level 2 provides more detailed setup information such as activities selected or not selected for testing.
3. -s
4. --throttle
5. --wait-dbg : Stops the Monkey from executing until a debugger is attached to it.
etc., command for debugging, constraints, events & general commands refer android developer site for more information.
Friday, November 5, 2010
Developing a Device Administration Application
System administrators can use the Device Administration API to write an application that enforces remote/local device security policy enforcement. This section summarizes the steps involved in creating a device administration application.
Creating the manifest:
To use the Device Administration API, the application's manifest must include the following:
A subclass of DeviceAdminReceiver that includes the following:
--The BIND_DEVICE_ADMIN permission.
--The ability to respond to the ACTION_DEVICE_ADMIN_ENABLED intent, expressed in the manifest as an intent filter.
A declaration of security policies used in metadata.
Here is an snippet for the Device Administration sample manifest:
android:description="@string/device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
Note that:
The activity in the sample application is an Activity subclass called Controller. The syntax ".app.DeviceAdminSample$Controller" indicates that Controller is an inner class that is nested inside the DeviceAdminSample class. Note that an Activity does not need to be an inner class; it just is in this example.
The following attributes refer to string resources that for the sample application reside in ApiDemos/res/values/strings.xml. For more information about resources, see Application Resources.
android:label="@string/activity_sample_device_admin" refers to the user-readable label for the activity.
android:label="@string/sample_device_admin" refers to the user-readable label for the permission.
android:description="@string/sample_device_admin_description" refers to the user-readable description of the permission. A descripton is typically longer and more informative than a label.
android:permission="android.permission.BIND_DEVICE_ADMIN" is a permission that a DeviceAdminReceiver subclass must have, to ensure that only the system can interact with the receiver (no application can be granted this permission). This prevents other applications from abusing your device admin app.
android.app.action.DEVICE_ADMIN_ENABLED is the the primary action that a DeviceAdminReceiver subclass must handle to be allowed to manage a device. This is set to the receiver when the user enables the device admin app. Your code typically handles this in onEnabled(). To be supported, the receiver must also require the BIND_DEVICE_ADMIN permission so that other applications cannot abuse it.
When a user enables the device admin application, that gives the receiver permission to perform actions in response to the broadcast of particular system events. When suitable event arises, the application can impose a policy. For example, if the user attempts to set a new password that doesn't meet the policy requirements, the application can prompt the user to pick a different password that does meet the requirements.
android:resource="@xml/device_admin_sample" declares the security policies used in metadata. The metadata provides additional information specific to the device administrator, as parsed by the DeviceAdminInfo class. Here are the contents of device_admin_sample.xml:
Implementing the code
The Device Administration API includes the following classes:
DeviceAdminReceiver
Base class for implementing a device administration component. This class provides a convenience for interpreting the raw intent actions that are sent by the system. Your Device Administration application must include a DeviceAdminReceiver subclass.
DevicePolicyManager
A class for managing policies enforced on a device. Most clients of this class must have published a DeviceAdminReceiver that the user has currently enabled. The DevicePolicyManager manages policies for one or more DeviceAdminReceiver instances
DeviceAdminInfo
This class is used to specify metadata for a device administrator component.
These classes provide the foundation for a fully functional device administration application. The rest of this section describes how you use the DeviceAdminReceiver and DevicePolicyManager APIs to write a device admin application.
Subclassing DeviceAdminReceiver
To create a device admin application, you must subclass DeviceAdminReceiver. The DeviceAdminReceiver class consists of a series of callbacks that are triggered when particular events occur.
In its DeviceAdminReceiver subclass, the sample application simply displays a Toast notification in response to particular events. For example:
public class DeviceAdminSample extends DeviceAdminReceiver {
...
@Override
public void onEnabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: enabled");
}
@Override
public CharSequence onDisableRequested(Context context, Intent intent) {
return "This is an optional message to warn the user about disabling.";
}
@Override
public void onDisabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: disabled");
}
@Override
public void onPasswordChanged(Context context, Intent intent) {
showToast(context, "Sample Device Admin: pw changed");
}
void showToast(Context context, CharSequence msg) {
Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();
}
...
}
Enabling the application
One of the major events a device admin application has to handle is the user enabling the application. The user must explicitly enable the application for the policies to be enforced. If the user chooses not to enable the application it will still be present on the device, but its policies will not be enforced, and the user will not get any of the application's benefits.
The process of enabling the application begins when the user performs an action that triggers the ACTION_ADD_DEVICE_ADMIN intent. In the sample application, this happens when the user clicks the Enable Admin button
for Reference's Android Device Administration code
Creating the manifest:
To use the Device Administration API, the application's manifest must include the following:
A subclass of DeviceAdminReceiver that includes the following:
--The BIND_DEVICE_ADMIN permission.
--The ability to respond to the ACTION_DEVICE_ADMIN_ENABLED intent, expressed in the manifest as an intent filter.
A declaration of security policies used in metadata.
Here is an snippet for the Device Administration sample manifest:
android:description="@string/device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
Note that:
The activity in the sample application is an Activity subclass called Controller. The syntax ".app.DeviceAdminSample$Controller" indicates that Controller is an inner class that is nested inside the DeviceAdminSample class. Note that an Activity does not need to be an inner class; it just is in this example.
The following attributes refer to string resources that for the sample application reside in ApiDemos/res/values/strings.xml. For more information about resources, see Application Resources.
android:label="@string/activity_sample_device_admin" refers to the user-readable label for the activity.
android:label="@string/sample_device_admin" refers to the user-readable label for the permission.
android:description="@string/sample_device_admin_description" refers to the user-readable description of the permission. A descripton is typically longer and more informative than a label.
android:permission="android.permission.BIND_DEVICE_ADMIN" is a permission that a DeviceAdminReceiver subclass must have, to ensure that only the system can interact with the receiver (no application can be granted this permission). This prevents other applications from abusing your device admin app.
android.app.action.DEVICE_ADMIN_ENABLED is the the primary action that a DeviceAdminReceiver subclass must handle to be allowed to manage a device. This is set to the receiver when the user enables the device admin app. Your code typically handles this in onEnabled(). To be supported, the receiver must also require the BIND_DEVICE_ADMIN permission so that other applications cannot abuse it.
When a user enables the device admin application, that gives the receiver permission to perform actions in response to the broadcast of particular system events. When suitable event arises, the application can impose a policy. For example, if the user attempts to set a new password that doesn't meet the policy requirements, the application can prompt the user to pick a different password that does meet the requirements.
android:resource="@xml/device_admin_sample" declares the security policies used in metadata. The metadata provides additional information specific to the device administrator, as parsed by the DeviceAdminInfo class. Here are the contents of device_admin_sample.xml:
Implementing the code
The Device Administration API includes the following classes:
DeviceAdminReceiver
Base class for implementing a device administration component. This class provides a convenience for interpreting the raw intent actions that are sent by the system. Your Device Administration application must include a DeviceAdminReceiver subclass.
DevicePolicyManager
A class for managing policies enforced on a device. Most clients of this class must have published a DeviceAdminReceiver that the user has currently enabled. The DevicePolicyManager manages policies for one or more DeviceAdminReceiver instances
DeviceAdminInfo
This class is used to specify metadata for a device administrator component.
These classes provide the foundation for a fully functional device administration application. The rest of this section describes how you use the DeviceAdminReceiver and DevicePolicyManager APIs to write a device admin application.
Subclassing DeviceAdminReceiver
To create a device admin application, you must subclass DeviceAdminReceiver. The DeviceAdminReceiver class consists of a series of callbacks that are triggered when particular events occur.
In its DeviceAdminReceiver subclass, the sample application simply displays a Toast notification in response to particular events. For example:
public class DeviceAdminSample extends DeviceAdminReceiver {
...
@Override
public void onEnabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: enabled");
}
@Override
public CharSequence onDisableRequested(Context context, Intent intent) {
return "This is an optional message to warn the user about disabling.";
}
@Override
public void onDisabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: disabled");
}
@Override
public void onPasswordChanged(Context context, Intent intent) {
showToast(context, "Sample Device Admin: pw changed");
}
void showToast(Context context, CharSequence msg) {
Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();
}
...
}
Enabling the application
One of the major events a device admin application has to handle is the user enabling the application. The user must explicitly enable the application for the policies to be enforced. If the user chooses not to enable the application it will still be present on the device, but its policies will not be enforced, and the user will not get any of the application's benefits.
The process of enabling the application begins when the user performs an action that triggers the ACTION_ADD_DEVICE_ADMIN intent. In the sample application, this happens when the user clicks the Enable Admin button
for Reference's Android Device Administration code
Device Administration - New Feature Supported from Froyo
Android 2.2(FROYO) introduces support for enterprise applications by offering the Android Device Administration API.
--Device Administration API provides device administration features at the system level.
--These APIs allow you to create security-aware applications that are useful in enterprise settings, in which IT professionals require rich control over employee devices.
***For example, the built-in Android Email application has leveraged the new APIs to improve Exchange support. Through the Email application, Exchange administrators can enforce password policies — including alphanumeric passwords or numeric PINs — across devices.
**Administrators can also remotely wipe (that is, restore factory defaults on) lost or stolen handsets.
**Exchange users can sync their email and calendar data.
--This above information is intended for developers who want to develop enterprise solutions for Android-powered devices. It discusses the various features provided by the Device Administration API to provide stronger security for employee devices that are powered by Android.
Device Administration API Overview :
Here are examples of the types of applications that might use the Device Administration API:
--Email clients.
--Security applications that do remote wipe.
--Device management services and applications.
How does it work?
You use the Device Administration API to write device admin applications that users install on their devices. The device admin application enforces the desired policies. Here's how it works:
A system administrator writes a device admin application that enforces remote/local device security policies. These policies could be hard-coded into the app, or the application could dynamically fetch policies from a third-party server.
The application is installed on users' devices. Android does not currently have an automated provisioning solution. Some of the ways a sysadmin might distribute the application to users are as follows:
Android Market.
Enabling non-market installation.
Distributing the application through other means, such as email or websites.
The system prompts the user to enable the device admin application. How and when this happens depends on how the application is implemented.
Once users enable the device admin application, they are subject to its policies. Complying with those policies typically confers benefits, such as access to sensitive systems and data.
If users do not enable the device admin app, it remains on the device, but in an inactive state. Users will not be subject to its policies, and they will conversely not get any of the application's benefits—for example, they may not be able to sync data.
If a user fails to comply with the policies (for example, if a user sets a password that violates the guidelines), it is up to the application to decide how to handle this. However, typically this will result in the user not being able to sync data.
If a device attempts to connect to a server that requires policies not supported in the Device Administration API, the connection will not be allowed. The Device Administration API does not currently allow partial provisioning. In other words, if a device (for example, a legacy device) does not support all of the stated policies, there is no way to allow the device to connect.
If a device contains multiple enabled admin applications, the strictest policy is enforced. There is no way to target a particular admin application.
To uninstall an existing device admin application, users need to first unregister the application as an administrator.
Policies
In an enterprise setting, it's often the case that employee devices must adhere to a strict set of policies that govern the use of the device. The Device Administration API supports the policies listed in Table 1. Note that the Device Administration API currently only supports passwords for screen lock:
Table 1. Policies supported by the Device Administration API.
Below explanation with Policy:Description
Password enabled Requires that devices ask for PIN or passwords.
Minimum password length : Set the required number of characters for the password. For example, you can require PIN or passwords to have at least six characters.
Alphanumeric password required : Requires that passwords have a combination of letters and numbers. They may include symbolic characters.
Maximum failed password attempts : Specifies how many times a user can enter the wrong password before the device wipes its data. The Device Administration API also allows administrators to remotely reset the device to factory defaults. This secures data in case the device is lost or stolen.
Maximum inactivity time lock : Sets the length of time since the user last touched the screen or pressed a button before the device locks the screen. When this happens, users need to enter their PIN or passwords again before they can use their devices and access data. The value can be between 1 and 60 minutes.
Other features
In addition to supporting the policies listed in the above table, the Device Administration API lets you do the following:
Prompt user to set a new password.
Lock device immediately.
Wipe the device's data (that is, restore the device to its factory defaults).
--Device Administration API provides device administration features at the system level.
--These APIs allow you to create security-aware applications that are useful in enterprise settings, in which IT professionals require rich control over employee devices.
***For example, the built-in Android Email application has leveraged the new APIs to improve Exchange support. Through the Email application, Exchange administrators can enforce password policies — including alphanumeric passwords or numeric PINs — across devices.
**Administrators can also remotely wipe (that is, restore factory defaults on) lost or stolen handsets.
**Exchange users can sync their email and calendar data.
--This above information is intended for developers who want to develop enterprise solutions for Android-powered devices. It discusses the various features provided by the Device Administration API to provide stronger security for employee devices that are powered by Android.
Device Administration API Overview :
Here are examples of the types of applications that might use the Device Administration API:
--Email clients.
--Security applications that do remote wipe.
--Device management services and applications.
How does it work?
You use the Device Administration API to write device admin applications that users install on their devices. The device admin application enforces the desired policies. Here's how it works:
A system administrator writes a device admin application that enforces remote/local device security policies. These policies could be hard-coded into the app, or the application could dynamically fetch policies from a third-party server.
The application is installed on users' devices. Android does not currently have an automated provisioning solution. Some of the ways a sysadmin might distribute the application to users are as follows:
Android Market.
Enabling non-market installation.
Distributing the application through other means, such as email or websites.
The system prompts the user to enable the device admin application. How and when this happens depends on how the application is implemented.
Once users enable the device admin application, they are subject to its policies. Complying with those policies typically confers benefits, such as access to sensitive systems and data.
If users do not enable the device admin app, it remains on the device, but in an inactive state. Users will not be subject to its policies, and they will conversely not get any of the application's benefits—for example, they may not be able to sync data.
If a user fails to comply with the policies (for example, if a user sets a password that violates the guidelines), it is up to the application to decide how to handle this. However, typically this will result in the user not being able to sync data.
If a device attempts to connect to a server that requires policies not supported in the Device Administration API, the connection will not be allowed. The Device Administration API does not currently allow partial provisioning. In other words, if a device (for example, a legacy device) does not support all of the stated policies, there is no way to allow the device to connect.
If a device contains multiple enabled admin applications, the strictest policy is enforced. There is no way to target a particular admin application.
To uninstall an existing device admin application, users need to first unregister the application as an administrator.
Policies
In an enterprise setting, it's often the case that employee devices must adhere to a strict set of policies that govern the use of the device. The Device Administration API supports the policies listed in Table 1. Note that the Device Administration API currently only supports passwords for screen lock:
Table 1. Policies supported by the Device Administration API.
Below explanation with Policy:Description
Password enabled Requires that devices ask for PIN or passwords.
Minimum password length : Set the required number of characters for the password. For example, you can require PIN or passwords to have at least six characters.
Alphanumeric password required : Requires that passwords have a combination of letters and numbers. They may include symbolic characters.
Maximum failed password attempts : Specifies how many times a user can enter the wrong password before the device wipes its data. The Device Administration API also allows administrators to remotely reset the device to factory defaults. This secures data in case the device is lost or stolen.
Maximum inactivity time lock : Sets the length of time since the user last touched the screen or pressed a button before the device locks the screen. When this happens, users need to enter their PIN or passwords again before they can use their devices and access data. The value can be between 1 and 60 minutes.
Other features
In addition to supporting the policies listed in the above table, the Device Administration API lets you do the following:
Prompt user to set a new password.
Lock device immediately.
Wipe the device's data (that is, restore the device to its factory defaults).
Subscribe to:
Posts (Atom)