mirwing's Story

Android NDK r3 & SDK Tools r5, ADT 0.9.6 Release

mirwing — Tue, 09 Mar 2010 07:13:31 +0900

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

mirwing — Wed, 24 Feb 2010 18:48:58 +0900

[출처 : Kandroid]

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

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

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

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

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

Android가 되길 바랍니다.

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

Android Development Environment Setting - SDK/NDK

mirwing — Sun, 21 Feb 2010 15:16:20 +0900

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

mirwing — Wed, 17 Feb 2010 23:05:49 +0900

[출처 : 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

mirwing — Wed, 17 Feb 2010 23:05:38 +0900

[출처 : 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

mirwing — Thu, 21 Jan 2010 17:10:02 +0900

[출처 : 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 공식 발표

mirwing — Wed, 06 Jan 2010 12:10:07 +0900

오늘 새벽 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로 꾸미지 못해도 좋아요....

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

Android SDK Tools - traceview -

mirwing — Mon, 04 Jan 2010 18:01:27 +0900

traceview

Traceview_A_Graphical_Log_Viewer.pdf

[ Developer Android ]

[ 예제로 시작하는 안드로이드 개발(에이콘/릭 로저스 외 지음/ 978-89-6077-097-3) ]

APP이 제대로 동작한다고 해도 너무 느릴 수 있다. 애플리케이션 내 메소드가 서로 어떻게 상호작용하는지 알고 각 메소드에서 머무는 시간이 얼마인지 측정할 수 있다.

이 프로그램은 두 개의 부분으로 나뉘는데 첫째는 애플리케이션을 실행하기 전에 돌려야 하고, 나머지 부분은 실행을 마치고 나서 분석하기 위해 돌려야 한다.

런타임 데이터 수집

애플리케이션 로그를 켜거나 끌 수 있다. 이 기능을 켜두면 트레이스 수집용 메소드가 애플리케이션에 링크돼 타겟 시스템에 바이너리 트레이스 파일을 만든다. 이 트레이스 파일에는 모든 메소드 초기화와 각 메소드에서 머문 시간의 기록이 있다.

트레이스 분석

이 바이너리 트레이스 파일을 타겟 장치에서 컴퓨터로 복사한 후 트레이스 분석 프로그램을 돌려 파일의 모든 정보를 그래픽 환경에서 볼 수 있다. 애플리케이션이 어느 메소드에서 가장 많은 시간을 소비하는지, 그리고 해당 메소드는 또 어느 메소드를 호출 하고, 거기에서는 얼마나 많은 시간을 소비하는지를 알아볼 수 있다.

트레이스 데이터 수집

애플리케이션에 디버그 패키지(android.os.Debug)를 import한다.
트레이스 정보 수집을 시작하려는 지점에서 Debug.startMethodTracing()을 호출한다.
수집을 멈추려는 지점에서 Debug.stopMethodTracing()을 호출한다.

이 메소드는 항상 트레이스 정보를 타겟 시스템의 SD 카드에 저장한다.

$ adb pull sdcard/x.trace x.trace

$ traceview [pathname]x.trace

New resources and sample code on developer.android.com

mirwing — Mon, 21 Dec 2009 14:15:18 +0900

[원문 : Developer Blog]

Android Developer Guide 문서에 새로운 resources와 sample code들이 추가 되었습니다.

추가된 목록들은 아래에 있습니다.

The new sample code includes:

Multiple Resolutions: a simple example showing how to use resource directory qualifiers to support multiple screen configurations and Android SDK versions.
Wiktionary and WiktionarySimple: sample applications that illustrate how to create an interactive home screen widget.
Contact Manager: an example on using the new ContactsContract interface to query and manipulate a user's various accounts and contact providers.
Bluetooth Chat: a fun little demo that allows two users to have a 1 on 1 chat over Bluetooth. It demonstrates how to discover devices, initiate a connection, and transfer data.
API Demos > App > Activity > QuickContactsDemo: a demo showing how to use the android.widget.QuickContactsBadge class, new in Android 2.0.
API Demos > App > Activity > SetWallpaper: a demo showing how to use the new android.app.WallpaperManager class to allow users to change the system wallpaper.
API Demos > App > Text-To-Speech: a sample using Text-To-Speech (speech synthesis) to make your application talk.
NotePad (now with Live Folders): this sample now includes code for creating Live Folders.

Knowing is half the battle

mirwing — Mon, 21 Dec 2009 14:00:19 +0900

[원문 : Developer Blog]

Posted by Raphaël Moll on 17 December 2009 at 9:00 AM

As a developer, I often wonder which Android platforms my applications should support,especially as the number of Android-powered devices grows. Should my application only focus on the latest version of the platform or should it support older ones as well?

To help with this kind of decision, I am excited to announce the new device dashboard. It provides information about deployed Android-powered devices that is helpful to developers as they build and update their apps. The dashboard provides the relative distribution of Android platform versions on devices running Android Market.

Android Platform	Percentage of Devices
1.1	0.3%
1.5	27.7%
1.6	54.2%
2.0	2.9%
2.0.1	14.8%

The above graph shows the relative number of Android devices that have accessed Android Market during the first 14 days of December 2009.

From a developer's perspective, there are a number of interesting points on this graph:

At this point, there's little incentive to make sure a new application is backward compatible with Android 1.0 and Android 1.1.
Close to 30% of the devices are running Android 1.5. To take advantage of this significant install base, you may consider support for Android 1.5.
Starting with Android 1.6, devices can have different screen densities & sizes. There are several devices out there that fall in this category, so make sure to adapt your application to support different screen sizes and take advantage of devices with small, low density (e.g QVGA) and normal, high density (e.g. WVGA) screens. Note that Android Market will not list your application on small screen devices unless its manifest explicitly indicates support for "small" screen sizes. Make sure you properly configure the emulator and test your application on different screen sizes before uploading to Market.
A new SDK for Android 2.0.1 was released two weeks ago. All Android 2.0 devices will be updated to 2.0.1 before the end of the year, so if your application uses features specific to Android 2.0, you are encouraged to update it to take advantage of the latest Android 2.0.1 API instead.

In summary, Android 1.5, 1.6, and 2.0.1 are the 3 versions of the platform that are deployed in volume. Our goal is to provide you with the tools and information to make it easy for you to target specific versions of the platform or all the versions that are deployed in volume.

We plan to update the dashboard regularly to reflect deployment of new Android platforms. We also plan to expand the dashboard to include other information like devices per screen size and so on.