업로드가 가능한 파일과 심사할 수 있는 앱은 다릅니다. 제출 후보 하나를 정하고 빌드·등록정보·정책 자료가 같은 앱을 설명하는지 대조합니다.
디버그 앱에서는 로그인되는데 릴리스 후보에서는 서버 주소가 다르거나, 스토어 화면에는 이전 기능이 남아 있을 수 있습니다. 제출 전에는 메뉴를 하나씩 채우기보다 어떤 빌드를 검토하고 있는지 고정하는 편이 비교하기 쉽습니다.
제출 후보 하나에 자료를 연결합니다
| 같이 볼 것 | 직접 대조할 값 |
| 빌드 설정과 Console 앱 | applicationId / 패키지명 |
| 릴리스 후보와 업로드 기록 | versionCode와 후보 파일 |
| 앱 동작과 스크린샷 | 현재 제공하는 기능인지 |
| 사용자 데이터와 정책 | SDK·서버의 실제 데이터 흐름 |
| 로그인과 심사 접근 | 검토자가 주요 기능을 열 수 있는지 |
제출 준비 대조표의 local_value와 console_value를 채워보세요. 빈칸은 미확인 상태로 남기고, 어떤 파일·화면으로 확인했는지 evidence에 적습니다. 표에는 실제 계정 정보나 심사 결과가 들어 있지 않습니다.
릴리스 빌드 자체를 시험합니다
테스트한 커밋과 빌드 파일을 기록하고, 릴리스 환경에서 로그인·주요 기능·네트워크 실패를 확인합니다. 패키지명은 Play에서 앱을 식별하는 값이고 버전 코드는 업데이트 순서를 위한 값입니다. 앱 만들기 및 설정하기에서 AAB와 버전 관리의 공식 설명을 볼 수 있습니다.
서명 키와 비밀번호는 대조표에 넣지 않습니다. 실제 운영 키가 보이는 빌드 로그나 화면도 공개 자료에서 제외합니다. 업로드 여부와 실제 기기에서 후보가 실행되는지는 별도로 확인합니다.
일정은 자신의 계정 요건에서 계산합니다
신규 개인 계정의 테스트 요구사항은 적용 대상과 절차를 따로 설명합니다. 자신의 계정 화면과 안내를 먼저 확인하고 테스터와 기간을 계획해야 합니다. 다른 사람의 과거 일정만 보고 즉시 출시 가능한 것으로 가정하지 않습니다.
타깃 API는 현재 대상 API 요구사항에서 앱 종류와 제출 시점에 맞게 확인합니다. 이 글에서는 쉽게 낡는 버전 숫자를 고정하지 않고, 준비표에 확인일과 근거를 남기도록 했습니다.
정책 답변은 앱과 SDK를 기준으로 씁니다
스토어 설명, 개인정보처리방침, 데이터 보안 답변이 실제 앱과 맞는지 비교합니다. 데이터를 직접 수집하지 않는다고 생각해도 SDK가 전송하는 정보가 있을 수 있습니다. 조사 방법은 데이터 흐름 조사표에 따로 정리했습니다.
마지막으로 Console이 남긴 필수 작업과 오류를 확인하고 계정의 제출 절차를 따릅니다. 이 글은 실제 계정에서 제출 버튼까지 실행한 후기가 아닙니다. 결과물은 후보 빌드와 등록 자료의 불일치를 찾는 대조표이며, 완료했다고 심사 통과가 보장되지는 않습니다.
댓글
0개아직 표시된 댓글이 없습니다.