출처 : http://blog.daum.net/bluebread/15



안드로이드에서 git을 사용하는데 적응이 안되는 부분이 변경사항을 보는 것입니다.

(물론 gerrit을 사용하는 환경이라면 또다른 이야기입니다.)


araxis merge 나 beyond compare 와 같은 디렉토리 비교툴에 익숙하시다면, git diff의 결과물이 낮설겁니다.


git diff 의 표시형식은 다음과 같이 - + 로 추가 삭제된 내용을 표시합니다.


이런 diff 형식이 낮선 분들은 git difftool을 사용하여 다음과 같은 좌우로 비교창을 열어 볼 수도 있습니다. (vimdiff를 사용한 예)



위에서는 vimdiff를 사용하였지만, git difftool은 실행할 파일을 지정할 수가 있습니다.

이 기능을 이용하여 (git difftool의 help를 보십시오.) diffzip.sh 라는 스크립트를 만들었습니다.

변경 이전과 이후의 바뀐 파일들만을 diff_old/diff_new 디렉토리로 정리해 zip을 해주는 유틸리티입니다.


일단 소스를 보시면 다음과 같습니다.

diffzip.sh

#!/bin/bash
if [ -f diff.zip ]
then
rm diff.zip
fi
git difftool -y -x '~/oldnew.sh' $@
zip -r diff.zip diff_new diff_old
rm -rf diff_new
rm -rf diff_old

oldnew.sh

#!/bin/bash

function bury_copy()
{
mkdir -p `dirname $2` && cp "$1" "$2";
}

$(bury_copy $1 diff_old/$BASE)
$(bury_copy $2 diff_new/$BASE)


diffzip.sh 의 사용법은 다음과 같습니다.

0. 전제조건

- git version이 1.7.4 이상이라야 합니다. (git difftool이 $BASE 변수를 제대로 설정하여야 하기 때문에 필요합니다.)

- zip 이 설치되어 있어야 합니다. 저는 다음 버전을 사용했습니다. Zip 3.0 (July 5th 2008), by Info-ZIP.


1. diffzip.sh 와 oldnew.sh를 ~/ 디렉토리에 만듭니다.

2. 두 스크립트를 실행가능하게 만듭니다.
chmod +x diffzip.sh
chmod +x oldnew.sh

3. git 디렉토리에서 ~/diffzip.sh 를 실행하면 diff.zip 파일이 생깁니다.

실행화면은 다음과 같습니다.


이 zip 파일에는 diff_old/ 와 diff_new/ 라는 디렉토리가 들어있고 변경파일들만 포함되어 있습니다


4. 이 diff.zip 파일을 풀어보면 다음과 같이 변경사항들이 들어있게 됩니다.


내가 변경한 내용을 다른 사람에게 보여줄 때 매우 유용합니다.

즉. 코드 리뷰시에 쓸모가 있지요.

32bit framebuffer를 png로 바꾸는 perl script

ex) cat /dev/graphics/fb0 > /sdcard/fb0.dat

./fb2png 768 1024  < fb0 > screen3.png

#!/usr/bin/perl -w

 $w = shift || 240; 

 $h = shift || 320; 

 $pixels = $w * $h; 

 open OUT, "|pnmtopng" or die "Can't pipe pnmtopng: $!\n"; 

 printf OUT "P6%d %d\n255\n", $w, $h; 

 while ((read STDIN, $raw, 4) and $pixels--) { 

   $long = unpack('L', $raw); 

   print OUT pack("C3",

    ($long & 0x000000ff),

    ($long & 0x0000ff00) >> 8,

    ($long & 0x00ff0000) >> 16,

    ); 

 } 

 

 close OUT; 



$ ioctl -h 
ioctl -h 
ioctl [-l <length>] [-a <argsize>] [-rdh] <device> <ioctlnr> 
  -l <lenght>   Length of io buffer 
  -a <argsize>  Size of each argument (1-8) 
  -r            Open device in read only mode 
  -d            Direct argument (no iobuffer) 
  -h            Print help 


I tried on Tiny6410. Using ioctl one can turn on and off the leds


To turn on led3 
# ioctl  -d  /dev/leds 1 3
sending ioctl 0x1 0x03 0x00 0x00 0x00
return buf: 03 00 00 00

To tun off led3
 # ioctl  -d  /dev/leds 0 3
sending ioctl 0x0 0x03 0x00 0x00 0x00
return buf: 03 00 00 00

Hope this helps.

로그 보는데 이만한게 없다.

커널로그도 되고 ini 파일을 편집해서 자기가 원하는데로 커맨드를 추가 할수도 있다.

하기 주소에서 받으면 된다.

http://blog.naver.com/iookill/140135139931


하기는 내가 쓰는 LogFilterCmd.ini 내용

CMD_COUNT=10

CMD_0=shell cat /proc/kmsg

CMD_1=logcat -v time -b main

CMD_2=logcat -v time -b radio

CMD_3=logcat -v time -b events

CMD_4=logcat -v time -b system

CMD_5=logcat -v time -b main -b radio -b system -b events

CMD_6=logcat -v time -b main -b system

CMD_7=logcat -v time -b main -b radio

CMD_8=logcat -v threadtime

CMD_9=root


기본적으로 리커버리 종료시 "/cache/recovery/log" 에 저장된다.

만약 recovery 디버그 메세지를 커널 메세지로 실시간으로 보고 싶을때 하기처럼 바꿔주면 된다.

static const char *TEMPORARY_LOG_FILE = "/tmp/recovery.log"; 를

static const char *TEMPORARY_LOG_FILE = "/dev/kmsg"; 로



Tip) user 영역에서 커널 메세지를 찍고 싶을땐 /dev/kmsg에 써주면 된다.

http://www.androidpub.com/1123776


Android New Gingerbread API: StrictMode

[이 포스트는 어플리케이션 반응 속도에 광적으로 집착하는 Brad Fitzpatrick 에 의해 작성되었습니다. - Tim Bray]


배경 이야기

 구글의 장점 중 하나는 바로 '20% 시간' 제도 입니다. 20%의 시간 만큼 여러분이 원하는 프로젝트를 진행할 수 있는 제도이지요. 처음 구글에 입사했을 때, 여기 저기 돌아다니며, 저는 7개의 20% 프로젝트를 진행하고 있다고 농담을 하곤 했습니다. 그리고 그 중 하나가 바로 안드로이드 관련된 일입니다. 저는 안드로이드의 개방성을 사랑합니다. 제가 원하는 것이라면 무엇이든 할 수 있거든요. 심지어, 오토바이를 타고 집에 돌아올 때 쯤 알아서 창고 문을 열어주는 일도 가능합니다. (음...아마도 그런 자작 어플리케이션을 짠 듯?)  안드로이드가 꼭 성공했으면 하는데, 한 가지 아쉬운 점이 있습니다. 안드로이드 플랫폼은 늘 부드럽게 동작하지는 않습니다. 애니매이션은 가끔 뚝뚝 끊기는도 하고, 사용자가 버튼을 눌러도 한 동안 아무 일도 벌어지지 않을 때도 있습니다. 결코 멈춰서서는 안되는 메인 스레드에서 뭔가 잘못된 일이 벌어지고 있음에 틀림 업습니다.

 저는 SMS 를 많이 활용합니다. 그래서, 20% 프로젝트 중 하나로, Cupcake(Android 1.5) 릴리즈 당시 안드로이드 메세징 어플리케이션의 속도를 향상 시키는 일을 하기도 했었지요. 제법 많은 개선이 이루어졌습니다. 그리곤 잠시 다른 일을 하다가, 어느날인가 안드로이드  Donut(Android 1.6)이 릴리즈되고 나서 보니, 이런... 제가 구현한 최적화들이 모두 망가져 있더군요. 우울했습니다. 그리고 생각했조. 보다 근본적으로, 안드로이드 플랫폼에 내장된,  어플리케이션 성능을 모니터링 할 수 있는 방법이 필요하다는 것을 깨닭았습니다.

 그래서 1년 전쯤 안드로이드 팀에 풀타임으로 합류하여, 프로요의 성능 이슈 문제 특히 ANR 관련된 문제를 조사하는데 오랜 시간을 들였습니다. ANR 혹은 어플리케이션의 성능 문제를 디버깅 하는 것은 어렵고 지루한 일이었습니다. 어떻게 원인을 찾아야 하는지 명확하게 설명해놓은 문서도 없더군요. 특히나, 여러 프로세스가 연관된 문제(Binder, ContentResolver, Service, ContentProvider 등과 연관된)는 최악입니다. 무언가 좀 더 나은 방법이 필요했습니다.

여러분은 지금 StrictMode 에 진입하였습니다.

"당신은 지금 16 ms 제한 구역에서 120 ms 로 달리고 있습니다..."

 StrictMode 는 진저브레드에서 추가된 새로운 API 입니다. 여러분이 특정 스레드에서 일어날 수 없는 일들을 미리 규약(Policy)으로 지정한 후, 만일 그런 사태가 벌어졌을 때 어떤 처리(Penalty)를 할지 결정할 수 있겠도와줍니다. 각각의 규약은 개별 스레드의 로컬 정수형 변수의 비트마스크 형식으로 구현되어있습니다. 기본적으로 스레드에서는 무슨일이든 허용됩니다. 그리고 여러분은 아래의 플래그들을 이용해서 하나씩 하나씩 규약 조건을 추가할 수 있습니다.

  • 규약: detect disk writes - 디스크 쓰기 작업
  • 규약: detect disk reads - 디스크 읽기 작업
  • 규약: detect network usage - 네트워크 사용
  • 위반 시: log - 로그를 남기기
  • 위반 시: crash - 강제 종료시키기
  • 위반 시: dropbox - dropbox 에 기록하기
  • 위반 시: show an annoying dialog - 다이얼로그 박스 띄우기

 이런 저런 조건이 설정 되고 나면, StrictMode 는 해당 스레드에서 디스크 I/O 작업이 일어나는 경우 (java.io.*, android.database.sqlite.* 등) 혹은 네트워크 작업 (java.net.*) 이 일어나는 경우, Policy 를 확인 하고 적절한 조치를 취하게 됩니다.

 StrictMode 의 또 하나의 중요한 특징은 바로 는 특정 Policy 가 적용된 스레드 내부에서 Binder IPC 를 통해 다른 스레드 혹은 다른 프로세스의 메서드를 사용하는 경우에도 동일한 Policy 가 적용된다는 점 입니다. 예를 들어, 디스크 읽기가 금지된 스레드 내에서 외부 ContentProvider 를 통해 디스크를 읽어 들이는 경우에도 해당 사실이 탐지되며, 이와 관련된 Stack Trace 정보가 전달됩니다. 이는 한 스레드에 적용된 Policy 가 이 스레드에서 접근 하는 다른 스레드에도 전파될 수 있도록 구현되어있기 때문입니다.

느릿 느릿 움직이는 어플리케이션을 좋아하는 사람은 아무도 없습니다.

 여러분은 직접 작성하신 어플리케이션의 어떤 곳에서 디스크 I/O 작업을 수행하는지는 전부 알고 계실 수도 있습니다. 하지만 사용하고 있는 시스템 서비스와 프로바이더가 디스크 I/O 작업을 하고 있는 부분은 어떨까요? 저는 자신 없습니다. 살펴봐야할 내용이 너무 많더군요. 물론, 안드로이드 개발팀은 성능에 문제를 일으킬 수 있는 API 가 있는 경우 해당 내용을 SDK 문서에 명시하고 있습니다. 하지만, 이제는 SDK 문서를 샅샅히 뒤지는 대신 무심코 메인 스레드에서 I/O 작업을 수행하는 부분을 찾아내기 위하여 StrictMode 를 사용하고 있습니다.

휴대폰 메모리에 관하여 

 그런데 잠깐, "디스크 I/O 작업을 하는게 뭐가 문제인거조? 안드로이드 디바이스는 모두 플레쉬 메모리를 갖고 있잖아요? 그거 엄청 빠른 SSD 같은거 아닌가요? 디스크 I/O 작업이 좀 있다 한 들 별로 상관 없을거 같은데..." 라고 생각하시는 분들이 있을지도 모르겠네요. 하지만 불행히도 이는 사실이 아닙니다.

 여러분은 안드로이드 디바이스에서 사용되는 플래쉬 메모리 혹은 파일 시스템이 늘 빠를 거라고 가정해서는 안됩니다. 예를 들어,현재 많은 안드로이드 디바이스에서 사용하고 있는 YAFFS(Yet Another Flash File System) 파일 시스템은 I/O 작업을 한 때 Global 범위의 락이 사용됩니다. 즉, 전체 디바이스 상에서 오직 한 번에 하나의 디스크 작업만이 가능한 것이지요. 따라서, 운이 나쁘다면 아주 단순히 'stat' 메서드를 사용하는 데에도 제법 긴 시간이 걸릴 수 있습니다. 전통적인 Block 기반의 파일 시스템을 사용하는 다른 디바이스라 하더라도, 파편화된 블럭을 모으기 위한 GC 작업이 수행되거나 플래쉬 메모리에서는 매우 오랜 시간이 걸리는 삭제 작업이 이루어지고 있는 중이라면 I/O 요청을 수행하는데 오랜 시간이 걸릴 수 있습니다. (보다 자세한 배경 지식이 알고 싶으시다면 lwn.net/Articles/353411 를 참조하세요.) 모바일 디바이스에서 디스크 (혹은 파일 시스템) I/O 작업의 90% 정도는 생각보다 느립니다. 더군다나 메모리 여유 공간이 적어지면 적어질 수록 더더욱 느려지지요. (다음 슬라이드를 확인해 보세요. Google I/O Zippy Android apps talk)

메인 스레드

 안드로이드 콜백과 라이프 사이클 관련된 이벤트들은 모두 메인 스레드(UI 스레드)에서 처리됩니다. 다시 말해, 모든 애니매이션, 스크롤 그리고 플리핑 프로세스들도 전부 이 메인 스레드에서 콜백 형식으로 처리 됩니다. 따라서, 예를 들어 여러분이 60fps 로 동작하는 애니매이션을 진행하면서 동시에 사용자의 입력을 처리하고자 한다면, 여러분이 메인 스레드 상에서 사용자의 입력에 반응 하는데 사용할 수 있는 시간은 오직 16ms 뿐입니다. 만일 I/O 작업 혹은 다른 이유로 인해 이보다 오랜 시간이 걸릴 경우, 애니매이션이 버벅되기 시작 할 것 입니다. 물론 일반적인 경우, 단순한 디스크 읽기 작업에 16ms 의 시간이 걸리지는 않겠지만, 상황에 따라 꼭 그런 것 만도 아닙니다. YAFFS 파일 시스템의 경우라면 다른 프로세스에서 디스크 쓰기 작업을 위해 락을 잡고 있는 경우 그런 일이 빈번하게 발생 할 수 있습니다.

 네트워크는 특히나 더욱 느리고 예측 불가합니다. 따라서, 메인스레드에서는 절대로 네트워크 작업을 해서는 안됩니다. 사실, 앞으로 공개될 허니컴에서는 메인스레드에서 네트워크 작업이 일어나는 경우 이를 치명적인 에러로 인지하고 프로그램을 종료시켜버릴 예정입니다. 다시 한번 강조하지만, 만일 여러분의 어플리케이션이 허니컴 이 후 버전에서도 잘 동작하길 원하신다면, 절대로 UI 스레드 상에서 네트워크 작업을 해서는 안됩니다.

StrictMode 사용하기

 추천되는 방식은 다음과 같습니다. 여러분이 어플리케이션을 개발하는 동안에는 StrictMode 를 켜 두세요. 발생하는 여러가지 오류를 수정하고 어플리케이션 성능을 향상시키시기 바랍니다. 그리고 마지막에 어플리케이션을 릴리즈 시에는 이 기능을 비활성화 시켜 두시면 됩니다.

예를 들어 여러분의 어플리케이션의 onCreate() 시점에 다음과 같은 내용을 추가 하실 수 있습니다.
 public void onCreate() {
     if (DEVELOPER_MODE) {
         StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                 .detectDiskReads()
                 .detectDiskWrites()
                 .detectNetwork()
                 .penaltyLog()
                 .build());
     }
     super.onCreate();
 }
 혹은 간단히,
    public void onCreate() {
     if (DEVELOPER_MODE) {
         StrictMode.enableDefaults();
     }
     super.onCreate();
 }
 이렇게 하실 수도 있습니다. 아래쪽의 간단한 메서드 StrictMode.enableDefaults() 는 개발자 분들이 진저브레드 이전 버전을 타켓으로 어플리케이션을 개발할 때도 손쉽게, reflection 등을 이용하여, StrictMode 를 사용할 수 있도록 돕기위해 추가되었습니다. 예를 들어, 여러분의 1.6 도넛 타켓 어플리케이션을 개발하면서, 진저 브레드 에뮬레이터 혹은 디바이스 상에서 Strict Mode 를 이용하여 해당 어플리케이션을 테스트 할 수 있습니다. Reflection 을 이용하여 StrictMode.enableDefaults() 만 호출 하시면 말이지요.

StrictMode 결과를 살펴보기

 만일 기본 모드인 penaltyLog() 를 사용한다면, 특정 규약을 위반하는 경우가 발생하는 순간 해당 내용이 로그캣 콘솔에 출력됩니다. 만일 좀 더 멋진 결과를 원하신다면, penaltyDropbox() 를 사용하세요. 이 경우 규약 위반 내용이 DropBoxManager 에 쓰여지며, 이 후에 필요할 때, adb shell dumpsys sropbox data_app_strictmode --print 명령을 통해 해당 내용을 확인 하실 수 있습니다.

어플리케이션을 부드럽게 만들기 위한 팁들

 스레드와 java.util.concurrent.* 패키지를 활용하세요. 그리고 Handler, AsyncTask, AsyncQueryHandler, IntentService 등의 안드로이드 API 를 활용하시기 바랍니다.

구글 팀도 StrictMode 를 유용하게 사용하였습니다.

 안드로이드를 개발하면서 우리는 매일 매일 내부 개발자 버전 ("dogfood" 빌드)을 릴리즈하여 직접 사용해봅니다. 그리고 진저 브레드 버전을 개발하는 동안에는 StrictMode 로깅기능을 켜놓고 모든 로그를 출력해 보았습니다. 매시간 MapReduce Job 이 돌면서, 엄청난 양의 로그를 정리하고 의미있는 리포트를 출력했지요. 이벤트 루프가 멈칫 거리는 경우의 Stack Trace 정보와, Latency 퍼센트, 어떤 프로세스 혹은 패키지가 문제를 일으키는가 등등...

 StrictMode 를 사용해서 우리는 플랫폼 전체적으로 응답성을 저해하고 애니매이션에 문제를 일으킬 수 있는 수백개에 달하는 버그를 수정하였습니다. 특정 어플리케이션에 관련된 문제들 뿐만 아니라, 시스템 코어 쪽에도 성능 최적화가 이루어졌습니다. 만일 여러분이 지금 프로요 버전을 사용하고 있더라도, 최신 GMail, Google Maps, YouTube 등의 어플리케이션을 업데이트 받으신다면 StrictMode 를 통해 개선된 성능을 직접 체험하실 수 있을 것 입니다.

 시스템 내부적으로 성능을 개선하는데 한계가 있는 몇몇 경우에는 새로운 API 를 추가하기도 하였습니다. 예를 들어, SharedPreferences.Editor.apply() 메서드가 추가되었습니다. 이 메서드는 기존의 commit() 대신에 사용하실 수있습니다. 만일 여러분이 commint() 메서드의 리턴 값을 확인 할 필요가 없다면. (사실 이 값을 확인 하는 사람은 아무도 없더군요.) 물론 여러분은 reflection 을 통하여 사용자 플랫폼에 따라 apply() 혹은 commit 가 호출 되도록 구현할 수도 있습니다.

 프로요를 사용하다가 진저버드로 갈아타신 분들은 시스템의 반응성이 굉장히 좋아진 것을 보고 깜짝 놀라실 겁니다. 우리 이웃의 크롬 팀도 최근 StrictMode 와 유사한 기능을 추가하였습니다. 물론 성능 향상이전적으로 StrictMode 의 덕분은 아닙니다. 새롭게 추가된 Concurrent GC 도 큰 역할을 하였습니다.

향후 계획

 StrictMode API 는 계속 확장될 것 입니다. 허니컴에 추가될 몇 몇 멋진 기능들은 이미 계획되어있습니다. 그 외에 여러분이 특별히 필요하다고 생각되는 기능이 있으면 언제든지 알려주세요. 우리는 stackoverflow.com 에서 “strictmode” 라고 태그가 붙은 질문들을 늘 모니터링 하고 있습니다.

감사합니다.

http://source-android.frandroid.com/system/core/libcutils/android_reboot.c


특별히 셋팅하지 않는 이상 sync()와 remount_ro()를 수행한뒤 리부팅을 한다.

int android_reboot(int cmd, int flags, char *arg) { int ret; if (!(flags & ANDROID_RB_FLAG_NO_SYNC)) sync(); if (!(flags & ANDROID_RB_FLAG_NO_REMOUNT_RO)) remount_ro(); switch (cmd) { case ANDROID_RB_RESTART: ret = reboot(RB_AUTOBOOT); break; case ANDROID_RB_POWEROFF: ret = reboot(RB_POWER_OFF); break; case ANDROID_RB_RESTART2: ret = __reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, arg); break; default: ret = -1; } return ret; }


1. export INIT_BOOTCHART=true 

경우에 따라 하기 디파인을 강제로 바꿔야 할때가 있다.
android/app/mydroid/system/core/init/bootchart.h
# define BOOTCHART 0 -> 1

2.  touch  system/core/init/*

3. build 한다.

이미지 다운로드후

4. adb shell 로 접속한다.

5. 쉘 프롬프트가 뜨면 아래 문구를 치고 리부팅한다. 120 은 120초 동안 로그를 남기겠다는 뜻.
echo 120 > /data/bootchart-start

재부팅 한후 120초 지나면

6. 하기 커맨드를 입력하면 header / kernel_pacct / proc_diskstats.log / proc_ps.log / proc_stat.log 파일을 가져온다.

adb pull /data/bootchart

7.  로그파일을 bootchart.tgz로 압축한다.

tar zcvf bootchart.tgz header kernel_pacct proc_diskstats.log proc_ps.log proc_stat.log

8. 첨부된 jar를 이용해서 그림으로 추출한다. (JRE나 JDK가 깔려 있어야 한다)

java -jar bootchart.jar ./bootchart.tgz



bootchart.jar



run.cmd



[출처] Bootchart on Android|작성자 kysant

'개발 개발 > Android' 카테고리의 다른 글

Android New Gingerbread API: StrictMod  (3) 2012.09.19
android reboot  (0) 2012.09.18
Bootchart on Android  (0) 2012.07.03
ext4 minimum partition size , ext4 최소 크기  (0) 2012.06.10
adb로 메모리 정보 주기적으로 보기  (0) 2012.05.29
Debugging Deadlocks on Android  (0) 2012.05.24