[Flutter] (Project) MapleApp: 29. 배포 전 준비

이번 칼럼은 배포 전 해야 할 일에 대해서 작성하겠다. 개인적으로 준비한 프로젝트이며, 실질적으로 appbundle을 준비하는 것 이외의 모든 부분이 개발자 밖의 영역이라고 생각되고, 또 그렇게 진행되는 모습을 알아갈 수 있었다. 하지만, 앱 출시를 준비하고 등록하는 모든 과정을 직접 경험해봐야 한다는 생각에 이 글을 준비했다. 물론 모든 내용을 전달해 드릴 순 없지만, 큰 문제 없이 진행되는 모습을 알려드리려 한다. 문단 첫 마디에 사용된 아이콘의 경우 🐇 🥕 🍒 🍇 🍎 🍌 순서이므로, 글의 흐름에 영향을 크게 미치진 않지만 토끼나 당근이 보인다면 새로운 문단이 시작됨을 알아주셨음한다.

 

또한, 이 글은 내 개인적으로 배포 전 해야할 일에 대해 정리하여 지속적으로 확인하기 위한 것이다.

 

🐇 프로젝트 이름 변경

일단 프로젝트의 이름을 변경해야 한다. com.example 패키지를 사용하는 경우, Play Console에서 appbundle을 등록할 때 반려당할 수 있으니 꼭 변경해주자. 변경해야 할 파일의 위치는 다음과 같다.

🥕 lib/pubspec.yaml

🍒 name

🍒 description

 

🥕 android/app/src

🍒 main/kotlin/com/example/의 folder/package name

🍒 main/AndroidManifest.xml

android:label

🍒 build.gradle

android의 namespace

android의 defaultConfig의 applicationId

 

🥕 ios/Runner/info.plist

중간 중간에 기존 project 기본 이름을 변경된 이름으로 수정

 

🥕 README

기존 proejct 기본 이름을 변경된 이름으로 수정

🐇 저작권에 위배되지 않는 아이콘 설정

🥕 android ic_launcher.png 생성

※ reference : https://www.appicon.co/

🐇 지적 재산권 저작권 표시

🥕 데이터

🥕 서체

🥕 아이콘 및 이미지

애플리케이션 내 이미지 명 + 플랫폼 + 저작자에 대한 내용을 기술할 것

🐇 Android App build/release

※ reference : https://docs.flutter.dev/deployment/android

안드로이드 앱을 빌드 하고 출시하기 전 확인해야 할 사항입니다. reference를 참고하여 자신이 숙지할 때 까지 더 자세히 알아보는 것을 추천합니다.

 

🍒 adding launcher icon

Flutter 앱이 생성될 때, 기본 런처 아이콘이 표시됩니다. 애플리케이션을 나타낼 수 있는 런처 아이콘을 먼저 설정해야 합니다. 자동으로 맞춤 설정을 하고 싶으면 flutter_launcher_icons library를 확인하시고, 수동으로 진행하는 경우 다음과 같이 진행할 수 있습니다.

 

🍇 Material Design Icon의 지침 준수하기

※ reference : https://m3.material.io/styles/icons

🍇 {proejctName}/android/app/src/main/res

※ reference : https://www.appicon.co/

경로의 지정된 폴더, mipmap- 에 아이콘 파일을 배치합니다. 각 해상도에 맞는 ic_launcher icon을 만들기 위해선 위 reference를 사용하세요

 

🍒 enabling material component

애플리케이션이 FlatformView를 사용하는 경우, Android 시작하기 가이드에 따라 Material 구성 요소를 활성화 시킬 수 있습니다.

 

🍇 Android Material 종속성 추가

<my-app>/android/app/build.gradle에서 Android Material에 대한 dependency를 추가합니다.

dependencies {
    // ...
    implementation 'com.google.android.material:material:<version>'
    // ...
}

최신 버전을 확인하려면 GoogleMaven을 방문하세요

🍇 테마 적용

밝은 테마 : <my-app>/android/app/src/main/res/values/styles.xml

어두운 테마 : <my-app>/android/app/src/main/res/values-night/styles.xml

 

🍒 signing app

※ reference : https://developer.android.com/studio/publish/app-signing

Google PlayStore에 게시하려면 디지털 인증서로 앱에 서명을 해야 합니다. Android는 "업로드"와 "앱 사인"이라는 두 가지 서명 키를 사용합니다. 개발자는 "업로드"키로 서명된 .aab 파일을 PlayStore에 ..apk로 업로드합니다. 최종 사용자는 "앱 사인”키로 서명된 .apk 파일을 다운로드 합니다. 전체 진행 과정은 다음과 같습니다.

 

🍇 업로드 키 및 키 저장소 생성

업로드 키와 저장소를 생성하는 행위는 AndroidStudio와 PowerShell에서 진행할 수 있습니다.

※ reference : https://developer.android.com/studio/publish/app-signing?hl=ko#generate-key

AndroidStudio는 위 reference를 참고하여 Key를 생성할 수 있습니다.

하지만, 우리는 Flutter를 사용하고 있으므로 AndroidStudio에서 해당 지침을 따라갈 수 없습니다. 그래서 Flutter 공식문서에서 제공하는 수행 방법을 따라가면 됩니다.

🍎 KeyStore 생성

keytool -genkey -v -keystore {path}\\upload-keystore.jks -storetype JKS -keyalg RSA -keysize 2048 -validity 10000 -alias upload

해당 명령문을 입력하면 다음과 같은 진행 절차를 겪을 수 있습니다. {path}의 경우 자신이 저장하고 싶은 곳에 자유롭게 저장해도 된다. 단, keystore파일은 비공개로 유지해야 합니다.

 

🍌 키 저장소 비밀번호 입력/새 비밀번호 다시 입력

🍌 이름과 성 입력

🍌 조직 단위 이름 입력

🍌 조직 이름 입력

조직 단위나 조직 이름이 없는 경우 빈칸으로 제시해도 된다. 추후에 Unknown으로 표기되나, 이후 이 행위로 인해 일어날 파장이 존재한다면 어떻게 진행되는 지는 추가로 작성하겠다.

🍌 구/군/시 이름 입력

🍌 시/도 이름 입력

🍌 두 자리 국가 코드 입력

시/도/구/군/시의 경우 자유롭게 입력하고 두 자리 국가 코드는 대한민국이므로 "82"입력하면 된다.

모두 영어로 작성하였으나, 한글로 작성하면 어떻게 되는지 나중에 알아보겠다. 위 행위를 모두 마치면 다음과 같은 글귀가 나오게 된다.

다음에 대해 유효 기간이 10,000일인 2,048비트 RSA 키 쌍 및 자체 서명된 인증서(SHA256withRSA)를 생성하는 중 : CN=Name, OU=Unknown, O=Unknown, L=Bucheon, ST=Gyeonggi, C=82

🍌 upload에 대한 키 비밀번호 입력

Enter를 누르시면 위에서 입력한 키 저장소 비밀번호/새 비밀번호 항목에 입력한 비밀번호와 동일하게 설정됩니다. 비밀번호의 경우 추후 앱 서명시 필요하기 때문에 잊어버리지 않도록 주의하세요.

 

※ Warning: JKS 키 저장소는 고유 형식을 사용합니다. "keytool -importkeystore -srckeystore E:\keys\upload-keystore.jks -destkeystore E:\keys\upload-keystore.jks -deststoretype pkcs12"를 사용하는 산업 표준 형식인 PKCS12로 이전하는 것이 좋습니다.

 

지정한 경로에 가면 keystore.jks 파일이 생성된 것을 확인할 수 있고, Flutter Project의 android 하위에 key.properties 파일을 생성하고 생성된 keystore 파일을 옮겨 놓으면 됩니다. android project는 기본적으로 local.properties 파일과 ~keystore 파일에 대해 gitignore가 적용되어 있습니다.

 

🍇 업로드 키로 앱에 서명

생성한 {projectName}/android/key.properties에 다음과 같이 속성 값을 삽입합니다.

storePassword=
keyPassword=
keyAlias=upload
storeFile=.\upload-keystore.jks

storePassword와 keyPassword는 keystore를 생성할 때 입력한 키 저장소 비밀번호와 upload에 대한 키 비밀번호를 작성하시면 됩니다.

 

🍎 {proejctName}/android/app/build.gradle

이제 생성한 업로드 키를 사용하도록 Android의 build.gradle에 새로 추가합니다.

🍌 키 저장소 정보 추가

다음으로 key.properties에 대한 정보를 등록해야합니다.

def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
   keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

🍌 buildTypes 추가

build.gradle에 debug 모드로 작성되어 있는 부분입니다. 우리는 signingConfigs를 추가하고, release 모드로 실행할 수 있도록 다음과 같이 변경해야 합니다.

signingConfigs {
   release {
       keyAlias keystoreProperties['keyAlias']
       keyPassword keystoreProperties['keyPassword']
       storeFile keystoreProperties['storeFile'] ? file(keystoreProperties['storeFile']) : null
       storePassword keystoreProperties['storePassword']
   }
}
buildTypes {
   release {
       signingConfig signingConfigs.release
   }
}

다음과 같이 변경하면, 캐시된 빌드로 인해 서명 프로레스에 영향을 미칠 수도 있습니다. 다음 명령문을 통해 flutter proejct를 재구성 하세요

flutter clean
flutter pub get

 

🍒 shrinking code with R8

R8은 Google의 코드 축소기로서 APK/AAB를 build할 때 기본적으로 활성화 됩니다.

🍒 enabling multidex support

※ reference : https://developer.android.com/build/multidex?hl=ko

※ reference : https://docs.flutter.dev/deployment/android#enabling-multidex-support

 

API version 20 이하로 targeting 하는 애플리케이션의 경우, Android의 dex제한인 64k method에 직면할 수 있습니다. 또한, flutter run 축소가 활성화 되지 않은 앱의 디버그 버전을 실행할 때도 이 문제가 발생할 수 있습니다.

Flutter 도구는 MultiDex를 쉽게 활성화 할 수 있도록 지원합니다. 이와 관련된 내용을 진행하시려면 reference를 참고하세요.

 

🍒 reviewing app manifest

{projectName}/android/app/src/main 경로에 있는 AndroidManifest.xml 파일을 검토하세요. 검토할 내용은 다음과 같습니다.

 

🍇 application

앱의 최종 이름을 반영하도록 application 태그의 android:label을 편집하세요

🍇 uses-permission

애플리케이션 코드에 인터넷 엑세스가 필요한 경우 android.permission.INTERNET 권한을 추가해주세요.

표준 탬플릿에는 포함되어 있지 않지만, 개발 중에는 인터넷 엑세스에 허용 가능하도록 되어있습니다. 따라서, 적용하지 않을 시 배포되는 apk에는 인터넷 권한이 적용되지 않을 수 있습니다.

 

🍒 reviewing build configuration

{proejctName}/android/app 경로의 build.gradle을 검토하세요. 검토할 항목은 다음과 같습니다.

 

🍇 defaultConfig 하위 항목

🍌 applicationId

최종 고유의 applicationId를 지정합니다.

🍌 minSdkVersion

기본값은 flutter.minSdkVersion으로 앱이 실행되도록 디자인한 최소 API 수준을 지정합니다.

🍌 targetSdkVersion

기본값은 flutter.targetSdkVersion으로 앱이 실행되도록 디자인한 대상 API 수준을 지정합니다.

🍌 versionCode

내부 버전 번호로 사용되는 양의 정수입니다. 이 숫자는 한 버전이 다른 버전보다 최신인지 확인하는 데에만 사용되며, 숫자가 높을수록 최신 버전을 나타냅니다. 사용자에게 표기되는 내용은 아닙니다.

🍌 versionName

사용자에게 표시되는 버전 번호로 사용되는 문자열입니다. 원시 문자열 또는 문자열 리소스에 대한 참조로 지정할 수 있습니다.

🍌 buildToolsVersion

Gralde Plugin은 Project에서 사용하는 buildtools의 기본 버전을 지정합니다. 이 옵션을 사용하여 다른 버전의 빌드 도구를 지정할 수 있습니다.

 

🍇 android 항목 아래

🍌 compileSdkVersion

기본값은 flutter.compileSdkVersion으로 Gradle이 앱을 컴파일 하는데 사용해야 하는 API수준을 지정합니다.

 

🍒 building app for release

Google Play Store는 AppBundle을 더 선호하지만, 아직 AppBundle이 적용되지 않는 Store는 APK를 사용한다고 합니다. 일단 두 가지 모두 정리하고, AppBundle을 활용하여 Play Store에 게시를 진행하려는 절차를 밟을 것입니다.

 

🍇 AppBundle 빌드

서명 단계를 완료하면 앱 번들이 서명됩니다. 이 시점에서는 리버스 엔지니어링을 더 어렵게 만들기 위해 Dart 코드를 난독화하는 것을 고려할 수 있습니다 . 코드를 난독화하려면 빌드 명령에 몇 가지 플래그를 추가하고 스택 추적을 난독화하기 위해 추가 파일을 유지 관리해야 합니다.

flutter build appbundle

실행은 flutter build의 릴리즈 빌드로 설정됩니다. 앱의 릴리즈 번들은 {proejctName}/build/app/outputs/bundle/release/app.aab로 생성됩니다.

기본적으로 AppBundle에는 armeabi-v7a, arm64-v8a, x86-64용으로 컴파일 된 Dart 코드와 Flutter 런타임이 포함되어 있습니다.

 

🍌 bundletool을 활용하여 오프라인 테스트

🍌 Google Play를 이용한 온라인 테스트

내부 테스트 트랙이나 알파 또는 베타 채널을 사용하여 번들을 프로덕션에 출시하기 전에 테스트할 수 있습니다.

※ reference : https://developer.android.com/studio/publish/upload-bundle?hl=ko

Play 스토어에 번들을 업로드하려면 위 레퍼런스를 참고하세요.

 

🍇 APK 빌드

APK를 빌드할 땐, 리버스 엔지니어링을 더 어렵게 만들기 위해 Dart 코드 난독화를 고려할 수 있습니다. 코드 난독화를 위해선 build command에 몇 가지 플래그를 추가해야 합니다.

flutter build apk // --release 기본 옵션 포함된, 가장 기본이 되는 빌드 방법
flutter build apk --split-per-abi

이 명령을 실행하면 다음 3개의 APK파일이 생성됩니다.

[project]/build/app/outputs/apk/release/app-armeabi-v7a-release.apk
[project]/build/app/outputs/apk/release/app-arm64-v8a-release.apk
[project]/build/app/outputs/apk/release/app-x86_64-release.apk

플래그를 제거하면 모든 ABI 대상이 --split-per-abi에 대해 컴파일 된 코드가 포함된 큰 APK가 생성됩니다. 이 APK는 분할된 APK보다 더 크기 때문에 사용자는 기기 아키텍처에 적용할 수 없는 기본 바이너리를 다운로드하게 되므로 주의하세요.

 

🍒 publishing to the google play store

🍒 updating app version number

앱 기본 버전 번호는 1.0.0 입니다. 업데이트 하려면 pubspec.yaml으로 이동하여 version: 1.0.0+1로 업데이트 하세요. version에 작성된 1.0.0은 애플리케이션의 versionName을 의미하며, +1은 versionCode를 나타냅니다. 해당 값은 android 파일의 localproperties에 자동으로 업데이트 됩니다.

※ reference : https://developer.android.com/studio/publish/versioning?hl=ko

앱 버전에 대한 유지보스와 관련하여는 위 reference를 참고하세요.

 

🍒 android release FAQ

🐇 Play에 업로드

※ reference : https://developer.android.com/studio/publish/app-signing?hl=ko#enroll

Play Console에 업로드 하기 위해선, Play 앱 서명에 등록해야 합니다. 이전 단계에서 발급한 upload-key를 활용하여 서명할 수 있습니다. 그럼 이제 Play Console에 진입해서 진행해야 할 단계에 대해 알아가봅시다.

 

🥕 Google Play Console 시작하기

※ reference : https://play.google.com/console/signup

일단 개발자 계정으로 전환해야 합니다. Google Console이 제시하는 대로 2단계 설정을 완료하고, 다시 Google Play Console 사이트에 접속합니다.

 

이후 저는 개인용 계정이므로, 개인을 선택하여 시작합니다. 이후 내 정보를 입력하고 개발자 계정을 생성합니다.

개발자 계정을 생성하기 위해서는 다음 정보가 필요합니다. 항목에 알맞는 사항을 넣고, 개발자 계정 생성을 완료하세요.

🍌 개발자 계정 이름

Google Play에서 공개 될 개발자의 이름입니다.

🍌 담당자 이름, 연락처 이메일/주소/전화번호

해당 내용은 Google에서 계정에 연락해야 하기 위한 수단으로 Google Play에는 표시되지 않습니다.

🍌 선호 언어

이메일로 커뮤니케이션을 진행할 때 사용 될 국가적 언어를 의미합니다.

이후 앱 관련한 질문에 대답합니다. 추후 수정 가능하며, 앞으로 게시할 실제 행동에 제약이 생기진 않습니다.

※ agreement : https://play.google.com/about/developer-distribution-agreement.html

이용 약관을 확인하고, 동의하여 개발자 계정을 생성합니다. 개발자 계정을 생성하는 데는 최초 1회 $25, 한화 약 3만원의 결제 금액이 생깁니다.

🐇 앱 버전 준비 및 출시

※ reference : https://support.google.com/googleplay/android-developer/answer/9859348?hl=ko&visit_id=638404560066143377-1402164544&rd=1

버전을 사용하면 앱의 Android App Bundle을 관리하고 앱을 특정 트랙에 출시할 수 있습니다. 항목은 다음과 같습니다.

 

🥕 공개 테스트

Google Play에서 테스테에게 제공됩니다. 사용자는 스토어 등록 정보를 통해 테스트에 참여할 수 있습니다.

🥕 비공개 테스트

개발자가 선택하는 제한된 수의 테스터에게 제공되며, 이 테스터는 앱의 출시 전 버전을 테스트하고 의견을 제출할 수 있습니다.

🥕 내부 테스트

개발자가 선택하는 최대 100명의 테스터에게 제공됩니다.

🥕 프로덕션 테스트

선택한 국가의 모든 GooglePlay 사용자에게 제공됩니다.

새 버전을 만드려면 앱을 테스트 트랙으로 출시할 권한이 있어야 합니다. 2023년 11월 13일 이후 개인 계정을 만든 개발자는 특정 테스트 요구사항을 충족해야 Google Play에 앱을 게시할 수 있습니다. 그 항목은 다음과 같습니다.

 

🍇 최소 지난 14일 동안 지속적으로 동의한 최소 20명의 테스터를 대상으로 앱에 대한 비공개 테스트를 진행해야 합니다. 이 기준을 충족해야 Play Console의 대시보드에서 프로덕션 엑세스를 신청하여 최종적으로 Google Play에 앱을 배포할 수 있습니다.

※ reference : https://support.google.com/googleplay/android-developer/answer/14151465?sjid=841654535308975600-AP

 

🍌 테스터 모집

누구나 참여자가 될 수 있습니다. 내 주변 지인들에게 연락하여 앱 베타 테스터가 되어 달라고 요청할 수 있습니다.

🍌 테스터 참여

테스터 그룹이 확인하고 보고하는 방법에 대한 명확한 지침을 제공하는 것이 중요합니다. 어떤 유형의 피드백을 찾고 있느지 알려주고, 전체적인 피드백을 받을 수 있도록 테스터가 앱 기능을 최대한 많이 사용하도록 권장하세요.

Google Play를 활용하여 비공개 피드백을 제공할 수도 있습니다. 단, 테스터에게 최소 14일동안 지속적으로 비공개 테스트를 선택한 상태로 유지해야 한다는 점을 강조하세요.

🍌 사용자 피드백 수집 및 보기

Play Console에서 평가 및 리뷰 > 테스트 피드백으로 이동하여 관리할 수 있습니다.

🍌 사용자 피드백에 대한 조치

앱 테스트 기간 동안 테스터의 피드백에 응답하고 그들이 발견한 버그를 반드시 수정해야 합니다.

관련된 모든 사항에 대해 자세히 알고 싶으면 위 reference를 참고하세요.

 

🍇 새 앱 만들기

Google Play Console에서 본인 인증을 진행하면 앱을 만들 수 있습니다. 추후 본인 인증이 확인되면 앱을 게시할 수 있습니다. 본인 인증이 확인 되기 전, 앱 만들기를 진행해보려 합니다.

 

🍎 앱 세부정보 입력

앱 이름/기본 언어/카테고리/가격/선언에 대한 앱의 세부 정보를 입력해야 합니다.

선언 항목의 경우 다음 과 같은 내용에 대해 동의해야 합니다.

🍌 개발자 정책

※ reference : https://play.google.com/about/developer-content-policy/

• 제한된 콘텐츠
• 명의 도용
• 지적 재산
• 개인정보 보호, 사기 및 기기 악용
• 수익 창출 및 광고
• 스토어 등록정보 및 프로모션
• 스팸 및 최소 기능
• 멀웨어
• 원치 않는 모바일 소프트웨어
• 가족
• 기타 프로그램
• 시행

🍎 기본 스토어 등록정보

요구하는 항목에 맞게 모든 내용을 삽입하면 됩니다.

🍎 비공개 테스트

프로덕션을 제출하기 전, 비공개 테스트 버전을 개시하고 최소 20명 이상의 테스터가 14일 이상 테스트를 진행해야 합니다.

 

🍌 새 버전 출시하기

가장 중요하게 볼 항목은 flutter build appbundle을 통해 AppBundle을 제작할 때, Android project/app/src/main/res 경로에 있는 AndroidManifest 파일의 android/namespace를 확인해야 합니다.

기본적으로 com.example.{projectName}으로 설정되어 있는데, Play Console에 업로드 될 appbundle은 com.example 사용을 지양하고 있기 때문에 허용되지 않습니다. namespace 명명 규칙에 따라 새롭게 작성하고 모든 패키지를 개선한 뒤 시도하세요.

※ namespace 규칙:

• 애플리케이션 ID는 두 개 이상의 세그먼트(한 개 이상의 점)로 구성해야 합니다.
• 각 세그먼트는 문자로 시작해야 합니다.
• 모든 문자는 영숫자나 밑줄[a~z, A~Z, 0~9 또는 _]이어야 합니다.
• 애플리케이션 ID를 네임스페이스와 동일하게 유지합니다. 두 속성의 차이가 약간 혼란스러울 수 있지만 동일하게 유지한다면 아무것도 걱정할 필요가 없습니다.
• 앱을 게시한 후에는 애플리케이션 ID를 변경하지 마세요. 변경하면 Google Play 스토어에서 후속 업로드를 새 앱으로 간주합니다.
• 애플리케이션 ID를 명시적으로 정의합니다. applicationId 속성을 사용하여 애플리케이션 ID가 명시적으로 정의되지 않으면 자동으로 네임스페이스와 동일한 값이 사용됩니다. 즉, 네임스페이스를 변경하면 애플리케이션 ID가 변경되는데 이는 일반적으로 바람직하지 않습니다.

🍌 기존의 bundle을 올려버렸을 경우

Play Console에는 App Bundle 탐색기가 존재합니다. 출시를 하지 않았으면, App Bundle에 있는 항목을 삭제할 수 있습니다.

또한 추후, 업그레이드 된 버전의 항목을 관리하려면 다음 두 항목에 대해 숫자를 증가시켜 주세요.

• pubspec.yaml의 version
• android/local.properties의 versionName/versionCode

🍌 기존 bundle을 유지하고, 새로운 Version의 bundle을 추가하는 경우

비공개 테스트 애플리케이션의 트랙 관리에 진입하면, 우측 상단에 새 버전 만들기 버튼이 존재합니다. 이 경로를 통해 내 새로운 버전의 appbundle을 추가할 수 있고, 전체적인 관리가 가능합니다. appbundle을 추가하는 방법은 위에 작성되었던 내용과 동일합니다.

 

🍎 Android 13에 광고 ID 변경사항 도입

기존 에뮬레이터도 API 33을 사용하고 있었기 때문에, 광고 ID에 대해 설정해주어야 한다. 내 앱 같은 경우, 광고를 도입하지 않을 것이므로 "광고 ID 사용을 하지 않음"을 선택하여 해결했다.

🍎 게시 개요 전 안내사항

앱의 변경 사항을 Google에 전송하여 검토를 받아야 합니다. 검토 항목은 현재까지 설정된 모든 항목에 대하여 진행됩니다. 추후 검사 결과를 파악하여 다시 작성해 보겠습니다.

 

🍌 게시 개요 페이지에서 검토를 위해 변경사항을 전송할 시점을 관리하세요

Play Console에서 앱에 적용한 대부분의 변경사항은 검토를 위해 Google에 전송하여 승인을 받은 후 게시해야 합니다. 게시 개요 페이지에서 앱 변경사항을 확인하고 준비가 되면 Google에 전송하여 검토를 받으면 됩니다.

🍌 승인된 변경사항이 게시되는 시점을 관리하려면 관리형 게시를 사용 설정하세요

게시 개요 페이지에서 관리형 게시를 사용 설정 또는 사용 중지할 수 있습니다. 관리형 게시를 사용 설정하면 승인된 변경사항을 Google Play에 게시할 시기를 관리할 수 있습니다. 관리형 게시가 사용 중지된 경우 변경사항이 승인되는 즉시 게시됩니다.

🍌 앱 변경사항 추적

언제든지 게시 개요로 이동하여 앱 변경사항의 개요를 살펴보고 변경사항이 검토를 위해 전송할 준비가 되었는지, 검토 중인지 또는 게시할 준비가 되었는지 확인할 수 있습니다.

 

🍇 테스터 모집

Play Console에서 요구하는 모든 기본 사항을 마치면 테스터를 추가할 수 있습니다. 단, 테스터의 이메일을 추가할 때 google email만 사용 가능합니다.

 

이 모든 작업을 완료하면 Play Console에서 검토가 진행됩니다. 개시 개요를 통해 확인할 수 있으며, 상당한 기간이 소모될 수 있습니다. 테스터를 위해서 어떤 내용을 준비하고 진행해야 하는지, 14일 테스트를 위한 작업은 무엇을 해야 하는지에 대해 유지보수 측면으로 다음 칼럼에서 작성하도록 하겠습니다.