Google Play에서 멀티 디바이스 품질 및 모바일 이외의 기기에 게시하는 방법

환영합니다, 여러분.

멀티 디바이스 앱 품질을 탐색하고 모바일 이외의 폼 팩터를 위해 Google Play에 게시하는 방법에 관한 세션에 참여해 주셔서 감사합니다.

저는 자동차용 Android팀의 개발자 관계 엔지니어인 얀 클라이너트입니다.

저는 Play 신용안전팀의 운영 책임자인 파우스틴 리아오입니다.

오늘 여러분과 함께하게 되어 매우 기쁩니다.

수년 동안 Android 개발이라고 하면 대부분 휴대기기만 떠올렸지만, Android 생태계는 스마트폰을 넘어 훨씬 더 확장되었습니다.

오늘날 사용자는 Android TV를 통해 거실에서, Android Auto 또는 Automotive OS를 통해 카풀을 기다리거나 자동차를 충전하는 동안, Wear OS를 통해 손목에서, 그리고 Android XR을 통해 몰입형 3D 공간에서 앱과 상호작용하고 있습니다.

이는 성장을 위한 엄청난 기회이지만, 이러한 폼 팩터로 확장한다는 것은 게시 전략에서 고려해야 할 몇 가지 부수적인 사항이 있다는 것을 의미합니다.

앱을 빌드하고 Google Play에 게시하여 출시하는 전반적인 과정은 모바일 출시와 거의 동일합니다.

앱을 빌드하고 준비한 다음 Play Console에서 등록정보를 만들고, 앱을 테스트하고, 프로덕션 버전을 업로드 및 제출한 후 검토 및 승인을 기다립니다.

하지만 모바일 이외의 폼 팩터용 앱을 게시할 때는 몇 가지 고유한 고려사항이 있습니다.

오늘은 더 원활하고 예측 가능한 멀티 디바이스 출시 프로세스를 준비하는 데 도움이 되는 명확한 프레임워크를 제공해 드리겠습니다.

기본부터 시작해 보겠습니다. 앱을 설계하고 패키징하는 방법입니다.

따라서 Google Play Console을 사용하기 전에 중요한 아키텍처 결정을 내려야 합니다.

지원하는 모든 폼 팩터의 모든 항목이 포함된 단일 통합 App Bundle을 빌드하시나요? 아니면 앱을 폼 팩터별 모듈로 분할하고 각 모듈에 대해 Android App Bundle(AAB)을 생성하시나요?

모듈 또는 모듈화는 유지관리 가능성을 개선하는 방식으로 코드베이스를 구조화하는 방법을 의미합니다.

모듈화에는 여러 가지 접근 방식이 있지만 일반적으로 코드베이스를 느슨하게 결합된 독립적인 부분으로 구성하며, 각 부분은 모듈입니다.

따라서 통합 Android App Bundle 접근 방식이 관리하기 더 간단해 보일 수 있지만 실제로는 모듈식 접근 방식을 사용하는 것이 좋습니다.

이 모듈식 접근 방식을 권장하는 이유를 보여주는 예시를 살펴보겠습니다.

모바일과 Android TV를 모두 지원하는 앱이 있다고 가정해 보겠습니다.

표준 모바일 출시 트랙에서 단일 Android App Bundle을 제출했는데 Android TV 앱이 검토 확인을 통과하지 못하면 전체 출시가 중단됩니다.

따라서 Android TV 앱과 모바일 앱의 출시 모두에 영향을 미칩니다.

따라서 모바일 앱에 문제가 없더라도 Android TV 검토가 실패한 원인이 된 문제를 해결하고 앱을 다시 제출하여 검토를 받아야 사용자에게 출시할 수 있습니다.

반면, 각 폼 팩터에 맞는 모듈식 Android App Bundle을 사용하면 더 세부적으로 제어할 수 있으며 모바일 출시와 폼 팩터 출시를 분리할 수 있습니다.

따라서 모바일 앱과 TV 앱에 별도의 앱 모듈이 있는 경우 각각에 대해 별도의 Android App Bundle을 생성할 수 있습니다.

TV 앱 검토에 문제가 있는 경우 해당 앱의 출시만 차단되며, 문제를 해결할 때까지 차단이 유지됩니다.

모바일 앱의 버전이 의도한 대로 게시됩니다.

앞서 언급했듯이 모듈화에는 여러 가지 접근 방식이 있습니다.

다음은 모바일 환경과 Android Automotive OS 환경을 갖춘 오디오북 앱을 모듈화하는 접근 방식의 한 예입니다.

상단에 녹색으로 표시된 부분은 각 폼 팩터의 앱 모듈로, 플랫폼별 종속 항목을 구분하는 데 도움이 됩니다.

노란색은 기능 모듈로, 앱 기능의 격리된 부분에 해당합니다.

데이터 모듈은 파란색으로 표시되고 하단에는 핵심 또는 일반 모듈이 있습니다. 이 모듈은 일반적으로 다른 모듈에서 자주 사용하는 코드를 포함하는 데 사용됩니다.

그런 다음 프로젝트의 Gradle 설정 파일에 이 다중 모듈 Gradle 구성을 포함하고 설정하여 이러한 종류의 모듈화를 지원할 수 있습니다.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

따라서 각 앱 모듈과 번들에 동일한 패키지 이름 또는 애플리케이션 ID를 계속 사용합니다.

이러한 모듈식 접근 방식은 Play Console의 트랙 전략과 직접적으로 연결됩니다.

게시할 때 표준 모바일 트랙이 있지만 전용 폼 팩터 트랙도 제공됩니다.

Android TV, Android XR, Android Automotive OS의 경우 선택할 수 있습니다.

모바일과 함께 게시하거나 전용 폼 팩터 트랙을 사용할 수 있습니다.

하지만 두 가지 예외가 있습니다.

Wear OS의 경우 전용 Wear OS 트랙을 사용해야 합니다.

Android Auto의 경우 기본적으로 자동차 화면에 투사되는 모바일 앱의 확장 프로그램이므로 표준 모바일 트랙만 선택할 수 있습니다.

여러 트랙을 관리하는 경우 버전 관리가 중요합니다.

한 가지 방법은 버전 코드의 처음 몇 자리를 폼 팩터에 할당하는 것입니다.

예를 들어 모바일은 01, Wear OS는 02, Android Automotive OS는 03입니다.

일반적으로 버전 코드의 길이를 7자리 이상으로 설정하여 나머지 자릿수를 앱 버전에 사용할 수 있도록 하는 것이 좋습니다.

이렇게 하면 Play Console에서 버전 코드 충돌을 방지할 수 있습니다.

앱이 패키징되면 이제 테스트할 차례입니다.

폼 팩터 개발에는 철저한 테스트가 필요하며, Google Play는 프로덕션에 출시하기 전에 이를 수행할 수 있는 세 가지 채널(내부 테스트, 비공개 테스트, 공개 테스트)을 제공합니다.

전용 폼 팩터 트랙을 사용하는 경우 이러한 테스트 트랙을 폼 팩터와 결합하여 프로세스를 더욱 세부적으로 제어할 수도 있습니다.

예를 들어 원하는 경우 표준 트랙에서 모바일 앱의 비공개 테스트 버전을 사용하고, 전용 Android TV 폼 팩터 트랙에서 Android TV 앱의 별도 비공개 테스트 버전을 사용하며, 각 트랙에 서로 다른 테스터 그룹을 설정할 수 있습니다.

따라서 내부 테스트는 좋은 시작점이 됩니다.

최대 100명의 테스터에게 앱을 빠르게 배포할 수 있으며, 중요한 점은 Play 검토를 트리거하지 않는다는 것입니다.

즉, 개발자와 테스터가 기기에 앱을 빠르게 설치하고 에뮬레이터나 실제 TV, 시계 또는 기타 기기에서 환경을 검증할 수 있습니다.

내부 테스트를 사용하면 테스터와 공유할 수 있는 고유한 URL이 제공됩니다.

내부 테스트 결과가 만족스러우면 비공개 테스트 및 공개 테스트로 넘어갈 수 있습니다.

비공개 테스트 버전을 사용하면 내부 테스트를 넘어 더 광범위한 테스터를 대상으로 출시 전 버전의 앱을 테스트하여 타겟팅된 의견을 수집할 수 있습니다.

비공개 테스트 그룹은 이메일 주소 목록 또는 Google 그룹스를 통해 관리할 수 있습니다.

반면 공개 테스트는 Google Play에서 더 큰 규모의 그룹을 대상으로 테스트를 실행하는 데 도움이 됩니다.

Google Play에 표시되며 누구나 공개 테스트 프로그램에 참여할 수 있습니다.

초대가 필요하지 않으며, 앱에 관한 의견과 비공개 의견을 개발자와 공유할 수 있습니다.

이러한 공개 및 비공개 테스트 트랙은 검토를 트리거합니다.

이는 사실 엄청난 이점입니다.

이를 통해 검토 절차 자체를 테스트하고 출시일 전에 장애물을 제거할 수 있습니다.

검토 절차에 관해 이야기해 보겠습니다. 이 절차에는 어떤 내용이 포함되며 왜 중요한가요?

이러한 정책과 가이드라인의 핵심은 앱 품질입니다.

고품질 앱 및 게임은 사용자에게 가치를 제공하며, 즐겁게 사용할 수 있고, 프리미엄 기기를 최대한 활용하며, 안전을 염두에 두고 설계되었습니다.

그럼 최대한 쉽게 검토를 통과할 수 있도록 앱을 준비하는 방법을 살펴보겠습니다.

훌륭한 사용자 환경이 어떤 것인지에 중점을 둔 앱 품질 가이드라인을 살펴보는 것이 가장 좋습니다.

Google은 모든 앱에 적용되며 모든 앱이 충족해야 하는 최소 품질을 정의하는 핵심 앱 품질 가이드라인과 적응형 앱 품질 가이드라인을 게시합니다. 이 가이드라인은 기기 폼 팩터, 화면 크기, 디스플레이 모드와 관계없이 앱이 우수한 환경을 제공하는지 확인하는 데 도움이 됩니다.

이 두 가지 가이드라인은 시작하기에 정말 좋은 출발점입니다.

하지만 각 폼 팩터에는 폼 팩터별 앱 품질 가이드라인도 있습니다.

검토자는 이러한 가이드라인에 따라 실제 기기와 에뮬레이터에서 앱을 테스트합니다.

따라서 앱이 이러한 정책을 준수하는지 확인하는 것이 매우 중요합니다.

각 폼 팩터에서 앱이 거부되는 가장 일반적인 이유를 간단히 살펴보겠습니다.

하지만 이 체크리스트가 모든 앱 품질 가이드라인을 포괄하지는 않습니다.

따라서 작업하는 각 폼 팩터의 품질 가이드라인을 자세히 살펴보고 더 강력한 기준을 확인하세요.

Android TV부터 살펴보겠습니다.

따라서 이러한 섹션 슬라이드의 하단에는 해당 폼 팩터의 앱 품질 가이드라인 전체 목록으로 연결되는 짧은 링크가 표시됩니다.

Android TV 앱이 거부되는 일반적인 이유 중 하나는 앱에서 지원하는 각 언어의 홈 화면 배너 이미지가 누락된 경우입니다.

따라서 앱을 식별하는 현지화된 텍스트가 포함된 320x180픽셀 이미지를 제공해야 합니다.

이 슬라이드의 이미지는 이러한 기준을 준수하는 홈 화면 배너의 예시를 보여줍니다.

둘째, 대부분의 TV에서 사용자는 D패드 리모컨을 사용하여 기기와 상호작용합니다.

따라서 D패드 탐색과 포커스를 적절하게 지원하는 것이 매우 중요합니다.

이러한 기준에 따라 거부되지 않도록 최소한의 D패드 컨트롤을 지원해야 합니다.

Android TV 앱이 거부되는 세 번째 일반적인 이유는 Android 매니페스트 파일에 CATEGORY_LEANBACK_LAUNCHER 인텐트 필터가 누락된 경우입니다.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

이 필터는 앱을 TV용으로 사용 설정된 것으로 식별하고 Google Play에서도 사용자에게 TV 앱으로 식별하도록 합니다.

사용자가 TV 홈 화면에서 앱을 선택하면 이 인텐트가 실행할 활동을 식별합니다.

따라서 매니페스트에 이 권한을 포함해야 합니다.

다음은 Android XR입니다.

Android XR로 구동되는 XR 헤드셋 또는 XR 글라스를 빌드할 때는 앱의 성능, 렌더링, 안정성에 특히 주의를 기울이세요.

Perfetto를 사용하여 Jetpack XR SDK로 빌드된 앱의 성능을 프로파일링하면 최소 프레임 속도 요구사항을 준수하는지 확인할 수 있습니다.

Unity와 같은 실시간 엔진을 사용하여 빌드하는 경우 엔진에 내장된 프로파일링 도구를 사용하여 렌더링 요구사항을 준수하는지 확인할 수 있습니다.

다음은 Android Auto와 Android Automotive OS로 구성된 자동차입니다.

Android Auto 및 Android Automotive OS에는 이 특정 폼 팩터에만 적용되는 카테고리 개념이 있습니다.

또한 특정 카테고리의 앱만 자동차에 게시할 수 있습니다.

따라서 Google에서 지원하는 카테고리 중 하나와 일치하지 않는 카테고리에 앱을 제출하거나, 베타 버전인 카테고리의 공개 테스트 또는 프로덕션에 앱을 제출하면 거부됩니다.

그 의미를 좀 더 자세히 설명해 드리겠습니다.

여기에서 각 플랫폼의 자동차에서 지원되는 앱 카테고리 개요와 사용 가능 여부를 확인할 수 있습니다.

베타 버전인지, 정식 버전인지, 아직 지원되지 않는지(여기서는 '출시 예정'으로 표시됨)를 확인할 수 있습니다.

따라서 내비게이션이나 관심 장소 앱과 같은 일부 카테고리는 정식 버전으로 제공되며, 이는 누구나 이러한 카테고리 중 하나에 속하는 앱을 자동차용 프로덕션에 게시할 수 있음을 의미합니다.

하지만 Android Auto용 통신 통화 앱과 같은 다른 카테고리는 베타 버전입니다.

따라서 이러한 카테고리의 경우 내부 테스트 또는 비공개 테스트 트랙에 게시할 수 있지만, 해당 카테고리의 사전 체험판 프로그램 중 하나에 참여하지 않는 한 프로덕션에 게시할 수 없습니다.

자세한 내용은 자동차용 Android 개발자 가이드에서 확인할 수 있습니다.

여기에서 사전 체험 프로그램에 참여를 신청할 수 있는 링크를 찾을 수 있습니다.

Android Automotive OS 스크린샷의 사양이 누락되거나 잘못된 경우도 앱이 거부되는 일반적인 이유입니다.

따라서 Android Automotive OS 스크린샷을 제공할 때는 여기에 나열된 크기의 세로 모드 스크린샷 2개 이상과 가로 모드 스크린샷 2개 이상을 포함해야 합니다.

Android Automotive OS 에뮬레이터를 사용하여 이러한 스크린샷을 캡처할 수 있습니다.

필요한 크기의 스크린샷을 캡처할 수 있도록 설정되어 있습니다.

마지막으로, 자동차용 앱에서는 안전이 가장 중요합니다.

따라서 앱이 운전자 주의 분산 행동 가이드라인을 준수하지 않으면 거부됩니다.

예를 들어 동영상 앱은 재생을 일시중지해야 하며 차량이 움직이는 동안에는 표시되지 않아야 합니다.

마지막으로 Wear OS가 있습니다.

따라서 Wear OS 앱은 작고 둥근 디스플레이에 최적화되고 형식이 지정되지 않으면 거부될 수 있습니다.

따라서 여기서는 Compose for Wear OS의 최신 안정화 버전을 사용하여 다양한 크기의 기기에서 콘텐츠가 가장자리에서 잘리지 않도록 하거나, 예를 들어 스크롤 가능한 콘텐츠가 있을 때 스크롤바가 표시되도록 하는 것이 좋습니다.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Android Automotive OS와 마찬가지로 Wear OS 앱도 Wear OS 스크린샷이 누락되거나 부정확한 경우 거부될 수 있습니다.

여기 Androidify 샘플 앱의 Google Play 스토어 등록정보에 있는 스크린샷의 좋은 예가 있습니다. 이 스크린샷은 요구사항을 충족합니다.

따라서 Wear OS 기기에서 실행되는 앱을 보여주는 스크린샷을 하나 이상 제출해야 합니다.

그 결과가 궁금하신가요?

특정 폼 팩터의 앱 품질 가이드라인을 읽고 제출하기 전에 가이드라인에 따라 테스트하세요.

몇 가지 중요한 도움말도 알려드리겠습니다.

앱에 로그인이 필요한 경우 Play Console의 앱 액세스 섹션에서 활성 데모 계정과 유효한 사용자 인증 정보를 제공해야 합니다.

검토자가 로그인할 수 없으면 앱을 테스트할 수 없으며 자동으로 거부됩니다.

또한 약속한 기능을 제공해야 합니다.

모바일 스크린샷만 사용하지 마세요.

앱이 Wear OS 및 Android TV에서 사용 가능한 경우 Play Console에서 해당 폼 팩터의 고화질 스크린샷을 업로드해야 합니다.

마지막으로, 구체적으로 설명하세요.

앱이 어떤 기능을 하는지, 왜 써 볼만한 가치가 있는 앱인지, 사용자가 각 유형의 기기에 앱을 설치했을 때 어떤 점을 기대할 수 있는지 정확하게 설명하세요.

정리하자면, 사용자가 어디에 있든 도달할 수 있다는 것은 엄청난 기회입니다. 모듈식으로 설계하고, 내부 테스트를 활용하여 빠르게 반복하고, 폼 팩터 품질 가이드라인에 따라 설계하고, 스토어 등록정보를 최적화하면 앱을 더 원활하게 출시하고 검토 프로세스를 준비하는 데 도움이 됩니다.

오늘 시간을 내주셔서 정말 감사합니다.

개발자 여러분이 Google Play에 선보일 멋진 멀티 디바이스 환경이 무척 기대됩니다.