Android 패키지 키트(APK)는 Google Android 운영 체제에 애플리케이션 소프트웨어와 미들웨어를 배포하고 설치하는 데 사용되 는 표준 패키지 파일 형식입니다. APK 파일은 애플리케이션의 바이트코드, 리소스, 자산, 인증서, 매니페스트 파일을 포함하는 ZIP 형식의 아카이브입니다.
APK 파일에는 다음과 같은 핵심 구성 요소가 포함되어 있습니다. - AndroidManifest.xml: Android 빌드 도구, OS, Google Play에 앱에 대한 필수 정보를 설명하는 XML 형식의 매니페스트 파일입니다. 여기에는 앱의 패키지 이름, 버전, 액세스 권한, 참조된 라이브러리 파일 등이 포함됩니다. - Classes.dex: Android 런타임에서 이해할 수 있는 DEX 파일 형식으로 컴파일된 클래스입니다. 여기에는 애플리케이션의 컴파일된 Java 바이트코드가 포함되어 있습니다. - 리소스: 이미지, 문자열 테이블, XML의 사용자 인터페이스 레이아웃 등 resources.arsc에 컴파일되지 않은 리소스입니다. - Resources.arsc: 값, 드로어블, 레이아웃 및 기타 요소에 대한 XML 파일과 같은 사전 컴파일된 리소스를 포함하는 파일입니다. - 자산: AssetManager에서 검색할 수 있는 애플리케이션 자산을 포함하는 디렉토리입니다. - META-INF 디렉토리: 이 폴더에는 다음이 포함되어 있습니다. - MANIFEST.MF: 매니페스트 파일 - CERT.RSA: 애플리케이션의 인증서 - CERT.SF: MANIFEST.MF 파일의 해당 줄에 대한 리소스 및 SHA-1 다이제스트 목록
일반적인 APK 파일의 구조는 다음과 같습니다.
/AndroidManifest.xml /classes.dex /resources.arsc /res/ drawable/ layout/ values/ /assets/ /META-INF/ MANIFEST.MF CERT.RSA CERT.SF
앱을 설치하면 기기는 다운로드한 APK 파일에서 classes.dex 파일을 추출하여 실행할 Dalvik 실행 파일(DEX)을 생성합니다. 그런 다음 Android 런타임(ART)은 이 DEX 파일을 사용하여 앱을 실행합니다. DEX 파일의 바이트코드는 Java의 .class 파일의 스택 기반 바이 트코드와 달리 레지스터 기반입니다. DEX 바이트코드는 표준 Java 바이트코드보다 더 컴팩트하고 메모리 효율적이도록 설계되었습니다.
앱 개발 중에 Android 애플리케이션 모듈은 디버깅 및 테스트를 위해 중간 서명되지 않은 APK로 컴파일됩니다. 빌드 프로세스에는 앱 리소스를 압축된 이진 형식으로 변환하고, 코드를 DEX 형식으로 변환하고, 컴파일된 리소스, 코드, Android 매니페스트 파일로 최종 APK를 빌드하는 것이 포함됩니다. 릴리스를 위해서는 APK에 키스토어로 서명해야 하며, 이 키스토어는 앱의 저자를 설정하고 앱 업데이트를 배포하는 데 사용됩니다.
Google은 Zip 호환 아카이브(zip, jar, apk)를 보거나, 생성하고, 업데이트하는 Android 자산 패키징 도구(aapt)를 제공합니다. 또한 리소스를 이진 자산으로 컴파일할 수도 있습니다. 개발자는 'aapt dump' 명령을 사용하여 파일을 추출하지 않고도 APK의 내용에 대한 정보를 얻을 수 있습니다. 'aapt dump badging'은 애플리케이션 패키지 이름, 버전, 포함된 활동을 출력하는 반면, 'aapt dump permissions'는 선언된 권한을 표시합니다.
APK 형식을 이해하는 것은 Android 개발자가 배포를 위해 앱을 적절하게 패키징하는 데 중요합니다. 또한 기존 앱의 내용과 동작을 검사하는 데도 유용합니다. 보안 연구원은 종종 APK 파일을 분석하여 Android 애플리케이션의 잠재적 보안 취약성이나 개인 정보 문제를 파악합니다.
요약하자면 Android 패키지 키트(APK)는 Android 앱의 표준 패키지 형식으로, 컴파일된 바이트코드, 리소스, 자산, 메타데이터를 특정 구조의 ZIP 기반 아카이브에 포함합니다. APK 형식과 도구에 익숙해지는 것은 Android 개발에 필수적이며, 개발자가 Google Play와 같은 앱 마켓플레이스를 통해 배포하기 위해 애플리케이션을 빌드, 테스트, 게시할 수 있도록 합니다.
파일 압축은 동일한 정보가 더 적은 비트를 차지하도록 중복성을 줄입니다. 얼마나 멀리 갈 수 있는지에 대한 상한선은 정보 이론에 의해 결정됩니다. 무손실 압축의 경우, 한계는 소스의 엔트로피입니다(섀넌의 소스 코딩 정리 와 그의 1948년 원본 논문 “통신의 수학적 이론”참조). 손실 압축의 경우, 속도와 품질 간의 절충은 속도-왜곡 이론에 의해 포착됩니다.
대부분의 압축기에는 두 단계가 있습니다. 첫째, 모델이 데이터의 구조를 예측하거나 노출합니다. 둘째, 코더가 이러한 예측을 거의 최적의 비트 패턴으로 변환합니다. 고전적인 모델링 계열은 렘펠-지브입니다. LZ77 (1977) 과 LZ78 (1978)은 반복되는 하위 문자열을 감지하고 원시 바이트 대신 참조를 내보냅니다. 코딩 측면에서는 허프만 코딩 (원본 논문 1952참조)이 더 가능성 있는 기호에 더 짧은 코드를 할당합니다. 산술 코딩 과 범위 코딩 은 엔트로피 한계에 더 가깝게 압축하는 더 세분화된 대안이며, 현대적인 비대칭 숫자 체계(ANS) 는 빠른 테이블 기반 구현으로 유사한 압축을 달성합니다.
DEFLATE(gzip, zlib, ZIP에서 사용)는 LZ77과 허프만 코딩을 결합합니다. 사양은 공개되어 있습니다. DEFLATE RFC 1951, zlib 래퍼 RFC 1950, gzip 파일 형식 RFC 1952. Gzip은 스트리밍을 위해 구성되었으며 명시적으로 임의 접근을 시도하지 않습니다. PNG 이미지는 PNG 사양에 따라 DEFLATE를 유일한 압축 방법으로 표준화합니다(최대 32KiB 창). “압축 방법 0… deflate/inflate… 최대 32768바이트” 및 W3C/ISO PNG 제2판.
Zstandard (zstd): 매우 빠른 압축 해제와 높은 비율을 위해 설계된 최신 범용 압축기입니다. 형식은 RFC 8878 (또한 HTML 미러) 및 참조 사양 GitHub에 문서화되어 있습니다. gzip과 마찬가지로 기본 프레임은 임의 접근을 목표로 하지 않습니다. zstd의 초능력 중 하나는 사전입니다. 코퍼스에서 가져온 작은 샘플로, 작거나 유사한 많은 파일에서 압축을 극적으로 향상시킵니다( python-zstandard 사전 문서 및 Nigel Tao의 작업 예제참조). 구현은 “비정형” 및 “정형” 사전을 모두 허용합니다 (토론).
Brotli: 웹 콘텐츠(예: WOFF2 글꼴, HTTP)에 최적화되어 있습니다. 정적 사전과 DEFLATE와 유사한 LZ+엔트로피 코어를 혼합합니다. 사양은 RFC 7932이며, WBITS가 [10, 24]인 2WBITS−16의 슬라이딩 윈도우(1KiB−16B ~ 16MiB−16B)와 임의 접근을 시도하지 않음