Posted by Mauricio Vergara, Product Marketing Manager, with contibutions by Thousand Ant.

 

Lyft is singularly committed to app excellence. As a rideshare company — providing a vital, time-sensitive service to tens of millions of riders and hundreds of thousands of drivers — they have to be. At that scale, every slowdown, frozen frame, or crash of their app can waste thousands of users’ time. Even a minor hiccup can mean a flood of people riding with (or driving for) the competition. Luckily, Lyft’s development team keeps a close eye on their app’s performance. That’s how they first noticed a slowdown in the startup time of their drivers’ Android app.

They needed to get to the bottom of the problem quickly — figure out what it would take to resolve and then justify such an investment to their leadership. That meant answering a number of tough questions. Where was the bottleneck? How was it affecting user experience? How great a priority should it be for their team at that moment? Luckily, they had a powerful tool at their disposal that could help them find answers. With the help of Android vitals, a Google Play tool for improving app stability and performance on Android devices, they located the problem, made a case for prioritizing it to their leadership, and dedicated the right amount of resources to solving it. Here’s how they did it.

New priorities

The first thing Lyft’s development team needed to do was figure out whether this was a pressing enough problem to convince their leadership to dedicate resources to it. Like any proposal to improve app quality, speeding up Lyft Driver’s start-up time had to be weighed out against other competing demands on developer bandwidth: introducing new product features, making architectural improvements, and improving data science. Generally, one of the challenges to convincing leadership to invest in app quality is that it can be difficult to correlate performance improvements with business metrics.

They turned to Android vitals to get an exact picture of what was at stake. Vitals gives developers access to data about the performance of their app, including app-not-responding errors, battery drainage, rendering, and app startup time. The current and historical performance of each metric is tracked on real devices and can be compared to the performance of other apps in the category. With the help of this powerful tool, the development team discovered that the Lyft Driver app startup time was 15–20% slower than 10 other apps in their category — a pressing issue.

Next, the team needed to establish the right scope for the project, one that would be commensurate with the slowdown’s impact on business goals and user experience. The data from Android vitals made the case clear, especially because it provided a direct comparison to competitors in the rideshare space. The development team estimated that a single developer working on the problem for one month would be enough to make a measurable improvement to app startup time.

Drawing on this wealth of data, and appealing to Lyft’s commitment to app excellence, the team made the case to their leadership. Demonstrating a clear opportunity to improve customer experience, a reasonably scoped and achievable goal, and clear-cut competitive intelligence, they got the go-ahead.

How They Did It

Lyft uses “Time to interact” as a primary startup metric (also known as Time to full display). To understand the factors that impact it, the Lyft team profiled each of their app’s launch stages, looking for the impasse. The Lyft Driver app starts up in four stages: 1) First, start the application process 2) “Activity” kicks off the UI rendering. 3) “Bootstrap” sends network requests for the data necessary to render the home screen. 4) Finally, “Display” opens the driver’s interface. Rigorous profiling revealed that the slowdown occurred in the third, bootstrapping, phase. With the bottleneck identified, the team took several steps to resolve it.

 

First, they reduced unneeded network calls on the critical launch path. After decomposing their backend services, they could safely remove some network calls in the launch path entirely. When possible, they also chose to execute network calls asynchronously. If some data was still required for the application to function, but was not needed during app launch, these calls were made non-blocking to allow the launch to proceed without them. Blocking network calls were able to be safely moved to the background. Finally, they chose to cache data between sessions.

 

These may sound like relatively small changes, but they resulted in a dramatic 21% reduction in app startup time. This led to a 5% increase in driver sessions in Lyft Driver. With the results in hand, the team had enough buy-in from leadership to create a dedicated mobile performance workstream and add an engineer to the effort as they continued to make improvements. The success of the initiative caught on across the organization, with several managers reaching out to explore how they could make further investments in app quality.

Learnings

The success of these efforts contains several broader lessons, applicable to any organization.

As an app grows and the team grows with it, app excellence becomes more important than ever. Developers are often the first to recognize performance issues as they work closely on an app, but can find it difficult to raise awareness across an entire organization. Android vitals offers a powerful tool to do this. It provides a straightforward way to back up developer observations with data, making it easier to square performance metrics with business cases.

When starting your own app excellence initiative, it pays to first aim for small wins and build from there. Carefully pick actionable projects, which deliver significant results through an appropriate resource investment.

It’s also important to communicate early and often to involve the rest of the organization in the development team’s quality efforts. These constant updates about goals, plans, and results will help you keep your whole team on board.

Further Resources

Android vitals is just one of the many tools in the Android ecosystem designed to help understand and improve app startup time and overall performance. Another complementary tool, Jetpack Macrobenchmark, can help provide intelligence during development and testing on a variety of metrics. In contrast to Android vitals, which provides data from real users’ devices, Macrobenchmark allows you to benchmark and test specific areas of your code locally, including app startup time.

The Jetpack App startup library provides a straightforward, performant way to initialize components at application startup. Developers can use this library to streamline startup sequences and explicitly set the order of initialization. Meanwhile, Reach and devices can help you understand your user and issue distribution to make better decisions about which specs to build for, where to launch, and what to test. The data from the tool allows your team to prioritize quality efforts and determine where improvements will have the greatest impact for the most users. Perfetto is another invaluable asset: an open-source system tracing tool which you can use to instrument your code and diagnose startup problems. In concert, these tools can help you keep your app running smoothly, your users happy, and your whole organization supportive of your quality efforts.

If you’re interested in getting your own team on board for the pursuit of App Excellence (or join Lyft), check out our condensed case study for product owners and executives linked here.

Posted by Don Turner, Developer Relations Engineer, and Francois Goldfain, Director of Android Media Framework

 

Today we're launching the Jetpack Core Performance library in alpha. This library enables you to easily understand what a device is capable of, and tailor your user experience accordingly. It does this by allowing you to obtain the device’s performance class on devices running Android 11 (API level 30) and above.

A performance class is a ranking that reflects both a device's level of performance and its overall capabilities. As such, it largely reflects the device’s hardware specifications, but also how it performs in certain real-world scenarios, verified by the Android Compatibility Test Suite.

The performance class requirements currently focus on media use cases. For example, a Media Performance Class 12 device is guaranteed to:

• have 6+ GB of RAM
• have a 12+ megapixel rear-facing camera supporting video capture at 4k@30fps,
• be able to initialize a video codec in <50ms even when under load
• and many other requirements.

A device that meets these requirements can optimally handle many popular media use cases including the typical video pipelines in social media apps for capturing, encoding, and sharing.

As an app developer, this means you can reliably group devices with the same level of performance and tailor your app’s behavior to those different groups. This enables you to deliver an optimal experience to users with both more and less capable devices. Performance class requirements will expand with each major Android release, making it possible to easily target different levels of experience to the performance class range you find appropriate. For example, you might wish to tailor “more premium” and “more functional” experiences to certain performance classes.

How to use performance class

To add performance class to your app, include the following dependency in your build.gradle:

implementation 'androidx.core:core-performance:1.0.0-alpha02'

Then use it to tailor your user experience. For example, to encode higher resolution video depending on Media Performance Class:

class OptimalVideoSettings(context: Context){

   private val devicePerf: DevicePerformance = DevicePerformance.create(context)

   val encodeHeight by lazy {
       when (devicePerf.mediaPerformanceClass) {
           Build.VERSION_CODES.S -> 1080 // On performance class 12 use 1080p
           Build.VERSION_CODES.R -> 720 // On performance class 11 use 720p
           else -> 480
       }
   }

   val encodeFps by lazy {
       when(devicePerf.mediaPerformanceClass){
           Build.VERSION_CODES.S -> 60 // On performance class 12 use 60 fps
           Build.VERSION_CODES.R -> 30 // On performance class 11 use 30 fps
           else -> 30
       }
   }
}

When to use performance class

The Android device ecosystem is very diverse. The same application code can lead to very different behaviors depending on the device’s capabilities. For example, encoding a 4K video might take a few seconds on one device but a few minutes on another. User expectations also vary greatly based on the device they purchase. To provide an optimized user experience, it is common to group devices based on some criteria, such as RAM size or year released, then tailor your app's features for each group.

The problem with using an arbitrary value such as RAM size for grouping is that it provides no guarantees of a device's performance. There will also always be outliers that perform better or worse than expected within that group. Grouping on performance class solves this problem since it provides these guarantees, backed by real-world tests.

Manually testing devices that belong to different performance classes is one option to assess and identify the changes needed to balance functionalities and usability. However, the recommended approach to validate changes in the app experience is to run A/B tests and analyze their impact on app metrics. You can do this with the support of an experimentation platform such as Firebase. Providing the device’s performance class to the experimentation platform gives an additional performance dimension to the test results. This lets you identify the right optimizations for each class of device.

Snap Inc.

Snap has been using device clustering and A/B testing to fine tune their experience for Snapchatters. By leveraging performance class, Snapchat confidently identifies device capability in a scalable way and delivers an optimal experience. For example, the visual quality of shared videos is increased by using higher resolution and bitrate on Media Performance Class 12 devices than by default. As more devices are upgraded to meet Media Performance Class, Snapchat will run additional A/B tests and deploy features better optimized for the device capabilities.

Device support

The performance class requirements are developed in collaboration with leading developers and device manufacturers, who recognize the need for a simple, reliable, class-based system to allow app optimizations at scale.

In particular, Oppo, OnePlus, realme, Vivo and Xiaomi have been first to optimize their flagship devices to ensure that they meet the Media Performance Class 12 requirements. As a result, Build.VERSION.MEDIA_PERFORMANCE_CLASS returns Build.VERSION_CODES.S (the Android 12 API level) on the following devices:

• OnePlus 10 Pro
• OPPO Find X3 Pro
• realme GT 2 Pro
• Vivo X60 Pro+ and X70 Pro+
• Xiaomi Mi 12 and Mi 12 Pro
• Google Pixel 6 and Pixel 6 Pro

Why a Jetpack library?

The Jetpack Core Performance library was introduced to extend performance class to devices not yet running Android 12 or not advertising their eligible performance class at the time they passed the Android Compatibility Test Suite.

The library, which supports devices running Android 11 and above, aims to address this. It reports the performance class of many devices based on the test results collected during the device certification or through additional testing done by the Google team. We're adding new devices regularly, so make sure you’re using the latest version of the Core Performance library to get maximum device coverage.

Reporting performance class to Firebase

When using Firebase as an experimentation platform for A/B tests, it's easy to send the device performance class to Firebase Analytics using a user property. Filtering the A/B test reports by performance class can indicate which experimental values led to the best metrics for each group of devices.

Here's an example of an A/B test which varies the encoding height of a video, and reports the performance class using a user property.

class MyApplication : Application() {

    private lateinit var devicePerf: DevicePerformance 
    private lateinit var firebaseAnalytics: FirebaseAnalytics
         

    override fun onCreate() {
        devicePerf = DevicePerformance.create(this)
        firebaseAnalytics = Firebase.analytics        
        firebaseAnalytics.setUserProperty(
           "androidx.core.performance.DevicePerformance.mediaPerformanceClass",
           devicePerf.mediaPerformanceClass)
    }

    fun getVideoEncodeHeight() : Long = remoteConfig.getLong("encode_height")
}

Next steps

We'd love for you to try out the Core Performance library in your app. If you have any issues or feature requests please file them here.

Also, we'd be interested to hear any feedback you have on the performance class requirements. Are there specific performance criteria or hardware requirements that are important for your app's use cases? If so, please let us know using the Android issue tracker.

Posted by Sameer Samat, Vice President, Product Management

Mobile apps have transformed our lives. They help us stay informed and entertained, keep us connected to each other and have created new opportunities for billions of people around the world. We’re humbled by the role Google Play has played over the last 10 years in this global transformation.

We wouldn’t be here if it weren’t for the close partnership with our valued developers and using their feedback to keep evolving. For example, based on partner feedback and in response to competition, our pricing model has evolved to help all developers on our platform succeed and today 99% of developers qualify for a service fee of 15% or less.

Recently, a discussion has emerged around billing choice within app stores. We welcome this conversation and today we want to share an exciting pilot program we are working on in partnership with Play developers.

User Choice Billing

When users choose Google Play, it’s because they count on us to deliver a safe experience, and that includes in-app payment systems that protect users’ data and financial information. That’s why we built Google Play’s billing system to the highest standards for privacy and safety so users can be confident their sensitive payment data won’t be at risk when they make in-app purchases.

We think that users should continue to have the choice to use Play’s billing system when they install an app from Google Play. We also think it’s critical that alternative billing systems meet similarly high safety standards in protecting users’ personal data and sensitive financial information.

Building on our recent launch allowing an additional billing system alongside Play’s billing for users in South Korea and in line with our principles, we are announcing we will be exploring user choice billing in other select countries.

This pilot will allow a small number of participating developers to offer an additional billing option next to Google Play’s billing system and is designed to help us explore ways to offer this choice to users, while maintaining our ability to invest in the ecosystem. This is a significant milestone and the first on any major app store — whether on mobile, desktop, or game consoles.

Partnering with Spotify

We’ll be partnering with developers to explore different implementations of user-choice billing, starting with Spotify. As one of the world’s largest subscription developers with a global footprint and integrations across a wide range of device form factors, they’re a natural first partner. Together, we’ll work to innovate in how consumers make in-app purchases, deliver engaging experiences across multiple devices, and bring more consumers to the Android platform.

Spotify will be introducing Google Play’s billing system alongside their current billing system, and their perspective as our first partner will be invaluable. This pilot will help us to increase our understanding of whether and how user choice billing works for users in different countries and for developers of different sizes and categories.

Alex Norström, Chief Freemium Business Officer, commented: “Spotify is on a years-long journey to ensure app developers have the freedom to innovate and compete on a level playing field. We’re excited to be partnering with Google to explore this approach to payment choice and opportunities for developers, users and the entire internet ecosystem. We hope the work we’ll do together blazes a path that will benefit the rest of the industry.”

We understand this process will take time and require close collaboration with our developer community, but we’re thrilled about this first step and plan to share more in the coming months.

Posted by The Android Team

Large screens are growing in reach, with now over 250M active Android tablets, foldables, and ChromeOS devices. As demand continues to accelerate, we’re seeing users doing more than ever on large screens, from socializing and playing games, to multitasking and getting things done. To help people get the most from their devices, we're making big changes in Google Play to enable users to discover and engage with high quality apps and games.

Changes in Play

We’ll be introducing three main updates to the store: ranking and promotability changes, alerts for low quality apps, and device-specific ratings and reviews.

Ranking and Promotability Changes

We recently published our large screen app quality guidelines in addition to our core app quality guidelines to provide guidance on creating great user experiences on large screens. It encompasses a holistic set of features, from basic compatibility requirements such as portrait and landscape support, to more differentiated requirements like keyboard and stylus capabilities. In the coming months, we’ll be updating our featuring and ranking logic in Play on large screen devices to prioritize high-quality apps and games based on these app quality guidelines. This will affect how apps are surfaced in search results and recommendations on the homepage, with the goal of helping users find the apps that are best optimized for their device. We will also be deepening our investment in editorial content across Play to highlight apps that have been optimized for large screens.

Alerts for Users Installing Low Quality Apps

For apps that don’t meet basic compatibility requirements, we’ll be updating current alerts to users on large screens to help set expectations for how apps will look and function post-install. This will help notify users about apps that may not work well on their large screen devices.We are working to provide additional communications on this change, so stay tuned for further updates later this year.

Device-Specific Ratings and Reviews

Lastly, as we previously announced, users will soon be able to see ratings and reviews split by device type (e.g. tablets and foldables, Chrome OS, Wear, or Auto) to help them make better decisions about the apps that are right for them. Where applicable, the default rating shown in Play will be that of the device type the user is using, to provide a better sense of the app experience on their device. To preview your ratings and reviews by device, you can view your device-type breakdown in Play Console today.

Analyze your ratings and reviews breakdown by device type to plan large screen optimizations

Tools for Getting Started on Large Screen Optimizations

Developers optimizing for large screens are already seeing positive impact to user engagement and retention. To help you get started, here are some tips and resources for optimizing your app for large screens:

• Use our large screens quality guidelines as a checklist to help you benchmark your apps’ compatibility level and plan for any enhancements
• Reference our developer documentation on large screens development, including our resources for building responsive layouts, and how to best support different screen sizes.
• Track device type changes in core metrics as well as user and issue distributions across device types via our recently released Device Type breakdowns in the Reach and Devices section of Play Console. You can use Reach and Devices not only for existing apps or games, but also to plan your next title - by choosing a relevant peer group and analyzing user and issue distributions.
  

  Use the Device Type filter to select one or multiple device types to analyze in Reach and Devices

  
  

  See device type breakdowns of your user and issue distributions to optimize your current title
  or plan your next title

  
  

  The features in Play will roll out gradually over the coming months, so we encourage you to get a head start in planning for large screen app quality enhancements ahead of these changes. Along the way, we will continue collecting feedback to understand how we can best support large screen optimizations that improve consumer experiences and empower developers to build better apps.

  

  Source: Android Developers Blog