Android Developer 에 있는 내용을 짧은 영어지만.. 읽어보며 남긴다.
ProGuard tool은 사용하지 않는 class, method, field 코드를 제거하고, 해당 코드의 이름을 모호하게 변경하여 코드를 축소하고 최적화한다. 그 결과 소스의 사이즈는 작이지고 apk 파일은 해독(decompile)이 더 어려워진다. Proguard가 적용된 어플리케이션은 해독이 어렵기 때문에, Application의 라이센스같은 보안에 민감한 부분의 활용에 있어서 중요하다.
ProGuard는 Android build system에 통합되어 있어서 수동으로 적용할 필요는 없다. ProGuard는 Application을 release mode로 build 하는 경우에만 동작한다. 그래서, debug mode에서 Application을 build 하는 경우에는 code의 난독화 처리를 할 필요는 없다. ProGuard를 적용하는 것은 선택사항이지만 추천할 만하다.
이 문서는 ProGuard의 활성화 및 구성에 대한 기술뿐만 아니라 난독화된 코드의 stack을 decode하는 Retrace tool의 사용법에 대해 설명한다.
안드로이드 프로젝트를 만들 때, proguard.cfg 파일은 자동으로 프로젝트의 root directory에 생성된다. 이 파일은 ProGuard가 코드를 어떻게 난독화 하고 최적화 하는지를 정의한다. 그래서 필요에 맞게 편집히는 방법을 이해하는 것이 중요하다. 기본 구성 파일은 일반적인 경우를 포함하며, 사용자의 필요에 의해 편집할 수 있다. ProGuard 구성파일의 편집에 대한 정보는 Configuring ProGuard를 참조하면 된다.
Ant 나 Eclipse Build 등의 일부분으로 ProGuard가 동작하게 하려면 <project_root>/project.properties 파일안의 proguard.config 속성을 설정하면 된다. 디렉토리의 경로는 절대경로나 프로젝트에 대한 상대경로도 가능하다.
proguard.cfg 파일에 아래와 같이 작성한다.
상대경로
proguard.config=proguard.cfg
절대경로
proguard.config=/path/to/proguard.cfg
release mode로 Application을 build 할 경우에 Ant 나 Eclipse Build 를 사용하게 되면 모두 proguard.cfg 파일의 proguard.config 속성을 자동으로 확인하게 된다. 이 경우 *.apk 파일로 packaging 하기 전에 ProGuard가 Application의 모든 bytecode를 처리한다. debug mode에서는 debugging을 처리하는 작업이 너무 무겁기 때문에 ProGuard를 적용하지 않는다.
ProGuard가 생성하는 파일은 아래와 같다.
* mapping.txt : 기존 코드와 난독화된 코드의 맵핑에 대한 리스트. 후에 release build로 생성한 Application에서 보고되는 bug report가 난독화된 코드명으로 전달되기 때문에 이 파일은 중요하다.
* seeds.txt : 난독화 되지 않은 class, member 들의 목록이다.
* usage.txt : *.apk 파일에서 제외된 코드 목록이다.
※ 주의 : release build 로 매번 build 시에 이 파일들은 ProGuard에 의해 마지막 파일로 덮어써진다. Application의 release 시에 이전 release된 Application의 난독화를 풀기 위해서는 새로운 release 마다 각 생성되었던 파일들의 복사본을 저장한다. 이 파일들을 왜 저장하는지에 대한 정보는 Debugging considerations for published applications 를 참고하면 된다.
일부 상황에서 proguard.cfg 파일의 기본 설정은 충분할 것이다. 하지만 많은 상황에서 ProGuard가 정확하게 분석하는 것이 어렵고, 사용되지 않는다는 판단하에 Application이 실제로 필요로 하는코드를 Proguard 지워 버릴 수도 있다. 아래와 같은 예가 있다.
* JNI로 부터 호출되는 method
* 동적으로 참조하는 field 와 method
기본 proguard.cfg 파일은 일반적인 경우는 커버 할 수 있다. 그러나 개발자는 ProGuard가 Application이 호출하는 모든 class 를 난독화 시켜버리는 경우에 ClassNotFoundException 과 같은 오류에 직면할 수 있다.
proguard.cfg 파일에 -keep 옵션을 추가하게 되면 위 오류를 수정할 수 있다.
-keep 옵션을 사용할 때에는 많은 선택과 고려사항이 있다. 그래서 구성파일을 편집하는 것에 관한 정보가 있는 ProGuard Manual 을 읽는 것을 추천한다. Useage section 의 Keep options 과 Examples section 은 특별히 유용하다. Troubleshooting section 은 개발자가 코드를 ProGuard 할때 직면하는 일반적인 여러 문제에 대해 서술하고 있다.
Decoding Obfuscated Stack Traces
stack trace가 난독화 코드로 이루어졌을 때, 불가능하지는 않지만 method 들의 이름이 모호하여 debugging 을 어렵게 만듭니다. 다행이도 ProGuard는 실행을 할 때 마다 난독화된 코드에 맵핑된 원본 코드를 볼 수 있는 <project_root>/bin/proguard/mapping.txt 파일을 생성한다.
<sdk_root>/tools/proguard/bin/retrace.bat(sh) 파일은 난독화된 코드로 이루어진 stack trace를 읽기쉽게 변환해 준다. retrace tool 의 실행 문법은 아래와 같다.
* 문법
retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
* 실행
retrace.bat -verbose mapping.txt obfuscated_trace.txt
<stacktrace_file>을 지정하지 않을 경우 retrace tool 은 표준 입력값으로 해석한다.
Debugging considerations for published applications
배포에 대한 모든 release를 위한 mapping.txt 파일은 저장한다. 각 release에 대한 mapping.txt 를 유지하는 것으로 사용자가 부딪히는 버그와 난독화된 stack trace에 의한 문제를 debug 할수 있음을 보장해 준다. 프로젝트의 mapping.txt 파일은 매 release build 마다 덮어쓰기 되어진다. 그래서 개발자는 필요한 버전을 저장하는 것에 대해 주의를 기울여야 한다.
예를 들어, application 배포와 새버전을 위한 새유형에 관한 개발의 이야기를 들었다. 곧 ProGuard를 사용하여 release build를 한다. 그 build는 이전의 mapping.txt 파일을 덮어쓰기 한다. 사용자가 현재 배포된 Application의 statck trace를 포함하는 버그리포트를 제출한다. 개발자는 사용자의 기기에 관련되는 버전의 mapping.txt 파일이 사라졌기 때문에 사용자의 statck trace를 debugging 할 수 있는 방법이 없다. mapping.txt 파일이 덮어쓰기 되버린 상황이다. 그래서 개발자는 debug를 해야한 하는 매 release 마다 mapping.txt 파일을 복사를 해두어야 한다.
mapping.txt 파일을 저장하는 방법은 개발자가 정한다. 예로, 개발자는 그들의 소스코드와 마찬가지로 버전이나 빌드번호가 포함되게끔 파일의 이름을 변경할 수 있다.
다 읽어보고 나니 이건 그냥 정보일 뿐이었다는....
ProGuard의 사용에 대한 방법은 꼭 아래에서 확인 하여야 한다... 어쩐지.. 짧더라니..
댓글