1) 안드로이드(리눅스)에 대한 기초의 기초의 기초 (해킹) 지식
-- 커널?
-- 리눅스? / 터미널?
--
안드로이드?
-- GPL? 오픈소스?
-- 루팅?
-- 펌웨어? / 롬?
-- 리커버리? / 다운로드 모드?
--
기타 등등...?
2) 안드로이드(넓게 보면 리눅스)
커널 컴파일 방법3) 커스텀 롬 요리
방법
4) 헥스 에디터를 이용한 여러 가지 재미있는(??)
놀이
5) 제 머리에 새로운 정보가 입력되는 대로 추가 예정
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
오랜만입니다.
오늘은 /system/framework 과 /system/app 안의 모든 odex 파일들을 deodex하고
이를 sign한 뒤 최종적으로 update.zip을 만드는 방법을 설명드리겠습니다.
사실 뭐 그리 거창한 작업은 아니고 꼭 필요한
것도 아닙니다.
더군다나 갤럭시S같은 경우에는 리커버리 모드에 update.zip을 설치하는 메뉴가 없기 때문에 롬을 설치하기가
까다롭기까지 합니다.
그렇지만 이런 기초적인 지식은 안드로이드 전반에 쓰이는 것이기 때문에 이렇게 소개를 드리고자
합니다.
프레임워크과 시스템의 어플리케이션을 deodex하는 것에는 크게 2가지의 장점이 있습니다.
1)
테마를 제작할 때 생기는 용량의 제약을 deodex를 함으로써 해소할 수 있다.
(odex 파일을 압축하기에 대략
30~40%의 용량 이득이 있습니다.)
2) 시스템 전반에 걸친 테마 제작을 위해서는 deodex가 되어야 한다.
일단 odex, deodex의 간단한 개념부터 알고
가도록 합시다.
<### odex 파일에 관한 일반적인 설명
###>
기본적으로 안드로이드는 자바 기반의 가상머신을 프로그램 실행의 기본으로
삼습니다. 이녀석이 바로 Dalvik이라는 넘입니다.
dex파일이란 녀석은 달빅머신에 의해 사용되는 Dalvik-cache 를 포함하고 있는데요. 이는
apk파일 안에 들어있습니다.
odex파일은 dex파일을 기기 특성에 맞게 최적화하여 apk의 안에 넣지 않고 apk와
나란히 저장되는 녀석이고, 기본 시스템 어플리케이션들은 모두 apk+odex 형식으로 저장되어 있습니다.
하나의 odex 파일이 생성될 때 BOOTCLASSPATH라는 파일을 불러오고 여기서 이 odex는 해당 BOOTCLASSPATH
파일들에 의존성을 가지게 됩니다. 그러므로 이 odex가 유효하게 사용되기 위해서는 의존성을 가지는
정확한 BOOTCLASSPATH 파일들이 함께 하여야만 하는 것이지요. Dalvik은 각각의 odex 파일이 의존하고 있는
녀석들의 checksum을 저장하고 있다가 해당 odex 파일이 사용될 때 BOOTCLASSPATH와의 checksum이 매치가 되는지 단단히
확인을 합니다.
BOOTCLASSPATH는 메인 어플/jar가 로드될 때 추가적으로 클래스를 불러올 수 있는 jar와 어플들의
리스트입니다.
보통의 안드로이드 시스템에는 5개의 기본 BOOTCLASSPATH가 있습니다.
/system/framework 에 있는 것들이죠)
기본 BOOTCLASSPATH라 함은, 모든 어플들이 이 5개를 기본적으로 참조한다는
말이겠죠?
그러나 몇몇 어플들은 이 기본 jar들 외에 다른 녀석에게 의존성을 가지기도 합니다.
예를 들어보면, 구글 지도를 사용하는
어플리케이션은 위의 기본 5개외에 com.google.android.maps.jar 라는 파일에 의존성을 가지고 있으므로 이를 반드시
BOOTCLASSPATH에 추가해 주어야 한다는 것입니다.
이런 odex의 의존성은 여러 가지 불편한 점이 있습니다.
1)
예를 들어 갤럭시S의 apk+odex를 갤럭시K에 가져와서 실행할 수 없습니다. (익히 알고 계시죠?)
-->> 이 것이
가능하려면 갤럭시K가 갤럭시S와 똑같은 프레임워크 파일들을 사용해야 합니다.
2) BOOTCLASSPATH중 하나에 수정을 가하게 되면
이 녀석에 의존하고 있는 모든 odex 파일들이 사용 불가가 됩니다.
<### Deodex란? ###>
Deodex를 한다는 것은
이렇게 밖으로 나와있는 odex파일들을 apk파일 안으로 되돌려 넣는다는 것을 말합니다. 이를 적용하게 되면 기본적으로 odex파일을 걱정할
필요 없이 쉽게 파일들을 바꿀 수 있습니다. 하지만 이 행위의 주된 목적은 services.jar파일을 deodex함으로써 모든 텍스트의
색깔같은 테마를 변경하는 것이 가능하게 하는 것입니다. 많은 테마변경을 하고자
한다면 롬은 반드시 deodex가 되어야 합니다. 예를 들자면 커스텀 lockscreen 같은 것들은 보통 deodex된 롬을 필요로 합니다.
deodex를 하지 않고서도 몇 가지 테마 수정을 할 수는 있지만, deodex를 하게 됨으로써 더욱 더 많은 변경을 할 수
있습니다.
deodex는 단지 위의 조각들을 원래 어플의 안으로 되돌려 넣는 행위입니다. 이로 인한 장점은
어플들이 효과적으로 수정될 수 있는 점과, 개발자들로 하여금 나눠져 있는 코드의 odex부분때문에 곯머리 썩지 않아도 된다는
것입니다.
결론은 deodex는 odex를 dex로
재컴파일한 다음에 apk 안에 다시 쑤셔 넣는 것을 말합니다.
<### Zipalign이란? ###>
Zipalign을 하게 됨으로써 안드로이드는 어플리케이션과 조금 더 효율적으로 상호작용을 할
수 있게 됩니다. 따라서 이로 인해 전체적인 시스템과 어플리케이션의 실행을 빠르게 할 수 있습니다. 구글에서는 Zipalign을 강하게
권유하는군요. 그래서 했습니다. -_-)
안드로이드에선, 각각의 어플에 적재된 데이터 파일들이 다중 프로세스에 의해 이용됩니다. 홈
어플리케이션은 다른 어플의 이름과 아이콘에 관한 자원을 읽어들이고, 시스템 서버는 다양한 이유때문에 어플의 자원을 읽습니다. 그리고 명백하게,
어플 자기 자신도 자원들을 읽습니다.
안드로이드의 이 자원관리 코드는 4바이트 경계들로 메모리-맵핑
(Wh.....What?..-0-)되었을 때 효율적으로 이용될 수 있습니다. 하지만 이 자원들이 4바이트 정렬이 되지 않는다면, 즉
zipalign이 되지 않는다면, 이를 명확하게 읽기 위한 과정이 필요하므로 약간의 느려짐과 추가적인 메모리 소비를
보입니다.
따라서 우리는 zipalign 툴을 이용해 어플리케이션 자원들을 4바이트로 정렬하는 것입니다.
이제 본격적으로 시작해 볼까요?
아! 그 전에 준비가 필요합니다.
일단 첨부파일을
받아주세요.
그리고 자바 실행 환경 (JRE, Java Runtime Environment)을 설치해주셔야 합니다.
네이버에서 jre 설치라고 검색해 보시면 답이 나올겁니다.
마지막으로 사용하는 운영체제는 우분투를 기준으로
하겠습니다.
>>>>>>>>>>
아래는
deodex를 하는 과정을 간단히 나타낸 것 입니다.
http://code.google.com/p/smali/ 라는
안드로이드 dex 어셈블러/디스어셈블러를 이용합니다.
1. 먼저 baksmali를 이용해 odex 파일을 해체합니다.
이렇게 해체하면 odex가 자바 원시코드들의 모임으로 분해되므로 이 과정에서 코드 수정을 적절하게 가해주면
기존에는
없던 새로운 기능을 추가할 수 있기도 합니다.
2. 이를 smali를 이용해 classes.dex 파일로 다시 뭉쳐줍니다.
3. zip을 이용해서 classes.dex파일을 해당 apk파일 안에 압축합니다.
4. 재생성된 apk를
zipalign합니다.
이제 세부적인 관찰을 해봅시다.
설명은 smali 소스 페이지에 있는 instruction에서
필요한 부분을 알려드리는 것으로 하겠습니다.
1. baksmali로 odex 해체하기
baksmali 에 사용할 수 있는 옵션에는 여러 가지가 있습니다.
-x : 입력된 odex파일을 deodex합니다.
ex) baksmali -x Calculator.dex
-c : BOOTCLASSPATH파일을 지정해 줍니다. (왜 필요한 지는
아시겠죠? 모르시겠으면 위의 odex의 설명을 다시 읽어보세요)
1) 처음부터 콜론(:)으로 시작하는 경우 : 기본 5개
BOOTCLASSPATH에 원하는 jar를 덧붙입니다.
2) 콜론이 없이 그냥 시작하는 경우 : 써준 것만을
BOOTCLASSPATH로 합니다.
ex) blah.odex라는 녀석이 기본 외에
com.google.android.gtalkservice.jar에 추가적으로 의존성을 가지고 있을 때
baksmali -c :com.google.android.gtalkservice.jar -x blah.odex 와
baksmali
-c core.jar:ext.jar:framework.jar:android.policy.jar:services.jar:com.google.android.gtalkservice.jar
-x blah.odex 는 같은 의미임을
아시겠나요?
-d : 필요한
BOOTCLASSPATH 파일들이 같은 디렉토리 안에 있지 않을 때 -d 옵션을 이용해서 지정된 디렉토리 안을
찾아보도록
지시합니다. 이 옵션은 한 번에 하나의 디렉토리만 지정할 수 있으므로 여러 경로를 지정하고 싶으면
-d 옵션을 여러번 써주면
됩니다.
ex) baksmali -d ../framework.jar -x Calculator.dex
2.
smali로 해체된 조각들을 dex파일로 모으기
smali "내보낼 폴더" -o classes.dex 의 명령어를 사용합니다.
ex) smali out -o
classes.dex
3. zip 을 이용해서 dex파일을 apk 안으로 집어 넣습니다.
ex) zip
Calculator.apk classes.dex
4. 재생성된 apk를 zipalign 해줍니다.
ex) zipalign -f -v 4 Calculator.apk Calculator_temp.apk
위의 과정은 단 1개의 odex 파일을 deodex하는 과정입니다.
그럼 안드로이드 시스템의 모든 파일들을
deodex하려면 어떻게 해야 할까요?
하나 하나씩 일일히 한다는 것은 말도 안되겠죠.
다음의 순서를 지켜야
합니다.
1) /system/framework 안의 모든 것들을 deodex 한다.
=> -d 옵션으로
자기 자신의 폴더를 검색하게 합니다.
ex) baksmali -d /system/framework -x core.odex
2)
/system/app 안의 시스템 어플리케이션들을 deodex 한다.
=> -d 옵션으로 프레임워크의 폴더를
검색하게 하고 -c 옵션으로 해당 odex들이 필요로 하는 모든 jar 파일들을 명시합니다.
ex) baksmali
-d /system/framework -c
:com.sec.android.solunconverter.jar:com.samsung.device.jar
:framework-tests.jar:seccamera.jar:sechardware.jar:twframework.jar
:libSECDMF.jar:javax.obex.jar:com.google.android.maps.jar
-x blah.odex
이런 규칙을 지키면서 폴더 내의 모든
파일들에 대해 반복문을 실행해 주면 됩니다.
이 반복문에 대한 것은 쉘스크립트를 짜셔야 하고, 이에 대한 설명은 생략하겠습니다.
(너무 길어져서요)
첨부파일로 제가 갤럭시S 프로요를 deodex하기 위해 짰었던 쉘스크립트를 올려놓겠습니다.
주석도
별로 안달려있고 코드가 아주 난잡합니다. 이에 대한 분석은 여러분이 직접 해보시도록 하세요!
당연히 진저브레드에서는 뭔가가 달라졌을
것이므로 이에 대해 수정을 해주셔야 사용할 수 있겠죠?
이제 다음 과정입니다.
deodex를 통해
/system/app과 /system/framework 폴더를 얻었습니다.
여기에 또 다른 파일을 추가해도 상관 없습니다.
예를 들어 /system/bin/su파일과 /system/app/Superuser.apk 파일을 추가해서 넣어줘도 관계가 없다는
얘기이지요.
이 부분에서 테마 작업을 하셔도 되고 기타 등등의 모든 작업을 다 해주시면 됩니다.
그리고
META-INF 라는 폴더 또한 있어야 합니다.
결과적으로 META-INF 와 system 폴더가 같은 위치에 있고, system
폴더 안에 app, framework 등등이 있는 상태겠죠?
update.zip ------
META-INF
|
--- system --- app
+ framework + etc.
META-INF 폴더는 역시 첨부파일에 있습니다.
다음으로 META-INF/com/google/android 안에
updater-script 라는 것에 대해 알아보죠.
이 스크립트는 update.zip 파일의 내용물을 어떻게 설치할 것인가 에
대한 설계도라고 생각하시면 됩니다.
updater-script 의 명령어 중에 몇 가지를 알려드리죠.
조건이 다르면 멈춥니다.
ex) assert compatible_with("0.2") == "true"
#
show_progress(1.000000, 0); : 진행 막대를 까먹는 양을 조절합니다.
소수부분 : 1.0이 들어가면
절반(50%)씩 싹둑싹둑 까먹습니다. 0.5는 25%씩 까먹습니다.
정수부분 : 진행막대를 까먹는 시간을 지정합니다.
# set_progress(0.200000); : 까먹는 양을 조절한다.
# ui_print("보여주고 싶은 글"); :
화면에 해당 글을 보여줍니다.
# run_program("/sbin/busybox", "mount", "/system"); :
/sbin/busybox 를 이용해 /system 폴더를 마운트한다.
# delete("/system/bin/su"); : 해당
파일을 삭제
# delete_recursive("/system"); : /system폴더와 이하의 모든 것들을 삭제
#
package_extract_dir("system", "/system"); : update.zip 안에 있는 system 폴더를 /system
에다가 풀어 놓는다.
# mount("MTD", "system", "/system");
: /system파티션에 마운트
# unmount("/system"); : /system 파티션을 마운트 해제한다.
#
symlink("/system/bin/su", "/system/xbin/su"); : /system/bin/su 를 /system/xbin/에
symlink
# set_perm(0, 0, 6755, "/system/bin/su"); : 퍼미션 조정 (
# set_perm_recursive(0,0,6755,
"/system/bin"); : 해당 폴더 이하의 모든 파일의 퍼미션을 한 방에 조정
updater-script 의 작성까지 마치셨다면 이제 남은 과정이 얼마 없습니다.
첫 째는 위의 파일들을
몽땅 update.zip으로 압축하시는 겁니다.
ex) zip -r update_unsigned.zip
./*
둘 째는 위에서 만든 update_unsigned.zip을 사인하는 겁니다.
signapk.jar 파일이 있는
디렉토리로 이동하셔서 아래의 명령어를 치면 됩니다.
ex) java -jar signapk.jar
testkey.x509.pem testkey.pk8 $rom_path/update_unsigned.zip
$rom_path/../update.zip
와 드디어 update.zip이 완성 되었습니다.
이 파일은 리커버리
모드에서 install from an update.zip 메뉴로 설치하실 수 있습니다.
위에 올린 장황한 설명들은 원리부터
차근차근 설명한 것이기 때문에 이를 이용해서 모든 과정을 처리하기엔 문제가 있을겁니다.
따라서 제가 올린 첨부파일의 스크립트를
적극적으로 분석,연구,수정하셔서 사용하시는 것이 나을 것 입니다.
또, 갤럭시S 프로요때의 지식을 가지고 작성한 강좌인 만큼,
다른 기종의 스마트폰이나 현재 진저브레드 운영체제의 갤럭시S에서 정상적으로 적용될 지는 저도 알지 못하니 그 점 알아주시기 바랍니다.
.
.
.
.
.
.
.
.
.
이 강좌가 딱히 크게 성능의 개선이나
편의성을 제공해 드리지는 않을겁니다.
단지 저는 이런 정보들이 여러분의 내면에 숨어있던 개발 본능을 일깨우고, 이로 하여금 소소한
재미를 느끼도록 도울 수 있었으면 하는 바람입니다.
다만, 이 강좌를 보고 실천하시는 과정에서
발생한 기기 문제 혹은 정신적 문제(?)에 대한 책임은 스스로가 해결하시길 바랍니다.
마지막으로, 제 머리와 구글링을
통해 나온 정보인 만큼 오류가 많이 있을 수 있고, 잘못된 명령어 때문에 고생을 하실 수 있으니 이 점에 대해 알아두시기를 바라며 정정할 부분이
있을 시 답글로 달아주시면 적극 반영하도록 하겠습니다.
Zipalign은 Android SDK Tools에 있는 것을 쓰면 간편히 됩니다^^~