어떤 설정을 어떤 형식으로 만들었는가
Android build variant는 build type과 product flavor 등의 조합입니다. 기본 debug는 디버깅 가능 설정과 디버그 키를 사용합니다. release라는 이름만으로 배포 서명이나 특정 최적화가 자동 적용됐다고 판단하지 말고 프로젝트 구성을 확인합니다.
APK는 기기에 설치할 패키지이고 AAB는 APK 생성을 위한 게시 형식입니다. 같은 빌드 설정에서도 APK 또는 bundle을 생성할 수 있습니다. Google Play 신규 앱은 AAB 게시를 요구하지만, AAB 자체가 설치되는 것은 아닙니다.
업로드 인증과 설치 APK 서명은 역할이 다릅니다
Play App Signing에서는 개발자가 업로드 키로 AAB를 서명하고, Play가 앱 서명 키로 배포 APK를 서명합니다. 두 역할을 구분해야 합니다. 별도 업로드 키를 만들지 않아 같은 키를 사용하는 구성도 있으므로 두 키가 항상 같거나 항상 다르다고 단정하지 않습니다.
외부 배포 전에는 실제 설치용 APK의 인증서와 debuggable 설정을 확인합니다. 파일 이름이 release이거나 서명됐다고 해서 제품의 보안성이 검증된 것은 아닙니다. 비밀키·keystore 비밀번호를 공개 기록이나 로그에 남기지 않습니다. 이 글은 키를 생성·교체하거나 앱을 업로드한 작업 기록이 아닙니다.
릴리스가 항상 작고 빠르다는 보장은 없습니다
R8 설정은 Android Gradle Plugin 버전에 맞춰 코드·리소스 최적화와 keep 규칙을 확인해야 합니다. 빌드 유형의 이름으로 모든 로그와 심볼이 없어졌다고 가정하지 않습니다. 반사 호출이나 직렬화 등의 사용도 실제 릴리스 산출물로 시험해야 합니다.
Native debug symbols는 설치 라이브러리의 심볼 제거와 충돌 분석용 심볼 보관을 구분합니다. Play에는 별도 심볼 파일을 올리거나 AAB에 심볼을 넣어 제공할 수 있습니다. 충돌 분석에 필요한 파일을 release라는 이유만으로 없애서는 안 됩니다.
크기는 동일 기능과 같은 대상 기기의 다운로드·설치 구성을 비교합니다. 범용 APK 파일과 특정 기기용 분할 다운로드를 조건 없이 비교하거나 모든 앱에 고정된 절감률을 적용하지 않습니다.
AAB가 아니라 생성된 APK 세트를 시험합니다
bundletool은 AAB에서 APK 세트를 만들고, 연결된 기기에 맞는 조합을 설치할 수 있습니다. 대상 구성에 따라 base·configuration·feature APK가 선택됩니다. bundle 파일의 크기만 보고 사용자가 받은 파일이나 실행 성능을 확정하지 않습니다.
- 선택한 variant와 AGP 버전을 기록합니다.
- 산출물이 APK인지 AAB인지, 어떤 서명·debuggable·최적화 설정이 적용됐는지 확인합니다.
- 기기 ABI·화면 밀도·언어·모듈 조건에 맞는 실제 설치 APK 세트를 확인합니다.
- 그 산출물의 동작과 크기, native crash 분석에 필요한 심볼의 대응을 검사합니다.
보존된 Bajrang Solge 재공유 카드 #547의 비교 그림을 계기로 작성했지만, 특정 원글 permalink와 고해상도 두 번째 그림은 확인하지 못했습니다. 그림·수치·작은 글씨는 기술 근거로 옮기지 않았으며 위 공식 문서를 기준으로 독자 서술했습니다. 실제 앱 빌드·설치·Play 게시·성능 측정은 하지 않았습니다. 충돌 분석의 다음 단계는 LLDB와 tombstone에서 이어집니다.
English summary. Build variants and package formats are separate axes. An AAB produces installable APKs, while upload and app-signing keys serve different roles. Verify the actual installed artifacts, optimization settings and matching symbols instead of inferring behavior from a release label.