Sagar Kamdar, VP of Product Management
The app experiences that you as developers build help people around the world in ways we couldn’t have imagined, and at Android Dev Summit, happening over the next two days, we’ll talk about that spirit - focusing on the user, understanding their needs, and then building experiences to delight them. We just wrapped up the keynote, and over the next two days, we’ll focus on an important theme for Android: helping you build excellent apps, across devices. First on updates to our modern Android development offering to help you stay more productive so you can focus on building great applications, and then helping you extend those apps across devices to all form factors. And as a big part of this, we’re introducing the 12L feature drop on foldables and tablets - a set of features optimising Android 12 for large screens - read on to learn more!
When it comes to helping you build excellent apps, our expanding collection of development tools, APIs, language, and distribution technologies–Modern Android Development, MAD for short–are your partners to help you stay more productive. And we’ve got a number of new features across MAD to help you be productive and create better apps, starting with one of our biggest announcements: the introduction of Material You and its radical new design vision into Jetpack Compose, Android's modern toolkit for building native UI.
Material You, introduced in Android 12 earlier this year at Google I/O, focuses on delivering experiences that are personal for every style, accessible for every need, and adaptive for every screen. We’re releasing the first alpha of Compose Material 3, which offers Material Design 3 styled components and theme, enabling Material You personalization features like dynamic color. We’re also releasing the first beta version of Jetpack Compose 1.1 with features like stretch overscroll for Android 12, improved touch-target sizing, experimental lazy layout animations, and more. Jetpack Compose is stable and ready for use in production and we continue to add the features you need to make it fast and easy to build Android UI across all form factors, with new support for Wear OS and for building homescreen widgets.
Beyond Compose, Jetpack continues to add the features you’ve been asking us for. Navigation adds multiple backstacks support. WorkManager, our recommended solution for persistent work, makes it easier to handle Android 12 background restrictions, adding support for expedited jobs. Room adds auto-migration and multi-map relations. DataStore, our recommended replacement for SharedPreferences, has reached 1.0 and Macrobenchmark, a tool to measure and improve startup and frame performance, added simplified and more accurate frame timing, and compatibility back to Android M.
We also have updates to help you build across Android form factors. Learn more about how being available across different Android devices and form factors is helping Spotify achieve their mission of connecting billions of fans with millions of creators.
Large screens have seen some incredible momentum: a 92% Year-over-Year growth in Chrome OS, making it the fastest growing desktop OS in the world, a 20% growth in tablet sales in the last year and a 2.5x growth in foldables sales, the newest and most innovate form factor…altogether those represent over 250M active large screen Android devices - and Android is giving you an OS to match. And we’ve got some… *large* news to *unfold* here: a developer preview of an upcoming feature drop for Android 12, with updates added JUST for large screens; we call it 12L. With 12L we’ve optimised and polished the system UI for large screens, made multitasking more powerful and intuitive, and improved our compatibility support for apps so they look better right out of the box. You can try the new large-screen features today as part of the 12L developer preview. Check out what is in 12L and how we’re making it easier to build for large screens here.
Many developers have created helpful experiences for the latest version of Wear OS which launched earlier this year, and we're looking forward to richer, more immersive app experiences like what we’re seeing from Strava, Spotify, and Calm. Jetpack Compose makes building UIs so much faster and easier - so we’re bringing Compose support to Wear OS. Compose for Wear OS is now in developer preview, with new samples and documentation to help you get started. The Tiles API, now in Beta, provides predictable, glanceable access to information and quick actions. We’ve also partnered with Samsung to make it easier to design watch faces. Watch Face Studio, created by Samsung, allows you to produce your own watch faces without any coding, so watch you see..is watch you get. You can read more about all of the Wear OS news here.
We’ve invested in more ways to power your business growth on Google Play. To strengthen user trust, we’ve introduced the Data safety section to highlight your privacy practices and the Play Integrity API to make sure your app installs are always genuine. We’ve also invested in more tools and features to help boost your app quality and recently updated our programs so that 99% of developers qualify for a service fee of 15% or less. To learn more, check out our blog post or watch the full session.
We just dropped over 30 technical sessions, which you can watch here at your own pace. And over the next two days, we have a lot more live content for you to enjoy - including your opportunity to get your burning #AskAndroid questions answered by the team who built Android on topics like Modern Android Development, Large Screens, or Compose with Material You. Plus, we’ll also be hosting live Android Code-Alongs, where you can tune in to watch Android experts as they code, tackle programming challenges, and answer your questions live across Jetpack Compose and Compose for Wear OS. You can check out the full agenda with timings here. While we can’t wait for the opportunity to connect with you in person soon, we’re excited to engage with you remotely over the next two days. Enjoy your #AndroidDevSummit!
Posted by Dave Burke, VP of Engineering
There are over a quarter billion large screen devices running Android across tablets, foldables, and ChromeOS devices. In just the last 12 months we’ve seen nearly 100 million new Android tablet activations–a 20% year-over-year growth, while ChromeOS, now the fastest growing desktop platform, grew by 92%. We’ve also seen Foldable devices on the rise, with year on year growth of over 265%! All told, there are over 250 million active large screen devices running Android. With all of the momentum, we’re continuing to invest in making Android an even better OS on these devices, for users and developers.
So today at Android Dev Summit, we announced a feature drop for Android 12 that is purpose-built for large screens, we’re calling it 12L, along with new APIs, tools, and guidance to make it easier to build for large screens. We also talked about changes we’re making to Google Play to help users discover your large-screen optimized apps more easily. Read on to see what’s new for large screens on Android!
Today we're bringing you a developer preview of 12L, our upcoming feature drop that makes Android 12 even better on large screens. With the preview, you can try the new large screen features, optimize your apps, and let us know your feedback.
In 12L we’ve refined the UI on large screens across notifications, quick settings, lockscreen, overview, home screen, and more. For example, on screens above 600dp, the notification shade, lockscreen, and other system surfaces use a new two-column layout to take advantage of the screen area. System apps are also optimized.
Two-column layouts show more and are easier to use
We’ve also made multitasking more powerful and intuitive - 12L includes a new taskbar on large screens that lets users instantly switch to favorite apps on the fly. The taskbar also makes split-screen mode more discoverable than ever - just drag-and-drop from the taskbar to run an app in split-screen mode. To make split-screen mode a better experience in Android 12 and later, we’re helping users by automatically enabling all apps to enter split screen mode, regardless whether the apps are resizable.
Drag and drop apps into split-screen mode
Last, we’ve improved compatibility mode with visual and stability improvements to offer a better letterboxing experience for users and help apps look better by default. We’ve made letterboxing easily customizable by device manufacturers, who can now set custom letterbox colors or treatments, adjust the position of the inset window, apply custom rounded corners, and more.
We plan to release the 12L feature drop early next year, in time for the next wave of Android 12 tablets and foldables. We’re already working with our OEM partners to bring these features to their large screen devices - watch for the developer preview of 12L coming soon to the Lenovo P12 Pro. With the features coming to devices in the few months ahead, now is a great time to optimize your apps for large screens.
For developers, we highly recommend checking out how your apps work in split screen mode with windows of various sizes. If you haven’t optimized your app yet, see how it looks in different orientations and try the new compatibility mode changes if they apply. Along with the large screen features, 12L also includes a handful of new APIs for developers, along with a new API level. We’ve been careful not to introduce any breaking changes for your apps, so we won’t require apps to target 12L to meet Google Play requirements.
To get started with 12L, download the 12L Android Emulator system images and tools from the latest preview release of Android Studio. Review the features and changes to learn about areas to test in your apps, and see preview overview for the timeline and release details. You can report issues and requests here, and as always, we appreciate your feedback!
12L is for phones, too, but since most of the new features won’t be visible on smaller screens, for now we’re keeping the focus on tablets, foldables, and ChromeOS devices. Later in the preview we plan to open up Android Beta enrollments for Pixel devices. For details, visit developer.android.com/12L.
It's time to start designing fully adaptive apps to fit any screen, and now we're making it even easier. To help you get ready for these changes in the OS and Play, along with the developer preview we're releasing updates to our APIs, tools and guidance.
The first step to supporting adaptive UI is designing your app to behave nicely on both a small and a larger screen. We’ve been working on new Material Design guidance that will help you scale your app’s UI across all screens. The guidance covers common layout patterns prevalent in the ecosystem that will help inspire and kick-start your efforts.
Adaptive UI patterns in the Material Design guidelines
To provide the best possible navigation experience to your users, you should provide a navigation UI that is tailored to the Window Size Class of the user’s device. The recommended navigation patterns include using a navigation bar for compact screens and a navigation rail for medium-width device classes and larger (600dp+). For expanded-width devices, there are several ideas on larger screen layouts within our newly released Material Design guidance such as a List/Detail structure that can be implemented, using SlidingPaneLayout. Check out our guidance on how to implement navigation for adaptive UIs in Views and Compose.
While updating the navigation pattern and using a SlidingPaneLayout is a great way to apply a large screen optimized layout to an existing application with fragments, we know many of you have applications based on multiple activities. For those apps, the new activity embedding APIs released in Jetpack WindowManager 1.0 beta 03 make it easy to support new UI paradigms, such as a TwoPane view. We’re working on updating SlidingPaneLayout to support those APIs - look for an update in the coming months.
SlidingPaneLayout
Jetpack Compose makes it easier to build for large screens and diverse layouts. If you’re starting to adopt Compose, it’s a great time to optimize for large screens along the way.
Compose is a declarative UI toolkit; all UI is described in code, and it is easy to make decisions at runtime of how it should adapt to the available size. This makes Compose especially great for developing adaptive UI, as it is very easy to handle UI changes across different screen sizes or components. The Build adaptive layouts in Compose guide covers the basics of what you need to know.
The Jetpack WindowManger library provides a backward-compatible way to work with windows in your app and build responsive UI for all devices. Here’s what’s new.
Activity embedding
Activity embedding lets you take advantage of the extra display area of large screens by showing multiple activities at once, such as for the List-Detail pattern, and it requires little or no refactoring of your app. You determine how your app displays its activities—side by side or stacked—by creating an XML configuration file or making Jetpack WindowManager API calls. The system handles the rest, determining the presentation based on the configuration you’ve created.
Activity embedding works seamlessly on foldable devices, stacking and unstacking activities as the device folds and unfolds. If your app uses multiple activities, activity embedding can enhance your user experience on large screen devices. Try the activity embedding APIs in Jetpack WindowManager 1.0 Beta 03 and later releases. More here.
Activity embedding with Jetpack WindowManager
Use Window size classes to help detect the size of your window
Window Size Classes are a set of opinionated viewport breakpoints for you to design, develop and test resizable application layouts against. The Window Size Class breakpoints have been split into three categories: compact, medium, and expanded. They have been designed specifically to balance layout simplicity with the flexibility to optimize your app for the most unique use cases, while representing a large proportion of devices in the ecosystem. The WindowSizeClass APIs will be coming soon in Jetpack WindowManager 1.1 and will make it easier to build responsive UIs. More here.
Window Size Classes in Jetpack WindowManager
Make your app fold-aware
WindowManager also provides a common API surface for different window features, like folds and hinges. When your app is fold aware, the content in the window can be adapted to avoid folds and hinges, or to take advantage of them and use them as natural separators. Learn how you can make your app fold aware in this guide.
Reference Devices
Since Android apps should be built to respond and adapt to all devices and categories, we’re introducing Reference Devices across Android Studio in many tools where you design, develop and test UI and layout. The four reference devices represent phones, large foldable inner displays, tablets, and desktops. We’ve designed these after analyzing market data to represent either popular devices or rapidly growing segments. They also enable you to ensure your app works across popular breakpoint combinations with the new WindowSizeClass breakpoints, to ensure your app covers as many use cases as possible.
Reference Device definitions
Layout validation
If you’re not sure where to get started adapting your UI for large screens, the first thing you can do is use new tools to identify potential issues impacting large screen devices. In Android Studio Chipmunk, we’re working on a new visual linting tool to proactively surface UI warnings and suggestions in Layout Validation, including which reference devices are impacted.
Layout validation tool with Reference Device classes
Resizable emulator
To test your app at runtime, we can use the new resizable emulator configuration that comes with Android Studio Chipmunk. The resizable emulator lets you quickly toggle between the four reference devices - phone, foldable, tablet, and desktop. This makes it easier to validate your layout at design time and test the behavior at runtime, both using the same reference devices. To create a new Resizable emulator, use the Device Manager in Android Studio to create a new Virtual Device and select the Resizable device definition with the Android 12L (Sv2) system image.
Resizable Android Emulator
To make it easier for people to find the best app experiences on their tablets, foldables, and ChromeOS devices, we're making changes in Play to highlight apps that are optimized for their devices.
We’re adding new checks to assess each app’s quality against our large screen app quality guidelines to ensure that we surface the best possible apps on those devices. For apps that are not optimized for large screens, we’ll start warning large screen users with a notice on the app’s Play Store listing page.
We'll also be introducing large screen specific app ratings, as announced earlier this year, so users will be able to rate how your app works on their large screen devices. These changes are coming next year, so we're giving you advanced notice to get your apps ready!
Also, make sure to check out our post that highlights how we are evolving our business model to address developer needs in Google Play.
To help you get started with building for large screens and foldables, no matter whether you’re using Views or Compose, we’ve got you covered! We’re launching new and updated guidance on how to support different screen sizes both in a new and in an existing app, how to implement navigation for both Views and Compose, how to take advantage of foldable devices and more. Check them out in the large screens guides section for Views support or in the Compose guides section.
Nothing speaks louder than code - we updated the following samples to support responsive UIs:
For some hands-on work, check out our Support foldable and dual-screen devices with Jetpack WindowManager updated codelab.
Posted by Alex Musil, Director of Product, Google Play
At this year’s Android Developer Summit, we shared new features we’ve been building to help power your growth on our platform, including enhancements to trust and safety, tools to boost your app quality and improve monetization, some updates for games, and an exciting new app marketing certificate.
Watch the whole session below, or keep reading for the highlights.
We've made important changes to ensure all types of businesses can be successful on Google Play. We now have multiple programs designed to support our app ecosystem with 99% of developers qualifying for a service fee of 15% or less.
Recently, we announced that starting January 1, 2022, we’re decreasing the service fee for all subscriptions on Google Play from 30% to 15%. Additionally, we're making changes to the Play Media Experience program, where ebooks and on-demand music streaming services will now be eligible for service fees as low as 10%.
For more information about our service fees, please see our FAQs.
Earlier this year, we shared details about the upcoming Data safety section in the Play Store, which will let users know what type of data your app collects and shares and how that data is used. By giving you a way to showcase your approach to privacy and security, we’re not only building trust, we’re helping users make informed decisions about the apps they install and use.
Users will see the new Data safety section in the Play Store starting in February 2022. You have until April 2022 before your apps must have this section completed and approved, but we encourage you to fill out the required Data Safety form in Play Console now. For more information, including guidance on how to fill out the form, watch our “Get prepared for the Data safety section” session.
We regularly update our policies to make Google Play a safe and trustworthy experience. Check out our Policy Center or this PolicyBytes video for new announcements from this week. You can also join our policy webinars and send in your questions, available for multiple regions (Global, India, Japan, or Korea).
Another way that we’re protecting both you and our users is by investing in new developer tools that help you protect your apps and games from abuse and attack, so you can ensure your users have the experience you intend. The new Play Integrity API will let you determine if you’re interacting with your genuine app binary, installed by Google Play, and running on a genuine Android device that’s powered by Google Play services. If not, you can decide how best to introduce additional friction and reduce the risk to your app.
The Play Integrity API will be rolling out to all developers over the next few months. To learn more, watch our “Play Integrity API” session and express interest in early access.
We've released several updates to help you improve the performance of your app.
First, we’re making it easier for you to be alerted to and fix new issues with improvements to Android vitals. Your most recent data is now more visible to help you see issues right away, and we’ve added trends, filters, and app version information to help you identify the source of the issue quickly.
We also recently launched a new tool in Play Console called Reach and devices to help you understand which features or fixes would help you reach the most users on Google Play. By understanding your user and issue distribution, you can make better decisions about which specs to build for, where to launch, and what to test to make the biggest impact.
We’re making changes to the way users evaluate your app quality, too. One of the most important ways that users assess your app is by checking your ratings and reviews. That’s why starting in November, users on phones will start to see ratings specific to their registered country. Then, in early 2022, users will see ratings specific to the device that they’re on, including form factors such as tablets, Chromebooks, and wearables. You can preview your location-specific and device-specific ratings in Play Console now, and we encourage you to check them out so you have time to make any app quality improvements you need before the new ratings go into effect in the Play Store.
To help you better monetize your apps and games, we continue to invest in modernizing our platform, including updates to the Billing Library. Billing Library version 3, which was announced June 2020, includes new ways for users to pay, subscription promotion capabilities, purchase attribution for games, and improvements to purchase reliability and security. As a reminder, all updates to existing apps must use Billing Library version 3 or newer by November 1, 2021. Learn more about updating to Billing Library version 3 or newer — which requires few updates to your code — in the release notes.
We’re also excited to announce a new feature in the Billing Library: in-app messaging. Today, subscription users who go into payment decline often aren’t aware of it, or experience too much friction to fix their payment. That’s why we’ve launched a new API that can detect whether a user is in payment decline and show a helpful message right in your app, so the user can immediately fix the payment without leaving the app to go to the Play Store. Best of all, the integration is super easy — just a single line of code. On average, our early-access partners saw a 99% improvement in subscription recovery and spend for users who saw the message. In-app messaging will be available in the next Billing Library release, so stay tuned for more information.
The updated sign-in API for Play Games Services, which drastically simplifies the sign-in implementation, is now in early access. The new SDK makes for a one-line implementation.
We’ve also simplified the setup for users, combining the Google Play Games install and profile creation in one step. This allows users to get back to their game more quickly, even when they don’t have Play Games installed. We’re also streamlining the process of opting in to auto-sign-in for an even smoother experience for returning users.
But that’s not all. Because needing to have the Google Play Games app installed is creating friction for some users, starting in 2022, Play Games Services will no longer require this installation. This change will allow 2 billion users to sign in to your Play Games Services-enabled games with a zero-touch experience. More details are coming soon. You can express your interest in the early access program on our developer site.
Last but not least, we also announced the launch of the Google Play Store Listing Certificate. This new program is designed to help app marketers demonstrate their proficiency and skills in Play Store listing best practices.
To get certified, app marketers can take online training that will help you best tell your app or game’s story on Google Play. You’ll learn key skills that will help you drive growth through high-quality and policy-compliant store listings. After the training, take the exam to get an industry-recognized certificate.
We hope you take advantage of all these new features and programs to grow your businesses on Google Play. Please continue sharing your feedback so we can build the tools you need to power your growth. Thank you for being part of the Google Play community.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Eric McCleve, Google Play Academy Programs Lead
At Google Play, our goal is to help developers and marketers reach and resonate with over 2 Billion users who visit our platform every month looking for high quality content and services. Having a great store listing experience can be a huge benefit in helping achieve user acquisition goals for your app or game.
To help you get the most out of our store listing tools and features, we’re excited to announce a new Store Listing Certificate on Google Play Academy. The certificate is designed for both learners who have an app or game on Google Play and want to improve its store listing, or aspiring app makers who want to build in-demand mobile marketing skills. The training and exam cover:
Watch this video to learn more about the training and exam certificate
To get certified, you can take online training on Google Play Academy and learn best practices to help you best tell your app or game’s story. You’ll learn key skills that will help you drive growth through high-quality and policy-compliant store listings. After the training, take the exam to get an industry-recognized certificate. You will also be invited to join Google Developer Certification Directory, a network of Google certified developers.
Mohamed Kamara, founder of InovCares, a health startup that modernizes healthcare for women, learned app store listing best practices from Google Play Academy.
Hear Mo explain how Google Play Academy’s training helped him better tell his app’s story on Google Play
Start training and get certified. Happy learning!
Posted by Don Turner, Developer Relations Engineer
Today, we're launching the first alpha of Jetpack Media3. It's a collection of support libraries for media playback, including ExoPlayer. This article will explain why we created Media3, what it contains, and how it can simplify your app architecture.
We have several existing media APIs: Jetpack Media also known as MediaCompat, Jetpack Media2, and ExoPlayer. These libraries were developed with different goals, and have several areas of overlapping functionality.
For example, ExoPlayer and Media2 both contain UI components, and MediaCompat and Media2 contain classes for handling media sessions.
It can be challenging to decide which library to use for a given use case, and objects from different libraries are often not compatible, requiring adapters or connecting code. Media3 removes these challenges by providing a single set of libraries which work well together.
To create Media3 we:
Media3 contains many libraries. The ones most relevant for simple media playback are shown below.
Library name
Purpose
Useful classes for playback
media3-exoplayer
Objects for playing video and audio, provided by ExoPlayer.
SimpleExoPlayer for simple playback use cases
media3-ui
Views for displaying media playback controls, content, and metadata.
StyledPlayerView displays audio and video content from a Player
media3-session
Objects for creating and interacting with a media session.
MediaSession for advertising what you're playing
MediaLibraryService for advertising your content library
Our existing media APIs have a lot of objects which accept playback commands, like "play," "pause," and "skip". Identifying these "player-like" objects and ensuring that they implement a common Player interface was one of the biggest undertakings in the development of Media3.
We've updated, enhanced, and streamlined the Player interface from ExoPlayer to act as the common Player interface for Media3.
Player
Classes such as MediaController and MediaSession that previously contained references to other "player-like" objects have been updated to reference the new player.
MediaController
MediaSession
This is useful when communicating with UI components. Both ExoPlayer and MediaController now implement Player, so either one of them can be used to communicate with StyledPlayerView or other UI components.
ExoPlayer
StyledPlayerView
Diagram showing how MediaController and ExoPlayer implement the Player interface and can be used to communicate with UI components, like StyledPlayerView
Using this Player interface avoids the need for connecting components, allowing for less code and a simpler app architecture.
In particular, this makes working with media sessions easier. Instead of using the MediaSessionConnector extension, or writing your own "player to media session" connector, you can create a MediaSession using a Player, like this:
MediaSessionConnector extension
player = ExoPlayer.Builder(context).build() session = MediaSession.Builder(context, player).build()
Now your media session will automatically reflect the state of your player, and any commands sent to your media session will be automatically forwarded to your player. All that in just two lines of code!
If your app needs to expose its content library to other apps, like Android Auto, use MediaLibraryService, rather than a MediaBrowserService from MediaCompat.
MediaLibraryService
MediaBrowserService
You'll then create a MediaLibrarySession and implement a MediaLibrarySessionCallback whose methods will be called by the browsing app to obtain your content tree.
MediaLibrarySession
MediaLibrarySessionCallback
Diagram showing how MediaLibraryService can be used to expose a content library
One of the key benefits of using Jetpack libraries is API stability. If you use symbols that are part of the stable API, you generally don't need to update your code to use a new release of that library within the same major version.
In Media3, some of the most commonly used objects are marked as stable, including the Player API and media session classes.
Most of ExoPlayer's API surface is marked as unstable.
Diagram showing stable and unstable areas of the Media3 API
To use an unstable method or class you'll need to add the OptIn annotation before using it.
OptIn
@androidx.annotation.OptIn(UnstableApi::class) private fun initializeExoPlayer() { // ... }
If your project uses a lot of unstable methods it may be more convenient to add this suppression to your project-wide lint.xml.
<issue id="UnsafeOptInUsageError"> <ignore regexp='\(markerClass = androidx\.media3\.UnstableApi\.class\)'/> </issue>
Just because part of an API is marked as unstable doesn't mean that the API is unreliable or that you shouldn't use it - it's just a way of informing you that it might change in the future.
Media3 is released today in alpha and we'd love you to try it out.
One of the best ways to do this is to check out the demo app, which shows how to play video and audio, and integrate with a media session.
You can add the Media3 dependencies to your app by adding the following artifacts to your build.gradle:
build.gradle
implementation 'androidx.media3:media3-ui:1.0.0-alpha01' implementation 'androidx.media3:media3-exoplayer:1.0.0-alpha01' implementation 'androidx.media3:media3-session:1.0.0-alpha01'
If you have feedback or run into problems, please file an issue. We'd really love to hear from you.
For more information check out the “What's next for AndroidX Media and ExoPlayer” talk from Android Dev Summit 2021 and the Media3 release notes.
Posted by Jeremy Walker, Developer Relations Engineer
This year’s Android Dev Summit had many exciting announcements for Android developers, including some major updates for the Wear OS platform. At Google I/O, we announced the launch of the new Wear OS. Since then, Wear OS Powered by Samsung has launched on the Galaxy Watch4 series. Many developers such as Strava, Spotify, and Calm have already created helpful experiences for the latest version of Wear OS, and we’re looking forward to seeing what new experiences developers will help bring to the watch. To learn more and create better apps for the wrist, read more about the updates to our APIs, design tools, and the Play store.
The Jetpack Compose library simplifies and accelerates UI development, and we’re bringing Compose support to Wear OS. You can design your app with familiar UI components, adapted for the watch. These components include Material You, so you can create beautiful apps with less code.
Compose for Wear OS is now in developer preview. To learn more and get started:
Try it out and share your feedback here or join the #compose-wear channel on the Jetbrains Slack and let us know there! Make sure you do it before we finalize APIs during beta!
Watch faces are one of the most visible ways that users can express themselves on their smartwatches. Creating a watch face is a great way to showcase your brand for users on Wear OS. We’ve partnered with Samsung to provide better tools for watch face creation and make it easier to design watch faces for the Wear OS ecosystem.
Watch Face Studio is a design tool created by Samsung that allows you to produce and distribute your own watch faces without any coding. It includes includes intuitive graphics tools to allow you to easily design watch faces. You can create watch faces for your personal use, or upload them in Google Play Console to share with your users on Wear OS devices that support API level 28 and above.
We recently released a number of Android Jetpack Wear OS libraries to help you follow best practices, reduce boilerplate, and create performant, glanceable experiences for your users.
Tiles are now enabled for most devices in the market, providing predictable, glanceable access to information and quick actions. The API is now in beta, check it out!
For developers who want more fine-grain control of their watch faces (outside of Watch Face Studio), we've launched the new Jetpack Watch Face APIs beta built from the ground up in Kotlin.
The new API offers a number of new features:
This is a great time to start moving from the older Watch Face Support Library to this new version.
We’re making it easier for people to discover your Wear OS apps in the Google Play Store. Earlier this year, we enabled searching for watch faces and made it easier for people to find your apps in the Wear category. We also launched the capability for people to download apps onto their watches directly from the mobile Play Store. You can read more about these changes here.
We’ve also released updated Wear OS quality guidelines to help you meet your users’ expectations, as well as new screenshot guidelines to help your users have a better understanding of what your app will look like. To help people better understand how your app would work on their device in their location, we will be launching form factor and location specific ratings in 2022.
To learn more about developing for Wear OS, check out the developer website.
Posted by Arif Sukoco, Android Studio Engineering Manager (@GoogArif) & Jolanda Verhoef, Developer Relations Engineer (@Lojanda)
We know it can be challenging to run Android instrumented tests at scale, especially when you have a big test suite that you want to run against a variety of Android device profiles.
At I/O 2021 we first introduced Unified Test Platform or UTP. UTP allows us to build testing features for Android instrumented tests such as running instrumented tests from Android Studio through Gradle, and Gradle Managed Devices (GMD). GMD allows you to define a set of virtual devices in build.gradle, and let Gradle manage them by spinning them up before each instrumented test run, and tearing them down afterwards. In the latest version of Android Gradle Plugin 7.2.0, we are introducing more features on top of GMD to help scale tests across multiple Android virtual devices in parallel.
The first feature we are introducing is sharding on top of GMD. Sharding is a common technique used in test runners where the test runner splits up the tests into multiple groups, or shards, and runs them in parallel. With the ability to spin up multiple emulator instances in GMD, sharding is an obvious next step to make GMD a more scalable solution for large test suites.
When you enable sharding for GMD and specify the desired number of shards, it will automatically spin up that number of managed devices for you. For example, the sample below configures a Gradle Managed Devices called pixel2 in your build.gradle:
pixel2
android { testOptions { devices { pixel2 (com.android.build.api.dsl.ManagedVirtualDevice) { device = "Pixel 2" apiLevel = 30 systemImageSource = "google" abi = "x86" } } } }
Let’s say you have 4 instrumented tests in your test suite. You can pass an experimental property to Gradle to specify how many shards you want to divide your tests in. The following command splits the test run into two shards:
./gradlew -Pandroid.experimental.androidTest.numManagedDeviceShards=2 pixel2DebugAndroidTest
Invoking Gradle this way will tell GMD to spin up 2 instances of pixel2, and split the running of your 4 instrumented tests between those 2 emulated devices. In the Gradle output, you will see "Starting 2 tests on pixel2_0", and "Starting 2 tests on pixel2_1".
"Starting 2 tests on pixel2_0"
"Starting 2 tests on pixel2_1"
As seen in this example, sharding through GMD spins up multiple identical virtual devices. If you apply sharding and have more than one device defined in build.gradle, GMD will spin up multiple instances of each virtual device.
The HTML format output of your test run report will be generated in app/build/reports/androidTests/managedDevice/pixel2. This report will contain the combined test results from all the shards.
app/build/reports/androidTests/managedDevice/pixel2
You can also load the test results from each shard to Android Studio by selecting Run > Import Tests From File from the menu and loading the protobuf output files app/build/outputs/androidTest-results/managedDevice/pixel2/shard_1/test-result.pb and app/build/outputs/androidTest-results/managedDevice/pixel2/shard_2/test-result.pb.
app/build/outputs/androidTest-results/managedDevice/pixel2/shard_1/test-result.pb
app/build/outputs/androidTest-results/managedDevice/pixel2/shard_2/test-result.pb.
It’s worth remembering that when sharding your tests, there is always a tradeoff between the extra resources and time required to spin up additional emulator instances, and the savings in test running time. As such, it is more useful when you have larger test suites to run.
Also please note that currently GMD doesn’t support running tests for test-only modules yet, and there are known flakiness issues when running on cloud hosted CI servers.
When running multiple emulator instances at the same time, your limited server’s computing resources could become an issue.
One of the ways to improve this is by slimming down the Android emulator system image to create a new type of device that’s optimized for running automated tests. The Automated Test Device (ATD) system image is designed to consume less CPU and memory by removing components that normally do not affect the running of your app’s instrumented tests, such as the SystemUI, Settings app, bundled apps like Gmail, Google Maps, etc., and some other components. Please read the release notes for more information about the ATD system image.
The ATD system images have hardware rendering disabled by default. This helps with another common source of slow-running test suites. Often, when running instrumented tests on an emulator, access to the host’s GPU for graphics hardware acceleration is not available. In this case, the emulator will choose to use software graphics acceleration, which is much more CPU intensive. Nearly all functionalities still work as expected with hardware rendering off, with the notable exception of screenshots. If you need to take screenshots in your test, we recommend taking a look at the new AndroidX Test Screenshot APIs which will dynamically enable hardware rendering in order to take a screenshot. Please take a look at the examples for how to use these APIs.
To use ATD, first make sure you have downloaded the latest version of the Android emulator from the Canary channel (version 30.9.2 or newer). To download this emulator, go to Appearance & Behavior > System Settings > Updates and set the IDE updates dropdown to “Canary Channel”.
Next, you need to specify an ATD system image in your GMD configuration:
android { testOptions { devices { pixel2 (com.android.build.api.dsl.ManagedVirtualDevice) { device = "Pixel 2" apiLevel = 30 systemImageSource = "aosp-atd" // Or "google-atd" if you need // access to Google APIs abi = "x86" // Or "arm64-v8a" if you are on an Apple M1 machine } } } }
You can now run tests from the Gradle command line just like you would with GMD as before, including with sharding enabled. The only thing you need to add for now is to let Gradle know you are referring to a system image in the Canary channel.
./gradlew -Pandroid.sdk.channel=3-Pandroid.experimental.androidTest.numManagedDeviceShards=2pixel2DebugAndroidTest
Test running time improvement using ATD might vary, depending on your machine configuration. In our tests, comparing ATD and non-ATD system images running on a Linux machine with Intel Xeon CPU and 64GB of RAM, we saw 33% shorter test running time when using ATD, while on a 2020 Macbook Pro with Intel i9 processor and 32GB of RAM, we saw 55% improvement.
We’re really excited about these new features, and we hope they can allow you to better scale out your instrumented tests. Please try them out and let us know what you think! Follow us -- the Android Studio development team ‐ on Twitter and on Medium.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
