itech

Smule Adopts Google’s Oboe to Improve Recording Quality & Completion Rates

Light blue graphic with karaoke elements

Executive Summary

As the most downloaded singing app of all time, Smule Inc. has been investing on Android to improve the overall audio quality and, more specifically, to reduce latency, i.e. allowing singers to hear their voices in the headset as they perform. The teams specialized in Audio and Video allocated a significant part of 2021 into making the necessary changes to convert the Smule application used by over ten million Android users from using the OpenSL audio API to the Oboe audio library, enabling roughly a 10%+ increase in recording completion rate.

Introduction

Smule Inc. is a leader in karaoke, with an app that helps millions of people sing their favorite songs and share performances daily. The Smule application goes beyond traditional karaoke by focusing on co-creation, offering users the unique opportunity to share music and collaborate with friends, other singers on the platform, and their favorite music artists. Audio quality is paramount, and, in 2020, the Smule team saw potential to enhance the experience on Android.

Screenshots of Smule karaoke app

Smule’s legacy OpenSL implementation wasn’t well-suited to leverage the blazing-fast hardware of new devices while supporting the diverse devices across its world-wide market. Smule’s development team determined that upgrading the audio system was a necessary and a logical improvement.

Oboe Rollout Strategy

Smule was faced with two possible routes for improvement: directly targeting A Audio, a high-performance Android C audio API introduced in Android O designed for applications that require low latency, or Oboe, which wraps both AAudio and OpenSL internally. After careful evaluation, Smule’s development team opted for Oboe’s easy-to-use code base, and broad device compatibility, and robust community support, which achieved the lowest latency and made the best use of the available native audio.

The conversion to Oboe represented a significant architectural and technological evolution. As a result, Smule approached the rollout process conservatively, with a planned, gradual release that started with a small selection of device models to d validate quality. Week after week, the team enabled more devices (reverting a limited number of devices exhibiting problems in Oboe back to OpenSL). This incremental, methodical approach helped to minimize risk and allowed the engineering team to handle device-specific issues as they occurred.

Improving the Audio Quality Experience

Smule switched to Oboe to help improve the app experience. They hoped to reduce dramatically audio playback crashes, eliminate issues such as echo and crackling during recording, and reduce audio latency. A recent article in the Android Developers blog shows that the average latency of the twenty most popular devices decreased from 109 ms in 2017 to 39ms today using Oboe. Whereas a monitoring delay of 109ms is heard as a distinct echo which interferes with live singing, 39ms is beneath the acceptable threshold for real-time applications. The latencies of top devices today are all within 22ms of one another, and this consistency is a big plus.

The lift in recording completion rate Smule has seen using Oboe is likely due to this lower latency, allowing singers to hear their voices in the headset as they perform with Smule’s world-class audio effects applied, but without an echo.

Using an effective collaborative GitHub portal dedicated to Oboe, the Google team played a significant role in Smule’s Oboe integration, providing them with key insights and support. Working together, the two teams were able to launch the largest Oboe deployment to date, reaching millions of active users. The Smule team contributed to addressing some Oboe code issues, and the Google team coordinated with certain mobile device makers to further improve Oboe’s compatibility.


Audio quality is of the utmost importance to our community of singers, and we’re thankful for our shared commitment to delivering the best possible experience as well as empowering musical creation on Smule. – Eric Dumas, Smule CTO.


Given the massive scale of the operation, it was only natural to face device-specific issues. One notable example was an OS built-in functionality that injected echo sound effects in the raw audio stream, which prevented Smule from correctly applying its own patented DSP algorithms and audio filters. Google’s team came to the rescue, providing lightning fast updates and patches to the library. The process of reporting Oboe issues was straightforward, well defined, and handled in a timely manner by the Google team.

Smule overcame other device-specific roadblocks together, including errors with specific chipsets. As an example, when Oboe was asking for mono microphone input, a few devices provided stereo inputs mixed into one fake mono microphone input. Smule created a ticket in Oboe’s GitHub, providing examples and reproducing the issue using the Oboe tester app.

The Google-developed Oboe tester app was a helpful tool in solving and identifying issues throughout the implementation. It proved especially useful in testing many of the features of Oboe, AAudio, and OpenSL ES, as well as testing Android devices, measuring latency and glitches, and much more. The application offers a myriad of features that can help to simulate almost any audio setup. The Oboe tester can also be used in automated testing, by launching it from a shell script using an Android Intent. Smule relied heavily on the automation testing, given the large number of devices covered in the integration.

Once Smule was confident the device-specific issues were resolved and the Oboe audio was stable enough, Smule switched to a wider split testing rollout approach. In just a few weeks, Smule increased the population using Oboe from 10% to 100% percent of the successful devices, which was only possible due to the positive feedback and green KPI metrics Oboe received continuously throughout the release journey.

The results speak for themselves. Smule users on Oboe are singing more – it’s as simple as that. Unique karaoke recordings and performance joins, or duets, increased by a whopping 8.07%, Unique uploads by 3.84%, and song performances were completed by 4.10% more. Smule has observed in Q3 and Q4 2021 an increase of the recording completion rate by 10%+.

Using the Firebase Crashlytics tool by Google, Smule has seen a decline in audio-related crashes since the full Oboe release, making the app more stable – even on lower-end devices. Smule’s dedicated customer support team was thrilled to report a 33% reduction in audio-related complaints, including issues like (unintended) robot voice and echo.

The decision to switch to Oboe has paid off in spades. The application is functioning better than ever and Smule is well-equipped to face further advancements in audio and hardware with the updated technology. Most importantly, Smule users are happy and making music, which is what it’s all about.

Grow your game’s revenue with Google Play Console’s new strategic guidance

light blue illustration with coin bouncing

Last year, mobile game consumer spending grew 7.3% to $93.2 billion with no signs of slowing down. In this competitive, growing market, effectively monetizing your audience has never been more important. But without access to a strategy consultant, how can you know if your monetization strategy is as strong as it can be?

That’s why we’re expanding the suite of tools available in Play Console to help it be exactly that. Last year, we released new engagement and monetization metrics on the Statistics page to help you grow your business, and now we’re pleased to announce new strategic guidance tools to help you drive successful monetization.

In this new section, you’ll see our metric-driven guidance to help you better monetize your game by:

  1. Contextualizing your topline revenue: Understand how your game’s revenue metrics contribute to your overall business goals, and learn when to prioritize optimizing for one metric over another.
  2. Identifying opportunities: Find out where there is an opportunity to improve a metric by benchmarking against peer groups, and explore insights by country.
  3. Recommending next steps: Learn how to take advantage of monetization opportunities with specific actions you can take right away.
screenshot of strategic guidance for monetization webpage in Google Play Console

The strategic guidance metric hierarchy. (Learn more or visit our Play Academy for specific courses like monitoring KPIs.)

We’ve spent the last couple of years perfecting our guidance, and testing the dashboard with selected partners. Feedback on our strategic guidance has been positive — and we hope you’ll find it useful, too.

“This is extremely useful! These type of insights are actually what we expect from Google, because this is something that really can help us to scale our business.”

– Product Manager at Gameloft


Understand key monetization drivers and their relationships with the metric hierarchy

Strategic guidance can be found in Financial reports within Play Console. In partnership with experts in mobile games growth, we’ve included primary monetization metrics (including new metrics) and their relationships to help you easily assess your performance and measure against your peers. You can see all the metrics in this Help Center article.

The metric hierarchy is a tool to help you understand how you and your teams can directly influence the lower-level metrics of your games performance, like buyer conversions, which contribute to your overall top-line business performance. Using peerset comparisons and per-country breakdowns, you can quickly identify your biggest growth opportunities: what markets are underperforming and where you are a market leader.


Explore metric analysis to turn insights into action

Select a metric and explore it in detail to track your performance over time. Strategic guidance shows you a breakdown of your chosen metric by location to help you spot opportunities to expand your game globally. The detailed metric analysis also helps you identify where a small investment has an outsized return.

Strategic guidance metric recommendation example for returning daily buyer ratio.

Strategic guidance metric recommendation example for returning daily buyer ratio.

Whether you’ve created a casual game or an RPG, the metric-specific recommendations are designed to be insightful and relevant to a variety of game developers. They can be used to help you diversify your promotional content, refine your game mechanics, or test new price points that enable purchasing power parity.


Get IAP monetization guidance today, with more insights to come

With an increasing number of developers shifting focus from an ads-only monetization business model to include in-app purchases (IAP), we’ve developed strategic guidance to be most relevant for developers that include IAP-monetization as part of their overall strategy. With this launch, we’re excited to bring growth consulting opportunities to these game developers at scale. Stay tuned for more launches this year to help you successfully drive your revenue growth.

Improving App Performance with Baseline Profiles

Or how to improve startup time by up to 40%

Posted by Kateryna Semenova, DevRel Engineer; Rahul Ravikumar, Software Engineer; Chris Craik, Software Engineer

ALT TEXT GOES HERE

 

Why is startup time important?

A lot of apps find correlation between app performance and user engagement. People expect apps to be responsive and fast to load. Startup time is one of the major metrics for app performance and quality.

Some of our partners have already invested a lot of time and resources for app startup optimizations. For example, check out the Facebook story.

In this blog post we’ll discuss Baseline Profiles and how they improve app and library performance, including startup time by up to 40%. While this blogpost focuses on startup, baseline profiles also significantly improve jank as well.


History

Android 9 (API level 28) introduced ART optimizing profiles in Play Cloud to improve app startup time. On average, we’ve seen that apps’ cold starts are at least 15% faster across a variety of devices when Cloud Profiles are available.


How do Profiles work?

When the app is first launched after install or update, its code runs in an interpreted mode until it is JITted. In an APK, Java and Kotlin code is compiled as dex bytecode, but not fully compiled to machine code (since Android 6), due to the cost of storing and loading fully compiled apps. Classes and methods that are frequently used in the app, as well as those used for app startup, are recorded into a profile file. Once the device enters idle mode, ART compiles the apps based on these profiles. This speeds up subsequent app launches.

Starting with Android 9 (API level 28), Google Play also provides Cloud Profiles. When an app runs on a device, the profiles generated by ART are uploaded by the Play Store app and aggregated in the cloud. Once there are enough profiles uploaded for an application, the Play app uses the aggregated profile for subsequent installs.


Problem

While Cloud Profiles are great when they are available, they aren’t always ready to be used when an app is installed. Collecting and aggregating the profiles usually takes several days, which is a problem when many apps update on a weekly basis. Many users will install an update before the Cloud Profile is available. The Google Android team started looking for other ways to improve the latency of profiles.


Solution

Baseline Profiles are a new mechanism to provide profiles which can be used on Android 7 (API level 24) and higher. A baseline profile is an ART profile generated by the Android Gradle plugin using a human readable profile format that can be provided by apps and libraries. An example might look like this:

Example for Compose library.


The binary profile is stored in a specific location in the APK assets directory (assets/dexopt/baseline.prof).

Baseline Profiles are created during build time, shipped as part of the APK to Play, and then sent from Play to users when an app is downloaded. They fill the gap in the ART Cloud Profile pipeline, when Cloud Profiles are not yet available, and automatically merge with Cloud Profiles when they are.


This diagram displays the baseline profile workflow from creation through end-user delivery.

This diagram displays the baseline profile workflow from creation through end-user delivery.


One of the biggest benefits of Baseline Profiles is that they can be developed and evaluated locally so developers can see realistic end-user performance improvements. They are also supported on a lower version of Android(7 and higher) than Cloud Profiles, which are only available starting in Android 9.


Impact


App devs

In early 2021, Google Maps switched from a two-week to a one-week release cycle. More frequent updates meant more frequently discarding local pre-compilation, and more users experiencing slow launches without Play Cloud Profiles. By using Baseline Profiles, Google Maps improved their average startup time by 30% and saw a corresponding increase in searches by 2.4%, an immense gain for such an established app.


Library devs

Code in a library is just like that of an app – it’s not fully compiled by default, which can be a problem if it does significant work on the critical path of startup.

Jetpack Compose is a UI library that is not a part of the Android system image and thus not fully compiled when installed, unlike much of the Android View toolkit code. This was causing performance problems, especially for the first few cold launches of the app.

To solve this problem, Compose uses profile installer. It ships baseline profile rules which reduce startup time and jank in Compose apps.

Google PlayStore’s search results page has been re-written with Compose. After incorporating the Baseline Profile rules from Compose, time to render the initial search results page with images improved by ~40%.

The Android team has also added Baseline Profiles to relevant AndroidX libraries. This benefits all Android apps using these libraries. Constraint Layout has found shipping profile rules reduces animation frame times by more than one millisecond.


How to use Baseline Profiles


Create a custom Baseline Profile

All apps and library developers can benefit from including Baseline Profiles. Ideally, developers create profiles for their most critical user journeys to ensure that those journeys have consistently fast performance regardless of whether cloud profiles are available. Check out the detailed guide on how to set up Baseline Profiles for both app and library developers.


Update dependencies

If you are not ready to generate Baseline Profiles for your app right now, you can still benefit from them by updating your dependencies. If you build with Android Gradle Plugin 7.1.0-alpha05 or newer, you’ll get Baseline Profiles included in your APK that are already provided by libraries (such as Jetpack). Google Play compiles your app with these profiles at install time. You can supplement these profiles as part of building your application.


Measure Improvements

Don’t forget to measure improvements. Follow the steps on how to measure startup with the generated profile locally.


Provide feedback

Please share your feedback and let us know your experience!

Building apps for Android Automotive OS

Today we’re announcing the availability of version 1.2 beta of the Car App Library, enabling app developers to start building their navigation, parking, and charging apps for Android Automotive OS.

Now, developers can begin building and testing apps for these categories using the Automotive OS emulator across both Android Automotive OS and Android Auto. For the entire list of changes in v1.2 beta, 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.

As announced earlier, drivers of Polestar 2 and Volvo cars can now download charging (ChargePoint, PlugShare), parking (Spothero, Parkwhiz), and navigation (Flitsmeister, Sygic) apps developed with the Car App Library by joining the Google Group and opting-in to each app’s beta on the Google Play store, with your Gmail account.

Car App Library apps on Android Automotive OS are automatically rendered to be consistent with the rest of the experience within each car, without additional work needed from developers.. For example,

Polestar 2
Volvo
Polestar 2 setting with labeled On / Off switches for PlugShare

 

Polestar 2 setting with labeled On / Off switches for PlugShare

 

Volvo settings with sliding switches for PlugShare

 

Volvo settings with sliding switches for PlugShare

 

Polestar 2 sign-in screen for SpotHero

 

Polestar 2 sign-in screen for SpotHero

 

Volvo sign-in screen for SpotHero

 

Volvo sign-in screen for SpotHero

 

Example of app customization on Android Automotive OS

Experience for yourself how your app will look within the different systems, by accessing the OEM emulator system images downloadable in Android Studio. You can begin developing your charging, parking and navigation apps for Android Automotive OS today, and we are working to enable you to publish your apps to the Google Play store in the coming months (stay tuned!).

Beyond navigation, rideshare drivers spend a lot of time in their vehicles and will benefit from safer interactions if those apps can be brought to the car’s screen. We are working with Lyft and Kakao Mobility to bring their driver app experiences into the car in the coming months.

image of car screen with gps map and Lyft logo

We are also pleased to announce that we are expanding support to all Points of Interest apps. Beyond charging and parking, this allows any app that will help users discover and search for interesting locations on a map, and optionally enable them to navigate to such points. We are partnering with MochiMochi, Fuelio, Prezzi Benzina, and NAVITIME JAPAN as our early access partners.

If you’re interested in joining our Early Access Program in the future, please fill out this interest form. You can get started with the Android for Cars App Library today,

Announcing Glance: Tiles for Wear OS made simple

 

Last year we announced the Wear Tiles API. To complement that Java API, we are excited to announce that support for Wear OS Tiles has been added to Glance, a new framework built on top of Jetpack Compose designed to make it easier to build for surfaces outside your app on Android. We’d love to get your feedback on this alpha version.

Tiles provide Wear OS users easy access to the information and actions they need in order to get things done quickly. They also are one of the most used surfaces on Wear OS. Just one swipe away from the Watch Face, users can quickly access the most important information or actions from an app, like start a timer or get the latest weather forecast.


Watch face gif


Let’s see how we can create a Tile with Glance:


The simple code above generates the Tile below.


“Hello Glance” Tile sample with Glance

“Hello Glance” Tile sample with Glance


Note: Using Glance-wear-tiles


How it works

Glance creates “glanceable” experiences across Android surfaces using a base-set of Composables. For Tiles on Wear OS, Glance translates Composables into Tiles.


Diagram: Glance structure 

Diagram: Glance structure


Glance requires Compose to be enabled and depends on Runtime, Graphics, and Unit UI Compose layers, but it’s not directly interoperable with other existing Jetpack Compose UI elements, like Compose for Wear OS.

What’s in the Alpha

This initial release introduces the main APIs to build wear Tiles:

We are working on bringing even more functionality with default theming, further Android Studio support, and more. Stay tuned for new releases.

Get started with Glance

For a quick start, take a look at the samples in the AndroidX repository. Glance works with the latest stable Android Studio, although since Glance relies on Compose Runtime, follow the steps on the Jetpack Compose docs to set it up first.

The Alpha version is your opportunity to influence the APIs, so please share your feedback and let us know your experience!

Android Studio Bumblebee (2021.1.1) Stable

 

 

Bumblbee Android Studio

The Android Studio team has been abuzz with the stable release of Android Studio Bumblebee (2021.1.1) 🐝 and Android Gradle plugin (AGP) 7.1.0; the latest versions of Android official IDE and build system. We’ve improved functionality across a broad area of the typical developer workflow: Build and DeployProfiling and Inspection, and Design.

Some notable additions include a unified test execution between Android Studio and your continuous integration (CI) server ✅, convenient pairing flows to support ADB over Wi-Fi 📲, Improved Profiler tools to help you identify and analyze jank in your app 🕵️, and new ways to preview animations 🎥 and UI interactions without deploying your app to a device.

As always, this release wouldn’t be possible without the early feedback from our Preview users. So read on or watch below for further highlights and new features you can find in this stable version. If you’re ready to jump in and see for yourself, head over to the official website to download Android Studio Bumblebee (2021.1.1).


What’s in Android Studio Bumblebee (2021.1.1)

Below is a full list of new features in Android Studio Bumblebee (2021.1.1), organized by the three major themes.

Build and Deploy

  • New Device Manager: This new tool window in Bumblebee makes it easier to see and manage your virtual and physical test devices, and you can open it by selecting View > Tool Windows > Device Manager from the main menu bar. In the Virtual tab, create a new device, review device details, delete a device, or anything else you used to do from the now removed AVD Manager. In the Physical tab, quickly pair to a new device using ADB Wi-Fi and see details of each physical device at a glance, or quickly inspect each device’s file system using the Device File Explorer with a click of a button. Learn more about the New Device Manager in the release notes.
Device Manager

Device Manager


  • ADB over Wi-Fi: Bumblebee includes a simplified flow to connect to your Android 11 and higher devices over Wi-Fi for deployment and debugging using ADB. After you enable debugging over Wi-Fi on your device, select the Pair using Wi-Fi action in the Physical tab of the new Device Manager to open the pairing wizard. Then follow the steps provided to pair to a device connected over the same network. Learn more.
Pairing a device with ADB over Wifi

Pairing a device with ADB over Wifi


  • Run Instrumented Tests in Android Studio using Gradle: Have you ever run tests in Android Studio with different results than the same tests running on your CI? This can be a frustrating issue that leads to lost productivity. To resolve this issue, we’ve introduced a new test runner to Android Gradle plugin (AGP) 7.1.0 that Android Studio Bumblebee uses by default when running instrumentation tests, so all your tests run through a unified test runner. This is a similar improvement to Android Studio Arctic Fox, where we started running all unit tests via Gradle by default. And, similarly, this improvement doesn’t require you to change how you write or run your tests!

Using different runners lead to inconsistent results

Using different runners lead to inconsistent results


Android Studio now runs instrumentation tests via Gradle

Android Studio now runs instrumentation tests via Gradle


  • Android Gradle Plugin Upgrade Assistant now updates API usage: Originally introduced in Android Studio 4.2, the AGP Upgrade Assistant helped users update their projects to the latest version, and improvements in Arctic Fox provided a new UI with the ability to review and select the upgrade version and steps. In Bumblebee, the Upgrade Assistant now also checks for and offers to update your DSL to help you avoid using deprecated APIs before they are deleted. For more information see the Android Gradle Plugin DSL/API migration timeline.
  • Non-Transitive R classes on for new projects: Android Studio Arctic Fox introduced new refactoring tools to help you use non-transitive R classes to enable faster builds for applications with multiple modules. When creating new projects using Bumblebee, the IDE configures your project to use non-transitive R classes, by default. While this does bring performance improvements, you now have to refer to R classes by their proper package name, and not by the package names of their parent modules, as they will no longer resolve transitively. For more information see Use non-transitive R classes.
  • Emulator tool window enabled by default: Introduced in Android Studio 4.1, the Emulator launches within an Android Studio tool window and allows you to deploy and interact with virtual Android devices while fully remaining within the context of the IDE. The changes ads an improved UX for extended controls and snapshot management. For more information see Run the Android Emulator directly in Android Studio.
  • Apple Silicon Support Update – For those using macOS on Apple Silicon (arm64) hardware, Android Studio Arctic Fox and the Android Emulator have supported this new architecture since last year. However, with this release, we have now updated the Android SDK platform tools v32.0.0 (which includes ADB and fastboot) and build tools v32.1.0 (which includes aapt) to be universal binaries so that your Android developer tools no longer need the Rosetta binary translator to run. Based on community feedback, those developers on this hardware platform have seen notable performance improvements. See release notes.


Profile and Inspect

  • Jank detection track in Profilers: When profiling your app using devices running Android 11 (API level 30) or higher, the CPU profiler now shows a new group of tracks that illustrate the stages of each frame under Frame LifecycleApplicationWait for GPUComposition and Frames on display. Each track labels the frames with a frame number and color-codes the rectangle to make it easy for you to visualize where a particular frame is in its lifecycle, along with guides you can toggle to compare with Vsync events. You can use this data to understand where Jank might occur in your app and investigate the root causes. In the Analysis panel, there is now a Frames tab, which conveniently summarizes rendering information for all frames. For more information, see UI jank detection.

Detailed frame lifecycle information in the CPU Profiler

Detailed frame lifecycle information in the CPU Profiler


  • Profileable app profiling support in Studio Profilers: When profiling your app, it’s important to generate accurate data with the version of your app that most closely resembles what your users will install. To do so, you can now include the property in your app’s manifest to profile apps that are not debuggable, as shown below.

    Profileable is a manifest configuration introduced in Android 10, and is available for CPU and Memory profiling tasks. Using the profileable flag instead of the debuggable flag has the key advantage of lower overhead for performance measurement; however, certain profiling features are not available for Profileable builds, such as the Event timeline, API initiated CPU profiling, heap dumps, or live location recordings. For more information, see Profileable applications.
  • Inspect Jobs, Alarms, and Wakelocks: The Background Task Inspector has been expanded to allow you to inspect Jobs, Alarms, and Wakelocks. You can see live information on how these background tasks are being scheduled, and see detailed information about their execution, similar to how you can inspect Workers. Additionally, when inspecting Workers, you can track and inspect Jobs that your Workers schedule for you. If you used to use the Energy Profiler in previous versions of the IDE, you should now navigate to View > Tool Windows > App Inspection from the menu bar and select the Background Task Inspector to inspect Jobs, Alarms, and Wakelocks.

Inspect Jobs, Alarms, and Wakelocks in the Background Task Inspector

Inspect Jobs, Alarms, and Wakelocks in the Background Task Inspector


  • Network Inspection: The Network Profiler has now migrated to the App Inspection tool window, to allow for a lighter-weight experience for inspecting network traffic in your app. The look and feel of the Network Profiler has been maintained and works with any debuggable app on devices running API level 26 and higher. To use the new inspector, select View > Tool Windows > App Inspection from the menu bar and select the Network Inspector. For more information, see Inspect network traffic with the Network Inspector.
  • Capture Layout Inspector snapshots: You can now capture snapshots of your app’s layout hierarchy to save, share, or inspect later. Snapshots capture the data you would typically see when using the Layout Inspector, including a detailed 3D rendering of your layout, the component tree of your View, Compose, or hybrid layout, and detailed attributes for each component of your UI. When inspecting the layout of a live running app, click Export snapshot from the Layout Inspector toolbar and save the snapshot with an  extension. You can then load a Layout Inspector snapshot by selecting File > Open from the main menu bar, and opening a file. The snapshot appears in a tab in the Editor window, so that you can easily compare it with your running app. Learn more at Capture layout hierarchy snapshots.

GIF  
  • Support for Compose semantics in the Layout Inspector: In Compose, Semantics describe your UI in an alternative manner that is understandable for Accessibility services and for the Testing framework. In Android Studio Bumblebee, you can now use the Layout Inspector to inspect semantic information in your Compose layouts. When selecting a Compose node, use the Attributes window to check whether it declares semantic information directly, merges semantics from its children, or both. To quickly identify which nodes include semantics, either declared or merged, use select the View options dropdown in the Component Tree window and select Highlight Semantics Layers.

Design

  • Interactive Preview: Android Studio Arctic Fox launched with support to statically preview your composable functions in the Design / Split window of the Editor. In Bumblebee, we’ve expanded functionality to allow you to interact with certain components of your Compose layouts, to validate behavior without building and deploying the full app to a running device! To get started, navigate to a previewable compose function and click Start Interactive Mode in the Design / Split window. For more information see Interactive mode.

Interact with the Compose Preview to validate behavior

Interact with the Compose Preview to validate behavior


  • Animated Vector Drawables Preview: The Preview window is now also available when viewing vector drawables. When viewing a static drawable, you can use the preview window to change background options between “None”, “White”, “Black”, “Checkedered”, to view your drawable against different conditions. Animated drawables also provide the option to preview the animation at different speeds as well as backgrounds, to help you test animations before using them in your app. To learn more, see Animated Vector Drawables (AVD) preview.

Preview your animated vector drawables

Preview your animated vector drawables


  • Updated Device picker for design tools: To simplify designing your app for the diverse number of Android devices, we’ve updated the device picker in various design tool windows, such as Layout Editor and Layout Validation, with reference devices that reflect popular sizes of each device form factor. From phones to tablets, and Wear devices to Android TVs, it’s now easier to preview, validate, or edit your layout on screen sizes that are most representative of popular real-world devices. To learn more, see Change the preview appearance.

ALT TEXT GOES HERE

To recap, Android Studio Bumblebee (2021.1.1) includes these new enhancements & features:

Build and Deploy
  • Run Instrumented Tests in Android Studio using Gradle
  • Android Gradle Plugin Upgrade Assistant now updates API usage
  • Non-Transitive R classes on for new projects
  • New Device Manager
  • ADB over Wi-Fi
  • Emulator tool window enabled by default
  • Apple Silicon Support Update
Profile and Inspect
  • Jank detection track in Profilers
  • Profileable app profiling support in Studio Profilers
  • Inspect Jobs, Alarms, and Wakelocks in the Background task Inspector
  • Capture Layout Inspector snapshots
  • Support for Compose semantics in the Layout Inspector
Design
  • Interactive Preview
  • Animated Vector Drawables Preview
  • Updated Device picker for design tools