릴리스용 애플리케이션 준비

애플리케이션을 코딩하고 테스트한 후에 배포할 패키지를 준비해야 합니다. 이 패키지를 준비하는 첫 번째 작업은 릴리스할 애플리케이션을 빌드하는 것입니다. 여기에는 주로 일부 애플리케이션 특성을 설정하는 작업이 포함됩니다.

다음 단계를 통해 릴리스용 앱을 빌드합니다.

• 애플리케이션 아이콘 지정 – 각 Xamarin.Android 애플리케이션에 애플리케이션 아이콘이 지정되어 있어야 합니다. 기술적으로 필요하지는 않지만 Google Play와 같은 일부 마켓에서 필요합니다.

• 애플리케이션 버전 - 이 단계에서는 버전 관리 정보를 초기화하거나 업데이트합니다. 이것은 향후 애플리케이션 업데이트와, 사용자가 설치한 애플리케이션 버전을 인지하도록 하기 위해 중요합니다.

• APK 축소 – 관리 코드의 Xamarin.Android 링커와 Java 바이트 코드의 ProGuard를 사용하여 최종 APK의 크기를 크게 줄일 수 있습니다.

• 애플리케이션 보호 – 사용자 또는 공격자가 디버깅을 사용하지 않도록 설정하거나, 관리 코드를 난독 처리하고, 디버그 방지 및 변조 방지를 추가하고, 네이티브 컴파일을 사용하여 애플리케이션을 디버깅, 변조 또는 리버스 엔지니어링하지 못하도록 방지합니다.

• 패키징 속성 설정 – 패키징 속성은 APK(Android 애플리케이션 패키지) 생성을 제어합니다. 이 단계에서는 APK를 최적화하고 그 자산을 보호하며 필요에 맞게 패키지를 모듈화합니다. 또한 디바이스에 최적화된 Android 앱 번들을 사용자에게 제공할 수 있습니다.

• 컴파일 – 이 단계에서는 코드와 자산을 컴파일하여 릴리스 모드에서 빌드되는지 확인합니다.

• 게시 용 보관 – 이 단계에서는 앱을 빌드하고 서명 및 게시를 위해 보관에 배치합니다.

이러한 각 단계는 아래에서 자세히 설명합니다.

애플리케이션 아이콘 지정

각각의 Xamarin.Android 애플리케이션마다 애플리케이션 아이콘을 지정하는 것이 좋습니다. 일부 애플리케이션 마켓플레이스에서는 아이콘 없이 Android 애플리케이션을 게시하지 못합니다. Application 특성의 Icon 속성은 Xamarin.Android 프로젝트의 애플리케이션 아이콘을 지정하는 데 사용됩니다.

이러한 예제에서 @drawable/icon은 Resources/drawable/icon.png(.png 확장명이 리소스 이름에 포함되지 않음)에 있는 아이콘 파일을 참조합니다. 이 특성은 이 샘플 코드 조각에서처럼 Properties\AssemblyInfo.cs 파일에서 선언할 수도 있습니다.

[assembly: Application(Icon = "@drawable/icon")]

일반적으로 using Android.App은 AssemblyInfo.cs(Application 특성의 네임스페이스는 Android.App임)의 맨 위에 선언되지만, 아직 없는 경우 이 using 문을 추가해야 합니다.

애플리케이션 버전 지정

버전 작업은 Android 애플리케이션 유지 관리와 배포를 위해 중요합니다. 일종의 버전 작업이 없으면 애플리케이션이 업데이트되어야 하는지 여부를 판단하기가 어렵습니다. 버전 작업을 지원하기 위해 Android는 두 가지 유형의 정보를 인식합니다.

• 버전 번호 – 애플리케이션의 버전을 나타내는 정수 값(Android 및 애플리케이션에서 내부적으로 사용)입니다. 대부분의 애플리케이션은 이 값을 1로 설정한 다음 빌드마다 커집니다. 이 값은 버전 이름 특성과의 관련이나 선호 관계가 없습니다(아래 참조). 애플리케이션 및 게시 서비스는 이 값을 사용자에게 표시해서는 안 됩니다. 이 값은 AndroidManifest.xml 파일에 android:versionCode으로 저장됩니다.

• 버전 이름 – 특정 디바이스에 설치된 애플리케이션 버전에 대한 정보를 사용자에게 전달하는 데만 사용되는 문자열입니다. 버전 이름은 사용자 또는 Google Play에 표시하기 위한 것입니다. 이 문자열은 Android에서 내부적으로 사용되지 않습니다. 버전 이름은 디바이스에 설치된 빌드를 사용자가 식별하는 데 도움이 되는 모든 문자열이 될 수 있습니다. 이 값은 AndroidManifest.xml 파일에 android:versionName으로 저장됩니다.

APK 축소

불필요한 관리 코드를 제거하는 Xamarin.Android 링커와, 사용하지 않는 Java 바이트코드를 제거하는 Android SDK ProGuard 도구 조합을 통해 Xamarin.Android APK를 더 작게 만들 수 있습니다. 빌드 프로세스에서는 먼저 Xamarin.Android 링커를 사용하여 관리 코드(C#) 수준에서 앱을 최적화한 다음 ProGuard(사용하도록 설정된 경우)를 사용하여 Java 바이트코드 수준에서 APK를 최적화합니다.

링커 구성

릴리스 모드는 공유 런타임을 해제하고 연결을 실행하여 애플리케이션이 런타임 시 필요한 Xamarin.Android 부분만 탑재할 수 있게 합니다. Xamarin.Android의 링커는 정적 분석을 사용하여 Xamarin.Android 애플리케이션에서 사용하거나 참조하는 어셈블리, 형식 및 형식 번호를 결정합니다. 그런 다음 링커는 사용되지 않는(또는 참조되지 않는) 모든 어셈블리, 형식 및 멤버를 버립니다. 이렇게 해서 패키지 크기를 상당히 줄일 수 있습니다. 예를 들어 HelloWorld 샘플에서는 최종 APK 크기가 83% 줄었습니다.

• 구성: 없음 – Xamarin.Android 4.2.5 크기 = 17.4MB.

• 구성: SDK 어셈블리만 – Xamarin.Android 4.2.5 크기 = 3.0MB.

연결에는 의도치 않은 부작용이 있을 수 있으므로 물리적 디바이스의 릴리스 모드에서 애플리케이션을 다시 테스트하는 것이 중요합니다.

ProGuard

ProGuard는 Java 코드를 연결하고 난독 처리하는 Android SDK 도구입니다. ProGuard는 일반적으로 APK에 포함된 대형 라이브러리(예: Google Play Services)의 공간을 축소하여 애플리케이션을 더 작게 만드는 데 사용됩니다. ProGuard는 사용되지 않는 Java 바이트 코드를 제거하기 때문에 앱이 더 작아집니다. 예를 들어 작은 Xamarin.Android 앱에서 ProGuard를 사용하면 일반적으로 크기가 약 24% 감소합니다. 여러 라이브러리 종속성이 있는 더 큰 앱에서 ProGuard를 사용하면 일반적으로 크기가 훨씬 더 크게 감소합니다.

ProGuard는 Xamarin.Android 링커를 대체하지 않습니다. Xamarin.Android 링커는 관리 코드를 연결하고 ProGuard는 Java 바이트 코드를 연결합니다. 빌드 프로세스에서는 먼저 Xamarin.Android 링커를 사용하여 관리 코드(C#) 수준에서 앱을 최적화한 다음 ProGuard(사용하도록 설정된 경우)를 사용하여 Java 바이트 코드 수준에서 APK를 최적화합니다.

ProGuard 사용을 선택하면 Xamarin.Android이 나타나는 APK에서 ProGuard 도구를 실행합니다. ProGuard 구성 파일이 생성되며 빌드 시점에 ProGuard에서 사용됩니다. Xamarin.Android는 사용자 지정ProguardConfiguration 빌드 작업도 지원합니다. 사용자 지정 ProGuard 구성 파일을 프로젝트에 추가하고 아래 예제에서처럼 마우스 오른쪽 단추로 클릭하여 빌드 작업으로 선택할 수 있습니다.

ProGuard는 기본적으로 사용하지 않게 설정되어 있습니다. ProGuard 사용 옵션은 프로젝트가 릴리스 모드로 설정된 경우에만 사용할 수 있습니다. ProGuard 사용을 선택하지 않았다면 모든 ProGuard 빌드 작업이 무시됩니다. Xamarin.Android ProGuard 구성은 APK를 난독 처리하지 않으며 사용자 지정 구성 파일을 통해서도 난독 처리를 사용할 수 없습니다. 난독 처리를 사용려면 Dotfuscator를 통한 애플리케이션 보호를 참조하세요.

ProGuard 도구 사용에 대한 자세한 정보는 ProGuard를 참조하세요.

애플리케이션 보호

디버깅 사용 안 함

Android 애플리케이션 개발 중에는 JDWP(Java Debug Wire Protocol)를 사용하여 디버그를 수행합니다. 이것은 adb 같은 도구가 디버그를 위해 JVM과 통신할 수 있게 하는 기술입니다. JDWP는 Xamarin.Android 애플리케이션의 디버그 빌드에 대해 기본적으로 켜져 있습니다. JDWP는 개발 중에 중요하지만 릴리스된 애플리케이션에는 보안 문제를 야기할 수 있습니다.

Android 매니페스트에는 애플리케이션의 디버그 가능 여부를 제어하는 android:debuggable 특성이 포함됩니다. android:debuggable 특성은 false로 설정하는 것이 좋습니다. 이것은 조건부 컴파일 문을 AssemblyInfo.cs에 추가하면 간단하게 설정할 수 있습니다.

#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif

더비그 빌드에서는 디버그 편의를 위해 자동으로 일부 권한을 설정합니다(예: 인터넷 및 ReadExternalStorage). 하지만 릴리스 빌드는 명시적으로 구성된 권한만 사용합니다. 릴리스 빌드로 전환하면 앱이 디버그 빌드에서 사용 가능했던 권한을 잃게 되는 경우 권한에서 설명한 것처럼 필수 권한에서 이 권한을 명시적으로 사용하도록 설정했는지 확인합니다.

Dotfuscator를 통한 애플리케이션 보호

어셈블리를 네이티브 코드에 번들

이 옵션을 사용할 경우 어셈블리가 네이티브 공유 라이브러리에 번들로 포함됩니다. 이렇게 하면 어셈블리를 압축하여 더 작은 .apk 파일을 사용할 수 있습니다. 또한 어셈블리 압축은 최소한의 난독 처리 형식을 제공합니다. 이러한 난독 처리를 사용하지 않아야 합니다.

이 옵션을 사용하려면 엔터프라이즈 라이선스가 필요하며 빠른 배포 사용을 사용하지 않도록 설정한 경우에만 사용할 수 있습니다. 어셈블리를 네이티브 코드에 번들은 기본적으로 사용하지 않게 설정되어 있습니다.

네이티브 코드에 번들 옵션은 어셈블리가 네이티브 코드로 컴파일 되는 것이 아닙니다. AOT 컴파일을 사용하여 어셈블리를 네이티브 코드로 컴파일할 수 없습니다.

AOT 컴파일

AOT 컴파일 옵션(패키지 속성 페이지)을 사용하면 어셈블리의 AOT(Ahead-of-Time) 컴파일이 가능합니다. 이 옵션을 사용하면 런타임 이전에 어셈블리를 미리 컴파일하여 JIT(Just In Time) 시작 과부하가 최소화됩니다. 나타나는 네이티브 코드는 컴파일되지 않은 어셈블리와 함께 APK에 포함됩니다. 이로 인해 애플리케이션 시작 시간이 짧아지며 APK 크기는 약간 커집니다.

AOT 컴파일 옵션에는 엔터프라이즈 이상의 라이선스가 필요합니다. AOT 컴파일은 프로젝트가 릴리스 모드로 구성된 경우에만 사용할 수 있고 기본적으로 사용하지 않게 설정되어 있습니다. AOT에 대한 자세한 내용은 AOT를 참조하세요.

LLVM 최적화 컴파일러

LLVM 최적화 컴파일러는 더 작고 빠른 컴파일 코드를 만들며 AOT 컴파일 어셈블리를 네이티브 코드로 변환하지만 빌드 시간이 느려집니다. LLVM 컴파일러는 기본적으로 사용하지 않게 설정되어 있습니다. LLVM 컴파일러를 사용하려면 먼저 AOT 컴파일 옵션을 사용하도록 설정해야 합니다(패키지 속성 페이지).

패키지 속성 설정

공유 런타임 사용, 빠른 배포 사용 등과 같이 이러한 여러 속성은 디버그 모드용입니다. 그러나 애플리케이션이 릴리스 모드용으로 구성되었을 때 앱이 크기 및 실행 속도를 위해 최적화되고, 변조를 방지하며, 다양한 아키텍처 및 크기 제한을 지원하도록 패키징할 수 있는 방법을 결정하는 다른 설정이 있습니다.

지원되는 아키텍처 지정

Xamarin.Android 앱의 릴리스를 준비할 때는 지원되는 CPU 아키텍처를 지정해야 합니다. 단일 APK가 여러 서로 다른 아키텍처를 지원하는 머신 코드를 포함할 수 잇습니다. 여러 CPU 아키텍처 지원에 대한 세부 정보는 CPU 아키텍처를 참조하세요.

선택한 ABI마다 한 패키지(.APK) 생성

이 옵션을 사용하는 경우 모든 지원되는 ABI에 대해 대형 단일 APK를 만드는 것이 아니라, 지원되는 ABI 각각에 대해 하나의 APK가 만들어집니다(CPU 아키텍처에서 설명한 것처럼 고급 탭). 이 옵션은 프로젝트가 릴리스 모드로 구성되었고 기본적으로 사용하지 않게 설정된 경우에만 사용할 수 있습니다.

Multi-Dex

Multi-Dex 사용 옵션을 사용하도록 선택한 경우 Android SDK 도구를 사용하여 .dex 파일 형식의 65K 메서드 제한을 무시하게 됩니다. 65K 메서드 제한은 앱이 참조하는 Java 메서드 수(앱이 의존하는 라이브러리의 메서드 포함)를 기반으로 하며 소스 코드에 작성된 메서드 수를 기반으로 하지 않습니다. 애플리케이션이 일부 메서드만 정의하고 여러 메서드(또는 대규모 라이브러리)를 사용하는 경우 65K 제한이 초과될 수 있습니다.

앱이 참조되는 모든 라이브러리의 모든 메서드를 사용하는 것은 아니므로 ProGuard 같은 도구(위 참조)를 사용하면 사용되지 않는 메서드를 코드에서 제거할 수 있습니다. Multi-Dex 사용은 절대적으로 필요한 경우에만 사용하도록 설정합니다. 즉 ProGuard를 사용한 후에도 앱이 65K 이상의 Java 메서드를 참조하는 경우입니다.

Multi-Dex에 대한 자세한 내용은 64K가 넘는 메서드의 앱 구성을 참조하세요.

Android 앱 번들

앱 번들은 디바이스에 직접 배포할 수 없으므로 APK와 다릅니다. 대신, 컴파일된 모든 코드와 리소스와 함께 업로드하기 위한 형식입니다. 서명된 앱 번들을 업로드한 후에는 애플리케이션의 APK를 빌드하고 서명하는 데 필요한 모든 것이 Google Play에 제공되며, Google Play는 동적 배달을 사용하여 사용자에게 제공합니다.

Android 앱 번들에 대한 지원을 사용하려면 Android 프로젝트 옵션 내에서 Android 패키지 형식 속성의 bundle 값을 옵트인해야 합니다. 그러기 전에 앱 번들이 릴리스 패키지 전용이므로 프로젝트를 Release 구성으로 변경해야 합니다.

이제 보관 흐름에 따라 앱 번들을 생성할 수 있습니다. 그러면 애플리케이션에 대한 앱 번들이 생성됩니다.

Android 앱 번들에 대한 자세한 내용은 Android 앱 번들을 참조하세요.

Compile

게시를 위해 보관

관련 링크

• 다중 코어 디바이스 및 Xamarin.Android
• CPU 아키텍처
• AOT
• 코드 및 리소스 축소
• 64K가 넘는 메서드의 앱 구성