그냥 그런 블로그

ndk-build tool

android 명령을 사용해서 project 를 생성하고 나면, 그것을 컴파일해 줄 필요가 있다. 이 컴파일 작업은 ndk-build 를 통해서 이루어 진다. 그런데 책에서는 ndk-build 에 대해서 자세하게 다루고 있지 않다. 그런데 안타깝게도 안드로이드 개발자 사이트에서도 자세한 내용을 다루고 있지 않다. 하지만 $ANDROID_NDK/docs/NDK-BUILD.html 을 열어 보면 해당 도구에 대한 설명을 볼 수 있다.

이 문서는 "ndk-build 란?" 장을 제외하고는 NDK-BUILD.html 의 내용을 번역한 것이다.

ndk-build 란?

일단 ndk-build 라는 것의 개념부터 살펴 보도록 하자. ndk-build 에 대해서 --version 이라는 매개변수를 주고 실행하면 다음과 같은 결과를 볼 수 있다.

위의 결과를 보면 알 수 있겠지만, ndk-build 라는 것은 GNU Make 에 대한 wrapper 이다. 여기에서 이제 또 다른 의문이 생길 것이다. 그럼 make 란 무엇인가?

make 라는 것은 Visual Studio 같은 IDE 가 가지고 있는 빌드 시스템과 유사하다고 생각하면 된다. 예를 들어 우리는 Visual Studio 를 사용해서 솔루션과 프로젝트를 만들고 거기에 소스 파일, 헤더 파일, 리소스 파일 등을 추가한다. 그 다음에 솔루션이나 프로젝트의 속성창을 열어 필요한 옵션들을 설정한다. 그리고 나서 빌드 버튼을 누르게 된다. 그러면 지정된 옵션에 따라서 컴파일과 링크가 수행된다. 이 때 "최소 다시 빌드" 옵션을 설정하게 되면, 변경된 파일을 검색해서 관련 object 파일만을 컴파일하고 링크하게 된다. make 가 바로 이러한 작업을 해 주는 도구이다. 

물론 make 가 하는 일이 단순하게 그런 것만 있는 것은 아니다. 의존성을 설정한다던가 batch 명령과 유사한 작업을 한다던가 여러 가지 작업을 하게 된다. make 는 여러 가지 구현이 존재한다. 그 중에서 가장 많이 사용하는 것이 GNU Make 이다. 자세한 내용은 "GNU Make 강좌" 를 참조하기 바란다.  GNU Make 의 매뉴얼은 "GNU Make Manual" 에서 찾아 볼 수 있다.

어쨌든 ndk-build 는 GNU Make 의 wrapper 이며, 우리는 이것을 프로젝트를 설정하고 빌드하는 것을 도와 주는 도구 정도로 생각하면 되겠다.

용례.

안드로이드 NDK r4 는 새로운 작은 쉡 스크립트인 'ndk-build' 를 소개했는데, 이는 머신 코드를 빌드하는 것을 단순화하기 위한 것이다.

이 스크립트는 NDK 의 최상위 디렉토리에 존재하며, 응용프로그램 프로젝트 디렉토리나 그것의 모든 하위 디렉토리들에서 명령줄에서 실행된다. 예를 들어 :

여기에서 $NDK 는 NDK 설치 경로이다. 당신은 그것을 매번 입력하는 것을 피하기 위해서 PATH 에다가 $NDK 를 추가하거나 alias 를 만들 수 있다.

옵션.

'ndk-build' 에 대한 모든 매개 변수는 NDK 빌드 스크립트를 실행하는 기저에 깔린 GNU Make 명령에 직접적으로 전달된다. 자주 쓰는 용례는 다음과 같다 :

• ndk-build : 머신 코드를 다시 빌드한다.
• ndk-build clean : 생성된 바이너리를 모두 지운다.
• ndk-build NDK_DEBUG=1 : 디버깅할 수 있는 네이티브 코드를 생성한다.
• ndk-build V=1 : 빌드를 시작하고, 빌드 명령들을 보여 준다.
• ndk-build -B : 완전한 다시 빌드를 강제한다.
• ndk-build -B V=1 : 완전한 다시 빌드를 강제하고, 빌드 명령들을 보여 준다.
• ndk-build NDK_LOG=1 : 내부 NDK 로그 메시지들을 보여 준다( NDK 자체를 디버깅하는데 사용된다 ).
• ndk-build NDK_DEBUG=1 : 디버깅 가능한 빌드를 강제한다( 아래 참조 ).
• ndk-build NDK_DEBUG=0 : 릴리스 빌드를 강제한다( 아래 참조 ).
• ndk-build NDK_HOST_32BIT=1 : 항상 32 비트 툴체인을 사용한다( 아래 참조 ).
• ndk-build NDK_APPLICATION_MK=<file> : 다시 빌드하는데, NDK_APPLICATION_MK 명령줄 변수에 의해 지정된 특정 Application.mk 를 사용한다.
• ndk-build -C <project> : <project> 에 위치한 프로젝트 경로를 위해 네이티브 코드를 빌드한다. 터미널에서 'cd' 를 입력하고 싶지 않을 때 유용하다.

디버그 빌드 대 릴리스 빌드.

NDK r5 에서 ndk-build 는 릴리스 빌드와 디버그 빌드 사이를 더 쉽게 전환할 수 있도록 변경되었다. 이는 NDK_DEBUG 변수를 사용해서 수행된다.

예를 들어 :

NDK_DEBUG 를 지정하면, ndk-build 는 그것의 기본 동작을 유지하는데, 그것은 AndroidMenifest.xml 에 <application> 엘리먼트가 존재하면  android:debuggable="true" 로 설정되어 있는지를 확인한다.

그리고 편리하게도 NDK 에 의해 생성된 릴리스 오브젝트 파일과 디버그 오브젝트 파일은 서로 다른 디렉토리에 저장된다( 예를 들어 obj/local/<abi>/objs 와 obj/local/<abi>obj-debug ). 이는 두 모드를 전환할 때 ( 심지어 당신이 한 두개의 소스 파일들만을 수정했을 때 ), 모든 소스들이 다시 빌드되는 것을 막아 준다.

64 비트 툴체인과 32 비트 툴체인.

일부 툴체인들은 64 비트 버전과 32 비트 버전을 둘 다 가지고 있다. 예를 들어 $NDK/toolchain/<name>/prebuilt 와 $NDK/prebuilt 는 "linux-x86" 과 "linux-x86-64" 폴더를, 만약 OS 가 그것을 지원한다면 32 비트 모드 리눅스 툴과 64 비트 모드 리눅스 툴을 위해 모두 포함하고 있다.당신은 환경 변수나 ndk-build 명령줄에서  NDK_HOST_32BIT=1 을 사용하여 32 비트 툴체인을 사용하는 것을 강제할 수 있다.

Note that 64-bit tools utilize host resources better( faster, handle larger programs, etc ) and they should function identically to their 32-bit counterparts. le. 64-bit toolchains still generate 32-bit binaries for Android.

요구 사항.

'ndk-build' 나 NDK 를 범용적으로 사용하기 위해서는 GNU Make 3.81 을 필요로 한다. 빌드 스크립트들은 적절하지 못한 Make 톨을 사용하고 있는지를 확인할 것이며 에러 메시지를 출력하며 불평할 것이다.

만약 GNU Make 3.81 이 설치되어 있지만 기본 'make' 명령에 의해 실행될 수 없는 상태라면, GNUMAKE 를 환경 변수에 정의해서 'ndk-build' 를 실행하기 전에 그것을 가리키도록 하라. 예를 들어 :

혹은 그 변경을 더 영구적으로 만들라 :

당신의 쉘과 GNU Make 3.81 설치 위치를 맞춰라.

당신은 다음과 같은 환경 변수들을 사용해서 $NDK/prebuilt/<OS>/bin 의 다른 호스트 prebuilt 툴들을 덮어 쓸 수도 있다.

내부 구현.

'ndk-build' 자체는 GNU Make 에 대한 작은 wrapper 이며, 그것의 목적은 올바른 NDK 빌드 스크립트를 쉽게 실행하는 것이다. 이는 다음과 동일하다 :

여기에서 '$GNUMAKE' 는 GNU Make 3.81 이상을 가리키며, '$NDK' 는 당신의 NDK 설치 디렉토리를 가리킨다.

다른 쉘 스크립트들( 혹은 당신만의 Makefile 들 )로부터 NDK 빌드 스크립트를 실행하고자 한다면 이에 대한 지식을 사용하라.

책에 보면 android 툴을 사용해서 프로젝트를 생성하는 것을 볼 수 있다. 예를 들면 다음과 같은 명령을 사용한다.

책에서는 그냥 저렇게 하면 프로젝트가 생성된다고만 말하고 실제 그것이 어떤 의미를 가지고 있는지 혹은 어떤 동작을 하는지에 대해서 설명하지 않는다. 그래서 "그런가 보다"하고 넘어 갔었는데, 역시 근원을 파고들고자 하는 욕구가 사라지지 않아서 정리해 본다. 다행히도 Android Developer 사이트에 관련 문서가 있어서 번역해 본다.

원문 : Manaing Projects from the Command Line

주의 : 번역이 개판이므로 이상하면 원문을 참조하십시오.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

주의 : 가독성을 높이기 위해서 잘 알려진 용어나 발음이 비슷한 용어는 한글로 표기합니다.

명령줄에서 프로젝트 관리하기

android 툴은 세 종류의 프로젝트들을 모두 생성하기 위한 명령들을 제공한다. 안드로이드 프로젝트는 프로젝트를 설치를 위한 .apk 파일로 빌드하는데 필요한 파일들과 리소스들을 포함한다.

• 안드로이드 프로젝트는 프로젝트를 설치를 위한 .apk 파일로 빌드하는데 필요한 파일들과 리소스들을 포함한다. 당신은 최종적으로 장치에 설치하고자 하는 모든 응용프로그램을 위해 안드로이드 프로젝트를 생성할 필요가 있다.
• 당신은 안드로이드 프로젝트를 라이브러리 프로젝트로서 설계할 수도 있는데, 이는 그것에 의졶하는 다른 프로젝트들과 공유되는 것을 허용한다. 안드로이드 프로젝트가 라이브러리 프로젝트로 설계되면, 그것은 장치에 설치될 수 없다.
• 테스트 프로젝트들은 JUnit 기능을 확장해 안드로이드에 특화된 기능들을 포함한다. 테스트 프로젝트를 생성하는 것과 관련한 더 많은 정보를 원한다면, Testing from other IDEs 를 참조하라.

안드로이드 프로젝트 생성하기기

안드로이드 프로젝트를 생성하려면, 당신은 android 툴을 사용해야만 한다. 당신이 android 로 새로운 프로젝트를 생성할 때, 그것은 일부 기본 파일들, stub 파일들, 설정 파일들, 빌드 파일을 가진 프로젝트 디렉토리를 생성할 것이다.

새로운 안드로이드 프로젝트를 생성하려면, 명령줄을 열고, SDK 의 tools/ 디렉토리로 가서, 다음을 실행하라 :

• target 은 응용프로그램을 위한 "빌드 타겟" 이다. 그것은 당신이 응용프로그램을 빌드하려고 하는 ( Google APIs 와 같은 모든 애드온을 포함하는 ) 안드로이드 플래폼 라이브러리와 관련이 있다. 이용 가능한 타겟들과 그것들의 관련 아이디들을 보려면, 다음을 실행하라 : android list targets.
• name 은 프로젝트의 이름이다. 이것은 선택 사항이다. 만약 이름이 제공되면, 이 이름은 응용프로그램을 빌드할 때 .apk 파일 이름으로 사용될 것이다.
• path 는 프로젝트 디렉토리의 위치이다. 만약 디렉토리가 존재하지 않으면, 자동으로 생성될 것이다.
• activity 는 기본 Activity 클래스의 이름이다. 이 클래스 파일은 <path_to_your_project>/src/<your_package_namespace_path>/ 내부에 생성될 것이다. 당신이 name 을 지정하지 않으면 그것은 .apk 파일 이름으로 사용될 것이다.
• package 는 프로젝트를 위한 패키지 이름인데, 자바 프로그래밍 언어에서의 패키지를 위한 규칙과 동일하다.

여기 예제가 있다 :

프로젝트를 생성하고 나면, 당신은 개발을 시작할 준비가 된 것이다. 원하는 곳에 프로젝트 폴더를 옮길 수는 있지만, 응용프로그램을 에뮬레이터에 보내기 위해서는  Android Debug Bridge ( adb ) - SDK 의 platform-tools/ 디렉토리에 있음 - 를 사용해야만 한다는 것을 염두에 두기 바란다( 이에 대해서는 나중에 언급한다 ). 그래서 당신은 프로젝트 솔루션과 paltform-tools/ 폴더에 접근할 필요가 있다.

Tip : platform-tools/ 와 tools/ 를 PATH 환경 변수에 추가하라.

Caution : 당신은 SDK 디렉토리의 위치를 움직여서는 안 된다. 왜냐하면 이는 local.properties 에 위치한 SDK 위치 속성을 깨 버리기 때문이다. 만약 당신이 SDK 위치를 옮기고자 한다면, android update project  명령을 사용하라. 더 많은 정보를 원한다면 "프로젝트 갱신하기" 를 참조하라.

프로젝트 갱신하기

만약 이전 버전의 안드로이드 SDK 에서 만든 프로젝트를 업그레이드하고 싶거나 현존하는 코드로부터 새로운 프로젝트를 생성하고 싶다면, android update project 명령을 사용해 프로젝트를 새로운 개발 환경으로 갱신하라. 당신은 이 명령을 ( --target 옵션과 함께 ) 사용해서 현존하는 프로젝트의 빌드 타겟을 변경하거나 ( --name 옵션과 함께 ) 프로젝트 이름을 변경할 수 있다. android 툴은 분실되거나 갱신될 필요가 있는 ( 이전 섹션에서 열거되었던 ) 모든 파일들과 폴더들을 안드로이드 프로젝트가 필요한 만큼 생성하게 될 것이다.

현존하는 안드로이드 프로젝트를 갱신하려면, 명령줄을 열고 SDK 의 tools/ 디렉토리로 이동하라. 그리고 다음을 실행하라 :

• target 은 응용프로그램을 위한 "빌드 타겟" 이다. 그것은 당신이 응용프로그램을 빌드하려고 하는 ( Google APIs 와 같은 모든 애드온을 포함하는 ) 안드로이드 플래폼 라이브러리와 관련이 있다. 이용 가능한 타겟들과 그것들의 관련 아이디들을 보려면, 다음을 실행하라 : android list targets.
• path 는 프로젝트 디렉토리의 위치이다. 만약 디렉토리가 존재하지 않으면, 자동으로 생성될 것이다.
• name 은 프로젝트의 이름이다. 이것은 선택 사항이다. 만약 이름이 제공되면, 이 이름은 응용프로그램을 빌드할 때 .apk 파일 이름으로 사용될 것이다.

여기 예제가 있다 :

라이브러리 프로젝트 설정하기

라이브러리 프로젝트는 표준 안드로이드 프로젝트이다. 그래서 당신은 새로운 응용프로그램 프로젝트를 생성하는 것과 같은 방식으로 새로운 라이브러리 프로젝트를 생성할 수 있다. 특히, 당신은 필요한 파일들과 폴더들을 가진 새로운 라이브러리를 생성하기 위해 android 툴을 사용할 수 있다.

새로운 라이브러리 프로젝트를 생성하려면, <sdk>/tools/ 디렉토리로 이동하고 다음 명령을 사용하라 :

create lib-project 명령은 그 프로젝트가 라이브러리임을 빌드 시스템에 알려주는 프리셋 속성을 포함하는 표준 프로젝트 구조를 생성한다. 그것은 프로젝트의 project.properties 파일에다가 다음 라인을 추가함으로써 수행된다 :

명령이 종료되면, 라이브러리 프로젝트가 생성되고 당신은 아래 섹션들에서 설명하는 것처럼 소스 코드와 리소스들을 그 프로젝트 안으로 옮기기 시작할 수 있다.

만약 당신이 현존하는 응용프로그램 프로젝트를 라이브러리 프로젝트로 변환해서 다른 응용프로그램들이 그것을 사용할 수 있도록 하고 싶다면, 당신은 adnroid-library=true 속성을 응용프로그램의 project.properties 파일에 추가함으로써 그 작업을 수행할 수 있다.

매니페스트 파일 생성하기

라이브러리 프로젝트의 매니페스트 파일은 표준 안드로이드 응용프로그램처럼 반드시 그것이 포함하고 있는 공유 요소들을 모두 선언해야만 한다. 더 많은 정보를 원한다면, AndroidManifest.xml 을 위한 문서를 참조하라.

예를 들어, TicTacToeLib 예제 라이브러리 프로젝트는 GameActivity 라는 Activity 를 선언한다 :

라이브러리 프로젝트 갱신하기

만약 당신이 라이브러리 프로젝트의 빌드 속성들( 빌드 타겟, 위치 )을 갱신하고자 한다면, 다음 명령을 사용하라 :

라이브러리 프로젝트 참조하기

만약 당신이 응용프로그램을 개발하고 있고 공유 코드와 공유 리소스들을 라이브러리 프로젝트로부터 가져 오기를 원한다면, 당신은 응용프로그램 프로젝트의 빌드 속성들에 라이브러리 프로젝트에 대한 참조를 추가함으로써 이를 쉽게 수행할 수 있다.

라이브러리 프로젝트에 대한 참조를 추가하려면, <sdk>/tools/ 디렉토리로 가서 다음 명령을 사용하라 :

이 명령은 응용프로그램의 빌드 속성들을 갱신해서 라이브러리 프로젝트에 대한 참조를 포함하도록 한다. 특히, 그것은 android.library.reference.n 속성을 프로젝트의 project.properties 파일에 추가한다. 예를 들면 :

여러 개의 라이브러리들에 대한 참조를 추가하고 있다면, 당신은 그것의 상대적인 우선순위를 ( 그리고 merge 순서를 ) 설정할 수 있는데, 이는 project.properties 파일을 수작업으로 편집하고 각 참조들의 .n 인덱스를 적절하게 변경함으로써 이루어 진다. 예를 들어, 이러한 참조들을 가정해 보자 :

당신은 library_projectC 에 가장 높은 우선순위를 부여하기 위해 다음과 같이 참조들을 재정렬할 수 있다 :

레퍼런스들에서 .n 인덱스는 "1" 로 시작하며 "구멍" 없이 하나씩 증가한다는 것에 주의하라. 빠진 부분이 생긴 다음의 인덱스에서 나타나는 참조들은 무시된다.

빌드시에, 그 라이브러리들은 응용프로그램에 동시에 merge 되는데, 가장 낮은 우선순위에서 시작해 가장 높은 우선순위로 merge 된다. 라이브러리는 스스로는 다른 라이브러리를 참조할 수 없으며, 빌드시에 라이브러리들은 응용프로그램과 merge 되기 전에 다른 것들과 merge 되지 않는다는 것에 주의하라.

매니페스트 파일에서 라이브러리 요소 선언하기

응용프로그램 프로젝트의 매니페스트 파일에서, 당신은 응용프로그램이 라이브러리 프로젝트로부터 들여 오게 되는 응용프로그램이 사용하게 될 모든 요소들에 대한 선언을 추가해야만 한다. 예를 들어, 당신은 모든 <activity>, <service>, <receiver>, <provider> 등을 선언해야만 한다. 그리고 <permission>, <uses-library> 및 그와 유사한 요소들도 선언해야만 한다.

선언들은 라이브러리 요소들의 fully-qualified 이름들을 사용해 적절한 위치의 라이브러리 요소들을 참조한다.

예를 들어, TicTacToeMain 예제 응용프로그램은 다음과 같이 GameActivity 라는 라이브러리 Activity 를 선언한다 :

매니페스트 파일에 대한 더 많은 정보를 원한다면, AndroidManifest.xml 을 위한 문서를 참조하라.

의존성 있는 응용프로그램 빌드하기

하나 이상의 라이브러리 프로젝트에 의존하는 응용프로그램 프로젝트를 빌드하기 위해, 당신은 Build and Running 에 기술된 것처럼 표준 Ant 빌드 명령들과 컴파일 모드들을 사용할 수 있다. 그 툴들은 의존성 있는 응용프로그램 프로젝트를 컴파일하는 작업의 일부로서 응용프로그램에 의해 참조되는 모든 라이브러리들을 컴파일하고 merge 한다. 다른 명령들이나 단계들이 필요하지 않다.

Ubuntu 12.10 에서 NDK 를 설치할 때, 압축 관리자로 그냥 압축을 푸는 경우에 ndk-build 를 실행하면 다음과 같은 에러를 만날 수 있다.

이 문제 때문에 한참 고생을 했는데, 압축이 잘 못 풀려서 arm-linux-androideabi-gcc 가 생성되지 않기 때문에 발생하는 문제이다. 파일탐색기에서 "여기에 풀기"를 통해 압축을 풀면 이상하게 압축이 제대로 풀리지 않는 문제가 있다.

그래서 다음과 같이 직접 압축을 풀었더니 arm-linux-androideabi-gcc 가 제대로 생성되었다.

파일탐색기에서 푸는 것이 왜 제대로 안 풀리는 지는 모르겠다. 한 번 알아 볼 필요가 있을 것 같다.

AskUbuntu 에다가 질문을 올려 두었다. 어떤 답이 나올지 궁금하다. 리눅스 초보자라 이것 저것 모르는게 많아 골치 아프다; Why does a "Extract Here" context menu work incorrectly?

주의 : 공부하면서 정리한 내용이라 오류가 있을 수 있습니다.

주의 : 가독성을 높이기 위해서 잘 알려진 용어나 발음이 비슷한 용어는 한글로 표기합니다.

Android NDK 개발 환경 : Cygwin

왜 Cygwin 이 필요한가?

개발자라면 자신이 개발하고 있는 환경에 대해서 제대로 이해해야 할 필요가 있다고 생각한다. NDK 를 사용해서 안드로이드 앱을 개발하기 전에 개발환경에 대해서 대강이라도 이해해 보고자 공부하면서 정리해 본다.

안드로이드는 기본적으로 리눅스 커널을 기반으로 올라 가 있는 가상머신이기 때문에 NDK 는 리눅스 개발환경과 관련이 있다. 그러므로 윈도우즈 환경에서 안드로이드 NDK 프로그래밍을 하기 위해서는 시그윈이 필수이다. 아래 그림은 안드로이드의 시스템 아키텍처를 설명하는 것으로서, 인터넷에 가장 많이 퍼져 있는 것을 주워 왔다.

NDK 로 개발을 한다는 것이 의미하는 바가 무엇인지 생각해 볼 필요가 있다. 많이들 알고 있는 사실이겠지만, 어떤 프로그램이 어떤 머신에서 실행되기 위해서는 해당 머신에 맞는 실행가능한 파일( executable )을 만들어야만 한다. 그것이 소위 우리가 알고 있는 '컴파일'과 '링크'라는 작업이다. 이 컴파일 작업과 링크 작업을 합쳐서 '빌드'라고 표현한다.

우리가 열심히 코딩한 라인들은 어셈블리어로 변환되고, 이 어셈블리어들은 다시 기계어로 변환된다. 그리고 CPU 는 이 기계어를 마이크로 명령어로 나누어서 프로그램을 실행하게 된다. 그런데 이 CPU 가 어떠한 명령어 집합 구조( Instruction Set Architecture, ISA )를 제공하느냐에 따라서 다른 기계어를 만들어야 하기 때문에, 프로그램을 빌드할 때는 해당 CPU 에 맞는 구성을 만들어야 한다. 예를 들어 CPU 가 x86 ISA 를 제공한다면 x86 에 맞는 빌드 구성을 해야 하고, CPU 가 x86/64 를 제공한다면 거기에 맞는 빌드 구성을 만들어야 한다.

자 우리가 NDK 를 통해 만든 바이너리를 실행할 플래폼의 환경은 어떠한가? 일반적으로 현재 안드로이드 OS 가 돌아 가는 환경은 ARM 코어를 사용하는 리눅스 환경이다. 이는 어떠한 사실을 내포할까?

• 우리가 C/C++ 응용프로그램을 개발할 때 CreateFile() 과 같은 Win32 API 를 사용할 수 없다.

• Visual Studio 를 이용할 수 없다. --> VC++ 컴파일러를 사용할 수 없다.

사실 Visual Studio 의 컴파일러를 GCC( GNU Compiler Collection ) C++ 컴파일러로 연결해 놓고 개발할 수는 있을 것이다. 하지만 기본 환경 자체가 Win32 서브시스템과 x86 혹은 x86-64 아키텍처를 위한 개발에 최적화되어 있으므로 참 어려운 일이 될 것이다. 구글링을 해 보면 여러 가지 자료들이 나오기는 하는데 얼마나 편한 지는 잘 모르겠다. 어쨌든 우리는 리눅스 OS 를 기반으로 ARM ISA 에 맞춰서 빌드해야만 하는 상황이고, 윈도우즈 환경에서 이를 가능하게 만들 수 있는 방법을 찾아야만 한다. 

이때 우리에게 한 줄기 빛을 비춰주는 존재가 있으니, 그것이 바로 시그윈이다.

Cygwin 이란 무엇인가?

일단 시그윈 공식 사이트의 설명을 인용해 보도록 하겠다. 출처 : http://cygwin.com/index.html

시그윈은 :

• 윈도우즈를 위해 리눅스처럼 느껴지는 환경을 제공하는 도구들의 집합이다.

• 많은 리눅스 API 기능을 제공하는 리눅스 API 레이어로서 동작하는 DLL( cygwin1.dll )이다.

그리고 다음과 같이 착각하지 말라고 경고하고 있다.

시그윈은  :

• 윈도우즈 상에서 네이티브 리눅스 앱들을 실행하는 방법이 아니다. 당신이 윈도우즈 상에서 프로그램을 실행하기 원한다면, 소스로부터 앱들을 리빌드해야만 한다.
• signal, pty 등과 같은 유닉스 기능들을 인지하는 네이티브 윈도우즈 앱들을 마술처럼 만들어 주는 방법이 아니다. 다시 말하지만, 당신이 시그윈 기능의 이점을 취하기 원한다면, 소스로부터 앱들을 리빌드할 필요가 있다.

앞에서도 언급했지만 특정 CPU 아키텍처에 대해 리눅스용으로 빌드된 프로그램은 윈도우즈에서 실행될 수 없다. 당연히 윈도우즈 환경에 맞는 구성으로 다시 빌드해야만 한다. 시그윈은 크로스 플래폼 개발을 가능하게 해주는 환경일 뿐이지, 에뮬레이터가 아니라는 것을 명심해야만 한다.

Cygwin 의 작동 원리.

그렇다면 시그윈은 어떻게 해서 리눅스와 같은 개발 환경을 지원하게 되는 것일까?

여러분은 Visual Sutdio 를 통해 프로젝트 설정을 하다가 '서브시스템' 이라는 항목을 본 적이 있을 것이다. 윈도우즈는 여러 개의 서브시스템을 가지고 있는데, 우리가 주로 사용하는 것이 Win32 서브시스템이다. 아래 그림은 Windows NT 의 시스템 아키텍처에서의 POSIX 서브시스템을 보여 주고 있다.

윈도우즈 NT 시스템 아키텍처( 출처 : 위키피디아 )

이 POSIX 라는 것은 Portable Operating System Interface 의 약자로 IEEE 가 운영체제 간의 호환성을 유지하기 위해서 제정한 표준이다.

POSIX( 대충 '파직스'라고 발음됨 )는 "Portable Operating System Interface" 의 머리글자들이며, 운영체제 간의 호환성을 유지하기 위해서 IEEE 에 의해 제정된 표준 패밀리이다. POSIX 는 다양한 유닉스 및 다른 운영 체제들 간의 소프트웨어 호환성을 위해 응용프로그램 인터페이스( API )와 명령줄 쉘, 그리고 유틸리티 인터페이스들을 정의한다.

중략...

유닉스 같은 운영 체제 환경을 위한 POSIX 명세는 원래 코어 프로그래밍 인터페이스를 위한 단일 문서로 구성되어 있었지만, 결국에는 19 개의 분리된 문서로 늘어 났다( 예를 들면 POSIX1, POSIX2, 등 ). 표준화된 사용자 명령 줄과 스크립팅 인터페이스들은 Korn Shell 에 기반했다. awk, echo, ed 등을 포함하는 많은 사용자 수준 프로그램, 서비스, 유틸리티들도 표준화되었으며, 기본적인 I/O( 파일, 터미널, 네트웤 )을 포함하는 프로그램 수준 서비스들도 포함한다. POSIX 는 표준 스레딩 라이브러리 API 도 정의하는데, 이는 현대의 거의 대부분의 OS 에 의해서 지원된다. 요새는 대부분의 POSIX 파트들이 하나의 IEEE Std 1003. 1-2008 표준에 포하모디었으며, 이는 POSIX 1-2008 로 알려져 있다.

하략...

- 출처 : 위키피디아, POSIX

OS/2 라는 것은 MS 와 IBM 이 초기에 제작한 운영체제로 요새는 별로 의미가 없으므로 관심있는 분들은 위키피디아의 OS/2 라는 글을 따로 읽어 보기 바란다.

POSIX 를 지원하는 OS 리스트는 다음 링크의 'POSIX-oriented operating systems' 절에서 찾아 볼 수 있다 : 위키피디아, POSIX. GNU/Linux 같은 경우에는 POSIX 에 대해 '거의 대부분의 호환성' 을 가지고 있다. 시그윈은 POSIX 에 대해 '많은 호환성' 을 가지고 있다고 표현되고 있다. 즉 안드로이드 시스템의 기반이 되는 리눅스가 POSIX 를 거의 완벽하게 지원하고 있기 때문에, 우리는 윈도우즈 상에서 시그윈을 통해 거기에 맞는 환경을 구성할 수 있는 것이다.

위에서 윈도우즈의 POSIX 서브시스템에서 언급을 했는데 여기에서 윈도우즈의 POSIX 를 언급한 것은 그냥 예를 든 것 뿐이다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어라는 이야기는 아니다. 왜 그럴까? 윈도우즈의 POSIX 서브시스템은 POSIX 표준을 제대로 지키고 있지 않기 때문이다. 

시그윈은 윈도우즈의 POSIX 와는 개별적으로 동작하는 개발환경이다. 시그윈 환경, 시그윈 서브시스템, 시그윈 플래폼 등의 용어를 사용해도 무방하지 않을까 싶다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어로서 동작하지 않는 이유는 다음 글을 보면 좀 더 이해가 가지 않을까 싶다 : The Sad History of the Microsoft POSIX Subsystem. 아래에 일부만 인용해 보았다. 요약하면 윈도우즈 POSIX 가 허접(?)이란 것과 XP 부터는 POSIX 서브시스템을 지원하지 않는다는 것이다. 그 뒤의 이야기가 쭉 나오는데 다 읽어 보지는 못했다.

윈도우즈 NT 가 처음 개발되고 있었을 때, 목표 중의 하나는 커널을 프로그래밍 인터페이스와 분리하는 것이었다. NT 는 원래 OS/2 를 성공시키기 위한 것이었지만, 마이크로소프트는 윈도우즈 3.x 응용프로그램들을 실행하기 위한 호환성을 포함시키고, 방위산업 시장에 판매하기 위한 1980 년대 DoD( 국방성 ) Orange Book 과 FIPS 명세들을 만족시키기 원했다. 결과적으로 윈도우즈 NT 는 복잡한 자유재량에 의한 접근 제어 기능을 가진 멀티유저 플래폼으로서 개발되었으며, 하이브리드 마이크로커널 3 유저랜드^[각주:1] 환경들로서 구현되었다 :

• Windows( Win32 )
• OS/2
• POSIX

마이크로소프트는 Win32 문제를 가지고 IBM 과 다퉜으며, NT 프로젝트는 OS/2 와 갈라섰다. 팀의 초점은 Win32 로 이동했다. 그래서 Win32 API 를 호스트하는 Client Server Runtime Subsystem( CSRSS ) 은 의무적이 되었으며, OS/2 와 POSIX 서브시스템이 실제로 완료되지 않았음에도 불구하고 그것들은 윈도우즈 NT 부터 윈도우즈 2000 까지 5 개의 버전에 포함되었다. OS/2 서브시스템은 단지 OS/2 1.0 명령줄 프로그램들만을 실행할 수 있으며, presentation manager 에 대한 지원이 존재하지 않았다. POSIX 서브시스템은 POSIX.1 명세를 지원했지만, 모든 종류의 쉘이나 유닉스 같은 환경을 제공하지 않았다. Win32 가 윈도우즈 95 의 형태에서 성공하면서, OS/2 와 POSIX 서브시스템의 개발은 중단되었다. 그것들은 윈도우즈 XP 와 윈도우즈 서버 2003 에서 완전히 죽고 사라졌다.

반면에 Softway Systems 는 1996 년 쯤에 OpenNT 라고 불리는 유닉스-윈도우즈 NT 간 포팅 시스템을 개발했다. OpenNT 는 NT POSIX 서브시스템 상에서 빌드되었지만, 그것에 살을 붙여 이용할 수 있는 유닉스 환경을 제공했다. 이는 유닉스 시스템이 매우 비싸진 시점이었다. Softway 는 OpenNT 를 사용해서 US Federal agency 들을 위한 여러 유닉스 응용프로그램들을 윈도우즈 NT 로 변경했다. 1998 년에 OpenNT 는 Interix 라고 이름을 바꿨다. Softway Systems 는, 마이크로소프트 POSIX 서브시스템이 지원하지 않았던 시스템 호출을 구현하고, 풍부한 libc,  파일 시스템에 대한 single-rooted view, 그리고 실용적인 gcc 를 개발하기 위해, 최종적으로 NT POSIX 서브시스템에 대한 완전한 대체물을 만들었다.

하략...

위키피디아에 의하면 Windows Server 2003 R2 부터는 사실은 Interix 의 변형인 SUA( Subsystem for UNIX-based Applications )를 통해서 POSIX 를 지원하고 있다고 한다. 이것은 SFU( Windows Services for UNIX )라고 불리기도 한다. Windows Vista 및 Windows 7 의 Enterprise 에디션과 Ultimate 에디션도 SUA 를 포함하고 있다고 한다. 자세한 내용은 Windows Services for UNIX 를 참조하라.

결론.

우리가 윈도우즈 환경에서 리눅스 ARM 용 프로그램을 빌드하기 위해서는, 그에 맞는 바이너리를 생성해 줄 수 있는 환경( 컴파일러, API 등 )을 구성할 필요가 있다. 윈도우즈에서 이를 가능하게 해 주는 것이 POSIX 기반의 시그윈 개발 환경이다. 

우리는  시그윈 환경을 이용해 리눅스 ARM 용 프로그램을 빌드하고, 그것을 안드로이드 장치로 복사하고 설치하게 된다. 이것이 윈도우즈와 리눅스 간의  크로스 플래폼 개발이다. 안드로이드 SDK 를 사용하게 되면 자바 바이트 코드( 플래폼에 독립적인 중간 코드 )를 생성하기 때문에 빌드 환경이 중요하지 않지만, 안드로이드 NDK 는 실제 리눅스 API 를 이용하고 기계어로 컴파일하기 때문에 반드시 올바른 환경에서 개발해야만 한다.

이제 시그윈이라는 것의 정체에 대해 어느 정도 이해할 수 있게 되었을 것이라 생각한다. 그리고 시그윈을 통해 뭔가를 빌드한다는 것의 의미에 대해서 이해할 수 있게 되었을 것이라 생각한다.

다음에 시간이 나면 POSIX 에 대해서 좀 더 구체적으로 다뤄 보도록 하겠다.

 개발자라면 자신이 사용하고 있는 도구들에 대한 개념을 어느 정도는 이해하고 있어야만 합니다. 그런 의미에서 ADB( Android Debug Bridge )에 대한 글을 번역해 보았습니다.

원문 : Android Debug Bridge.

주의 : 번역이 개판이므로 이상하면 반드시 원문을 참조하세요.

주의 : 가독성을 높이기 위해서 발음이 비슷하거나 잘 알려진 용어는 한글로 표기합니다.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

Android Debug Bridge

Android Debug Bridge( adb )는 다용도의 명령줄 도구인데, 당신이 에뮬레이터 인스턴스나 안드로이드용 장치와 통신할 수 있도록 해 준다. 이는 클라이언트-서버 프로그램으로, 세 가지 요소를 포함한다.

• 클라이언트. 이는 당신의 개발 머신 상에서 동작한다. 당신은 adb 명령을 날림으로써 쉘^shell로부터 클라이언트를 실행할 수 있다. ADT 플러그인과 DDMS 와 같은 다른 안드로이드 도구들도 adb 클라이언트들을 생성한다.
• 서버. 이는 당신의 개발 장치 상에서 백그라운드 프로세스로서 동작한다. 이 서버는 클라이언트와 에뮬레이터나 장치상에서 실행중인 adb daemon 사이의 통신을 관리한다.
• Daemon. 이는 각각의 에뮬레이터나 장치 상에서 백그라운드 프로세스로서 동작한다.

당신은 adb 도구를 <sdk>/paltform-tools/ 에서 찾을 수 있다.

당신이 adb 클라이언트를 실행할 때, 그 클라이언트는 먼저 이미 실행중인 adb 서버 프로세스가 존재하는지를 검사한다. 만약 존재하지 않으면, 그것은 서버 프로세스를 실행한다. 서버가 시작될 때, 그것은 로컬 TCP 포트 5037 에 연결되며, adb 클라이언트들로부터 보내지는 명령들을 받는다 - 모든 adb 클라이언트들은 5037 포트를 사용해서 adb 서버와 통신한다.

그리고 나서 서버는 모든 실행중인 에뮬레이터/장치 인스턴스들에 대한 연결을 설정한다. 그것은 에뮬레이터/장치들에 의해 사용되는 5555 에서 5585 사이의 홀수 번호 포트들을 스캐닝함으로써 에뮬레이터/장치 인스턴스들을 배치한다. 서버가 adb daemon 을 찾으면, 그것은 그 포트에 연결을 설정한다. 각 에뮬레이터/장치 인스턴스들은 연속된 포트의 쌍을 요청한다는데 주의하라 - 콘솔 연결을 위해 짝수 번호 포트를 사용하고, adb 연결을 위해 홀수 번호 포트를 사용한다. 예를 들어 :

에뮬레이터 1, 콘솔 : 5554

에뮬레이터 1, adb : 5555

에뮬레이터 2, 콘솔 : 5556

에뮬레이터 2, adb : 5557

이런 식이다...

위에서 보이듯이 5555 포트에 연결된 에뮬레이터 인스턴스는 5554 포트에서 응답을 받는 콘솔의 인스턴스와 동일하다.

일단 서버가 모든 에뮬레이터 인스턴스들에 대한 연결을 설정하고 나면, 당신은 adb 명령을 사용해서 그러한 인스턴스들에 접근할 수 있다. 서버는 에뮬레이터/장치 인스턴스들에 대한 연결을 관리하고 다중의 adb 클라이언트들로부터의 명령을 다루기 때문에, 당신은 모든 클라이언트들( 혹은 스크립트 )로부터 모든 메율레이터/장치 인스턴스들을 제어할 수 있다.

Syntax

당신은 개발 머신의 명령줄이나 스크립트에서 adb 명령을 제출^issue할 수 있다. 용례는 다음과 같다 :

만약 단 하나의 에뮬레이터가 실행되고 있거나 단 하나의 장치만이 연결되어 있다면, adb 명령은 기본적으로 그 장치로 보내 진다. 만약 다중의 에뮬레이터가 실행되고 있거나 다중의 장치가 연결되어 있다면, 당신은 -d, -e, -s 옵션을 사용해서 그 명령이 향해야만 하는 대상 장치를 지정해야할 필요가 있다.

Commands

아래 표는 지원되는 adb 명령들을 모두 열거하고, 그것들의 의미 및 용례를 설명한다.

표1. 이용 가능한 adb 명령들.

Querying for Emulator/Device Instances

adb 명령을 제출하기 전에, 어떤 에뮬레이터/장치 인스턴스들이 adb 서버에 연결되는지 아는 것이 도움이 된다. 당신은 연결된 에뮬레이터/장치들의 리스트를 devices 명령을 사용해서 생성할 수 있다.

응답으로, adb 는 각 인스턴스에 대한 상태 정보를 출력한다.

• 시리얼 넘버 - 에뮬레이터/장치 인스턴스를 유일하게 식별하기 위해서 그것의 콘솔 포트 넘버를 사용해 adb 에 의해 생성된 문자열이다. 그 시리얼 넘버의 포맷은 <type>-<consolePort>이다. 여기에 시리얼 넘버의 예가 있다 : enumerator-5554.
• 상태 - 그 인스턴스의 연결 상태는 다음 중 하나일 것이다.
• offline - 그 인스턴스가 adb 에 연결되지 않았거나 응답하지 않고 있음.
• device - 그 인스턴스가 이제 adb 서버에 연결됨. 이 상태는 안드로이드 시스템이 완전히 부팅되거나 실행중임을 내포하지 않으며 선택적이다. 왜냐하면 그 인스턴스는 시스템이 부팅중일 때 adb 에 연결되기 때문이다. 그러나 부팅이 되고 나면, 에뮬레이터/장치 인스턴스에 대한 일반적인 실행가능한 상태이다.
• no device - 어떠한 에뮬레이터/장치도 연결되지 않음.

각 인스턴스를 위한 출력은 다음과 같은 형식이다 :

여기 devices 명령과 그것의 출력을 보여 주는 예가 있다.

Directing Commands to a Specific Emulator/Device Instance

만약 다중의 에뮬레이터/장치 인스턴스들이 실행중이라면, 당신은 반드시 adb 명령들을 제출할 때 대상 인스턴스를 지정해야만 한다. 이를 위해서, 명령들에서 -s 옵션을 사용하라. -s 옵션의 용례는 다음과 같다.

보면 알겠지만, 당신은 adb 할당 시리얼 넘버를 사용해 명령을 위한 대상 인스턴스를 지정한다. 당신은 devices 명령을 사용해 실행중인 에뮬레이터/장치 인스턴스들의 시리얼 넘버를 획득할 수 있다. 예를 들어 :

다중 장치들이 이용가능 할 때, 만약 당신이에뮬레이터/장치 인스턴스를 지정하지 않고 명령을 제출한다면, adb 는 에러를 생성한다는 것에 주의하라.

당신이 이용 가능한 다중의 장치( 하드웨어 혹은 에뮬레이터 )를 가지고 있지만 단 하나만이 에뮬레이터라면, 단순히 -e 옵션을 사용해 에뮬레이터에다가 명령들을 보내라. 이와 유사하게 다중의 장치들이 있지만 단 하나의 하드웨어 장치만이 연결되었다면, -d 옵션을 사용해서 하드웨어 장치에 명령을 보내라.

Installing an Application

당신은 개발 컴퓨터로부터의 응용프로그램을 복사해 에뮬레이터/장치 인스턴스에 설치하기 위해서 adb 를 사용할 수 있다. 이를 위해, install 명령을 사용하라. 그 명령을 사용하면, 당신은 설치하기 원하는 .apk 파일의 경로를 지정해야만 한다.

에뮬레이터/장치 인스턴스 상에 설치하고자 하는 .apk 을 생성하는 방법에 대한 더 많은 정보를 원한다면, Building and Running 을 참조하라.

만약 당신이 Eclipse IDE 를 사용하고 있고 ADT 플러그인이 설치되어 있다면, 당신은 에뮬레이터/장치 상에 응용프로그램을 설치하기 위해 adb( 혹은 aapt )를 직접 사용할 필요가 없다는 것을 기억하라. 대신에 ADT 플러그인이 당신을 위해 응용프로그램의 패키징과 설치를 처리해 준다.

Forwarding Ports

당신은 forward 명령을 사용해서 임의의 포트 포워딩을 설정할 수 있다 - 특정 호스트 포트상에서 에뮬레이터/장치 상의 다른 포트로의 포워딩 요청. 여기 6100 호스트 포트에서 에뮬레이터/장치 포트 7100 으로의 포워딩을 설정하는 방법이 다음에 나와 있다.

당신은 다음과 같이 이름있는 추상 UNIX 도메인 소켓들로 포워딩을 설정하기 위해서 adb 를 사용할 수 있다.

Copying Files to or from an Emulator/Device instance

당신은 adb 의 pull 과 push 명령들을 사용해서 에뮬레이터/장치 인스턴스로부터 혹은 인스턴스로 파일을 복사할 수 있다. 특정 위치로 APK 파일을 복사만하는 install 명령과는 다르게, pull 과 push 명령은 에뮬레이터/장치 인스턴스의 모든 위치로 임의의 디렉토리나 파일들을  복사할 수 있게 해 준다.

에뮬레이터나 장치로부터 파일이나 디렉토리( 그리고 그것의 하위 디렉토리들 )를 복사하기 위해서는, 다음과 같은 명령을 사용한다.

파일이나 디렉토리( 그리고 그것의 하위 디렉토리들 )를 에뮬레이터나 장치로 복사하기 위해서는, 다음과 같은 명령을 사용한다.

명령에서 <local> 과 <remote> 는 당신의 개발 머신( local ) 과 에뮬레이터/장치 인스턴스( remote ) 상의 대상 파일/디렉토리에 대한 경로를 가리킨다. 예를 들어 :

Using activity manager( am )

adb 쉘에서, 당신은 activity manager( am ) 도구를 사용해 명령들을 제출하여 activity 를 시작하고, 프로세스를 강제로 종료시키고, intent 를 송출하고^broardcast, 장치 스크린 속성들을 수정하는 등과 같은 다양한 시스템 동작들을 수행할 수 있다. 쉘에 있는 동안, 그 문맥은 다음과 같다 :

당신은 remote 쉘에 진입하지 않고도 adb 로부터 직접적으로 activity manager 명령을 제출할 수도 있다. 예를 들어 :

표2. 이용 가능한 activity manager 명령들.

Specification for <INTENT> arguments

<INTENT> 인자를 취하는 activity manager 명령들을 위해, 당신은 다음과 같은 옵션들을 사용해 intent 를 지정할 수 있다 :

-a <ACTION>

"android.intent.action.VIEW" 와 같은 intent action 을 지정한다. 당신은 이를 한 번만 선언할 수 있다.

-d <DATA_URI>

"content://contacts/people/1" 와 같은 intent data URI 를 지정한다. 당신은 이를 한 번만 선언할 수 있다.

-t <MIME_TYPE>

"image/png" 과 같은 intent MIME 타입을 추가한다. 당신은 이를 한 번만 선언할 수 있다.

-c <CATEGORY>

"android.intent.category.APP_CONTACTS" 와 같은 intent 카테고리를 지정한다.

-n <COMPONENT>

"com.example.app/.ExampleActivity" 와 같은 명시적인 intent 를 생성하기 위한 패키지 이름 접두어를 사용해 컴포넌트 이름을 지정한다..

-f <FLAGS>

intent 에 setFlags() 에 의해 지원되는 플래그를 추가한다.

--esn <EXTRA_KEY>

null extra 를 추가한다. 이 옵션은 URI intent 들에 대해서는 지원되지 않는다.

-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE>

문자 데이터를 key-value 쌍으로서 추가한다.

--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE>

Boolean 데이터를 key-value 쌍으로서 추가한다.

--ei <EXTRA_KEY> <EXTRA_INT_VALUE>

정수 데이터를 key-value 쌍으로서 추가한다.

--el <EXTRA_KEY> <EXTRA_LONG_VALUE>

Long 데이터를 key-value 쌍으로서 추가한다.

--ef <EXTRA_KEY> <EXTRA_FLOAT_VALUE>

실수 데이터를 key-value 쌍으로서 추가한다.

--eu <EXTRA_KEY> <EXTRA_URI_VALUE>

URI 데이터를 key-value 쌍으로서 추가한다.

--ecn <EXTRA_KEY> <EXTRA_COMPONENT_NAME_VALUE>

ComponentName 개체로서 변환되고 전달될 컴포넌트의 이름을 추가한다.

--eia <EXTRA_KEY> <EXTRA_INT_VALUE>[,<EXTRA_INT_VALUE...]

정수 배열을 추가한다.

--ela <EXTRA_KEY> <EXTRA_LONG_VALUE>[,<EXTRA_LONG_VALUE...]

Long 배열을 추가한다.

--efa <EXTRA_KEY> <EXTRA_FLOAT_VALUE>[,<EXTRA_FLOAT_VALUE...]

실수 배열을 추가한다.

--grant-read-uri-permission

FLAG_GRANT_READ_URI_PERMISSION 플래그를 포함시킨다.

--grant-write-uri-permission

FLAG_GRANT_WRITE_URI_PERMISSION 플래그를 포함시킨다.

--debug-log-resolution

FLAG_DEBUG_LOG_RESOLUTION 플래그를 포함시킨다.

--exclude-stopped-packages

FLAG_EXCLUDE_STOPPED_PACKAGES 플래그를 포함시킨다.

--include-stopped-packages

FLAG_INCLUDE_STOPPED_PACKAGES 플래그를 포함시킨다.

--activity-brought-to-front

FLAG_ACTIVITY_BROUGHT_TO_FRONT 플래그를 포함시킨다.

--activity-clear-top

FLAG_ACTIVITY_CLEAR_TOP 플래그를 포함시킨다.

--activity-clear-when-task-reset

FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET 플래그를 포함시킨다.

--activity-exclude-from-recents

FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 플래그를 포함시킨다.

--activity-launched-from-history

FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY 플래그를 포함시킨다.

--activity-multiple-task

FLAG_ACTIVITY_MULTIPLE_TASK 플래그를 포함시킨다.

--activity-no-animation

FLAG_ACTIVITY_NO_ANIMATION 플래그를 포함시킨다.

--activity-no-history

FLAG_ACTIVITY_NO_HISTORY 플래그를 포함시킨다

--activity-no-user-action

FLAG_ACTIVITY_NO_USER_ACTION 플래그를 포함시킨다.

--activity-previous-is-top

FLAG_ACTIVITY_PREVIOUS_IS_TOP 플래그를 포함시킨다.

--activity-reorder-to-front

FLAG_ACTIVITY_REORDER_TO_FRONT 플래그를 포함시킨다.

--activity-reset-task-if-needed

FLAG_ACTIVITY_RESET_TASK_IF_NEEDED 플래그를 포함시킨다.

--activity-single-top

FLAG_ACTIVITY_SINGLE_TOP 플래그를 포함시킨다.

--activity-clear-task

FLAG_ACTIVITY_CLEAR_TASK 플래그를 포함시킨다.

--activity-task-on-home

FLAG_ACTIVITY_TASK_ON_HOME 플래그를 포함시킨다.

--receiver-registered-only

FLAG_RECEIVER_REGISTERED_ONLY 플래그를 포함시킨다.

--receiver-replace-pending

FLAG_RECEIVER_REPLACE_PENDING 플래그를 포함시킨다.

--selector

intent 데이터와 타입을 설정하기 위해서 -d 와 -t 옵션의 사용을 요구한다.

<URI> <COMPONENT> <PACKAGE>

위의 옵션들 중 하나에 의해 한정되지 않을 때, 당신은 직접적으로 URI, 패키지 이름, 컴포넌트 이름을 지정할 수 있다. 인자가 한정되지 않았을 때, 그 도구는 그것이 ":"( 콜론 )을 포함한다면 그 인자를 URI 로 가정한다; 그것이 "/"( 슬래쉬 )를 포함하면 인자를 컴포넌트 이름으로 가정한다; 그렇지 않으면 그것은 인자를 패키지 이름으로 가정한다.

Using package manager( pm )

adb 쉘 안에서, 당신은 package manager( pm ) 도구를 사용하는 명령들을 제출함으로써 장치에 설치된 응용프로그램 패키지들 상에서의 동작과 질의를 수행할 수 있다. 쉘에 있는 동안, 그 문맥은 다음과 같다 :

당신은 remote 쉘에 진입하지 않고도 adb 로부터 package manager 명령을 직접적으로 제출할 수 있다. 예를 들어 :

표3. 이용 가능한 package manager 명령들.

Examing sqlite3 databases from a remote shell

adb remote 쉘에서, 당신은 안드로이드 응용프로그램들에 의해서 생성된 SQLite 데이터베이스들을 관리하기 위해서 sqllite3 명령줄 프로그램을 사용할 수 있다. sqlite3 도구는 많은 유용한 명령들을 포함하고 있다; .dump 는 테이블의 내용을 출력하며, .schema 는 현존 테이블을 위한 SQL CREATE 상태를 출력한다. 이 도구는 SQLite 명령들을 실시간에 실행할 수 있는 기능을 제공하기도 한다.

sqlite3 를 사용하기 위해, 에뮬레이터 인스턴스 상의 remote 쉘로 들어간다. 그리고 나서 sqlite3 명령을 사용해 그 도구를 실행한다. sqlite3 를 실행할 때 당신은 선택적으로 당신이 살펴 보고자 하는 데이터베이스의 전체 경로를 지정할 수 있다. 에뮬레이터/장치 인스턴스들은 SQLite3 데이터베이스들을 /data/data/<package_name>/databases/ 폴더에다가 저장한다.

여기 예제가 있다 :

일단 sqlite3 를 실행하고 나면, 당신은 그 쉘에서 sqlite3 명령들을 제출할 수 있다. adb remote 쉘로 나가고 싶으면, exit 나 CTRL+D 를 사용한다.

UI/Application Exerciser Monkey

몽키는 당신의 에뮬레이터나 장치 상에서 실행되는 프로그램이며, 클릭, 터치, 제스쳐 등과 같은 사용자 이벤트들과 시스템 수준 이벤트들의 의사-랜덤 스트림들을 생성한다. 당신은 몽키를 사용해서 당신이 개발하고 있는 응용프로그램들에 대한 랜덤하지만 약간 반복적인 방식으로 스트레스 테스트를 할 수 있다.

몽키를 사용하는 가장 단순한 방법은 아래 명령을 사용하는 것인데, 그것은 당신의 응용프로그램을 실행하고 500 개의 의사-랜덤 이벤트들을 그것에 보낸다.

몽키를 위한 명령 옵션에 대한 더 많은 정보를 원한다면, 완전한 UI/Application Exerciser Monkey 문서화 페이지를 참조하라.

Other shell commands

이용 가능한 모든 쉘 프로그램들을 열거하기 위해서는 다음과 같은 명령을 사용하라 :

help 는 대부분의 명령들에 대해 이용할 수 있다.

표4 는 좀 더 공용적인 adb 쉘 명령들을 열거한다.

표4. 일부 다른 adb 쉘 명령들.

Enabling locat logging

안드로이드 로깅 시스템은 시스템 디버그 출력을 수집하고 보기 위한 메커니즘을 제공한다. 다양한 응용프로그램 및 시스템의 일부로부터의 로그들은 일련의 circular buffer 들 안에 수집되는데, 그것들은 logcat 명령에 의해 보여지고 필터링될 수 있다.

당신은 logcat 명령을 사용해 시스템의 로그 버퍼들의 내용을 보고 따라갈 수 있다. 범용적인 용례는 다음과 같다 :

당신은 logcat 명령을 개발 컴퓨터나 에뮬레이터/장치 인스턴스의 remote adb 쉘에서 사용할 수 있다. 개발 컴퓨터에서 로그 출력을 보려면, 다음과 같이 한다 :

그리고 remote adb 쉘에서 로그 출력을 보려면 다음과 같이 한다 :

logcat 명령 옵션들과 filter 명세들에 대한 완전한 정보를 원한다면 Reading and Writing Logs 를 참조하라.

Stopping the adb server

어떤 경우에, 당신은 adb 서버 프로세스를 종료시키고, 그것을 다시 시작하기 원할 것이다. 예를 들어 adb 가 명령에 응답하지 않는다면, 당신은 그 서버를 종료시키고 재시작할 수 있으며, 그것은 그 문제를 해결할 것이다.

adb 서버를 중지하고자 한다면, kill-server 명령을 사용하라. 그리고 나서 당신은 다른 adb 명령을 제출함으로써 그 서버를 재시작할 수 있다.

원문 : http://developer.android.com/tools/publishing/app-signing.html

주의 : 번역이 개판이므로 원문을 참조하세요.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

주의 : 가독성을 높이기 위해서 잘 알려진 용어나 발음이 비슷한 용어는 한글로 표기합니다.

Signing Your Applications( 응용프로그램 서명하기 )

안드로이드 시스템은 모든 설치된 응용프로그램들이 응용프로그램의 개발자에 의해 설정된^held 개인 키^{private key} 를 가진 인증서^certificate 를 사용해 디지털 방식으로 서명될 것을 요구한다. 안드로이드 시스템은 그 인증서를 응용프로그램의 저작자를 식별하고 응용프로그램 사이에서 신뢰 관계를 설정하는데 사용한다. 그 인증서는 사용자가 설치할 수 있는 응용프로그램이 무엇인지를 제어하는데 사용되지는 않는다. 그 인증서는 인증 기관^{certificate authority}에 의해서 서명될 필요는 없다: 안드로이드 응용프로그램을 위해서 자체 서명 인증서를 사용하는 것은 일반적이며 완전히 허용되어 있다.

안드로이드 응용프로그램에 대한 서명을 이해하기 위해서 몇 가지 중요한 점이 있다 :

• 모든 응용프로그램은 반드시 서명되어야만 한다. 시스템은 서명되지 않은 응용프로그램을 에뮬레이터나 디바이스 상에 설치하지 않을 것이다.
• 응용프로그램을 디버깅하기 위해서, 빌드 툴들은 당신의 응용프로그램을 특별한 디버그 키를 사용해서 서명하는데, 그것은 안드로이드 SDK 빌드 툴에 의해서 생성된다.
• 당신의 응용프로그램을 최종 사용자들에게 릴리스할 준비가 되었을 때, 당신은 그것을 적절한 개인 키를 사용해 서명해야만 한다. 당신은 SDK 툴들에 의해서 생성된 디버그 키를 사용해 서명된 응용프로그램을 배포할 수 없다.
• 당신의 응용프로그램을 서명하기 위해서 자체 서명된 인증서를 사용할 수 있다. 인증 기관은 필요치 않다.
• 시스템은 서명자의 인증서의 유효 기간을 설치시에만 검사한다. 만약 응용프로그램의 서명자 인증서가 응용프로그램이 설치된 후에 만료되었다면, 응용프로그램은 정상적으로 계속 기능할 것이다.
• 당신은 표준 툴 - Keytool 과 Jarsigner - 를 사용해서 키를 생성하고 응용프로그램 .apk 파일들을 서명할 수 있다.
• 릴리스를 위해서 당신의 응용프로그램을 서명한 후에, 당신이 zipalign 툴을 사용해 최종 APK 패키지를 최적화할 것을 추천한다.

안드로이드 시스템은 적절히 서명되지 않은 응용프로그램을 설치하거나 실행하지 않을 것이다. 이는 안드로이드 시스템이 실제 디바이스에서 실행되든 에뮬레이터에서 실행되든 상관없이 적용된다. 그렇기 때문에, 당신은 반드시 에뮬레이터나 디바이스 상에서 그것을 실행하거나 디버깅하기 전에 응용프로그램에 대한 서명을 설정해야만 한다.

Signing Process( 서명 절차 )

안드로이드 빌드 절차는 응용프로그램을 빌드하기 위해서 사용하는 빌드 모드에 의존해 다른 서명을 한다. 두 가지 빌드 모드가 있다: 디버그 모드와 릴리스 모드. 당신은 응용프로그램을 개발하고 테스트하고 있는 동안에 디버그 모드를 사용한다. 당신은 사용자에게 직접적으로 배포할 수 있거나 Google Play 와 같은 응용프로그램 마켓에서 배포할 수 있는 릴리스 버전의 응용프로그램을 빌드하고자 할 때 릴리스 모드를 사용한다. 

디버그 모드에서 빌드할 때, 안드로이드 SDK 빌드 툴들은 ( JDK 에 포함된 ) Keytool 유틸리티를 사용하여 디버그 키를 생성한다. SDK 빌드 툴들은 디버그 키를 생성하기 때문에, 그것들은 디버그 키의 별명^alias과 비밀번호를 알고 있다. 당신이 디버그 모드로 응용프로그램을 컴파일할 때마다, 빌드 툴들은 ( 역시 JDK 에 포함된 ) Jarsigner 유틸리티와 디버그 키를 사용해서 당신의 응용프로그램의 .apk 파일을 서명한다. 그 별명과 비밀번호가 SDK 빌드 툴들에 알려져 있기 때문에, 그 툴들은 당신에게 디버그 키의 별명과 패스워드를 컴파일할 때마다 묻는 작업을 할 필요가 없다.

당신이 릴리스 모드로 빌드할 때, 당신은 자신만의 개인 키를 사용해 당신의 응용프로그램을 서명한다. 만약 당신이 개인 키를 가지고 있지 않다면, 당신은 Keytool 유틸리티를 사용해서 키를 생성할 수 있다. 응용프로그램이 릴리스 모드에서 컴파일될 때, 빌드 툴들은 당신의 개인 키를 Jarsigner 유틸리티와 함께 사용해 당신의 응용프로그램의 .apk 파일을 서명한다. 당신이 사용하는 인증서와 개인키는 당신의 것이기 때문에, 당신은 keystore 와 key alias 를 위한 비밀번호를 제공해야만 한다.

당신이 Eclipse 를 ADT 플러그인과 함께 사용해 응용프로그램을 실행하거나 디버깅하고 있을 때는, 디버그 서명 절차가 자동적으로 수행된다. Ant 빌드 스크립트를 debug 옵션과 함께 사용할 때도, 디버그 서명은 자동적으로 수행된다. 당신은 Eclipse Export Wizard 를 사용하거나 Ant 빌드 스크립트를 수정하고 release 옵션으로 빌드함으로써 릴리스 서명 절차를 자동화할 수 있다.

Signing Strategies( 서명 전략들 )

어떤 관점에서의 응용프로그램 서명은 아마도 당신의 응용프로그램 개발에 접근하는 방식에 영향을 줄 수도 있다. 특히 당신이 여러 개의 응용프로그램을 릴리스할 계획을 가지고 있다면 더욱 그러하다.

일반적으로 모든 개발자들을 위해서 추천되는 전략은 당신의 응용프로그램의 기대 수명 전반에 있어서 같은 인증서를 사용해서 서명하는 것이다. 당신이 그렇게 해야 하는 몇 가지 이유가 있다 :

• 응용프로그램 업그레이드 - 당신이 응용프로그램에 업데이트를 릴리스할 때, 만약 사용자가 새로운 업데이트를 끊김없이 사용하기를 원한다면, 당신은 계속해서 같은 인증서나 같은 인증서 집합을 사용해 업데이트에 서명하는 것을 원할 것이다. 시스템이 응용프로그램에 대한 업데이트를 설치할 때, 그것은 현존하는 버전의 인증서와 새로운 버전의 인증서를 비교한다. 만약 인증서 데이터와 순서가 정확하게 맞으면, 시스템은 업데이트를 허용한다. 만약 당신이   일치하는 인증서들을 사용하지 않고 새로운 버전을 서명하게 되면, 당신은 응용프로그램에 대해 새로운 패키지 이름을 할당할 필요가 있을 것이다 - 이 경우에, 사용자는 완전히 새로운 응용프로그램으로서 새로운 버전을 설치한다.
• 응용프로그램 모듈화 - 안드로이드 시스템은 같은 인증서에 의해 서명된 응용프로그램들이 같은 프로세스에서 실행될 것을 요청받으면 그것을 허용한다. 그래서 시스템은 그것들을 단일 응용프로그램으로 취급한다. 이러한 방식으로 당신은 응용프로그램을 모듈 단위로 배치할 수 있으며, 사용자들은 필요하다면 각 모듈을 독립적으로 업데이트할 수 있다.
• 권한을 통한 코드/데이터 공유 - 안드로이드 시스템은 서명 기반 승인 집행^{signature-based permissions enforcement}을 제공한다. 그래서 응용프로그램은 특정 인증서를 사용해 서명된 다른 응용프로그램에 기능을 노출할 수 있다. 여러 개의 응용프로그램을 같은 인증서를 사용해 서명하고 서명 기반 승인 검사를 이용하면, 당신의 응용프로그램은 안전하게 코드와 데이터를 공유할 수 있다.

서명 전략을 결정하는 데 있어서 다른 중요하게 고려해야할 점은 당신의 응용프로그램을 서명하기 위해서 사용할 키의 유효 기한을 설정하는 방법이다.

만약 당신이 단일 응용프로그램을 위한 업그레이드를 지원할 계획을 가지고 있다면, 당신은 당신의 키가 그 응용프로그램의 기대 수명을 초과하는 유효 기한을 가지도록 보장해야만 한다. 25 년 이상의 유효 기한이 추천된다. 당신의 키의 유효 기한이 만료되면, 사용자들은 더 이상 계속해서 새로운 버전의 응용프로그램에 대한 업그레이드를 할 수 없을 것이다.

만약 당신이 여러 개의 분리된 응용프로그램들을 같은 키를 사용해서 서명한다면, 당신은 당신의 키가 모든 응용프로그램의 모든 버전에 대한 기대 수명을 초과하는 유효기한을 가지도록 보장해야만 한다. 이 때 그 응용프로그램들에는 미래에 추가할 수도 있는 의존성있는 응용프로그램들이 포함된다.

만약 당신이 응용프로그램을 Google Play 에서 배포할 계획을 가지고 있다면, 당신이 응용프로그램을 서명하는데 사용한 키는 반드시 2033 년 10 월 22 일 이후에 종료되는 유효 기한을 가져야만 한다. Google Play 는, 새로운 버전이 이용 가능할 때 사용자들이 계속해서 응용프로그램을 업그레이드할 수 있도록 보장하기 위해서, 이 요구사항을 강제한다.

당신의 응용프로그램을 설계할 때, 이러한 점을 유념하고 응용프로그램을 서명하기 위한 적절한 인증서를 확인하기 바란다.

Basic Setup for Signing( 서명을 위한 기본 설정 )

시작하기 전에, Keytool 유틸리티와 Jarsigner 유틸리티가 SDK 빌드 툴들에 대해 이용 가능한지를 확인하라. 두 툴은 모두 JDK 에서 이용할 수 있다. 대부분의 경우에, 당신은 JAVA_HOME 환경 변수를 설정함으로써 이러한 유틸리티들을 찾는 방법을 SDK 빌드 툴들에 알려줄 수 있다. 이를 통해 빌드 툴들은 적절한 JDK 를 참조하게 된다. 그렇지 않으면, 당신은 JDK 버전의 Keytool 과 Jarsigner 을 당신의 PATH 변수에다가 추가할 수 있다.

만약 Java 를 위한 GNU 컴파일러를 원래부터 포함하는 버전의 리눅스 상에서 개발중이라면, 시스템이 JDK 버전의 Keytool 을 사용하고 있는지 확인하라. 만약 Keytool 이 이미 PATH 에 존재한다면, 그것은 /usr/bin/keytool 의 symlink^[각주:1] 를 가리키고 있을 것이다. 이 경우, symlink 대상을 확인해 그것이 JDK 의 Keytool 을 가리키는지를 확인하라.

Signing in Debug Mode( 디버그 모드에서 서명하기 )

안드로이드 빌드 툴들은 응용프로그램을 더 쉽게 개발하고 디버깅하게 하기 위해서 디버그 서명 모드를 제공한다. 그러면서도 여전히 APK 를 서명하기 위한 안드로이드 시스템 요구사항을 만족시킨다. 응용프로그램을 빌드하기 위해서 디버그 모드를 사용할 때, SDK 툴들은 Keytool 을 실행해서 자동적으로 디버그 키스토어와 키를 생성한다. 그리고 나서 이 디버그 키는 자동적으로 APK 를 서명하기 위해 사용되며, 그래서 당신은 자신의 키를 사용해 패키지를 서명할 필요가 없다.

SDK 툴들은 디버그 키스토어/키 를 미리 결정된 이름/비밀번호 를 사용해 생성한다.

• 키스토어 이름 : "debug.keystore"
• 키스토어 비밀번호 : "android"
• 키 별명 : "androiddebugkey"
• 키 비밀번호 : "android"
• CN: "CN=Android Debug,0=Android,C=US"

필요하다면 디버그 키스토어/키 의 위치/이름 을 변경하거나 커스텀 디버그 키스토어/키 를 공급할 수 있다. 그러나 모든 커스텀 디버그 키스토어/키 는 반드시 ( 위에 언급된 것처럼 ) 기본 디버그 키와 같은 키스토어/키 이름과 비밀번호를 가져야 한다. ( 그렇게 하기 위해서는 Eclipse/ADT 에서, Windows > Preferences > Android > Build 로 이동하라. )

주의 : 당신은 디버그 인증으로 서명된 응용프로그램을 대중에게 릴리스할 수 없다.

Eclipse Users

당신이 Eclipse/ADT 에서 개발하고 있다면 ( 그리고 Basic Setup for Signing 에서 기술된 것처럼 Keytool 과 Jarsigner 를 설정했다면 ), 디버그 모드에서의 서명은 기본적으로 활성화된다. 당신이 응용프로그램을 실행하거나 디버그할 때, ADT 는 .apk 파일을 디버그 인증서를 사용해 서명하고, 패키지 상에 zipalign 을 실행하고, 그 다음에 선택된 에뮬레이터나 연결된 디바이스 상에 그것을 설치한다. 당신이 해야할 특별한 일은 없으며, 제공된 ADT 가 Keytool 에 대한 접근권을 가진다.

Ant Users

만약 .apk 파일을 빌드하기 위해 Ant 를 사용하고 있다면, ant 명령을 debug 옵션과 함께 사용함으로써 디버그 서명 모드가 활성화된다( 당신이 android 툴을 사용해서 생성한 build.xml 파일을 사용하고 있다고 가정한다 ). 당신이 and debug 를 실행해서 응용프로그램을 컴파일할 때, 빌드 스크립트는 키스토어/키 를 생성하며, 당신을 위해서 APK 에 서명한다. 그리고 나서 스크립트는 API 를 zipalign 툴을 사용해 정렬한다. 당신이 해야 할 일은 없다. 더 많은 정보를 원한다면 Building and Running Apps on the Command Line 을 읽어 보라.

Expiry of the Debug Certificate( 디버그 인증서 만료 )

디버그 모드에서 ( Eclipse/ADT 와 Ant 빌드의 기본 설정 ) 응용프로그램을 서명하기 위해서 사용된 자체 서명 인증서는 그것의 생성일로부터 1 년의 만료일을 가진다.

인증서가 만료되면, 당신은 빌드 에러를 만나게 될 것이다. Ant 빌드에서 에러는 다음과 같다 :

Eclipse/ADT 에서, 당신은 안드로이드 콘솔에서 비슷한 에러를 볼 수 있다.

이 문제를 해결하기 위해서는 단순하게 debug.keystore 파일을 제거하기만 하면 된다. AVD 들을 위한 기본 저장소 위치는 OS X 와 Linux 에서는 ~/.android/ 이고, Windows XP 에서는 C:\Documents and Settings\<user>\.android\ 이고, Windows Vista 와 Windows 7 에서는 C:\Users\<user>\.android\ 이다.

다음에 빌드를 하면, 빌드 툴들은 새로운 키스토어와 디버그 키를 생성할 것이다.

당신의 개발 머신이 non-Gregorian locale 을 사용하고 있다면, 빌드 툴들은 아마도 이미 만료된 디버그 인증서를 생성할지도 모른다. 그래서 당신은 응용프로그램을 컴파일하려고 시도할 때마다 에러를 만나게 될 것이다. 이를 우회하기 위한 정보는 문제 해결 토픽인 I can't compile my app because the build tools generated an expired debug certificate 를 참조하라.

Signing in Release Mode( 릴리스 모드에서 서명하기 )

당신의 응용프로그램을 다른 사용자에게 릴리스하기 위한 준비가 되었다면, 당신은 반드시 다음과 같은 일을 수행해야만 한다 :

1. 적절한 개인 키 획득하라.
2. 응용프로그램을 릴리스 모드로 컴파일하라.
3. 당신의 개인 키를 사용해 응용프로그램에 서명하라.
4. 최종 APK 패키지를 정렬하라.

만약 ADT 플러그인을 사용해 Eclipse 에서 개발중이라면, 컴파일, 서명, 정렬 프로시저를 수행하기 위해서 Export Wizard 를 사용할 수 있다. Export Wizard 는 심지어 당신이 새로운 키스토어와 개인 키를 그 과정에서 생성할 수 있도록 허용한다. 그래서 당신이 Eclipse 를 사용한다면, Compile and sign with Eclipse ADT 는 건너 뛰어도 된다.

1. Obtain a suitable private key( 적절한 개인 키 획득하기 )

응용프로그램에 서명을 하기 위한 준비에서, 당신은 먼저 서명할 적절한 개인키를 가지고 있다는 것을 확신해야만 한다. 적절한 개인 키는 다음과 같은 것이다 :

• Is in your procession.
• 응용프로그램과 동일시되기 위한 개인, 회사, 조직을 표현한다.
• 응용프로그램이나 응용프로그램 모음^suite의 기대 수명을 초과하는 유효 기한을 가진다. 25 년 이상의 유효 기한을 추천한다.
  만약 당신이 응용프로그램을 Google Play 에서 배포할 계획이라면, 2033 년 10 월 22 일 이후에 끝나는 유효기간이 요구된다. 당신은 유효 기한이 그 날짜 이전에 만료되는 키를 가지고 서명된 응용프로그램을 올릴 수 없다.
• 안드로이드 SDK 툴들에 의해 생성된 디버그 키가 아니다.

그 키는 아마 자체 서명될 것이다. 만약 당신이 적절한 키를 가지고 있지 않다면, 반드시 Keytool 을 사용해서 생성해야만 한다. Basic Setup 에서 기술된 것처럼, 당신이 가진 Keytool 이 이용 가능한지 확인하라.

자체 서명된 키를 Keytool 을 사용해 생성하기 위해서는, keytool 명령을 사용하는데, 아래에 열거된 옵션들을 넘긴다( 필요하면 다른 것을 넘길 수 있다 ).

경고 : 개인키를 안전하게 보관하라. Keytool 을 실행하기 전에, 당신의 키를 안전하게 보관하는 방법과 그것이 당신과 사용자들에게 매우 중요한 이유에 대한 논의를 위해  Securing Your Private Key 를 반드시 읽어라. 특히, 당신이 키를 생성하고 있을 때, 당신은 키스토어와 키 모두를 위해 강한 비밀번호^{strong password}를 선택해야만 한다.

아래에 개인 키를 생성하는 keytool 명령의 예가 나와 있다 :

위의 예제 명령을 실행하면, keytool 은 키스토어와 키에 대한 비밀번호를 제공하고 키를 위한 구별 가능한 이름 필드들을 제공하기 위해 당신에게 묻는다. 그리고 나서 그것은 my-release-key.keystore 라는 파일로 키스토어를 생성한다. 그 키스토어와 키는 당신이 입력한 비밀번호로 보호된다. 그 키스토어는 단일 키와 10000 일 동안의 유효 기한을 포함한다. 별명은 당신이 나중에 응용프로그램을 서명할 때 이 키스토어를 참조하기 위해서 사용하게 될 이름이다.

Keytool 에 대한 더 많은 정보를 원한다면, http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html 에 있는 문서를 참조하라.

2. Compile the application in release mode( 릴리스 모드에서 응용프로그램 컴파일하기 )

사용자에게 응용프로그램을 릴리스하기 위해서, 당신은 그것을 릴리스 모드로 컴파일해야만 한다. 릴리스 모드에서, 컴파일된 응용프로그램은 기본적으로 서명되지 않으며, 당신은 개인 키를 사용해 그것을 서명할 필요가 있을 것이다.

주의 : 당신은 서명되지 않은 응용프로그램이나 디버그 키로 서명된 응용프로그램을 릴리스할 수 없다.

With Eclipse

서명되지 않은 APK 를 Eclipse 에서 익스포트하기 위해서는, Package Explorer 에서 프로젝트를 오른쪽 클릭하고, Android Tools > Export Unsigned Application Package 를 선택하라. 그리고 나서 서명되지 않은 APK 를 위한 파일 위치를 지정하라. ( 그렇지 않으면, AndroidManifest.xml 파일을 Eclipse 에서 열어서, Manifest 탭을 선택하고, Export an unsigned APK 를 클릭하라. )

당신은 Export Wizard 를 사용해서 컴파일과 서명을 합칠 수 있다. Compiling and signing with Eclipse ADT 를 참조하라.

With Ant

당신이 Ant 를 사용하고 있다면, ant 명령을 release 옵션과 함께 사용해 릴리스 모드를 활성화할 수 있다. 예를 들어, 만약 당신이 build.xml 을 포함하고 있는 디렉토리에서 Ant 를 실행하고 있다면, 그 명령은 다음과 같을 것이다 :

기본적으로, 빌드 스크립트는 응용프로그램 APK 를 서명하지 않은 채로 컴파일한다. 프로젝트의 bin/ 에서의 출력 파일은 <your_project_name>-unsigned.apk 일 것이다. 응용프로그램 APK 는 여전히 서명되지 않았기 때문에, 당신은 반드시 수동적으로 개인 키를 사용해 서명하고 zipalign 을 사용해 정렬해야만 한다.

그런데 당신이 키스토어와 키 별명의 이름에 대한 경로를 프로젝트의 ant.properties 파일에다가 제공해 놓았다면, Ant 빌드 스크립트는 서명과 정렬을 수행할 수 있다. 이 정보를 제공하면, 빌드 스크립트는 ant release 를 수행할 때 당신의 키스토어와 별명 비밀번호를 입력받는 창을 띄운다. 그것은 패키지에 서명을 하고 그것을 정렬할 것이다. bin/ 의 최종 출력 파일은 <your_project_name>-release.apk 가 될 것이다. 이 단계들이 자동화되면, 당신은 3 과 5 의 수동 프로시저를 건너 뛸 수 있다. ant.properties 파일에 키스토어와 별명을 지정하는 방법에 대해서 배우고 싶다면, Building and Running Apps on the Command Line 을 참조하라.

3. Sign your application with your private key( 개인 키로 응용프로그램 서명하기 )

서명될 준비가 된 응용프로그램 패키지를 가지고 있을 때, 당신은 Jarsigner 툴을 사용해서 그것에 서명할 수 있다. Basic Setup 에서 설명했듯이, 당신의 머신에서 이용 가능한 Jarsigner 를 가지고 있는지 확인하라. 또한 개인키를 포함하는 키스토어가 이용 가능한지 확인하라.

응용프로그램에 서명하기 위해서, 당신은 Jarsigner 를 실행하는데, 응용프로그램의 APK 와 APK 를 서명하기 위한 개인 키를 포함하는 키스토어를 모두 참조하게 된다. 아래 표는 당신이 사용할 수 있는 옵션을 보여 준다.

아래에 위의 예제에서 생성된 키스토어를 사용해 my_application.apk 라는 응용프로그램 패키지를 서명하기 위해 Jarsigner 를 사용하는 방법이 있다.

위의 예제를 실행하면, Jarsigner 는 키스토어와 키에 대한 비밀번호를 제공하기 위해 당신에게 묻는다. 그리고 나서 현재의 APK 를 수정하며, 그것은 APK 가 이제 서명되었음을 의미한다. 다른 키를 사용해 여러 번 APK 에 서명할 수 있다는 것에 주목하라.

주의 : JDK 7 부터, 기본 서명 알고리즘이 변경되었는데, APK 에 서명을 할 때 당신이 서명 알고리즘과 다이제스트 알고리즘을( -sigalg 와 -digestalg ) 지정하도록 요구하고 있다.

서명된 APK 를 검증하기 위해서, 당신은 다음과 같은 명령을 사용할 수 있다 :

만약 APK 가 적절하게 서명되었다면, Jarsigner 는 "jar verified" 를 출력한다. 만약 좀 더 세부적인 것을 우너한다면, 다음 명령들을 시도해 볼 수 있다 :

혹은

위에서 -certs 옵션을 가진 명령은 누가 키를 생성했는지를 기술하는 "CN=" 라인을 보여 줄 것이다.

주의 : 만약 당신이 "CN=Android Debug" 라는 것을 보게 된다면, 이것은 APK 가 안드로이드 SDK 에 의해 생성된 디버그 키로 서명되었음을 의미한다. 만약 응용프로그램을 릴리스하려는 의도라면, 당신은 반드시 디버그 키 대신에 개인 키를 사용해서 서명해야만 한다.

Jarsigner 에 대한 더 많은 정보를 원한다면, http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html 의 문서를 참조하라.

4. Align the final APK package( 최종 APK 패키지 정렬하기 )

개인키로 서명된 APK 를 확보했으면, zipalign 을 파일에 대해 실행하라. 이 툴은 모든 비압축 데이터가 파일의 시작부분에 대해 상대적인 특별한 바이트에 정렬되는 것을 보장한다. 4 바이트 경계에서 정렬을 보장하는 것은 디바이스 상에서 설치될 때 성능 최적화를 제공한다. 정렬되어 있다면, 심지어 그것들이 정렬 제약을 가진 이진 데이터를 포함하더라도, 안드로이드 시스템은 모든 데이터를 패키지로부터 복사하는 대신에 파일을 mmap() 을 사용해서 읽어들일 수 있다. 이것의 효과는 응용프로그램을 실행함으로써 소비되는 RAM 의 양을 줄이는 것이다.

zipalign 툴은 안드로이드 SDK 와 함께 제공되며, tools/ 디렉토리 내부에 있다. 서명된 APK 를 정렬하려면, 다음을 실행하라 :

-v 플래그는 ( 선택적인 ) verbose 출력을 켠다. 4 는 바이트 정렬( 4 아닌 다른 값을 사용하지 말라 )이다. 첫 번째 인자는 당신의 서명된 .apk 파일( 입력 )이며, 두 번째 파일은 대상 .apk 파일( 출력 )이다. 만약 당신이 현존하는 APK 를 override 했다면, -f 플래그를 추가하라.

주의 : 당신의 입력 APK 는 zipalign 을 사용해 패키지를 최적화하기 전에 반드시 개인 키로 서명되어 있어야만 한다. 만약 zipalign 을 사용한 후에 서명을 하면, 그것은 정렬을 취소할 것이다.

더 많은 정보를 원한다면, zipalign 툴에 대해 읽어 보라.

Compile and sign with Eclipse ADT( Eclipse ADT 를 사용해 컴파일하고 서명하기 )

만약 Eclipse 를 ADT 플러그인과 함께 사용하고 있다면, Export Wizard 를 사용해서 서명된 APK 를 익스포트할 수 있다( 그리고 필요하면 키스토어도 새로 생성할 수 있다 ). Export Wizard 는 Keytool 과 Jarsigner 와의 모든 상호작용을 당신을 위해 해 준다. 이는 위에서 언급했던 컴파일, 서명, 정렬 등을 위한 수동 프로시저들을 수행하는 대신에 GUI 를 사용해 패키지에 서명할 수 있도록 해 준다. 일단 마법사가 당신의 패키지를 컴파일하고 서명하면, 그것은 zipalign 을 사용해 패키지 정렬도 수행한다. Export Wizard 는 Keytool 과 Jarsigner 를 모두 사용하기 때문에, 당신은 당신의 컴퓨터에서 그것에 접근할 수 있다는 것만 보장하면 된다; Basic Setup for Signing 에서 언급했듯이...

Eclipse 에서 서명된 APK 를 생성하기 위해서는 :

1. Package Explorer 에서 프로젝트를 선택하고 File > Export 를 선택한다.
2. Android 폴더를 열고, Export Android Application 을 선택하고, Next 를 클릭한다.
   Export Android Application 마법사가 시작되는데, 그것은 응용프로그램을 서명하는 절차로 안내해 줄 것이고, APK 를 서명하기 위한 개인 키를 선택하기 위한 단계도 포함할 것이다( 혹은 새로운 키스토어와 개인키를 생성할 수도 있다 ).
3. Export Wizard 를 완료하면, 당신의 응용프로그램이 컴파일되고, 서명되고, 배포 준비가 될 것이다.

Securing Your Private Key( 개인키 보호하기 )

개인 키의 보안을 유지하는 것은 당신이나 사용자에게 있어서 매우 중요하다. 만약 누군가가 당신의 키를 사용하도록 허용하거나, 당신이 키스토어와 비밀번호를 서드 파티가 찾고 이용할 수 있는 보호되지 않은 위치에다가 남겨 두게 되면, 당신의 저작관과 사용자에 대한 신뢰가 위태롭게 된다.

서드 파티가 당신의 인지나 승인없이 당신의 키를 취할 수 있다면, 그 사람은 당신의 원본 응용프로그램들을 악의적으로 대체하고 그것들을 변질시키는 응용프로그램들을 서명하거나 배포할 수 있다. 또한 그러한 사람은 당신의 신분을 이용해 다른 응용프로그램이나 시스템 자체를 공격하거나 사용자의 데이터를 변질시키거나 훔치는 응용프로그램들을 서명하거나 배포할 수도 있다.

당신의 개발자로서의 평판은 그 키가 만료될 때까지 항상 적절하게 개인 키를 보호하느냐에 달려 있다. 여기 키 보안을 지키기 위한 몇 가지 팁들이 있다 :

• 키스토어와 키에 대해서 강한 비밀번호를 선택하라.
• Keytool 을 사용해 키를 생성할 때, -storepass 와 -keypass 옵션을 커맨드라인에서 제공하지 말라. 만약 그렇게 한다면, 당신의 비밀번호들이 쉘 히스토리에서 이용 가능하며, 그것은 당신의 컴퓨터에 로그인한 사용자라면 모두 접근할 수 있다.
• 비슷하게, 응용프로그램에 Jarsigner 를 사용해서 서명할 때, -storepass 와 -keypass 옵션을 커맨드라인에서 제공하지 말라.
• 누구에게도 개인 키를 주거나 빌려 주지 말라. 그리고 권한을 가지지 않은 사람들이 당신의 키스토어와 키의 비밀번호를 알 수 있도록 하지 말라.

일반적으로, 당신이 키를 생성하고 사용하고 저장할 때, 일반적인 예방책을 따른다면, 그것은 보호된 상태로 남아 있을 수 있을 것이다.

책의 71 페이지에서는 다음과 같은 명령어를 사용해서 APK 를 만들라고 하고 있다.

현재 1.8.4 버전의 ant 를 설치했는데, 이것은 구체적으로 빌드 타겟을 지정할 것을 요구한다.

그러므로 위에서 설명하고 있는 것처럼 아래와 같은 형식으로 호출해야 한다.

책의 70 페이지에서는 다음과 같이 project 를 설정하라고 이야기하고 있다.

필자는 윈도우 환경이기 때문에 cygwin 에서 다음과 같이 실행했다.

error 를 보면 알 수 있듯이 "-p" 옵션은 프로젝트가 있는 디렉토리의 경로를 지정할 것을 요구한다.

그러므로 현재 경로인 "./" 을 넣어서 해결했다.

책의 35 페이지에서는 ".bash_profile" 이라는 파일에 다음과 같은 식으로 스크립트를 추가할 것을 요구하고 있다.

환경변수를 가지고 올 때 MS_DOS 형식으로 인식하는 것을 막기 위함이라고 하는데, 저자가 설치한 것이 어떤 버전인지는 모르겠지만, 현재 설치한 버전(  1.7.17-1 )에서는 그런 문제가 자동으로 해결되어 있는 것 같다.

실제로 저런 스크립트를 추가하게 되면 오히려 제대로 동작하지 않는다.