# Navigating multi-device quality & publishing beyond mobile on Google Play - Speakers: Jan Kleinert (Developer Relations Engineer), Faustine Liao (DFX Operations Lead) - Track: Tools & Performance - Video: https://www.youtube.com/watch?v=93NhXMuUDJo - Page: https://developer.android.com/events/dev-summit/talks/navigating-multi-device-quality-publishing-beyond-mobile-on-google-play ## About the talk As the Android ecosystem expands across wrists, living rooms, vehicles, and XR, the opportunity to reach users on new screens is growing. However, distributing across Wear OS, Android TV, Android Auto, Android Automotive OS, or Android XR introduces distinct considerations for testing, store listings, and app reviews. This session explores how to effectively utilize Google Play Console for non-mobile form factors to help streamline a predictable multi-device launch. We will cover key distribution decisions, including how to structure track strategies and package names, configure targeted testing tracks, and tailor store listings. You'll get a practical walkthrough of form-factor App Quality guidelines to help avoid common review pitfalls and publish on Google Play with greater confidence. ## Summary - Modular app bundles isolate form-factor releases from your mobile app. If a form-factor review fails, only that specific bundle is blocked while your mobile release publishes as intended. - Play Console tracks offer flexible publishing paths, with exceptions for Wear OS and Android Auto. Wear OS requires a dedicated track, while Android Auto must use the standard mobile track. - Internal testing tracks distribute builds to up to 100 testers without triggering a Play review. Closed and open testing tracks do trigger reviews, helping you resolve hurdles before launch. - Form-factor review rejections often stem from missed device requirements, such as car app category limits or absent screenshots. Provide valid demo account credentials in Play Console whenever your app requires login. ## Resources - [Android user experience guidelines](https://developer.android.com/quality/user-experience) - [Android TV app quality guidelines](https://goo.gle/tv-app-quality) - [Android XR app quality guidelines](https://goo.gle/xr-app-quality) - [Android for Cars app quality guidelines](https://goo.gle/car-app-quality) - [Wear OS app quality guidelines](https://goo.gle/wear-app-quality) ## Topics google-play, multi-device, android-tv, android-auto, wear-os, android-xr, app-quality ## Transcript ### Introduction [00:05](https://www.youtube.com/watch?v=93NhXMuUDJo&t=5s) Welcome, everyone. [00:06](https://www.youtube.com/watch?v=93NhXMuUDJo&t=6s) Thank you so much for joining us for this session on navigating multi-device app quality and publishing on Google Play for form factors beyond mobile. [00:14](https://www.youtube.com/watch?v=93NhXMuUDJo&t=14s) I'm Jan Kleinert, a Developer Relations Engineer on the Android for Cars team. [00:18](https://www.youtube.com/watch?v=93NhXMuUDJo&t=18s) And I'm Faustine Liao, an Operations Lead on the Play Trust and Safety team. [00:22](https://www.youtube.com/watch?v=93NhXMuUDJo&t=22s) We are so excited to have everyone here with us today. [00:25](https://www.youtube.com/watch?v=93NhXMuUDJo&t=25s) So for years, when we said Android development, most of us really pictured just like a mobile device, but the Android ecosystem has expanded far beyond just smartphones. [00:34](https://www.youtube.com/watch?v=93NhXMuUDJo&t=34s) So today, your users are interacting with apps in their living rooms on Android TV, maybe in the carpool line or while they're charging their cars on Android Auto or Automotive OS, on their wrists with Wear OS, and increasingly in immersive 3D spaces with Android XR. [00:52](https://www.youtube.com/watch?v=93NhXMuUDJo&t=52s) This is a massive opportunity for growth, but expanding to these form factors means there are just a few marginal considerations to take into account for your publishing strategy. [01:01](https://www.youtube.com/watch?v=93NhXMuUDJo&t=61s) The overall process from building your app to having it published and live on Google Play remains generally the same as you're used to for mobile releases. [01:10](https://www.youtube.com/watch?v=93NhXMuUDJo&t=70s) Build and prepare your app, then create your listing in Play Console, test your app, upload and submit your production release, and then wait for review and approval. [01:20](https://www.youtube.com/watch?v=93NhXMuUDJo&t=80s) However, there are some unique considerations for publishing apps for form factors beyond mobile. [01:26](https://www.youtube.com/watch?v=93NhXMuUDJo&t=86s) And today, we're going to give you a clear framework to help you prepare for a smoother, more predictable multi-device release process. [01:34](https://www.youtube.com/watch?v=93NhXMuUDJo&t=94s) Let's start with the foundation: how to architect and package your app. ### App architecture and packaging [01:40](https://www.youtube.com/watch?v=93NhXMuUDJo&t=100s) So before you even touch Google Play Console, you have an important architectural decision to make. [01:44](https://www.youtube.com/watch?v=93NhXMuUDJo&t=104s) Do you build a single, unified app bundle containing everything for all the form factors you support, or do you break your app into form factor-specific modules and generate Android App Bundles, or AABs, for each? [01:57](https://www.youtube.com/watch?v=93NhXMuUDJo&t=117s) So when I'm saying modules or modularization, what I'm referring to is just a means of structuring your codebase in a way that improves maintainability. [02:05](https://www.youtube.com/watch?v=93NhXMuUDJo&t=125s) There are many approaches to modularization, but, in general, what you're doing is, organizing your codebase into loosely coupled, self-contained parts, where each part is a module. [02:16](https://www.youtube.com/watch?v=93NhXMuUDJo&t=136s) So while a unified Android app bundle approach might sound simpler to manage, we actually recommend the modular approach. [02:23](https://www.youtube.com/watch?v=93NhXMuUDJo&t=143s) So here's an example that demonstrates why we recommend this modular approach. [02:28](https://www.youtube.com/watch?v=93NhXMuUDJo&t=148s) So let's imagine you have an app that supports both mobile and Android TV. [02:33](https://www.youtube.com/watch?v=93NhXMuUDJo&t=153s) If you submit a single Android app bundle on the standard mobile release track and your Android TV app fails a review check, it halts the entire release. [02:43](https://www.youtube.com/watch?v=93NhXMuUDJo&t=163s) So that's going to impact both the release of your Android TV app and your mobile app. [02:47](https://www.youtube.com/watch?v=93NhXMuUDJo&t=167s) So even though there wasn't an issue with your mobile app specifically, you'll need to address the issues that caused that Android TV review to fail and resubmit your app for review before the release can be made available to your users. [03:01](https://www.youtube.com/watch?v=93NhXMuUDJo&t=181s) Now on the other hand, modular Android app bundles for each form factor will give you more granular control and help you isolate those form factor releases from your mobile releases. [03:12](https://www.youtube.com/watch?v=93NhXMuUDJo&t=192s) So instead, if you have separate app modules for your mobile app and your TV app, you can generate separate Android app bundles for each. [03:20](https://www.youtube.com/watch?v=93NhXMuUDJo&t=200s) And then if there's an issue with the review for your TV app, then only that app's release is going to be blocked until you can resolve the issue. [03:30](https://www.youtube.com/watch?v=93NhXMuUDJo&t=210s) The mobile app's release will be published as intended. [03:35](https://www.youtube.com/watch?v=93NhXMuUDJo&t=215s) Now as I mentioned earlier, there are many approaches to modularization. [03:39](https://www.youtube.com/watch?v=93NhXMuUDJo&t=219s) So here's just one example of an approach for modularizing an audiobook app that has a mobile experience and an Android Automotive OS experience. [03:48](https://www.youtube.com/watch?v=93NhXMuUDJo&t=228s) So up at the top, in green, we have an app module for each form factor, and this helps separate out the platform-specific dependencies. [03:56](https://www.youtube.com/watch?v=93NhXMuUDJo&t=236s) Then in yellow, we have feature modules, and those correspond to isolated parts of the app's functionality. [04:02](https://www.youtube.com/watch?v=93NhXMuUDJo&t=242s) The data modules are in blue, and then at the bottom, we have core, or common, modules, which are usually used, to contain code that other modules use frequently. [04:12](https://www.youtube.com/watch?v=93NhXMuUDJo&t=252s) And then in your project's Gradle settings files, you can include, set up this multi-module Gradle configuration to support this kind of modularization. ```kts ... 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") ``` [04:20](https://www.youtube.com/watch?v=93NhXMuUDJo&t=260s) So you'll keep using the same package name or application ID for each app module and bundle. ### Track strategy in Google Play Console [04:28](https://www.youtube.com/watch?v=93NhXMuUDJo&t=268s) That modular approach ties directly into your track strategy in Play Console. [04:33](https://www.youtube.com/watch?v=93NhXMuUDJo&t=273s) When you publish, you have the standard mobile track, but we also offer dedicated form factor tracks. [04:40](https://www.youtube.com/watch?v=93NhXMuUDJo&t=280s) For Android TV, Android XR, and Android Automotive OS, you have a choice. [04:46](https://www.youtube.com/watch?v=93NhXMuUDJo&t=286s) You can publish alongside mobile or use their dedicated form factor tracks. [04:51](https://www.youtube.com/watch?v=93NhXMuUDJo&t=291s) However, there are two exceptions. [04:54](https://www.youtube.com/watch?v=93NhXMuUDJo&t=294s) For Wear OS, you must use the dedicated Wear OS track. [04:58](https://www.youtube.com/watch?v=93NhXMuUDJo&t=298s) And for Android Auto, because it is fundamentally an extension of your mobile app projected onto the car screen, the only choice is the standard mobile track. [05:09](https://www.youtube.com/watch?v=93NhXMuUDJo&t=309s) If you're managing multiple tracks, versioning is critical. [05:13](https://www.youtube.com/watch?v=93NhXMuUDJo&t=313s) One approach is to assign the first couple of digits of your version code to the form factor. [05:18](https://www.youtube.com/watch?v=93NhXMuUDJo&t=318s) For example, 01 for mobile, 02 for Wear OS, 03 for Android Automotive OS, and so on. [05:27](https://www.youtube.com/watch?v=93NhXMuUDJo&t=327s) We generally recommend you make the version codes at least seven digits in length, so those remaining digits can be used for the app version. [05:37](https://www.youtube.com/watch?v=93NhXMuUDJo&t=337s) This helps prevent version code collisions in Play Console. [05:42](https://www.youtube.com/watch?v=93NhXMuUDJo&t=342s) Once your app is packaged, it's now time to test. [05:44](https://www.youtube.com/watch?v=93NhXMuUDJo&t=344s) Form-factor development requires thorough testing, and Google Play gives you three distinct channels to do this before releasing to production: internal testing, closed testing, and open testing. [06:00](https://www.youtube.com/watch?v=93NhXMuUDJo&t=360s) If you're using dedicated form-factor tracks, you can also combine these testing tracks with your form factors, giving you even more granular control over the process. [06:09](https://www.youtube.com/watch?v=93NhXMuUDJo&t=369s) For example, you could have a closed testing release for your mobile app on the standard track and a separate closed testing release for your Android TV app on the dedicated Android TV form-factor track with different sets of testers if you want to set it up that way. [06:25](https://www.youtube.com/watch?v=93NhXMuUDJo&t=385s) So, internal testing is a great starting point. [06:28](https://www.youtube.com/watch?v=93NhXMuUDJo&t=388s) It lets you quickly distribute your app to up to 100 testers, and, crucially, it does not trigger a Play review. [06:34](https://www.youtube.com/watch?v=93NhXMuUDJo&t=394s) So, this means you and your testers can install your app on devices quickly and validate the experience on emulators or a real TV, watch, or other device. [06:43](https://www.youtube.com/watch?v=93NhXMuUDJo&t=403s) And with internal tests, you'll get a unique URL that you can share with those testers. [06:49](https://www.youtube.com/watch?v=93NhXMuUDJo&t=409s) Once you're happy with the results of your internal testing, you can move to closed testing and open testing. [06:55](https://www.youtube.com/watch?v=93NhXMuUDJo&t=415s) You can expand beyond internal testing with a closed testing release, which lets you test pre-release versions of your app with a wider set of testers to get targeted feedback. [07:07](https://www.youtube.com/watch?v=93NhXMuUDJo&t=427s) You can manage your closed testing groups either as lists of email addresses or through Google Groups. [07:13](https://www.youtube.com/watch?v=93NhXMuUDJo&t=433s) Open testing, on the other hand, helps you run a test with a larger group on Google Play. [07:18](https://www.youtube.com/watch?v=93NhXMuUDJo&t=438s) You will be visible on Google Play, and anyone can join the open testing program. [07:24](https://www.youtube.com/watch?v=93NhXMuUDJo&t=444s) No invitation is needed, and they'll be able to share feedback, private feedback with you about the app. [07:31](https://www.youtube.com/watch?v=93NhXMuUDJo&t=451s) These open and closed testing tracks do trigger reviews. [07:34](https://www.youtube.com/watch?v=93NhXMuUDJo&t=454s) This is actually a massive advantage. [07:37](https://www.youtube.com/watch?v=93NhXMuUDJo&t=457s) It allows you to test the review process itself and clear any hurdles well before your highly anticipated launch day. ### App quality and review process [07:45](https://www.youtube.com/watch?v=93NhXMuUDJo&t=465s) So, speaking of the review process, let's talk a little bit about what the process entails and why it's important. [07:50](https://www.youtube.com/watch?v=93NhXMuUDJo&t=470s) At the heart of it, these policies and guidelines are all about app quality. [07:55](https://www.youtube.com/watch?v=93NhXMuUDJo&t=475s) So, high-quality apps and games deliver value to users, are delightful to use, make the most of premium devices, and are designed for safety. [08:03](https://www.youtube.com/watch?v=93NhXMuUDJo&t=483s) So, let's look at how you can prepare your app to pass the reviews as easily as possible. [08:09](https://www.youtube.com/watch?v=93NhXMuUDJo&t=489s) I think the best place to start is by looking at the App Quality guidelines that focus on what a great user experience looks like. [08:16](https://www.youtube.com/watch?v=93NhXMuUDJo&t=496s) We publish Core App Quality guidelines that apply to all apps and define the minimum quality that all apps should meet, as well as adaptive App Quality guidelines, and these are going to help you ensure that your app provides a great experience regardless of device form factor, screen size, or display mode. [08:33](https://www.youtube.com/watch?v=93NhXMuUDJo&t=513s) These two sets of guidelines together are a really good place to start. [08:37](https://www.youtube.com/watch?v=93NhXMuUDJo&t=517s) But we also have form-factor-specific App Quality guidelines for each of the form factors. [08:43](https://www.youtube.com/watch?v=93NhXMuUDJo&t=523s) Our reviewers are going to test your apps on real devices and emulators against these guidelines. [08:47](https://www.youtube.com/watch?v=93NhXMuUDJo&t=527s) So, it's really important to be sure your app adheres to them. [08:51](https://www.youtube.com/watch?v=93NhXMuUDJo&t=531s) So, here's a quick look at the most common reasons, coming up, that apps get rejected for each form factor. [08:57](https://www.youtube.com/watch?v=93NhXMuUDJo&t=537s) But keep in mind, these are not going to cover an exhaustive list of all the App Quality guidelines. [09:02](https://www.youtube.com/watch?v=93NhXMuUDJo&t=542s) So, be sure to view those quality guidelines for each form factor you work with in detail for the more robust set of criteria. ### Android TV app quality guidelines [09:10](https://www.youtube.com/watch?v=93NhXMuUDJo&t=550s) So, let's start with Android TV. [09:12](https://www.youtube.com/watch?v=93NhXMuUDJo&t=552s) So, at the bottom of these section slides, you'll see a short link that will take you to the full list of App Quality guidelines for that form factor. [09:20](https://www.youtube.com/watch?v=93NhXMuUDJo&t=560s) One common reason that Android TV apps are rejected is if they're missing a home screen banner image for each language that the app supports. [09:29](https://www.youtube.com/watch?v=93NhXMuUDJo&t=569s) So, what you should do is provide a 320 by 180 pixel image that includes localized text that identifies your app. [09:36](https://www.youtube.com/watch?v=93NhXMuUDJo&t=576s) The image on this slide shows an example of a home screen banner that does adhere to those criteria. [09:43](https://www.youtube.com/watch?v=93NhXMuUDJo&t=583s) Second, on most TVs, users are going to interact with the device using a D-pad remote. [09:49](https://www.youtube.com/watch?v=93NhXMuUDJo&t=589s) So, it's really critical that you properly support D-pad navigation and focus. [09:54](https://www.youtube.com/watch?v=93NhXMuUDJo&t=594s) Be sure that you're supporting at least the minimum D-pad controls to avoid any rejections based on those criteria. [10:02](https://www.youtube.com/watch?v=93NhXMuUDJo&t=602s) And then the third common reason for Android TV app rejections is if you're missing the `CATEGORY_LEANBACK_LAUNCHER` intent filter in your Android manifest file. ```xml ... ``` [10:10](https://www.youtube.com/watch?v=93NhXMuUDJo&t=610s) This filter is going to identify your app as being enabled for TV, and lets Google Play also identify it as a TV app to users. [10:18](https://www.youtube.com/watch?v=93NhXMuUDJo&t=618s) So then when a user selects your app on their TV home screen, this intent is what identifies which activity to launch. [10:24](https://www.youtube.com/watch?v=93NhXMuUDJo&t=624s) So make sure you've included it in your manifest. [10:28](https://www.youtube.com/watch?v=93NhXMuUDJo&t=628s) Android XR is next. [10:31](https://www.youtube.com/watch?v=93NhXMuUDJo&t=631s) When you're building for XR headsets or XR glasses powered by Android XR, pay particular attention to performance, rendering, and stability for your apps. [10:40](https://www.youtube.com/watch?v=93NhXMuUDJo&t=640s) You can use Perfetto to profile performance of apps that are built with the Jetpack XR SDK to help ensure you're adhering to the minimum frame rate requirements. [10:49](https://www.youtube.com/watch?v=93NhXMuUDJo&t=649s) And if you're building using a real-time engine like Unity, you can use that engine's built-in profiling tools that are built in within the engine to make sure that you're conforming to the rendering requirements. ### Guidelines for Android Auto and Android Automotive OS [11:02](https://www.youtube.com/watch?v=93NhXMuUDJo&t=662s) Next we have cars, which consists of both Android Auto and Android Automotive OS. [11:09](https://www.youtube.com/watch?v=93NhXMuUDJo&t=669s) For Android Auto and Android Automotive OS, there's a notion of categories, which are a little bit unique to this particular form factor. [11:15](https://www.youtube.com/watch?v=93NhXMuUDJo&t=675s) And only certain categories of apps are allowed to be published to cars. [11:19](https://www.youtube.com/watch?v=93NhXMuUDJo&t=679s) So if you submit an app to a category that doesn't align to one of the ones that we support, or if you submit an app to open testing or production for a category that's only in beta, that's going to result in a rejection. [11:32](https://www.youtube.com/watch?v=93NhXMuUDJo&t=692s) So let me show you what I mean in more detail. [11:35](https://www.youtube.com/watch?v=93NhXMuUDJo&t=695s) Up here, you can see an overview of the categories of apps that are supported on cars for each platform, along with their availability. [11:43](https://www.youtube.com/watch?v=93NhXMuUDJo&t=703s) So whether it's in beta, open, which means generally available, or not yet supported, which is indicated here by coming soon. [11:51](https://www.youtube.com/watch?v=93NhXMuUDJo&t=711s) So some categories like navigation or point of interest apps are generally available, and that means anyone can publish an app in one of those categories to production for cars. [12:01](https://www.youtube.com/watch?v=93NhXMuUDJo&t=721s) But other categories like communication calling apps for Android Auto are in beta. [12:06](https://www.youtube.com/watch?v=93NhXMuUDJo&t=726s) So for those categories, you can publish to internal testing or a closed testing track, but you cannot publish to production unless you've been accepted into one of our early access programs for that category. [12:19](https://www.youtube.com/watch?v=93NhXMuUDJo&t=739s) And you can find out more details about that and more in our Android for Cars developer guides. [12:23](https://www.youtube.com/watch?v=93NhXMuUDJo&t=743s) That's where you can find links to nominate yourself for those early access programs. [12:29](https://www.youtube.com/watch?v=93NhXMuUDJo&t=749s) Missing or incorrect specs for Android Automotive OS screenshots are another common reason that we see apps being rejected. [12:36](https://www.youtube.com/watch?v=93NhXMuUDJo&t=756s) So when you supply Android Automotive OS screenshots, you need to make sure you're including at least two portrait orientation screenshots, and at least two landscape orientation screenshots with the dimensions listed here. [12:48](https://www.youtube.com/watch?v=93NhXMuUDJo&t=768s) And you can use the Android Automotive OS emulator to help you capture these. [12:52](https://www.youtube.com/watch?v=93NhXMuUDJo&t=772s) That is set up in a way that it can capture just the right size of screenshots that you need. [12:58](https://www.youtube.com/watch?v=93NhXMuUDJo&t=778s) And then finally, safety is paramount with apps for cars. [13:01](https://www.youtube.com/watch?v=93NhXMuUDJo&t=781s) So if your app doesn't adhere to our driver distraction guidelines, it will be rejected. [13:06](https://www.youtube.com/watch?v=93NhXMuUDJo&t=786s) A video app, for example, must pause playback, and can't be visible while the vehicle is in motion. ### Wear OS app quality guidelines [13:13](https://www.youtube.com/watch?v=93NhXMuUDJo&t=793s) And last, but not least, we have Wear OS. [13:17](https://www.youtube.com/watch?v=93NhXMuUDJo&t=797s) So Wear OS apps can be rejected if they're not optimized and formatted for small, round displays. [13:22](https://www.youtube.com/watch?v=93NhXMuUDJo&t=802s) So what we recommend here is using the latest stable version of Compose for Wear OS to make sure that content isn't going to be cut off at the edges on different size devices, or, for example, to make sure that the scroll bar appears when there's scrollable content. ```kotlin @Composable fun MyText() { Text( text = stringResource(R.string.compose_for_wear_os), modifier = Modifier.fillMaxWidth(), textAlign = TextAlign.Center, style = MaterialTheme.typography.titleLarge ) } ``` [13:36](https://www.youtube.com/watch?v=93NhXMuUDJo&t=816s) And similar to what we mentioned for Android Automotive OS, Wear OS apps can also be rejected for missing or inaccurate Wear OS screenshots. [13:45](https://www.youtube.com/watch?v=93NhXMuUDJo&t=825s) So here's an example, a good example of a screenshot from the Google Play Store listing for the Androidify sample app, and this does meet the requirements. [13:55](https://www.youtube.com/watch?v=93NhXMuUDJo&t=835s) So make sure you submit at least one screenshot that shows your app running on a Wear OS device. ### Crucial tips for app submission [14:02](https://www.youtube.com/watch?v=93NhXMuUDJo&t=842s) The takeaway? [14:04](https://www.youtube.com/watch?v=93NhXMuUDJo&t=844s) Read the app quality guidelines for your specific form factor and test against them before you submit. [14:10](https://www.youtube.com/watch?v=93NhXMuUDJo&t=850s) Also, a few crucial tips. [14:12](https://www.youtube.com/watch?v=93NhXMuUDJo&t=852s) If your app requires a login, you must provide an active demo account and valid credentials in the app access section of Play Console. [14:21](https://www.youtube.com/watch?v=93NhXMuUDJo&t=861s) If our reviewers can't log in, we can't test your app and you'll be rejected automatically. [14:27](https://www.youtube.com/watch?v=93NhXMuUDJo&t=867s) Also, be sure to deliver what you promise. [14:30](https://www.youtube.com/watch?v=93NhXMuUDJo&t=870s) Don't just use mobile screenshots. [14:32](https://www.youtube.com/watch?v=93NhXMuUDJo&t=872s) If your app is available for Wear OS and Android TV, make sure you upload high-quality screenshots for those specific form factors in Play Console. [14:42](https://www.youtube.com/watch?v=93NhXMuUDJo&t=882s) And last but not least, be descriptive. [14:45](https://www.youtube.com/watch?v=93NhXMuUDJo&t=885s) Tell users exactly what the app does, why it's valuable, and what users can expect when they install it on each type of device. ### Conclusion and summary [14:54](https://www.youtube.com/watch?v=93NhXMuUDJo&t=894s) So to wrap things up, reaching users nearly everywhere they go is an incredible opportunity, and by architecting modularly, leveraging internal testing for fast iteration, designing against the form factor quality guidelines, and optimizing your store listings, that will help prepare your app for a smoother launch and review process. [15:15](https://www.youtube.com/watch?v=93NhXMuUDJo&t=915s) Thank you all so much for your time today. [15:17](https://www.youtube.com/watch?v=93NhXMuUDJo&t=917s) We can't wait to see the amazing multi-device experiences you will all bring to Google Play.