Posted by Manuel Vicente Vivo, Android Developer Relations Engineer
Contributors: Mauricio Vergara, Product Marketing Manager, Developer Marketing, Marialaura Garcia, Associate Product Marketing Manager, Developer Marketing
Headspace was ready to launch new wellness and fitness features, but their app architecture wasn’t. They spent eight months refactoring to a Model-View-ViewModel architecture, rewriting in Kotlin and improving test coverage from 15 to 80%. The improved app experience increased MAU by 15% and increased review scores from 3.5 to 4.7 between Q2 and Q4 of 2020. To learn more about how Headspace’s focus on Android Excellence impacted their business, read the accompanying case study here.
Headspace has grown into a leader in mindfulness by creating an app which helps millions of people to meditate daily. Mindfulness goes far beyond meditation, it connects to all aspects of a person’s life. That idea prompted the most recent stage in Headspace’s evolution. In 2019, they decided to expand beyond meditation and add new fitness and wellness features to their Android app. Headspace realized that they would need a cross-functional team of engineers and designers to be able to deliver on the new product vision and create an excellent app experience for users. An exciting new phase for the company: their design team started the process by creating prototypes for the new experience, with fresh new designs.
With designs in hand, the only thing stopping Headspace from expanding their app and broadening users’ horizons was their existing Android software architecture. It wasn’t well structured to support all these new features. Headspace’s development team made the case to their leadership that building on the existing code would take longer than a complete rewrite. After sharing the vision and getting everyone on board, the team set out on a collective journey to write a new Android app in pursuit of app excellence.
Headspace’s Android development team first needed a convenient way to standardize how they built and implemented features. "Before we wrote a single line of code, our team spent a week evaluating some important implementation choices for the foundation of our app,” Aram Sheroyan, an Android developer at Headspace explains;
“This was crucial pre-work so that we were all on the same page when we actually started to build."
Immersing themselves in Google’s literature on the latest, best practices for Android development and app architecture, the team found a solution they could all confidently agree on. Google recommended refactoring their app using a new base architecture: model-view-view-model. MVVM is a widely-supported software pattern that is progressively becoming industry standard because it allows developers to create a clear separation of concerns, helping streamline an app’s architecture. “It allowed us to nicely separate our view logic," Sheroyan explained.
With MVVM as the base architecture, they identified Android’s Jetpack libraries, including Dagger and Hilt for dependency injection. The new tools made boilerplate code smaller and easier to structure, not to mention more predictable and efficient. Combined with MVVM, the libraries provided them with a more detailed understanding of how new features should be implemented. The team was also able to improve quality in passing arguments between functions. The app had previously suffered from crashes due to NullPointerException errors and incorrect arguments. Adopting the safeArgs library helped to eliminate errors when passing arguments.
In rewriting the app, the team further made sure to follow the Repository pattern to support a clearer separation of concerns. For example, instead of having one huge class that saves data in shared preferences, they decided that each repository’s local data source should handle the respective logic. This separation of data sources enables the team to test and reproduce business code outside of the live app for unit testing without having to change production code. Separating concerns in this way made the app more stable and the code more modular.
The team also took the opportunity to fully translate their app into the Kotlin programming language, which offered useful helper functions, sealed classes, and extension functions. Removing legacy code and replacing the mix of Java and Kotlin with pure Kotlin code decreased build time for the app. The new architecture also made it easier to write tests and allowed them to increase test coverage from around 15% to more than 80%. This resulted in faster deployments, higher quality code, and fewer crashes.
To capture the new user experience in the app’s reviews, Headspace implemented the Google Play In-App Review API. The new API allowed them to encourage all users to share reviews from within the app. The implementation increased review scores by 24%, and — as store listing reviews are tied to visibility on Google Play — helped draw attention to the app’s recent improvements.
The rewrite took eight months and with it came a new confidence in the code. Now that the codebase had 80%+ unit test coverage, they could develop and test new features with confidence rather than worries. The new architecture made this possible thanks to its improved logic separation, and a more reusable code, making it easier to plan and implement new features.
The build time for the app decreased dramatically and development velocity picked up. The team’s new clarity around best practices and architecture also reduced friction for onboarding new developers, since it was now based on Android industry standards. They could communicate more clearly with potential candidates during the interview process, as they now had a shared architectural language for discussing problem sets and potential solutions.
With velocity came faster implementation of features and an improved retention flow. They could now optimize their upsell process, which led to a 20% increase in the number of paid Android subscribers relative to other platforms where the app is published. The combination of a new app experience and the implementation of the new In-App Review API led to their review scores improving from 3.5 to 4.7 stars between Q2 and Q4 of 2020! Overall, the new focus on Android App Excellence and the improved ratings earned Headspace a 15% increase in MAU globally..
These were just a few of the payoffs from the significant investment Headspace made in app excellence. Their laser focus on quality paid off across the board, enabling them to continue to grow their community of users and lay a solid foundation for the future evolution of their app experience.
If you’re interested in getting your team on board for your own App Excellence journey, check out our condensed case study for product owners and executives linked here. To learn more about how consistent, intuitive app user experiences can grow your business, visit the App Excellence landing page.
Posted by the Android Team
The Android Dev Summit is back! In just a few weeks, join us October 27-28 to hear about the latest updates in Android development. This year’s theme is Excellent apps, across devices, and you can learn about the development tools, APIs and technology to help you be more productive and create better apps that run across billions of devices, including tablets, wearables and more.
The show kicks off at 10 AM PT on October 27 with The Android Show: a technical keynote where you’ll hear all the latest news and updates for Android developers. From there, we have over 30 sessions on a range of technical Android development topics. Plus, we’ve assembled the team that builds Android to get your burning #AskAndroid questions answered live. This year’s Android Dev Summit will be your opportunity to connect digitally with Android developers around the world.
Interested in learning more? Be sure to sign up for updates through our newsletter here.
Posted by Mike Yerou, Software Engineer, Google Play
User management is an important responsibility for businesses of all sizes. The challenge is to make sure that every team member has the right set of permissions to fulfill their responsibilities, but without overexposing unrelated business data.
Over the years, you’ve asked us for better user and permission management tools in Play Console to help you handle growth efficiently and with confidence. And with the redesigned Google Play Console, we did just that. We decluttered the interface to make it easier to find what you want, and added new features to help you manage your teams easier.
The users and permissions page has been redesigned to make it easier for admins to manage their teams.
Permission names and descriptions were rewritten to make it easier to understand what you are — and aren’t — allowing users to do. You’ll also see clearer differentiation between account and app-level permissions.
New search, filtering, and batch-editing capabilities allowed you to quickly view and act on a subset of users.
And finally, to make auditing easier, we added a CSV export functionality for users of a developer account.
New access requests
While admins generally set permissions for users, you told us it would be helpful to allow users to request permissions as they figure out what’s required for their workflow. Well, now they can. Admins will still need to approve the request, but empowering users to ask for the exact permissions they need is a significant time-saver for admins.
In Play Console, users will now see a “Request access” button next to each action that is supported but not enabled due to missing permissions. To request the permission, users need to include an explanation of their need to the admin. Admins will be notified via their Inbox and can grant the permission for the specific user and app, reject it once, or reject it permanently to prevent users misusing the feature. Currently, this function is only supported for app permissions.
Team members can now request access for specific permissions.
New permission groups
When companies reach a certain size, it’s not uncommon for more than one person to have the same role, such as project managers or designers. When that happens, admins may find themselves assigning the same set of permissions over and over again.
To save you time, we recently introduced permission groups. Admins can now create a group with a set of permissions, and when a user is added to that group, they will inherit those permissions automatically. You can even choose to have the permissions in that group expire after a certain date. Users can be in multiple groups, and these groups can have overlapping permissions. We hope you’ll be able to use permission groups to improve your own working practices and encourage greater delegation and ease of user management.
We hope these new changes help you improve admin productivity and help your team get the most out of Play Console. To learn more about managing permissions, check out our Help Center.
Posted by Peter Visontay, Software Engineer; Bessie Jiang, Software Engineer
Contributors: Inara Ramji, Software Engineer; Rodrigo Farell, Interaction Designer; James Kelly, Product Manager; Henry Chin, Program Manager.
Most users spend a lot of time on their smartphones. Whether working, playing games, or connecting with friends, people often use apps as the primary gateway for their digital lives. In order to work, apps often need to request certain permissions, but with dozens of apps on any given device, it can be tough to keep up with the permissions you’ve previously granted – especially if you haven’t used an app for an extended period of time.
In Android 11, we introduced the permission auto-reset feature. This feature helps protect user privacy by automatically resetting an app’s runtime permissions – which are permissions that display a prompt to the user when requested – if the app isn’t used for a few months. Starting in December 2021, we are expanding this to billions more devices. This feature will automatically be enabled on devices with Google Play services that are running Android 6.0 (API level 23) or higher.
The feature will be enabled by default for apps targeting Android 11 (API level 30) or higher. However, users can enable permission auto-reset manually for apps targeting API levels 23 to 29.
So what does this mean for developers?
Some apps and permissions are automatically exempted from revocation, like active Device Administrator apps used by enterprises, and permissions fixed by enterprise policy.
If needed, developers can ask the user to prevent the system from resetting their app's permissions. This is useful in situations where users expect the app to work primarily in the background, even without interacting with it. The main use cases are listed here.
If an app targets at least API 30, and asks the user to disable permission auto-reset, then developers will need to make a few simple code changes. If the app does not disable auto-reset, then no code changes are required.
Note: this API is only intended for apps whose targetSDK is API 30 or higher, because permission auto-reset only applies to these apps by default. Developers don’t need to change anything if the app‘s targetSDK is API 29 or lower.
The table below summarizes the new, cross-platform API (compared to the API published in Android 11):
Build.VERSION.SDK_INT >= Build.VERSION_CODES.R
androidx.core.content.PackageManagerCompat.getUnusedAppRestrictionsStatus()
PackageManager.isAutoRevokeWhitelisted()
Intent.ACTION_AUTO_REVOKE_PERMISSIONS
androidx.core.content.IntentCompat.createManageUnusedAppRestrictionsIntent()
This cross-platform API is part of the Jetpack Core library, and will be available in Jetpack Core v1.7.0. This API is now available in beta.
Sample logic for an app that needs the user to disable auto-reset:
val future: ListenableFuture<Int> = PackageManagerCompat.getUnusedAppRestrictionsStatus(context) future.addListener( { onResult(future.get()) }, ContextCompat.getMainExecutor(context) ) fun onResult(appRestrictionsStatus: Int) { when (appRestrictionsStatus) { // Status could not be fetched. Check logs for details. ERROR -> { } // Restrictions do not apply to your app on this device. FEATURE_NOT_AVAILABLE -> { } // Restrictions have been disabled by the user for your app. DISABLED -> { } // If the user doesn't start your app for months, its permissions // will be revoked and/or it will be hibernated. // See the API_* constants for details. API_30_BACKPORT, API_30, API_31 -> handleRestrictions(appRestrictionsStatus) } } fun handleRestrictions(appRestrictionsStatus: Int) { // If your app works primarily in the background, you can ask the user // to disable these restrictions. Check if you have already asked the // user to disable these restrictions. If not, you can show a message to // the user explaining why permission auto-reset and Hibernation should be // disabled. Tell them that they will now be redirected to a page where // they can disable these features. Intent intent = IntentCompat.createManageUnusedAppRestrictionsIntent (context, packageName) // Must use startActivityForResult(), not startActivity(), even if // you don't use the result code returned in onActivityResult(). startActivityForResult(intent, REQUEST_CODE) }
The above logic will work on Android 6.0 – Android 10 and also Android 11+ devices. It is enough to use just the new APIs; you won’t need to call the Android 11 auto-reset APIs anymore.
The new APIs are also compatible with app hibernation introduced by Android 12 (API level 31). Hibernation is a new restriction applied to unused apps. This feature is not available on OS versions before Android 12.
The getUnusedAppRestrictionsStatus() API will return API_31 if both permission auto-reset and app hibernation apply to an app.
getUnusedAppRestrictionsStatus()
API_31
Posted by Maru Ahues Bouza, Director Android Developer Relations
In our previous blog post in this series, we defined app excellence as “creating an app that provides consistent, effortless, and seamless app user experiences. It is high performing and provides a great experience, no matter the device being used.” Let’s focus on the concept of app performance — what are the features of high performing apps, and how do you achieve app excellence through strong performance?
From a user’s perspective, high-performing apps “just work.” However, the process of creating a high performing app is not always straightforward. To break things down, here are the main dimensions of high performance:
An app should be robust and reliable. It should not freeze (application not responding, or “ANR”) or crash. Before you launch your app, check out Google Play’s pre-launch report to identify potential stability issues. After deployment, pay attention to the Android Vitals page in the Google Play developer console. Specifically, ANRs are caused by threading issues. The ANR troubleshooting guide can help you diagnose and resolve any ANRs that exist in your app.
Imagine the first experience a user has of your app is…..waiting. At some point, they are going to get distracted or bored, and you have lost a new user. Your app should either load quickly or provide some sort of feedback onscreen such as a progress indicator. You can use data from Android vitals to quantify any issues you may have with start up times. Android vitals considers excessive start up times as:
However, these are relatively conservative numbers. We recommend you aim for lower. Here are some great tips on how to test start up performance.
High quality frame rendering is not just for games. Smooth visual experiences that don’t stall or act sluggish are also important for apps. At a minimum aim to render frames every 16ms to achieve 60 frames per second, but bear in mind there are devices in the market with faster refresh rates. To monitor performance as you test, use the Profile HWUI rendering option. Here are tools to help diagnose rendering issues.
As soon as a user realizes your app is draining their battery, they are going to consider uninstalling. Your app can drain battery through stuck partial wake locks, excessive wakeups, background Wifi scans, or background network usage. Use the Android Studio energy profiler combined with planned background work, to diagnose unexpected battery use. For apps that need to execute background tasks that require a guarantee that the system will run them even if the app exits, WorkManager is a battery friendly Android Jetpack library that runs deferrable, guaranteed background work when the work’s constraints are satisfied.
For both security and performance, it’s important that any Google or third-party SDKs used are up-to-date. Improvements to these SDKs, such as stability, compatibility, or security, should be available to users in a timely manner. You are responsible for the entire code base, including any third party SDKs you may utilize. For Google SDKs, consider using SDKs powered by Google Play services, when available. These SDKs are backward compatible, receive automatic updates, reduce your app package size, and make efficient use of on-device resources.
To learn more, please visit the Android app excellence webpage, where you will find case studies, practical tips, and the opportunity to sign up for our App Excellence summit..
In our next blog posts, we will talk about seamless user experiences across devices. Sign up to the Android developer newsletter here to be notified of the next installment and get news and insights from the Android team.
Posted by Jeremy Walker, Engineer
In order to help you develop high quality Wear OS apps, we have been busy updating the Android Jetpack Wear OS libraries and recently delivered the first five stable Jetpack Wear OS libraries:
The Android Jetpack Wear OS libraries contain all the familiar functionality you’ve grown used to in the old Wearable Support library, better support for Wear OS 3.0, and the features listed above (many of which are written 100% in Kotlin).
As always with Android Jetpack, the new Wear OS libraries help you follow best practices, reduce boilerplate, and create performant, glanceable experiences for your users.
The core stable libraries are available now. The Watch Face and Complications libraries are in alpha and will be released as stable later this year. Once that launches, the Wearable Support Library will officially be deprecated.
We strongly recommend you migrate the libraries within your Wear OS apps from the Wearable Support library to their AndroidX equivalents as we make them available in stable.
Note: The Android Jetpack libraries are meant to be replacements for the Wearable Support Libraries and aren't designed to be used together.
Try them out and let us know what you think!
Thank you!
Posted by Madan Ankapura, Product Manager
Today, we are releasing the beta of Android for Cars App Library version 1.1. Your Android Auto apps using features that require Car App API level 2+ like map interactivity, vehicle’s hardware data, multiple-length text, long message and sign-in templates, can now be used in cars with Android Auto 6.7+ (which were previously limited to Desktop Head Unit only).
With this announcement, we are also completing the transition to Jetpack and will no longer be accepting submissions built with the closed source library (com.google.android.libraries.car.app). If you haven’t already, we encourage you to migrate to the AndroidX library now.
com.google.android.libraries.car.app)
For the entire list of changes in beta01, please see the release notes. To start building your app for the car, check out our updated developer documentation, car quality guidelines and design guidelines.
If you’re interested in joining our Early Access Program to get access to new features early in the future, please fill out this interest form. You can get started with the Android for Cars App Library today, by visiting g.co/androidforcars.
Posted by Dave Burke, VP of Engineering
We’re just a few weeks away from the official release of Android 12! As we put the finishing touches on the new version of Android, today we’re bringing you a final Beta update to help you with testing and development. For developers, now is the time to make sure your apps are ready!
You can get Beta 5 today on your Pixel device, including on the Pixel 5a with 5G, by enrolling here for over-the-air updates. If you’re already enrolled, you’ll automatically get the update. You can also try Android 12 Beta 5 on select devices from several of our partners like Sharp. Visit the Android 12 developer site for details.
Watch for more information on the official Android 12 release coming soon!
Today’s update includes a release candidate build of Android 12 for Pixel and other devices and the Android Emulator. We reached Platform Stability at Beta 4, so all app-facing surfaces are final, including SDK and NDK APIs, app-facing system behaviors, and restrictions on non-SDK interfaces. With these and the latest fixes and optimizations, Beta 5 gives you everything you need to complete your testing.
With the official Android 12 release coming next, we’re asking all app and game developers to complete your final compatibility testing and publish your compatibility updates ahead of the final release. For SDK, library, tools, and game engine developers, it’s important to release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates.
To test your app for compatibility, just install it on a device running Android 12 Beta 5 and work through the app flows looking for any functional or UI issues. Review the Android 12 behavior changes for all apps to focus on areas where your app could be affected. Here are some of the top changes to test:
Remember to test the libraries and SDKs in your app for compatibility. If you find any SDK issues, try updating to the latest version of the SDK or reaching out to the developer for help.
Once you’ve published the compatible version of your current app, you can start the process to update your app's targetSdkVersion. Review the behavior changes for Android 12 apps and use the compatibility framework to help detect issues quickly.
Android 12 has a ton of new features to help you build great experiences for users. Check out our Android 12 Beta 2 post for a recap and links to Android 12 talks at Google I/O. For complete details on all of the new features and APIs, visit the Android 12 developer site.
Also make sure to try Android Studio Arctic Fox with your Android 12 development and testing. We’ve added lint checks to help you catch where your code might be affected by Android 12 changes, such as for custom declarations of splash screens, coarse location permission for fine location usage, media formats, and high sensor sampling rate permission. You can give these a try by downloading and configuring the latest version of Android Studio.
Today’s Beta 5 release has everything you need to try the Android 12 features, test your apps, and give us feedback. Just enroll any supported Pixel device to get the update over-the-air. To get started developing, set up the Android 12 SDK.
You can also get Beta 5 on devices from several of our partners like Sharp. For even broader testing, you can try Beta 5 on Android GSI images, and if you don’t have a device, you can test on the Android Emulator. This update is also available for Android TV, so you can check out the latest TV features and test your apps on the all-new Google TV experience.
Stay tuned for the official Android 12 launch coming in the weeks ahead! Until then, feel free to continue sharing your feedback through our hotlists for platform issues, app compatibility issues, and third-party SDK issues.
A huge thank you to our developer community for helping shape the Android 12 release! You’ve given us thousands of bug reports and shared insights that have helped us adjust APIs, improve features, fix significant bugs, and in general make the platform better for users and developers.
We’re looking forward to seeing your apps on Android 12!
Posted by Ting-Yuan Huang, Software Engineer and Jiaxiang Chen, Software Engineer
Kotlin Symbol Processing (KSP), our new tool for building lightweight compiler plugins in Kotlin, is now stable! KSP offers similar functionality to the Kotlin Annotation Processing Tool (KAPT), however it’s up to 2x faster, offers direct access to Kotlin language constructs, and offers support for multiplatform targets.
Over the past few months, KSP has gone through 32 releases with over 162 bugs reported from the community and fixed by our team. If you were waiting to adopt it, now is the time to check it out.
On the Android team, we regularly ask developers: what are your biggest frustrations with writing apps today? One of the top issues that comes up repeatedly is build speed. Over the years we’ve been making steady improvements to the Android build toolchain, and today we’re excited to add to those improvements with KSP. KSP is the next generation of annotation processing in Kotlin: it will dramatically improve build speed for Kotlin developers, and unlike KAPT, it offers support for Kotlin/Native and Kotlin/JS.
"Adding KSP support to Room improved the compilation speed and also enabled Room to better understand Kotlin code, such as the nullability of generics that was not possible with KAPT. It also unlocks new possibilities like generating Kotlin code, which will allow Room to have a better Kotlin user experience in the future." - Yigit Boyar, Software Engineer, Android
The Kotlin Annotation Processing Tool (KAPT) works with Java’s annotation processing infrastructure to make most Java language annotation processors work in Kotlin out of the box. To do this, KAPT compiles Kotlin code into Java stubs that retain information that Java annotation processors care about. Creating these stubs is costly though, and means the compiler must resolve all the symbols in your program multiple times (once to generate stubs, and then again to do the actual compilation).
KSP moves away from the stub generation model by working as a Kotlin compiler plugin — it allows annotation processors to read and analyze source programs and resources directly in Kotlin instead of requiring you to depend on the Java annotation processing infrastructure. This both dramatically improves build speed (up to 2x faster for Room's Kotlin test app) and means that KSP can be used for non-Android and non-JVM environments like Kotlin/Native and Kotlin/JS.
To start using KSP, download the KSP playground project from GitHub, which shows how to use KSP both as an annotation processor and as a consuming app/library:
test-processor
workload
If you’re an app developer, check out the list of supported libraries and the quickstart guide for moving a module over from KAPT to KSP.
If you’re using Moshi or Room in your project, you can already try out KSP by making a quick fix to your module’s build file. For example, to use the KSP version of Room in a Gradle module you can simply replace the KAPT plugin with KSP and swap out the KSP dependency:
apply plugin: 'com.google.devtools.ksp' dependencies { ... implementation "androidx.room:room-runtime:$room_version" kapt "androidx.room:room-compiler:$room_version" ksp "androidx.room:room-compiler:$room_version" }
Check out the Room release notes for more info.
With the 1.0 release of KSP you will start to see improved build times for your Kotlin projects as you migrate away from libraries based on KAPT. We have also updated a number of Android specific libraries which are ready for you to try today and offer significant performance improvements.
Posted by Patricia Correa, Director, Global Developer Marketing
In June this year we opened applications for our Indie Games Accelerator, a mentorship program to help top mobile game startups achieve their full potential, as well as for our Indie Games Festival, a competition open to small game studios who get the opportunity to win promotions and be featured on Google Play. These annual programs are part of our commitment to helping all developers thrive in the Google ecosystem.
We received thousands of applications from developers across the world and we were truly amazed by the response. We’re impressed by the innovation and passion of the indie game community, and the unique and creative games they bring to players worldwide.
Last month we announced the Festival finalists and today we hosted the finals.
This year, for the first time, the events were virtual so everyone could attend. Players from around the world joined the adventure, met the finalists, played their games, and cheered on the Top 10 and the winners as they were announced on stage.
We also took the opportunity to announce the Indie Games Accelerator selected class of 2021.
Our deepest thanks to our amazing hosts: YouTube creator Papfi, Japanese comedians Kajisak and Kikuchiusotsukanai, and Inho Chung, who all shared their unique expertise and love of games.
Without further ado, here are this year's Festival winners…
Bird Alone by George Batchelor, United Kingdom
Cats in Time by Pine Studio, Croatia
Gumslinger by Itatake, Sweden
CATS & SOUP by HIDEA
Rush Hour Rally by Soen Games
The Way Home by CONCODE
Users' Choice
Animal Doll Shop by Funnyeve
Mousebusters by Odencat
Quantum Transport by ruccho
Survivor's guilt by aso
Check out the top 10 finalists in Europe, South Korea and Japan.
The selected studios will receive exclusive education and mentorship over the 12 week program, to help them build and grow successful businesses.
Americas
Aoca Game Lab, Brazil
Berimbau Game Studio, Brazil
Boomware Studio, Peru
Concrete Software, USA
Delotech Games, Brazil
DreamCraft Entertainment, Inc., USA
Ingames, Argentina
Ludare Games Group Inc., Canada
Whitethorn Games, USA
Asia Pacific
Banjiha Games, South Korea
CATS BY STUDIO, South Korea
dc1ab pte. Ltd., Singapore
Dreams & Co., Thailand
Gamestacy Entertinment, India
izzle Inc., South Korea
Koco Games, India
Limin Development and Investment Joint Stock Company, Vietnam
Mugshot Games Pty Ltd, Australia
Odencat Inc., Japan
Playbae, India
Xigma Games, India
XOGAMES Inc., South Korea
YOMI Studio, Vietnam
Europe, Middle East & Africa
Cleverside Ltd, Belarus
Dali Games, Poland
Firegecko Ltd, United Kingdom
Hot Siberians, Russia
Infinity Games, Portugal
Itatake, Sweden
Jimjum Studios, Israel
LIVA Interactive, Tunisia
Pale Blue Interactive, South Africa
Pine Studio, Croatia
Platonic Games, Spain
SMOKOKO LTD, Bulgaria
Spooky House Studios, Germany
If you missed the finals or would like to explore further, you can still sign in and wander around the space but only for a limited time. Explore now.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Marcus Leal, Senior Product Manager for Google Play Store
Our Modern Android Developer tools and APIs are designed to help you build high quality apps your users love, and this extends to form factors such as wearables. Earlier this year we announced udates to our developer tools APIs to support you in building seamless, high quality apps for your users. Today we’re announcing new guidelines to help support you in building these experiences.
We’ve started by updating our guidelines to give you a better understanding of what we expect of quality apps on Google Play, and what your users will be expecting for Wear OS 3.0. Some of the major changes are summarized below:
Many developers are already meeting these requirements and won’t need to make many of these changes when migrating to Wear OS 3.0. However, we recommend familiarizing yourself with the full updated guidelines here.
With these quality guideline updates, we’re also rolling out changes to the Play Store to improve the discoverability of Wear OS apps. In July we launched the ability for people to filter for Wear OS and Watch Faces when searching for apps within the Play Store.
We’re now releasing new screenshot requirements for Wear OS apps to help users better understand your Wear OS app’s functionality when discovering new apps. Starting October 13th, Wear OS apps will need to meet these screenshot requirements to be published on Google Play:
Similar to mobile, your store listing and the quality of your Wear OS app will influence your search ranking and opportunities for merchandising. In order to put your best foot forward on Google Play, we recommend thinking about the following considerations:
We hope this transparency helps your development process, and we look forward to seeing more seamless Wear OS experiences on Google Play. Happy Coding!
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
