Posted by Ady Abraham, Software Engineer
For a long time, phones have had a display that refreshes at 60Hz. Application and game developers could just assume that the refresh rate is 60Hz, frame deadline is 16.6ms, and things would just work. This is no longer the case. New flagship devices are built with higher refresh rate displays, providing smoother animations, lower latency, and an overall nicer user experience. There are also devices that support multiple refresh rates, such as the Pixel 4, which supports both 60Hz and 90Hz.
A 60Hz display refreshes the display content every 16.6ms. This means that an image will be shown for the duration of a multiple of 16.6ms (16.6ms, 33.3ms, 50ms, etc.). A display that supports multiple refresh rates, provides more options to render at different speeds without jitter. For example, a game that cannot sustain 60fps rendering must drop all the way to 30fps on a 60Hz display to remain smooth and stutter free (since the display is limited to present images at a multiple of 16.6ms, the next framerate available is a frame every 33.3ms or 30fps). On a 90Hz device, the same game can drop to 45fps (22.2ms for each frame), providing a much smoother user experience. A device that supports 90Hz and 120Hz can smoothly present content at 120, 90, 60 (120/2), 45(90/2), 40(120/3), 30(90/3), 24(120/5), etc. frames per second.
The higher the rendering rate, the harder it is to sustain that frame rate, simply because there is less time available for the same amount of work. To render at 90Hz, applications only have 11.1ms to produce a frame as opposed to 16.6ms at 60Hz.
To demonstrate that, let’s take a look at the Android UI rendering pipeline. We can break frame rendering into roughly five pipeline stages:
The entire pipeline is controlled by the Android Choreographer. The Choreographer is based on the display vertical synchronization (vsync) events, which indicate the time the display starts to scanout the image and update the display pixels. The Choreographer is based on the vsync events but has different wakeup offsets for the application and for SurfaceFlinger. The diagram below illustrates the pipeline on a Pixel 4 device running at 60Hz, where the application is woken up 2ms after the vsync event and SurfaceFlinger is woken up 6ms after the vsync event. This gives 20ms for an app to produce a frame, and 10ms for SurfaceFlinger to compose the screen.
When running at 90Hz, the application is still woken up 2ms after the vsync event. However, SurfaceFlinger is woken up 1ms after the vsync event to have the same 10ms for composing the screen. The app, on the other hand, has just 10ms to render a frame, which is very short.
To mitigate that, the UI subsystem in Android is using “render ahead” (which delays a frame presentation while starting it at the same time) to deepen the pipeline and postpone frame presentation by one vsync. This gives the app 21ms to produce a frame, while keeping the throughput at 90Hz.
Some applications, including most games, have their own custom rendering pipelines. These pipelines might have more or fewer stages, depending on what they are trying to accomplish. In general, as the pipeline becomes deeper, more stages could be performed in parallel, which increases the overall throughput. On the other hand, this can increase the latency of a single frame (the latency will be number_of_pipeline_stages x longest_pipeline_stage). This tradeoff needs to be considered carefully.
As mentioned above, multiple refresh rates allow a broader range of available rendering rates to be used. This is especially useful for games which can control their rendering speed, and for video players which need to present content at a given rate. For example, to play a 24fps video on a 60Hz display, a 3:2 pulldown algorithm needs to be used, which creates jitter. However, if the device has a display that can present 24fps content natively (24/48/72/120Hz), it will eliminate the need for pulldown and the jitter associated with it.
The refresh rate that the device operates at is controlled by the Android platform. Applications and games can influence the refresh rate via various methods (explained below), but the ultimate decision is made by the platform. This is crucial when more than one app is present on the screen and the platform needs to satisfy all of them. A good example is a 24fps video player. 24Hz might be great for video playback, but it’s awful for responsive UI. A notification animating at only 24Hz feels janky. In situations like this, the platform will set the refresh rate to ensure that the content on the screen looks good.
For this reason, applications may need to know the current device refresh rate. This can be done in the following ways:
Applications can influence the device refresh rate by setting a frame rate on their Window or Surface. This is a new capability introduced in Android 11 and allows the platform to know the rendering intentions of the calling application. Applications can call one of the following methods:
Please refer to the frame rate guide on how to use these APIs.
The system will choose the most appropriate refresh rate based on the frame rate programmed on the Window or Surface.
On Older Android versions (before Android 11) where the setFrameRate API doesn’t exist, applications can still influence the refresh rate by directly setting WindowManager.LayoutParams.preferredDisplayModeId to one of the available modes from Display.getSupportedModes. This approach is discouraged starting with Android 11 since the platform doesn’t know the rendering intention of the app. For example, if a device supports 48Hz, 60Hz and 120Hz and there are two applications present on the screen that call setFrameRate(60, …) and setFrameRate(24, …) respectively, the platform can choose 120Hz and make both applications happy. On the other hand, if those applications used preferredDisplayModeId they would probably set the mode to 60Hz and 48Hz respectively, leaving the platform with no option to set 120Hz. The platform will choose either 60Hz or 48Hz, making one app unhappy.
Refresh rate is not always 60Hz - don’t assume 60Hz and don’t hardcode assumptions based on that historical artifact.
Refresh rate is not always constant - if you care about the refresh rate, you need to register a callback to find out when the refresh rate changes and update your internal data accordingly.
If you are not using the Android UI toolkit and have your own custom renderer, consider changing your rendering pipeline according to the current refresh rate. Deepening the pipeline can be done by setting a presentation timestamp using eglPresentationTimeANDROID on OpenGL or VkPresentTimesInfoGOOGLE on Vulkan. Setting a presentation timestamp indicates to SurfaceFlinger when to present the image. If it is set to a few frames in the future, it will deepen the pipeline by the number of frames it is set to. The Android UI in the example above is setting the present time to frameTimeNanos1 + 2 * vsyncPeriod2
frameTimeNanos
+ 2 * vsyncPeriod
Tell the platform your rendering intentions using the setFrameRate API. The platform will match different requests by selecting the appropriate refresh rate.
Use preferredDisplayModeId only when necessary, either when setFrameRate API is not available or when you need to use a very specific mode.
Lastly, familiarize yourself with the Android Frame Pacing library. This library handles proper frame pacing for your game and uses the methods described above to handle multiple refresh rates.
frameTimeNanos received from Choreographer ↩
frameTimeNanos received from Choreographer
vsyncPeriod received from Display.getRefreshRate()
Our teams, like all of you, continue getting used to a new normal. For many of us, that means working from living rooms, kitchens, backyards and bedrooms. So, from our homes to yours, we wanted to take a moment to share our most recent developer preview for Android 11. This update includes bug fixes and a set of productivity improvements for developers.
You can see some of the highlights below, and visit the Android 11 developer site for details on all of the new features in Android 11. Today’s release is for developers and not intended for daily or consumer use, so we’re making it available by manual download and flash for Pixel 2, 3, 3a, or 4 devices. If you’re already running a Developer Preview build, you’ll receive an over-the-air (OTA) update to today’s release soon. As always, let us know what you think, and thank you for the helpful feedback you’ve shared so far.
In today’s release there are a number of new features and changes for you to try, as well as the latest updates to existing features, APIs, and tools. Here are just a few:
App exit reasons updates - Apps can exit for a variety of reasons, from crash to system kill or user action. Across the many device types, memory configurations, and user scenarios that your app runs in, it’s important to understand why the app exited and what the state was at the time. Android 11 makes this easier with an exit reasons API that you can use to request details of the app’s recent exits. In DP3 we’ve updated the APIs based on your input, so please take a look. If you haven’t had a chance to check out this new API yet, we recommend giving it a try and please let us know what you think here.
GWP-ASan heap analysis - Android 11 uses a variety of tools to harden security-critical components in the platform and apps. In DP3, we’re adding GWP-ASan as another way to help developers find and fix memory safety issues. GWP-ASan is a sampling allocation tool that detects heap memory errors with minimal overhead or impact on performance. We’ve enabled GWP-ASan to run by default in platform binaries and system apps, and now you can now enable it for your apps as well. If your app uses native code or libraries, we recommend enabling GWP-ASan and testing as soon as possible. For details, see the documentation.
ADB Incremental - Installing very large APKs with ADB (Android Debug Bridge) during development can be slow and impact your productivity, especially those developers working on Android Games. With ADB Incremental in Android 11, installing large APKs (2GB+) from your development computer to an Android 11 device is up to 10x faster. To use this new developer tool, first sign your APK with the new APK signature scheme v4 format, and then install your APK with the updated ADB command line tool found in the Android 11 Preview SDK. This new feature is part of a broad suite of new tools we're investing in to make you more productive in building games on Android. Note that in DP3, ADB Incremental only works with Pixel 4 / 4XL devices due to a required file system change at the device level. All new devices launching with Android 11 will include this change and will support ADB Incremental. Learn more here.
Wireless Debugging - In Android 11, we’ve completely revamped the debugging experience using ADB over a Wi-Fi connection. With limited USB ports on laptops, and a myriad of USB cables & connections to manage, the Wireless Debugging feature in Android 11 can help you be more productive. Unlike the existing TCP/IP debugging workflow, Wireless Debugging on Android 11 does not need a cable to set up, remembers connections over time, and can utilize the full speed of the latest Wi-Fi standards. In DP3, use the pairing code workflow to get started with this developer feature. We plan to add an integrated experience for Wireless Debugging with QR code scanning in a future Android Studio release, but we want to get your early feedback on the command line tool offered in Android 11 DP3. For details, see the documentation.
Try the new wireless debugging feature in Developer Options.
Data access auditing updates - In DP3 we renamed several of the APIs for this Android 11 developer feature. If you are already using the APIs, make sure to check out the changes. If you aren’t familiar, data access auditing lets you instrument your app to better understand how it accesses user data and from which user flows. For example, It can help you identify any inadvertent access to private data in your own code or within any SDKs you might be using. Give data access auditing a try in your apps - you can read more here. Let us know your feedback here.
For details on everything that’s changed in Developer Preview 3, take a look at the DP3 diff report and read the release notes for details about known issues.
With Developer Preview 3, we’re well on the way to finalizing features and APIs and shifting our focus to polish and performance. If you haven’t already, now is the time to begin testing your app for compatibility and identify any work you’ll need to do. We recommend releasing a compatible app update by Android 11 Beta to get feedback from the larger group of Android Beta users.
When we reach Platform Stability, system behaviors, non-SDK greylists, and APIs are finalized. At that time, plan on doing your final compatibility testing and releasing your fully compatible app, SDK, or library as soon as possible so that it is ready for the final Android 11 release. You can read more in the timeline for developers.
You can start compatibility testing today on a Pixel 2, 3, 3a, or 4 device, or you can use the Android Emulator. Just flash the latest build, install your current production app, and test the user flows. Make sure to review the behavior changes for areas where your app might be affected. There’s no need to change the app’s targetSdkVersion at this time, although we recommend evaluating the work since many changes apply once your app is targeting the new API level.
To help you test, we’ve made many of the targetSdk changes toggleable, so you can force-enable or disable them individually from Developer options or ADB. Check out the details here. Also see the greylists of restricted non-SDK interfaces, which can also be enabled/disabled.
App compatibility toggles in Developer Options.
Developer Preview 3 has everything you need to try the latest Android 11 features, test your apps, and give us feedback. Just download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device, or set up the Android Emulator through Android Studio. Next, update your Android Studio environment with the latest Android 11 Preview SDK and tools, see the set up guide for details.
As always, your feedback is crucial, so please continue to let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here.
For complete information on Android 11, visit the Android 11 developer site.
Since 2014, Android WebView has paved the way as an updateable system component, delivering stability and performance improvements, modern web platform features, and security patches to Android apps and users. However, updates can be a double edged sword: as much as we strive for stability and backward compatibility, new crashes and breaking changes occasionally slip through. To solve these issues faster, today we're announcing WebView DevTools, a new set of on-device debugging tools to diagnose WebView-caused crashes and misbehaving web platform features.
For your convenience, WebView DevTools comes included as part of WebView itself. The easiest way to launch WebView Devtools is to try out WebView Beta. WebView's beta program is a way for app developers to get WebView several weeks before they reach users, for extra lead time to report compatibility bugs to our team. Starting with today's release (M83), WebView Beta includes a launcher icon for WebView DevTools. Just look for the blue and gray WebView gear icon to get started debugging WebView in your app.
Inspecting a crash in WebView DevTools.
No software is bug-free and loading web content can be challenging, so it's no surprise WebView crashes are a pain point for apps. Worse yet, these crashes are difficult to debug because WebView's Java and C++ stack traces are obfuscated (to minimize APK size for Android users). To help make these crashes more actionable, we're exposing first-class access to WebView's built-in crash reporter. Just open WebView DevTools, tap on "crashes," and you'll see a list of recent WebView-caused crashes from apps on your device. You can use this tool to see if the crash report has been uploaded to our servers, force-upload it if necessary, and subsequently file a bug. This ensures our team has all the information we need to swiftly resolve these crashes and ensure a smoother user experience in your app.
Using flags to highlight WebView usage in Android apps.
However, not all bugs cause crashes. A handful of past WebView releases have broken Android apps due to behavior changes caused by new features. While our team's policy is to roll back features which break compatibility, the chromium team launches several features for WebView in each release, and we often need time to identify the offending feature. WebView DevTools can help here too. Inspired by Google Chrome's chrome://flags tool, which enables compatibility testing with web platform features, we're offering app developers similar controls for experimental features. To get started, open WebView DevTools, tap on "flags," enable or disable any available features, then kill and restart the WebView-based app you're testing. Using WebView DevTools will help us work together to pin down the culprit so we can roll it back. We've also included flags for features slated for upcoming releases, so you can test compatibility even earlier by enabling these features on your test device.
Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play
As part of our continuing efforts to enhance user trust and safety across Google Play, we regularly examine our policies to ensure a positive experience for developers and users. Today we are announcing policy updates that give users more control over their data, tighten subscription policies, and help prevent deceptive apps and media getting onto the Play Store.
We understand that many of you are adjusting to or actively supporting efforts in response to the current unprecedented circumstances. We want to assure you that we are mindful and supportive of those efforts, and have taken steps to minimize the potential short-term impact of these changes. You can read more about that in this blog post which shares resources for developers navigating the current context. We also wanted to briefly highlight two of the more impactful policies announced today.
Subscriptions continue to grow in popularity on Play; however, we hear user feedback that it isn’t always clear what you are signing up for. The goal of this policy update is to ensure users understand the subscription offer, the terms of free trials and introductory offers, and how to manage their subscription, including cancellation.
This blog post goes into more detail about the changes and gives examples of best practices and common violations. Developers have until June 16th to make any changes to their offer page.
Users consistently tell us that they want more control over their location data and that we should take every precaution to prevent misuse. Android users have always needed to grant explicit permission to any app that wants access to their location data. In Android 11, we’re granting additional user controls with the ability to grant a temporary “one-time” permission.
In February, we announced we would require that developers get approval if they want to access background location in their app. This ensures that only apps that really need access for core functionality can ask users for permission. This policy is now live and we encourage all developers who access location to view it.
We realize complying with certain aspects of this policy may require work for some developers so we are giving you an extended timeline to make changes. We suggest that you review location best practices and evaluate whether you have appropriate disclosures, and really need background location; however, no action will be taken for new apps until August 2020 or existing apps until November 2020. Additional details can be found in this help center article and we’ll keep you updated if processes or timelines change. Thanks for your continued support in making Google Play a trustworthy and valuable experience for everyone.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Angela Ying, Product Manager, Google Play
For many developers, subscriptions are an important part of your business. Google Play has continued to support the growth of subscription offerings through developer tools such as new insights in the Google Play Console, and an improved user experience, including the subscriptions center, where users can easily manage all of their subscriptions. Part of improving the subscription user experience comes from fostering a trustworthy platform for subscribers; making sure they feel fully informed when they purchase in-app subscriptions.
To continue to build this trust, we announced an updated subscriptions policy today, as part of a broader policy update to build user trust and enhance user safety across Google Play. This new policy requires you to be transparent about your subscription offering, to ensure every user evaluating your service has an informed choice.
When users lose trust in your app due to unclear subscription offers, they unsubscribe and often leave negative reviews, ultimately hurting your business. On the other hand, a clear and compelling offer gives users all the information they need to make a decision, increasing their trust in your service and hopefully encouraging them to stick around for a long time.
The goal of this policy update is to ensure users understand the subscription offer, the terms of free trials and introductory offers, and how to manage their subscription, including cancellation. You can read the full policy and see examples of best practices and common violations in the Policy Center, but the most important thing is to make sure you are clear about your subscription offering within your app. Consider the following best practices:
Be explicit about your subscription terms, such as:
If you offer free trials and introductory offers, clearly and accurately tell users:
Ensure your app clearly discloses how a subscriber can cancel and/or manage a subscription.
You have until June 16, 2020 to bring your existing apps into compliance with this policy.
In conjunction with these policy updates, we’ve made several platform-level product changes to help increase user trust and build user confidence in subscribing.
We believe that although these changes may lead to fewer conversions or more subscription cancelations in the short term, they will also result in higher quality, more committed subscribers with lower refund and chargeback rates. Overall, this should result in a more stable recurring revenue.
We want to help you do the right thing for your subscribers, so we’ve created this checklist, video and training in Google Play’s Academy for App Success to use as a reference when you’re making any necessary app updates.
Thank you for continuing to partner with us to make Google Play a trustworthy platform for you and your users. Not only can we work together to create great experiences for users, but we can continue to grow subscription businesses as well.
With more kids spending time at home, parents are looking for ways to find apps and games for children that are both enriching and entertaining. Today, we’re announcing an update that will make it easier for parents to find this content on the Google Play Store. We’re launching the Teacher Approved program, an editorial program to highlight high-quality, teacher-approved apps for kids. This is part of our ongoing effort to create a safer Google Play for kids.
We consulted with academic experts to develop a framework for rating apps for kids. Specially trained teachers across the US will rate apps for kids based on this framework, evaluating things like:
Teacher-approved apps will:
The Google Play store featuring teacher-approved apps
As a result of these changes, we are removing the Family star badge and the Family section on Google Play. All apps that were in the Family section will continue to be discoverable on the Play Store and appear in search results. Note that this change will have no effect on Family Library.
Apps need to meet the requirements of the Designed for Families program before they’re eligible to be reviewed by teachers. All Designed for Families apps are automatically placed in the teacher review queue.
We made the decision to launch the Teacher Approved program a little early given the vast number of kids at home now. Teachers are working hard to review apps as quickly as possible, but it will take time to review all apps, so we appreciate your patience. Our initial launch will be limited to the US, to be followed by a global rollout in the coming months.
To help developers better understand what the teachers are looking for, we published a new learning path on Google Play’s Academy for App Success, including findings from Google Play’s research into technology usage by parents and kids.
We’re committed to improving the ecosystem and partnering with our developers. We look forward to continuing to work with you to create the best possible experience for children and families on Google Play. For more information on the Teacher Approved program, check out our FAQs.
In these unprecedented times, Google Play's mission to support you, ensure your businesses continue to operate well, and help users get the content they need is more important than ever. With a surge in need for information, communications tools, entertainment, and more, we are striving to ensure our operations run smoothly, and we need your support.
Below, we’ve pulled together some important information to help you maintain business continuity, as well as best practices to help you stay nimble in the changing landscape.
Like many of you, we've had to manage work disruptions as a result of changing business conditions. This has led to a temporary slowing down of the app review process, which now may take 7 days or longer. As the situation evolves, we will continue to make sure that the most important updates reach users quickly, which may result in fluctuating review times. Certain critical apps may receive prioritized review and may not experience an extended delay in review time. Please check the Google Play Console for the most up-to-date information and guidance.
At the same time, in order to help ensure we are providing users with accurate and timely information relating to COVID-19, we also are prioritizing the review of apps published, commissioned, or authorized by official government entities and public health organizations.
If you want to control when your app goes live, we recommend timed publishing. Just submit your app for review, and once it’s approved, click “Go live” in the Play Console to instantly publish your app. Note: If you already have a release submitted to the production track that is under review, you will not see the “timed publishing” option.
At Google Play we take our responsibility to provide accurate and relevant information for our users very seriously. For that reason, we are currently only approving apps that reference COVID-19 or related terms in their store listing if the app is published, commissioned, or authorized by an official government entity or public health organization, and the app does not contain any monetization mechanisms such as ads, in-app products, or in-app donations. This includes references in places such as the app title, description, or release notes.
All other apps may use COVID-19 related keywords and related terms in the in-app experience. For non-medical related apps, references to COVID-19 are limited to non-health related claims (e.g. opening hours changes, sharing tips on activities to do at home, providing commentary on the economic/social impacts of COVID-19, etc). These apps may not include health claims (e.g. prevention methods, treatments, vaccines).
With the recent increase in traffic, some apps are seeing a spike in inappropriate one-star reviews from users. If you are receiving reviews that are not related to your app experience, you can flag the review in the Play Console. We’ve expanded our ability to assess and remove inappropriate reviews so we can handle your request as quickly as possible.
While subscriptions are a large part of many app business models, two groups are currently seeing the largest impact: 1) those whose core businesses have been adversely affected by COVID-19 (such as live event ticketing), and 2) those who provide a public service with their content or services.
For developers whose business value proposition has been affected, features like deferred billing and subscription pauses can help retain users until after the crisis has passed. For developers who want to offer their content or services like medical, online learning, and wellbeing apps at reduced or no cost, features like price changes and refunds through Google Play Billing are available to help.
Learn more best practices in our Medium post.
Google is also committed to helping our community at large. To help small businesses reconnect with their customers, Google is granting $340 million in ad credits to be used across our Google Ads platforms — learn more here.
Here’s what else we’re doing:
As the situation progresses, we will continue to gather more resources to help you. We’re also taking steps to limit changes and barriers because we know you have enough on your plate right now. Please stay tuned for more information, and thank you for being a part of the Google Play community. If you have any other suggestions about how we can support you during this time, please let us know by tweeting at us at @GooglePlayDev with #AskGooglePlay.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
