mirwing's Story

SDK Tools r6 & ADT 0.9.7 & NDK r4 for Froyo

2010-05-27T10:27:36+09:00

SDK Tools, r6

Dependencies:

If you are developing in Eclipse with ADT, note that SDK Tools r6 is designed for use with ADT 0.9.7 and later. After installing SDK Tools r6, we highly recommend updating your ADT Plugin to 0.9.7.

Library projects:

The SDK Tools now support the use of library projects during development, a capability that lets you store shared Android application code and resources in a separate development project. You can then reference the library project from other Android projects and, at build time, the tools compile the shared code and resources as part of the dependent applications. More information about this feature is available in the Developing in Other IDEs document.

If you are developing in Eclipse, ADT 0.9.7 provides the equivalent library project support.

ADT Plugin for Eclipse 0.9.7

Library projects:

The ADT Plugin now supports the use of library projects during development, a capability that lets you store shared Android application code and resources in a separate development project. You can then reference the library project from other Android projects and, at build time, the tools compile the shared code and resources as part of the dependent applications. More information about this feature is available in the Developing in Eclipse with ADT document.

If you are not developing in Eclipse, SDK Tools r6 provides the equivalent library project support through the Ant build system.

Android NDK, r4

General notes:

Provides a simplified build system through the new ndk-build build command.
Adds support for easy native debugging of generated machine code on production devices through the new ndk-gdb command.
Adds a new Android-specific ABI for ARM-based CPU architectures, armeabi-v7a. The new ABI extends the existing armeabi ABI to include these CPU instruction set extensions:
- Thumb-2 instructions
- VFP hardware FPU instructions (VFPv3-D16)
- Optional support for ARM Advanced SIMD (NEON) GCC intrinsics and VFPv3-D32. Supported by devices such as Verizon Droid by Motorola, Google Nexus One, and others.
Adds a new cpufeatures static library (with sources) that lets your app detect the host device's CPU features at runtime. Specifically, applications can check for ARMv7-A support, as well as VFPv3-D32 and NEON support, then provide separate code paths as needed.
Adds a sample application, hello-neon, that illustrates how to use the cpufeatures library to check CPU features and then provide an optimized code path using NEON instrinsics, if supported by the CPU.
Lets you generate machine code for either or both of the instruction sets supported by the NDK. For example, you can build for both ARMv5 and ARMv7-A architectures at the same time and have everything stored to your application's final .apk.
To ensure that your applications are available to users only if their devices are capable of running them, Android Market now filters applications based on the instruction set information included in your application — no action is needed on your part to enable the filtering. Additionally, the Android system itself also checks your application at install time and allows the installation to continue only if the application provides a library that is compiled for the device's CPU architecture.
Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.

Android 2.2 Version Note

2010-05-27T10:26:59+09:00

API Level

The Android 2.2 platform delivers an updated version of the framework API. The Android 2.2 API is assigned an integer identifier — 8 — that is stored in the system itself. This identifier, called the "API Level", allows the system to correctly determine whether an application is compatible with the system, prior to installing the application.

To use APIs introduced in Android 2.2 in your application, you need to set the proper value, "8", in the android:minSdkVersion attributes of the <uses-sdk> element in your application's manifest.

For more information about how to use API Level, see the API Levels document.

Framework API Changes

The sections below provide information about changes made to the application framework API provided by the Android 2.2 platform.

App installation on external storage media

The Android platform now allows applications to request installation onto the device's external storage media (such as the SD card), as an alternative to installation onto the device's internal memory.

Application developers can express the preferred installation location for their applications by means of a new attribute of <manifest> in the manifest file, android:installLocation. The attribute supports three values: "internalOnly", "preferExternal", and "auto". At install time, the system checks the value of android:installLocation and installs the application .apk according to the preferred location, if possible. If the application has requested external installation, the system installs it into a private, encrypted partition in the external media. Once an application .apk is installed externally, the system lets the user change the storage location of the .apk and move it onto the device's internal memory if needed (and vice versa), through Manage Applications in the user settings.

By default, the system installs all applications onto the device's internal memory, except for those that explicitly request external installation. This means that the system will always install legacy applications onto internal memory, since they do not have access to the android:installLocation attribute. However, it is possible to configure and compile a legacy application such that it is installed internally on older versions of the platform and externally on Android 2.2 and later platforms, if necessary.

Note that requesting installation onto the device's external media is not suitable for all applications, particularly because the external media may be removable and unmounting/remounting may disrupt the user experience and system settings.

For more information about setting a preferred install location for your application, including a discussion of what types of applications should and should not request external installation, please read the App Install Location document.

Data backup

The platform now provides a generalized backup service that applications can use to backup and restore user data, to ensure that users can maintain their data when switching devices or reinstalling the application. The Backup Manager handles the work of transporting the application data to and from the backup storage area in the cloud. The Backup Manager can store any type of data, from arbitrary data to files, and manages backup and restore operations in an atomic manner. For more information, see Data Backup.

Graphics

New OpenGL ES 2.0 APIs in android.opengl.GLES20.
New ETC1, ETC1Util, and ETC1Util.ETC1Texture classes and utility methods for using ETC1 for texture compression.
New ImageFormat class.
New YUV image format API to enable compression from YUV to JPEG and manipulation of YUV data.

Media

New APIs in android.media.AudioManager for managing audio focus, transport control, transient loss of audio focus, ducking.
New broadcast intent for routing audio to SCO — ACTION_SCO_AUDIO_STATE_CHANGED with extras indicating new state.
New APIs in SoundPool to detect completion of sound-loading.
New APIs in SoundPool for auto pause and resume.
New APIs in MediaRecorder for specifying audio settings for number of channels, encoding and sampling rates, sampling rate.
New APIs for adding files to the media database, so that they are automatically scanned. See MediaScannerConnection.scanFile and MediaScannerConnection.OnScanCompletedListener.

Speech recognition and third-party recognition engines

The platform provides new speech-recognition APIs that allow applications to have a richer interaction with the available voice recognizer. For example, the APIs are sufficient to integrate voice recognition deeply into an IME.
The platform also provides a RecognitionService base class that lets third-party developers create plug-in recognition engines.
New RecognitionListener interface to receive callbacks.
New RecognizerIntent extras that let a requester app specify details as preferred language, minimum length in milliseconds, and so on.

Camera and camcorder

Changes to camera preview API to improve efficieny of preview pipeline.
New display orientation for camera (it can now work in portrait orientation).
New APIs in android.hardware.Camera for managing zoom level.
New APIs android.hardware.Camera.Parameters for querying and setting device camera settings such as focal length, exposure, zoom level, view angle, and others.
New thumbnail utility for video and image thumbnails.
New CamcorderProfile and CamcorderProfile classes enable apps to determine device hardware camera capablities.
New support in android.media.ExifInterface for retrieving GPS and focal length.

Device policy manager

New device policy management APIs allow developers to write "device administrator" applications that can control security features of the device, such as the minimum password strength, data wipe, and so on. Users can select the administrators that are enabled on their devices. For more information, see the android.app.admin classees or the example application code inDeviceAdminSample.java.

UI Framework

New UI modes "car mode" and "night mode" and UiModeManager let applications adjust their application UI for specific user modes.
New ScaleGestureDetector that lets Views detect and handle transformation gestures that involve more than one pointer (multitouch) using the supplied MotionEvents.
Improvements in the way that multitouch events are reported in MotionEvent objects.
The layout attribute fill_parent is renamed to match_parent. This affects both XML and Java code (see ViewGroup.LayoutParams). Note that the platform will continue to honor uses offill_parent in legacy applications.
New layout attributes tabStripEnabled, tabStripRight, and tabStripLeft let developers customize the bottom strip of TabWidgets.
Better support for managed dialogs in Activity.

Accounts and sync

New method AddPeriodicSync() lets you schedule a periodic sync with a specific account, authority, and extras at the given frequency.

New manifest elements and attributes

For specifying the application's preferred install location (see App Installation on External Storage Media, above):
- New android:installLocation attribute of the <manifest> element. Specifies the default install location defined by an application.
For managing user data backup (see Backup manager, above, for more information):
- New android:backupAgent attribute of the <application> element. Specifies the component name of the BackupAgent subclass provided by the application to handle backup/restore operations, if any.
- New android:restoreAnyVersion attribute of the <application> element. Boolean value that indicates whether the application is prepared to attempt a restore of any backed-up dataset, even if the backup is apparently from a newer version of the application than is currently installed on the device.
For managing the platform's JIT compiler:
- New android:vmSafeMode attribute of the <application> element. Boolean value that specifies whether to disable JIT compiler optimizations when running the application.

Permissions

android.permission.BIND_DEVICE_ADMIN — Any device administration broadcast receiver must require this permission, to ensure that only the system can interact with it.
android.permission.KILL_BACKGROUND_PROCESSES — Allows an application to call killBackgroundProcesses(String).
android.permission.BIND_WALLPAPER — Any WallpaperService must require this permission, to ensure that only the system can interact with it.
android.permission.SET_TIME — Allows an application to set the system time.

API differences report

For a detailed view of all API changes in Android 2.2 (API Level 8), see the API Differences Report.

Built-in Applications

The system image included in the downloadable platform provides these built-in applications:

Alarm Clock
Browser
Calculator
Camera
Contacts
Custom Locale (developer app)
Dev Tools (developer app)
Email

Gallery
IMEs for Japanese, Chinese, and Latin text input
Messaging
Music
Phone
Settings
Spare Parts (developer app)

Locales

The system image included in the downloadable platform provides a variety of built-in locales. In some cases, region-specific strings are available for the locales. In other cases, a default version of the language is used. The languages that are available in the Android 2.2 system image are listed below (with language_country/region locale descriptor).

Chinese, PRC (zh_CN)
Chinese, Taiwan (zh_TW)
Czech (cs_CZ)
Dutch, Netherlands (nl_NL)
Dutch, Belgium (nl_BE)
English, US (en_US)
English, Britain (en_GB)
English, Canada (en_CA)
English, Australia (en_AU)
English, New Zealand (en_NZ)
English, Singapore(en_SG)
French, France (fr_FR)
French, Belgium (fr_BE)

French, Canada (fr_CA)

French, Switzerland (fr_CH)

German, Germany (de_DE)

German, Austria (de_AT)

German, Switzerland (de_CH)

German, Liechtenstein (de_LI)

Italian, Italy (it_IT)

Italian, Switzerland (it_CH)

Japanese (ja_JP)

Korean (ko_KR)

Polish (pl_PL)

Russian (ru_RU)

Spanish (es_ES)

Localized UI strings match the locales that are accessible through Settings.

Emulator Skins

The downloadable platform includes a set of emulator skins that you can use for modeling your application in different screen sizes and resolutions. The emulator skins are:

QVGA (240x320, low density, small screen)
WQVGA (240x400, low density, normal screen)
FWQVGA (240x432, low density, normal screen)
HVGA (320x480, medium density, normal screen)
WVGA800 (480x800, high density, normal screen)
WVGA854 (480x854 high density, normal screen)

For more information about how to develop an application that displays and functions properly on all Android-powered devices, see Supporting Multiple Screens.

Froyo! Android 2.2 Platform Highlights

2010-05-27T10:24:57+09:00

[[Developers Android]]

New User Features

Home

New Home screen tips widget assists new users on how to configure the home screen with shortcuts and widgets and how to make use of multiple home screens.

The Phone, applications Launcher, and Browser now have dedicated shortcuts on the Home screen, making it easy to access them from any of the 5 home screen panels.

Exchange support

Improved security with the addition of numeric pin or alpha-numeric password options to unlock device. Exchange administrators can enforce password policy across devices.

Remote wipe: Exchange administrators can remotely reset the device to factory defaults to secure data in case device is lost or stolen.

Exchange Calendars are now supported in the Calendar application.

Auto-discovery: you just need to know your user-name and password to easily set up and sync an Exchange account (available for Exchange 2007 and higher).

Global Address Lists look-up is now available in the Email application, enabling users to auto-complete recipient names from the directory.

Camera and Gallery

Gallery allows you to peek into picture stacks using a zoom gesture.

Camera onscreen buttons provide easy access to a new UI for controling zoom, flash, white balance, geo-tagging, focus and exposure. Camcorder also provides an easy way to set video size/quality for MMS and YouTube.

With the LED flash now enabled for the Camcorder, videos can be shot at night or in low light settings.

Portable hotspot

Certain devices like the Nexus One can be turned into a portable Wi-Fi hotspot that can be shared with up to 8 devices.

You can use your Android-powered phone as a 3G connection for a Windows or Linux laptop by connecting their phone to the computer with a USB cable. The connection is then shared between the two devices.

Multiple keyboard languages

Multi-lingual users can add multiple languages to the keyboard and switch between multiple Latin-based input languages by swiping across the space bar. This changes the keys as well as the auto-suggest dictionary.

Improved performance

Performance of the browser has been enhanced using the V8 engine, which enables faster loading of JavaScript-heavy pages.

Dalvik Performance Boost: 2x-5x performance speedup for CPU-heavy code over Android 2.1 with Dalvik JIT.

The graph to the right shows the performance speedup from Android 2.1 to Android 2.2 using various benchmark tests. For example, LinPack is now more than 5 times faster.

Kernel Memory Management Boost: Improved memory reclaim by up to 20x, which results in faster app switching and smoother performance on memory-constrained devices.

New Platform Technologies

Media framework

New media framework (Stagefright) that supports local file playback and HTTP progressive streaming
Continued support for OpenCore in Android 2.2

Bluetooth

Voice dialing over Bluetooth
Ability to share contacts with other phones
Support for Bluetooth enabled car and desk docks
Improved compatibility matrix with car kits and headsets

2.6.32 kernel upgrade

HIGHMEM support for RAM >256MB
SDIO scheduling and BT improvements

New Developer Services

Android Cloud to Device Messaging

Apps can utilize Android Cloud to Device Messaging to enable mobile alert, send to phone, and two-way push sync functionality.

Android Application Error Reports

New bug reporting feature for Android Market apps enables developers to receive crash and freeze reports from their users. The reports will be available when they log into their publisher account.

New Developer APIs

Apps on external storage

Applications can now request installation on the shared external storage (such as an SD card).

Media framework

Provides new APIs for audio focus, routing audio to SCO, and auto-scan of files to media database. Also provides APIs to let applications detect completion of sound loading and auto-pause and auto-resume audio playback.

Camera and Camcorder

New preview API doubles the frame rate from ~10FPS to ~20FPS. Camera now supports portrait orientation, zoom controls, access to exposure data, and a thumbnail utility. A new camcorder profile enables apps to determine device hardware capablities.

Graphics

New APIs for OpenGL ES 2.0, working with YUV image format, and ETC1 for texture compression.

Data backup

Apps can participate in data backup and restore, to ensure that users maintain their data after performing a factory reset or when switching devices.

Device policy manager

New device policy management APIs allow developers to write "device administrator" applications that can control security features on the device, such as the minimum password strength, data wipe, and so on. Users can select the administrators that are enabled on their devices.

UI framework

New "car mode" and "night mode" controls and configurations allow applications to adjust their UI for these situations. A scale gesture detector API provides improved definition of multi-touch events. Applications can now customize the bottom strip of a TabWidget.

Android NDK r3 & SDK Tools r5, ADT 0.9.6 Release

2010-03-09T07:33:46+09:00

[Android Developer]

Android NDK r3

The third release of the Android Native Development Kit (NDK) is now available for download from the Android developer site.

It can be used to target devices running Android 1.5 and higher. In addition to a few bug fixes and improvements, this release includes the following new features:

Toolchain improvement

The toolchain binaries have been refreshed for this release with GCC 4.4.0, which should generate slightly more compact and efficient machine code than the previous one (4.2.1).

Note that the GCC 4.4.0 C++ frontend is more pedantic, and may refuse to compile certain rare and invalid template declarations that were accepted by 4.2.1. To alleviate the problem, this NDK still provides the 4.2.1 binaries, which can optionally be used to build your machine code.

OpenGL ES 2.0 support

Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.

A new trivial sample, named "hello-gl2", demonstrates how to render a simple triangle using both shader types.

Name simplification

This NDK release is just called "r3", for "Revision 3", to indicate that it is not limited to a specific Android platform/API level. Some developers thought that the previous release's name (1.6_r1) was confusing and indicated that it could only be used to target Android 1.6, which was not true.

Enjoy!

SDK Tools r5

Dependencies:

If you are developing in Eclipse with ADT, note that SDK Tools r5 is designed for use with ADT 0.9.6 and later. After installing SDK Tools r5, we highly recommend updating your ADT Plugin to 0.9.6.
For Mac OS platforms, OS X 10.4.x (Tiger) is no longer officially supported.

SDK and AVD Manager:

Fixes SSL download for the standalone version of the SDK Updater.
Fixes issue with 64-bit JVM on Windows.
Adds support for platform samples components.
Improves support for dependency between components.
AVDs now sorted by API level.
The AVD creation dialog now enforces a minimum SD card size of 9MB.
Prevents deletion of running AVDs.
Settings are now automatically saved, no need to click "Apply".

Emulator:

Emulator now requires SD card to be 9MB or more.

Layoutopt:

Fixes layoutopt.bat to execute correctly on Windows.

ADT 0.9.6

Dependencies:

ADT 0.9.6 is designed for use with SDK Tools r5 and later. Before updating to ADT 0.9.6, we highly recommend that you use the Android SDK and AVD Manager to install SDK Tools r5 into your SDK.

General Notes:

Editing default.properties outside of Eclipse will now automatically update the project.
Loads the SDK content only when a project requires it. This will make Eclipse use less resources when the SDK contains many versions of Android.
Resolves potential deadlock between modal dialogs, when launching ADT the first time with the SDK Usage panel.
Fixes issues with the New Project Wizard when selecting samples.

AVD/SDK Manager:

Adds support for platform samples components.
Improves support for dependency between components.
AVDs now sorted by API level.
The AVD creation dialog now enforces a minimum SD card size of 9MB.
Prevents deletion of running AVDs.

DDMS:

DDMS plug-in now contains the Allocation Tracker view.
New action in the Logcat view: "Go to problem" lets you go directly from an exception trace output to the code.

Editors:

Explode mode in the Visual Layout Editor adds a margin to all layout objects so that it's easier to see embedded or empty layouts.
Outline mode in the Visual Layout Editor draws layout outline to make it easier to see layout objects.
Several fixes in the configuration selector of the Visual Layout Editor.

Application launching:

Applications launched from ADT now behave as if they were clicked from the Home screen.
Fixes issue where add-on with no optional library would not show up as valid targets for application launches.
Resolves possible crash when launching applications.

안드로이드 입문서 3rd Edition 발행 - Kandroid

2010-04-15T11:51:40+09:00

[출처 : Kandroid]

Kandroid에서 Android Dev. Guide를 한글로 번역한 문서를

pdf파일을 통해 공개하였습니다.

2nd Edition까지는 책으로 출판하였었지만 3rd 부터는 pdf로 공개한다고 하시네요.ㅋ

Android Dev. Guide가 Android 개발에는 많은 부분을 차지 하는 만큼

한글로 번역이 된만큼 한국의 많은 개발자 분들이 조금더 손쉽게 접근할 수 있는

Android가 되길 바랍니다.

Android Dev. Guide는 Android를 처음 접하시는 분들에게

Android 개념을 잡기위한 입문서라고 생각 되어 집니다.

PDF 문서는 위 링크를 통해 들어가시면 있습니다.

Android Development Environment Setting - SDK/NDK

2010-02-21T15:17:16+09:00

Android의 개발 환경을 설정하기 전에 Android에서 지원하는 개발 환경에 대해서 알아 보겠습니다.

Android를 개발할 수 있는 OS는 3가지가 있습니다.

Linux, Mac, Windows

이 중 Windows는 Android의 Source 레벨 까지 내려가기 위해서는 많은 작업을 해야 합니다.

Linux와 비슷하게 만들어 주는 cygwin이 존재하지만 저는 linux가 더 좋습니다.ㅋ

Linux와 Mac은 Android Source까지 다운로드를 할 수 있지만 역시 Linux의 경우가 좀더 호환이 잘 됩니다.

Android는 SDK와 NDK를 이용해 개발 할 수 있는데 NDK는 2010. 2월 21일 현재 아직 1.6r1버전 뿐입니다.

총 3가지의 환경설정을 포스팅 하겠는데 목록을 살펴보겠습니다.

1. Android SDK 설치
우선 가장 기본적은 SDK는 Java로 구성된 Android App을 개발할 수 있도록 해줍니다.

2. Android NDK 설치
JNI를 손 쉽게 해주는 NDK는 C/C++로 라이브러리를 만들어 Java에서 사용을 할 수 있도록 해주지만 1.6버전 뿐입니다.

3. Android Source 다운로드 & 컴파일
마지막으로 Android Source를 다운로드 받아 해당 소스를 컴파일하여 직접 system 이미지를 만들거나 Source에 포함되어 있는 컴파일러를 이용하여 라이브러리를 만들 수 있습니다.

위 3가지에 대한 각각의 내용은 링크로 연결 시키겠습니다.

Service API changes starting with Android 2.0

2010-02-17T23:05:49+09:00

[출처 : Android Developers Blog]

Service API changes starting with Android 2.0

Watching developers use the Android platform the last year has shown a number of trouble areas in the Service API as well as growing issues in the ways services operate. As a result, Android 2.0 introduced a number of changes and improvements in this area for both developers and users.

The three main changes to be aware of are:
Service.setForeground() is now deprecated and in 2.0 does nothing.
There were many edge cases in the service lifecycle that made it very easy to accidentally leave a service running; new APIs in 2.0 make this much easier to deal with.
Android 2.0 also introduces a new UI for end users to monitor and manage the running services on their device.

Background on services

Before going into the details of 2.0, it may be useful to go over a quick summary of services. The Service API in Android is one of the key mechanisms for applications to do work in the background. Due to the way Android is designed, once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.

This is a very powerful facility but along with that power comes some responsibility: an actively running service is taking resources away from other things that can run (including inactive processes in the background that don't need to be initialized the next time the user visits them). It is thus important that developers take care when designing their services that they only run when truly needed and avoid any bugs where they may accidentally leave the service running for long durations.

Redesigning Service.setForeground()

During the final stabilization period of Android 1.6 we started to see more issues due to an increasing number of applications using the Service.setForeground() API when they shouldn't be. This is an API that we haven't advertised much because it should not be used by most applications and can be very hard on the system: it asks that the service's process be treated as in the foreground, essentially making it unkillable and thus more difficult for the system to recover from low memory situations.

At that point in 1.6 it was too late to make any significant changes to the behavior here, but in 2.0 we have done so: Service.setForeground() now does nothing. The API was always intended to be something a service would do in conjunction with putting up an ongoing notification for the user; by saying you are in the foreground, the user should be "aware" that the service is running in some way and know how to stop it. Thus in place of the old API Andriod 2.0 introduces two new APIs that require a notification go along with being in the foreground:

   public final void startForeground(int id, Notification notification);
   public final void stopForeground(boolean removeNotification);

This also not coincidentally makes it much easier to manage the notification state along with the service, since the system can now guarantee that there is always a notification while the service is in the foreground, and that the notification goes away whenever the service does.

Many developers will want to write a service that works on older platforms as well as 2.0 and later; this can be accomplished by using something like the following code to selectively call the new APIs when they are available.

   private static final Class[] mStartForegroundSignature = new Class[] {
   int.class, Notification.class};
   private static final Class[] mStopForegroundSignature = new Class[] {
   boolean.class};

   private NotificationManager mNM;
   private Method mStartForeground;
   private Method mStopForeground;
   private Object[] mStartForegroundArgs = new Object[2];
   private Object[] mStopForegroundArgs = new Object[1];

   @Override
   public void onCreate() {
   mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
   try {
   mStartForeground = getClass().getMethod("startForeground",
   mStartForegroundSignature);
   mStopForeground = getClass().getMethod("stopForeground",
   mStopForegroundSignature);
   } catch (NoSuchMethodException e) {
   // Running on an older platform.
   mStartForeground = mStopForeground = null;
   }
   }

   /**
   * This is a wrapper around the new startForeground method, using the older
   * APIs if it is not available.
   */
   void startForegroundCompat(int id, Notification notification) {
   // If we have the new startForeground API, then use it.
   if (mStartForeground != null) {
   mStartForegroundArgs[0] = Integer.valueOf(id);
   mStartForegroundArgs[1] = notification;
   try {
   mStartForeground.invoke(this, mStartForegroundArgs);
   } catch (InvocationTargetException e) {
   // Should not happen.
   Log.w("MyApp", "Unable to invoke startForeground", e);
   } catch (IllegalAccessException e) {
   // Should not happen.
   Log.w("MyApp", "Unable to invoke startForeground", e);
   }
   return;
   }

   // Fall back on the old API.
   setForeground(true);
   mNM.notify(id, notification);
   }

   /**
   * This is a wrapper around the new stopForeground method, using the older
   * APIs if it is not available.
   */
   void stopForegroundCompat(int id) {
   // If we have the new stopForeground API, then use it.
   if (mStopForeground != null) {
   mStopForegroundArgs[0] = Boolean.TRUE;
   try {
   mStopForeground.invoke(this, mStopForegroundArgs);
   } catch (InvocationTargetException e) {
   // Should not happen.
   Log.w("MyApp", "Unable to invoke stopForeground", e);
   } catch (IllegalAccessException e) {
   // Should not happen.
   Log.w("MyApp", "Unable to invoke stopForeground", e);
   }
   return;
   }

   // Fall back on the old API. Note to cancel BEFORE changing the
   // foreground state, since we could be killed at that point.
   mNM.cancel(id);
   setForeground(false);
   }

Service lifecycle changes

Another situation we were increasingly seeing in 1.6 was that, even ignoring the services that inappropriately make themselves foreground, we had a growing number of devices with a large number of services running in the background all fighting each other over the available memory.

Part of this problem is services that are running more than they should or there simply being too much stuff trying to be done on the device. However, we also found many issues in the interaction between services and the platform that made it easy for an application to leave a service running even when it is trying to do the right thing. Consider this typical scenario:

An application calls startService().
That service gets onCreate(), onStart(), and then spawns a background thread to do some work.
The system is tight on memory, so has to kill the currently running service.
Later when memory is free, the service is restarted, and gets onCreate() called but not onStart() because there has not been another call to startService() with a new Intent command to send it.
Now the service will sit there created, not realizing it used to be doing some work, and so not knowing it should stop itself at some point.

To address this, in Android 2.0 Service.onStart() as been deprecated (though still exists and operates as it used to in previous versions of the platform). It is replaced with a new Service.onStartCommand() callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:

START_STICKY is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.
START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.
START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.
For compatibility with existing applications, the default return code for applications that are targeting an earlier version of the platform is a special START_STICKY_COMPATIBILITY code that provides the old behavior of not calling onStart() with a null intent. Once you start targeting API version 5 or later, the default mode is START_STICKY and you must be prepared to deal with onStart() or onStartCommand() being called with a null Intent.

You can also easily write a Service that uses both the old and new APIs, depending on the platform. All you need to do is compile against the 2.0 SDK with this code:

   // This is the old onStart method that will be called on the pre-2.0
   // platform. On 2.0 or later we override onStartCommand() so this
   // method will not be called.
   @Override
   public void onStart(Intent intent, int startId) {
   handleStart(intent, startId);
   }

   @Override
   public int onStartCommand(Intent intent, int flags, int startId) {
   handleStart(intent, startId);
   return START_NOT_STICKY;
   }

   void handleStart(Intent intent, int startId) {
   // do work
   }

New "running services" user interface

Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.

To help address this, Android 2.0 introduces a new "Running Services" activity available from the Application system settings. When brought up, it looks something like this:

The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:

GTalkService is part of the standard Google application suit; it is running in Google's "gapps" process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.
ActivityService is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.
SoftKeyboard is a third party input method. It has been running since I switched to it, about 4 minutes ago.
The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it:

Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system's input settings).

Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:

Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)
For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing "task killer" applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.

For developers, this is an important tool to ensure your services are well behaved. As you develop your app, be sure to keep an eye on Running Services to ensure that you are not accidentally leaving your services running when they shouldn't be. You should also now keep in mind that users may freely stop any of your services as they wish, without your control, and account for that.

Android's Services are a very powerful tool, but one of the main and subtle ways that application developers can harm the overall experience a user has with their phone.

Live wallpapers

2010-02-17T23:05:38+09:00

[출처 : Android Developers Blog]

With the introduction of live wallpapers in Android 2.1, users can now enjoy richer, animated, interactive backgrounds on their home screen. A live wallpaper is very similar to a normal Android application and has access to all the facilities of the platform: SGL (2D drawing), OpenGL (3D drawing), GPS, accelerometers, network access, etc. The live wallpapers included on Nexus One demonstrate the use of some of these APIs to create fun and interesting user experiences. For instance, the Grass wallpaper uses the phone's location to compute sunrise and sunset times in order to display the appropriate sky.

Creating your own live wallpaper is easy, especially if you have had previous experience with SurfaceView or Canvas. To learn how to create a live wallpaper, you should check out the CubeLiveWallpaper sample provided with the Android 2.1 SDK; you will find it in the directory platforms/android-2.1/samples/CubeLiveWallpaper.

A live wallpaper is very similar to a regular Android service. The only difference is the addition of a new method, onCreateEngine() whose goal is to create a WallpaperService.Engine. The engine is responsible for handling the lifecycle and the drawing of a wallpaper. The system provides you with a surface on which you can draw, just like you would with a SurfaceView. Drawing a wallpaper can be very expensive so you should optimize your code as much as possible to avoid using too much CPU, not only for battery life but also to avoid slowing down the rest of the system. That is also why the most important part of the lifecycle of a wallpaper is when it becomes invisible. When invisible, for instance because the user launched an application that covers the home screen, a wallpaper must stop all activity.

The engine can also implement several methods to interact with the user or the home application. For instance, if you want your wallpaper to scroll along when the user swipes from one home screen to another, you can use onOffsetsChanged(). To react to touch events, simply implement onTouchEvent(MotionEvent). Finally, applications can send arbitrary commands to the live wallpaper. Currently, only the standard home application sends commands to the onCommand() method of the live wallpaper:

android.wallpaper.tap: When the user taps an empty space on the workspace. This command is interpreted by the Nexus and Water live wallpapers to make the wallpaper react to user interaction. For instance, if you tap an empty space on the Water live wallpaper, new ripples appear under your finger.
android.home.drop: When the user drops an icon or a widget on the workspace. This command is also interpreted by the Nexus and Water live wallpapers.

Please note that live wallpaper is an Android 2.1 feature. To ensure that only users with devices that support this feature can download your live wallpaper, remember to add the following to your manifest before releasing to Android Market:

<uses-sdk android:minSdkVersion="7" />, which lets Android Market and the platform know that your application is using the Android 2.1 version.
<uses-feature android:name="android.software.live_wallpaper" />, which lets the Android Market and the platform know that your application is a live wallpaper.

Many great live wallpapers are already available on Android Market and we can't wait to see more!

Android SDK 2.1 Release 1

2010-01-21T17:10:02+09:00

[출처 : Android Developer]

Android 2.1, Release 1 SDK가 1월 12일(?) 쯔음...발표 되었습니다.

요즘 업무에 치여 살다 보니 약간 늦게 정리를 합니다....

http://developer.android.com/sdk/android-2.1.html

API Level : 7

This release includes new API changes and bug fixes. For information on changes, see the Framework API section.

Android 2.1 does not add significant user features, see the Android 2.0 Platform Highlights document for the latest user features.

Android 2.1 SDK에서는 Platform features는 2.0과 동일하고 Framework API에 새로운 API와 bug가 수정되어 졌네요.

Framework API

The sections below provide information about changes made to the application framework API provided by the Android 2.1 platform.

API level

The Android 2.1 platform delivers an updated version of the framework API. The Android 2.1 API is assigned an integer identifier — 7 — that is stored in the system itself. This identifier, called the "API Level", allows the system to correctly determine whether an application is compatible with the system, prior to installing the application.

To use APIs introduced in Android 2.1 in your application, you need to set the proper value, "7", in the attributes of the <uses-sdk> element in your application's manifest.

For more information about how to use API Level, see the API Levels document.

API changes summary

The following is a summary of some notable changes to the framework APIs.

Live Wallpapers

The following additions provide APIs for you to develop animated wallpapers:

New android.service.wallpaper package.
New WallpaperInfo class.
Updated WallpaperManager.

Telephony

New SignalStrength class provides information about the device's current network signal. This can be acquired from the new onSignalStrengthsChanged(SignalStrength) callback.
New onDataConnectionStateChanged(int, int) callback.

Views

New View methods isOpaque() and onDrawScrollBars(Canvas).
New RemoteViews methods addView(int, RemoteViews) and removeAllViews(int).
New ViewGroup methods isChildrenDrawingOrderEnabled() and setChildrenDrawingOrderEnabled(boolean).

WebKit

New WebStorage methods to manipulate web storage databases.
New GeolocationPermissions methods to get Geolocation permissions from, and set them on the WebView.
New WebSettings methods to manage settings for app cache, web storage, and zooming based on screen density.
New WebChromeClient methods for handling video, browsing history, custom Views, app cache limits, and more.

API differences report

For a detailed view of all API changes in Android 2.1 (API Level 7), as compared to API Level 6, see the API Differences Report.

Nexus One Phone 공식 발표

2010-01-06T12:10:07+09:00

오늘 새벽 Google에서 드디어 Nexus One을 공식 발표를 하였습니다.

공식 사이트 : http://www.google.com/phone/

Nexus One의 가격은 T-Mobile(2년 약정) : $179, 언락 : $529 입니다.

48개 국가에 판매가 될 예정이라고 되어있으며 한국은 역시 미정입니다.

공식 발표의 내용 중에서 DEMO 중에서는 거의 완벽에 가까운 음성인식을 확인 할 수 있습니다.

Gmail을 음성으로 쓰거나, 구글어스의 음성검색 모드나 텍스트 필드의 입력을 음성....

Q&A를 확인해 보면 구글은 판매만 하게 되고 디자인이나 생산, 유통은 HTC가 하였다고 합니다.

이 홈페이지를 통해 상세한 스펙이나 3D 체험, 그리고 주문을 할 수 있습니다.

출시는 미국을 시작으로 영국, 싱가폴, 홍콩에서 먼저 출시가 되고 나머지 국가들도 차차 출시가 될 예정입니다.

nexus one 주요 스펙

예상대로 Eclair 2.1이 올라가 있습니다.

Qualcomm QSD 8250 1GHz Processor

800 x 480 AMOLED touchscreen

5 megapixels Camera

Wi-Fi, AGPS

조도와 근접 센서

오 Korean이 보이는 군요....하지만 입력은 불가능 하네요....ㅋ

구글 폰이라 불리던 nexus one, 하지만 구글이 만들진 않았다.

구글이 한 일은 HTC가 내놓은 최고의 하드웨어 단말에 맞도록 최적화를 해준거네요...

그리고 Android 2.1 탑재

2.0과 2.1이 많이 차이나기를 바라는 사람들이 많았던 거 같습니다.

2.1을 사용해본 체험기에서 유독 눈에 띄는게 속도만 빨라진 드로이드라는 소리였습니다.

드로이드가 출시 되었을 때 모토로라가 발 빠르게 2.0을 출시하였지 HTC처럼 자신만의 UI를 올렸다고 생각되어 지진 않았기에

이번 nexus one이 출시 되어 질 때도 2.1을 올린 Android Phone이 출시가 되는거라 생각 했었는데

사람들의 기대는 2.1이 UI적으로 많이 개선 되기를 바랬던거 였을까요?....

이번 nexus one의 공식 발표에서 가장 커다란 변화는 역시 판매 방식의 변화일 것 같습니다.

구글이 판매를 담당하지만 자신들의 비지니스 모델은 광고라며 거의 판매 수익을 챙기지 않는다고 하네요.

이번 nexus one이 다른 Android Phone과 다른점이 spec, version 뿐이라서 실망했을 수도 있습니다.

하지만 Google, HTC, 모토로라가 보여주는 Android Phone은 많이 기대가 됩니다.

그리고 LG나 삼성에서도 저정도의 스펙, 최적화된 Android 그리고 국내출시!!! 만 되기를 기대합니다.

아직 자신들 만의 UI로 꾸미지 못해도 좋아요....

우선은 국내에서 첫 발을 내딛기만 해도 의미있다고 생각하니까요...