Tag Archives: Android 11

Working Towards Android App Excellence

Posted by Jacob Lehrbaum Director of Developer Relations, Android

illustration of freckled hand over mobile phone with graphs

Great app experiences are great for business. In fact, nearly three-quarters of Android app users who leave a 5 star review on Google Play mention the quality of their experience with the app¹; its speed, design, and usability. At Google, we want to help all developers achieve app excellence, and in turn help you drive user acquisition, retention, and monetization.

So what is “app excellence”? This may sound aspirational, but it is within reach for many apps. It starts with a laser focus on the user, and more specifically, with intuitive user experiences that get people to the main functionality of your app as quickly as possible — but that is just the beginning. Excellent apps are consistent across all of their screens and experiences. They perform well, no matter the device used. App excellence is achievable when all of the stakeholders who influence your app are invested in the experience of using your app.

One of the blockers that gets in the way of app excellence is shared or unclear accountability. Some of the primary measures of app quality, such as crashes and load times, are often seen as the responsibility of one group in the company, such as the engineering team. However, when we talk to best-in-class organizations² about how they achieve app quality, it is clear that taking a cross-functional approach is key, with engineering, design, product, and business teams working toward a common goal.

So what are some internal best practices behind app excellence?

Make app quality a cross-organizational focus — not just an engineering concern

It’s a way easier conversation for me at the business end because I can say “these competitors’ apps are faster than ours; we need to reduce our load time down from 5 seconds to 4 seconds”.

Software engineer, x-platform app

App excellence helps drive business performance. New features are great, but if they slow down app start-up times or take up too much device space, people will eventually use your app less often or even delete it. Engineers who have built a company-wide focus on quality have often done so by quantifying the impact of quality issues on business performance, through:

Case studies showing the impact of responsiveness, APK size, start-up time, and memory usage on business KPIs. Here you can find practical case studies showcasing how developers such as Headspace and Duolingo achieved app excellence.
Benchmarking against competitor apps. Check out peer benchmarks and other metrics on the Google Play Console.

Organize teams around features and/or app user journey stages

Companies that organize teams around features — or stages in the user journey — are more likely to deliver consistent experiences across each operating system they support, bring new apps or features to market faster, and deliver a better app experience for all their customers. These teams are often cross-functional groups that span engineering, marketing, ux, and product — and are responsible for the success of a feature or user journey stage³ across all devices and platforms. In addition to better experiences and feature parity, this structure enables alignment of goals across functional areas while reducing silos, and it also helps teams hyper-focus on addressing specific objectives.

Squads focused on business objectives heighten focus on the user.

Use the same devices your customers use

If a majority of your users are on a specific type of device, you can build empathy for their experience if you use the same phone, tablet or smart watch as your primary device. This is especially relevant for senior leadership in your organization who make decisions that impact the day-to-day experience of millions of users. For example, Duolingo has built this into their company DNA. Every Duolingo employee — including their CEO — either uses exclusively or has access to an entry level Android device to reflect a significant portion of their user base.

A user-centric approach to quality and app excellence is essential to business growth. If you are interested in learning how to achieve app excellence, read our case studies with practical tips, and sign up to attend our App Excellence Summit by visiting the Android app excellence webpage.

In subsequent blog posts, we will dig deep into two drivers of excellent app experiences: app performance and how it is linked to user behavior, and creating seamless user experiences across devices. Sign up to the Android developer newsletter here to be notified of the next installment, and get news and insights from the Android team.

Notes

Internal Google Play data, 2021. ↩
Google App Quality Research, 2021 ↩
The series of steps each user takes as they interact with your app is referred to as the “user journey.” Examples of user journey stages include installs, onboarding, engagement, and retention ↩

Source: Android Developers Blog

Improving urban GPS accuracy for your app

Posted by Frank van Diggelen, Principal Engineer and Jennifer Wang, Product Manager

At Android, we want to make it as easy as possible for developers to create the most helpful apps for their users. That’s why we aim to provide the best location experience with our APIs like the Fused Location Provider API (FLP). However, we’ve heard from many of you that the biggest location issue is inaccuracy in dense urban areas, such as wrong-side-of-the-street and even wrong-city-block errors.

This is particularly critical for the most used location apps, such as rideshare and navigation. For instance, when users request a rideshare vehicle in a city, apps cannot easily locate them because of the GPS errors.

The last great unsolved GPS problem

This wrong-side-of-the-street position error is caused by reflected GPS signals in cities, and we embarked on an ambitious project to help solve this great problem in GPS. Our solution uses 3D mapping aided corrections, and is only feasible to be done at scale by Google because it comprises 3D building models, raw GPS measurements, and machine learning.

The December Pixel Feature Drop adds 3D mapping aided GPS corrections to Pixel 5 and Pixel 4a (5G). With a system API that provides feedback to the Qualcomm® Snapdragon™ 5G Mobile Platform that powers Pixel, the accuracy in cities (or “urban canyons”) improves spectacularly.

Picture of a pedestrian test, with Pixel 5 phone, walking along one side of the street, then the other. Yellow = Path followed, Red = without 3D mapping aided corrections, Blue = with 3D mapping aided corrections.

Why hasn’t this been solved before?

The problem is that GPS constructively locates you in the wrong place when you are in a city. This is because all GPS systems are based on line-of-sight operation from satellites. But in big cities, most or all signals reach you through non line-of-sight reflections, because the direct signals are blocked by the buildings.

Diagram of the 3D mapping aided corrections module in Google Play services, with corrections feeding into the FLP API. 3D mapping aided corrections are also fed into the GNSS chip and software, which in turn provides GNSS measurements, position, and velocity back to the module.

The GPS chip assumes that the signal is line-of-sight and therefore introduces error when it calculates the excess path length that the signals traveled. The most common side effect is that your position appears on the wrong side of the street, although your position can also appear on the wrong city block, especially in very large cities with many skyscrapers.

There have been attempts to address this problem for more than a decade. But no solution existed at scale, until 3D mapping aided corrections were launched on Android.

How 3D mapping aided corrections work

The 3D mapping aided corrections module, in Google Play services, includes tiles of 3D building models that Google has for more than 3850 cities around the world. Google Play services 3D mapping aided corrections currently supports pedestrian use-cases only. When you use your device’s GPS while walking, Android’s Activity Recognition API will recognize that you are a pedestrian, and if you are in one of the 3850+ cities, tiles with 3D models will be downloaded and cached on the phone for that city. Cache size is approximately 20MB, which is about the same size as 6 photographs.

Inside the module, the 3D mapping aided corrections algorithms solve the chicken-and-egg problem, which is: if the GPS position is not in the right place, then how do you know which buildings are blocking or reflecting the signals? Having solved this problem, 3D mapping aided corrections provide a set of corrected positions to the FLP. A system API then provides this information to the GPS chip to help the chip improve the accuracy of the next GPS fix.

With this December Pixel feature drop, we are releasing version 2 of 3D mapping aided corrections on Pixel 5 and Pixel 4a (5G). This reduces wrong-side-of-street occurrences by approximately 75%. Other Android phones, using Android 8 or later, have version 1 implemented in the FLP, which reduces wrong-side-of-street occurrences by approximately 50%. Version 2 will be available to the entire Android ecosystem (Android 8 or later) in early 2021.

Android’s 3D mapping aided corrections work with signals from the USA’s Global Positioning System (GPS) as well as other Global Navigation Satellite Systems (GNSSs): GLONASS, Galileo, BeiDou, and QZSS.

Our GPS chip partners shared the importance of this work for their technologies:

“Consumers rely on the accuracy of the positioning and navigation capabilities of their mobile phones. Location technology is at the heart of ensuring you find your favorite restaurant and you get your rideshare service in a timely manner. Qualcomm Technologies is leading the charge to improve consumer experiences with its newest Qualcomm® Location Suite technology featuring integration with Google's 3D mapping aided corrections. This collaboration with Google is an important milestone toward sidewalk-level location accuracy,” said Francesco Grilli, vice president of product management at Qualcomm Technologies, Inc.

“Broadcom has integrated Google's 3D mapping aided corrections into the navigation engine of the BCM47765 dual-frequency GNSS chip. The combination of dual frequency L1 and L5 signals plus 3D mapping aided corrections provides unprecedented accuracy in urban canyons. L5 plus Google’s corrections are a game-changer for GNSS use in cities,” said Charles Abraham, Senior Director of Engineering, Broadcom Inc.

“Google's 3D mapping aided corrections is a major advancement in personal location accuracy for smartphone users when walking in urban environments. MediaTek’s Dimensity 5G family enables 3D mapping aided corrections in addition to its highly accurate dual-band GNSS and industry-leading dead reckoning performance to give the most accurate global positioning ever for 5G smartphone users,” said Dr. Yenchi Lee, Deputy General Manager of MediaTek’s Wireless Communications Business Unit.

How to access 3D mapping aided corrections

Android’s 3D mapping aided corrections automatically works when the GPS is being used by a pedestrian in any of the 3850+ cities, on any phone that runs Android 8 or later. The best way for developers to take advantage of the improvement is to use FLP to get location information. The further 3D mapping aided corrections in the GPS chip are available to Pixel 5 and Pixel 4a (5G) today, and will be rolled out to the rest of the Android ecosystem (Android 8 or later) in the next several weeks. We will also soon support more modes including driving.

Android’s 3D mapping aided corrections cover more than 3850 cities, including:

North America: All major cities in USA, Canada, Mexico.
Europe: All major cities. (100%, except Russia & Ukraine)
Asia: All major cities in Japan and Taiwan.
Rest of the world: All major cities in Brazil, Argentina, Australia, New Zealand, and South Africa.

As our Google Earth 3D models expand, so will 3D mapping aided corrections coverage.

Google Maps is also getting updates that will provide more street level detail for pedestrians in select cities, such as sidewalks, crosswalks, and pedestrian islands. In 2021, you can get these updates for your app using the Google Maps Platform. Along with the improved location accuracy from 3D mapping aided corrections, we hope we can help developers like you better support use cases for the world’s 2B pedestrians that use Android.

Continuously making location better

In addition to 3D mapping aided corrections, we continue to work hard to make location as accurate and useful as possible. Below are the latest improvements to the Fused Location Provider API (FLP):

Developers wanted an easier way to retrieve the current location. With the new getCurrentLocation() API, developers can get the current location in a single request, rather than having to subscribe to ongoing location changes. By allowing developers to request location only when needed (and automatically timing out and closing open location requests), this new API also improves battery life. Check out our latest Kotlin sample.
Android 11's Data Access Auditing API provides more transparency into how your app and its dependencies access private data (like location) from users. With the new support for the API's attribution tags in the FusedLocationProviderClient, developers can more easily audit their apps’ location subscriptions in addition to regular location requests. Check out this Kotlin sample to learn more.

Qualcomm and Snapdragon are trademarks or registered trademarks of Qualcomm Incorporated.

Qualcomm Snapdragon and Qualcomm Location Suite are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

Source: Android Developers Blog

New Android App Bundle and target API level requirements in 2021

Posted by Hoi Lam, Developer Relations Engineer, Android Platform

In 2021, we are continuing with our annual target API level update, requiring new apps to target API level 30 (Android 11) in August and in November for all app updates. In addition, as announced earlier this year, Google Play will require new apps to use the Android App Bundle publishing format. This brings the benefits of smaller apps and simpler releases to more users and developers and supports ongoing investment in advanced distribution.

Over 750,000 apps and games already publish to production on Google Play using app bundles. Top apps switching save an average size of 15% versus a universal APK. Users benefit from smaller downloads and developers like Netflix and Riafy see higher install success rates, which is especially impactful in regions with more entry level devices and slower data speeds. Developers switching can use advanced distribution features such as Play Asset Delivery and Play Feature Delivery. We value your feedback and plan to introduce further features and options for Play App Signing and Android App Bundles before the switchover.

Requirements for new apps

From August 2021, the Google Play Console will require all new apps to:

Publish with the Android App Bundle format.
Utilize Play Asset Delivery or Play Feature Delivery to deliver assets or features that exceed download size of 150MB. Expansion files (OBBs) will no longer be supported for new apps.
Target API level 30 (Android 11) or above and adjust for behavioral changes.

Requirements for updates to existing apps

From November 2021, updates to existing apps will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store.

Requirements for instant experiences

The switch to Android App Bundle delivery will also impact instant experiences using the legacy Instant app ZIP format. From August 2021, new instant experiences and updates to existing instant experiences will be required to publish instant-enabled app bundles.

Moving forward together

Here is a summary of all the changes:

TYPE OF RELEASE	REPLACED	REQUIRED AUG 2021
New apps on Google Play	APK	Android App Bundle (AAB)
	Target API level set to 29+	Target API level set to 30+
	Expansion files (OBBs)	Play Asset Delivery or Play Feature Delivery
TYPE OF RELEASE	REPLACED	REQUIRED NOV 2021
Updates to existing apps on Google Play	No new publishing format requirement
Updates to existing apps on Google Play	Target API level set to 29+	Target API level set to 30+

Wear OS apps are not subject to the new target API level requirement.

Apps can still use any minSdkVersion, so there is no change to your ability to build apps for older Android versions.

To learn more about transitioning to app bundles, watch our new video series: modern Android development (MAD) skills. We are extremely grateful for all the developers who have adopted app bundles and API level 30 already. We look forward to advancing the Android platform together with you.

Source: Android Developers Blog

Introducing Android 11 on Android TV

Posted by Wolfram Klein, Product Manager, Android TV

We’ve been turning it up to 11 all summer long, leading up to the launch of Android 11 on mobile. Now, following right behind the mobile release, we are launching Android 11 on Android TV to bring the latest platform features to the big screen.

Android 11 on Android TV introduces performance and privacy improvements, new features tailored for the TV, and updated developer tools, in addition to enabling many of the features we announced during the #11WeeksOfAndroid.

Foundational Improvements

Android TV continues to bring many of the benefits that come with the core Android update to the TV. With Android 11, performance improvements, like enhanced memory management, and privacy features, like one-time permissions, are introduced to make sure TV devices work quickly and securely.

Tailored for the TV

Android 11 emphasizes media by bringing support for Auto Low Latency Mode, and low latency media decoding, along with a new Tuner Framework with updated Media CAS support and extensions to the HAL implementation of HDMI CEC.

With extended gamepad support, silent boot mode for system updates, inactivity prompts, and OEM configurable wake keys, Android 11 allows greater control over TV functions. New framework functionality for managing System LEDs and physical microphone mute buttons also facilitate integrations for far-field microphone enabled devices.

Faster Testing

Testing on the TV is now easier than ever. The addition of test harness mode on Android TV and Play Store support in the Android TV Emulator help you seamlessly inspect your apps as you develop.

Android TV OEM partners will be launching and upgrading devices to Android 11 over the coming months. To help you test your Android TV app implementations for the next generation of devices, Android 11 will be available as a system update to ADT-3 devices today. To learn more about getting your Android TV app ready for Android 11, visit our developers page.

We're looking forward to seeing your apps on Android 11!

Source: Android Developers Blog

Turning it up to 11: Android 11 for developers

Posted by Stephanie Cuthbertson, Director, Product Management

Android 11 is here! Today we’re pushing the source to the Android Open Source Project (AOSP) and officially releasing the newest version of Android. We built Android 11 with a focus on three themes: a People-centric approach to communication, Controls to let users quickly get to and control all of their smart devices, and Privacy to give users more ways to control how data on devices is shared. Read more in our Keyword post.

For developers, Android 11 has a ton of new capabilities. You’ll want to check out conversation notifications, device and media controls, one-time permissions, enhanced 5G support, IME transitions, and so much more. To help you work and develop faster, we also added new tools like compatibility toggles, ADB incremental installs, app exit reasons API, data access auditing API, Kotlin nullability annotations, and many others. We worked to make Android 11 a great release for you, and we can’t wait to see what you’ll build!

Watch for official Android 11 coming to a device near you, starting today with Pixel 2, 3, 3a, 4, and 4a devices. To get started, visit the Android 11 developer site.

People, Controls, Privacy

People

Android 11 is people-centric and expressive, reimagining the way we have conversations on our phones, and building an OS that can recognize and prioritize the most important people in our lives. For developers, Android 11 helps you build deeper conversational and personal interactions into your apps.

Conversation notifications appear in a dedicated section at the top of the shade, with a people-forward design and conversation specific actions, such as opening the conversation as a bubble, creating a conversation shortcut on the home screen, or setting a reminder.
Bubbles - Bubbles help users keep conversations in view and accessible while multitasking on their devices. Messaging and chat apps should use the Bubbles API on notifications to enable this in Android 11.
Consolidated keyboard suggestions let Autofill apps and Input Method Editors (IMEs) securely offer users context-specific entities and strings directly in an IME’s suggestion strip, where they are most convenient for users.

Bubbles and people-centric conversations.

Controls

Android 11 lets users quickly get to and control all of their smart devices in one space. Developers can use new APIs to help users surface smart devices and control media:

Device Controls make it faster and easier than ever for users to access and control their connected devices. Now, by simply long pressing the power button, they’re able to bring up device controls instantly, and in one place. Apps can use a new API to appear in the controls. More here.
Media Controls make it quick and convenient for users to switch the output device for their audio or video content, whether it be headphones, speakers or even their TV. More here.

Device controls and media controls.

Privacy

In Android 11, we’re giving users even more control and transparency over sensitive permissions and working to keep devices more secure through faster updates.

One-time permission - Now users can give an app access to the device microphone, camera, or location, just for one time. The app can request permissions again the next time the app is used. More here.

One-time permission dialog in Android 11.

Background location - Background location now requires additional steps from the user beyond granting a runtime permission. If your app needs background location, the system will ensure that you first ask for foreground location. You can then broaden your access to background location through a separate permission request, and the system will take the user to Settings to complete the permission grant.

Also note that in February we announced that Google Play developers will need to get approval to access background location in their app to prevent misuse. We're giving developers more time to make changes and won't be enforcing the policy for existing apps until 2021.

Permissions auto-reset - if users haven’t used an app for an extended period of time, Android 11 will “auto-reset” all of the runtime permissions associated with the app and notify the user. The app can request the permissions again the next time the app is used. More here.

Scoped storage - We’ve continued our work to better protect app and user data on external storage, and made further improvements to help developers more easily migrate. More here.

Google Play system updates - Launched last year, Google Play system updates help us expedite updates of core OS components to devices in the Android ecosystem. In Android 11, we more than doubled the number of updatable modules, including 12 new modules that will help improve privacy, security, and consistency for users and developers.

BiometricPrompt API - Developers can now use the BiometricPrompt API to specify the biometric authenticator strength required by their app to unlock or access sensitive parts of the app. For backward compatibility, we’ve just added these capabilities to the Jetpack Biometric library. We’ll share further updates as the work progresses.

Identity Credential API - This will unlock new use cases such as mobile drivers licences, National ID, and Digital ID. We’re working with various government agencies and industry partners to make sure that Android 11 is ready for digital-first identity experiences.

You can read about all of the Android 11 privacy features here.

Helpful innovation

Enhanced 5G support - Android 11 includes updated developer support to help you take advantage of the faster speeds and lower latency of 5G networks. You can learn when the user is connected to a 5G network, check whether the connection is metered, and get an estimate of the connection bandwidth. To help you build experiences now for 5G, we’ve also added 5G support in the Android Emulator. To get started with 5G on Android, visit the 5G developer page.

Moving beyond the home, 5G can for example let you enhance your “on-the-go” experience by providing seamless interactions with the world around you from friends and family to businesses.

New screen types - Device makers are continuing to innovate by bringing exciting new device screens to market, such as hole-punch and waterfall screens. Android 11 adds support for these in the platform, with APIs to let you optimize your apps. You can manage both hole-punch and waterfall screens using the existing display cutout APIs. You can set a new window layout attribute to use the entire waterfall screen, and a new waterfall insets API helps you manage interaction near the edges.

Call screening support - Android 11 helps call-screening apps do more to manage robocalls. Apps can verify an incoming call’s STIR/SHAKEN status (standards that protect against caller ID spoofing) as part of the call details, and they can report a call rejection reason. Apps can also customize a system-provided post call screen to let users perform actions such as marking a call as spam or adding to contacts.

Polish and quality

OS resiliency - In Android 11 we’ve made the OS more dynamic and resilient as a whole by fine-tuning memory reclaiming processes, such as forcing user-imperceptible restarts of processes based on RSS HWM thresholds. Also, to improve performance and memory, Android 11 adds Binder caching, which optimizes highly used IPC calls to system services by caching data for those that retrieve relatively static data. Binder caching also improves battery life by reducing CPU time.

Synchronized IME transitions - New APIs let you synchronize your app’s content with the IME (input method editor, or on-screen keyboard) and system bars as they animate on and offscreen, making it much easier to create natural, intuitive and jank-free IME transitions. For frame-perfect transitions, a new WindowInsetsAnimation.Callback API notifies apps of per-frame changes to insets while the system bars or the IME animate. Additionally, you can use a new WindowInsetsAnimationController API to control system UI types like system bars, IME, immersive mode, and others. More here.

Synchronized IME transition through insets animation listener.

App-driven IME experience through WindowInsetsAnimationController.

HEIF animated drawables - The ImageDecoder API now lets you decode and render image sequence animations stored in HEIF files, so you can make use of high-quality assets while minimizing impact on network data and APK size. HEIF image sequences can offer drastic file-size reductions for image sequences when compared to animated GIFs.

Native image decoder - New NDK APIs let apps decode and encode images (such as JPEG, PNG, WebP) from native code for graphics or post processing, while retaining a smaller APK size since you don’t need to bundle an external library. The native decoder also takes advantage of Android’s process for ongoing platform security updates. See the NDK sample code for examples of how to use the APIs.

Low-latency video decoding in MediaCodec - Low latency video is critical for real-time video streaming apps and services like Stadia. Video codecs that support low latency playback return the first frame of the stream as quickly as possible after decoding starts. Apps can use new APIs to check and configure low-latency playback for a specific codec.

Variable refresh rate - Apps and games can use a new API to set a preferred frame rate for their windows. Most Android devices refresh the display at 60Hz refresh rate, but some support multiple refresh rates, such as 90Hz as well as 60Hz, with runtime switching. On these devices, the system uses the app’s preferred frame rate to choose the best refresh rate for the app. The API is available in both the SDK and NDK. See the details here.

Dynamic resource loader - Android 11 includes a new public API to let apps load resources and assets dynamically at runtime. With the Resource Loader framework you can include a base set of resources in your app or game and then load additional resources, or modify the loaded resources, as needed at runtime.

Neural Networks API (NNAPI) 1.3 - We continue to add ops and controls to support machine learning on Android devices. To optimize common use-cases, NNAPI 1.3 adds APIs for priority and timeout, memory domains, and asynchronous command queue. New ops for advanced models include signed integer asymmetric quantization, branching and loops, and a hard-swish op that helps accelerate next-generation on-device vision models such as MobileNetV3.

Developer friendliness

App compatibility tools - We worked to minimize compatibility impacts on your apps by making most Android 11 behavior changes opt-in, so they won’t take effect until you change the apps’ targetSdkVersion to 30. If you are distributing through Google Play, you’ll have more than a year to opt-in to these changes, but we recommend getting started testing early. To help you test, Android 11 lets you enable or disable many of the opt-in changes individually. More here.

App exit reasons - When your app exits, it’s important to understand why the app exited and what the state was at the time -- across the many device types, memory configurations, and user scenarios that your app runs in. Android 11 makes this easier with an exit reasons API that you can use to request details of the app’s recent exits.

Data access auditing - 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. More here.

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. More here.

Kotlin nullability annotations - Android 11 adds nullability annotations to more methods in the public API. And, it upgrades a number of existing annotations from warnings to errors. These help you catch nullability issues at build time, rather than at runtime. More here.

Get your apps ready for Android 11

With Android 11 on its way to users, now is the time to finish your compatibility testing and publish your updates.

Flow chart steps for getting your apps ready for Android 11.

Here are some of the top behavior changes to watch for (these apply regardless of your app’s targetSdkVersion):

One-time permission - Users can now grant single-use permission to access location, device microphone and camera. More here.
External storage access - Apps can no longer access other apps’ files in external storage. More here.
Scudo hardened allocator - Scudo is now the heap memory allocator for native code in apps. More here.
File descriptor sanitizer - Fdsan is now enabled by default to detect file descriptor handling issues for native code in apps. More here.

Android 11 also includes opt-in behavior changes - these affect your app once it’s targeting the new platform. We recommend assessing these changes as soon as you’ve published the compatible version of your app. For more information on compatibility testing and tools, check out the resources we shared for Android 11 Compatibility week and visit the Android 11 developer site for technical details.

Enhance your app with new features and APIs

Next, when you're ready, dive into Android 11 and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

We recommend these for all apps:

Dark theme (from Android 10) - Make sure to provide a consistent experience for users who enable system-wide dark theme by adding a Dark theme or enabling Force Dark.
Gesture navigation (from Android 10) - Support gesture navigation by going edge-to-edge and ensure that custom gestures work well with gestures. More here.
Sharing shortcuts (from Android 10) - Apps that want to receive shared data should use the sharing shortcuts APIs to create share targets. Apps that want to send shared data should make sure to use the system share sheet.
Synchronized IME transitions - Provide seamless transitions to your users using the new WindowInsets and related APIs. More here.
New screen types - for devices with hole-punch or waterfall screens, make sure to test and adjust your content for these screens as needed. More here.

We recommend these if relevant for your app:

Conversations - Messaging and communication apps can participate in the conversation experience by providing long-lived sharing shortcuts and surfacing conversations in notifications. More here.
Bubbles - Bubbles are a way to keep conversations in view and accessible while multitasking. Use the Bubbles API on notifications to enable this.
5G - If your app or content can benefit from the faster speeds and lower latency of 5G, explore our developer resources to see what you can build.
Device controls - If your app supports external smart devices, make sure those devices are accessible from the new Android 11 device controls area. More here.
Media controls - For media apps, we recommend supporting the Android 11 media controls so users can manage playback and resumption from the Quick Settings shade. More here.

Read more about all of the Android 11 features at developer.android.com/11.

Coming to a device near you!

Android 11 will begin rolling out today on select Pixel, OnePlus, Xiaomi, OPPO and realme phones, with more partners launching and upgrading devices over the coming months. If you have a Pixel 2, 3, 3a, 4, or 4a phone, including those enrolled in this year’s Beta program, watch for the over-the-air update arriving soon!

Android 11 factory system images for Pixel devices are also available through the Android Flash Tool, or you can download them here. As always, you can get the latest Android Emulator system images via the SDK Manager in Android Studio. For broader testing on other Treble-compliant devices, Generic System Images (GSI) are available here.

If you're looking for the Android 11 source code, you'll find it here in the Android Open Source Project repository under the Android 11 branches.

What’s next?

We’ll soon be closing the preview issue tracker and retiring open bugs logged against Developer Preview or Beta builds, but please keep the feedback coming! If you still see an issue that you filed in the preview tracker, just file a new issue against Android 11 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the preview program this year! You gave us great feedback to help shape the release, and you filed thousands of issues that have made Android 11 a better platform for everyone.

We're looking forward to seeing your apps on Android 11!

Source: Android Developers Blog

Playing nicely with media controls

Posted by Don Turner - Developer Advocate - Android Media

In Android 11 we've made it easier than ever for users to control media playback. This is achieved with three related features: media controls, playback resumption and seamless transfer.

This article will explain what these features are, how they work together and how you can take advantage of them in your apps.

Media Controls

Android 11's media controls are found below the Quick Settings panel and represent a dedicated persistent space for controlling media playback.

Media controls in Android 11

Part of the motivation for media controls is that users often have multiple media apps (music player, podcasts, video player etc) and regularly switch between them. Media controls display up to five current and recent media sessions in a carousel allowing the user to swipe between them.

On Android 10 and earlier, media notifications for multiple apps can occupy most of the notification area. All those control buttons can also be confusing. Moving the controls into a dedicated space means that there's more room for other notifications, and provides a more consistent user experience for controlling media apps.

Here's the comparison:

Android 10 media notifications (left) Android 11 media controls (right)

Displaying media controls for your app

Now, the really good news. As long as you're using MediaStyle with a valid MediaSession token (both available since Lollipop API 21), media controls will be displayed for your app automatically - no extra work for you!

In case you're not using a MediaStyle and MediaSession here's a quick recap in code:

// Create a media session. NotificationCompat.MediaStyle
// PlayerService is your own Service or Activity responsible for media playback.  
val mediaSession = MediaSessionCompat(this, "PlayerService")

// Create a MediaStyle object and supply your media session token to it. 
val mediaStyle = Notification.MediaStyle().setMediaSession(mediaSession.sessionToken)

// Create a Notification which is styled by your MediaStyle object. 
// This connects your media session to the media controls. 
// Don't forget to include a small icon.
val notification = Notification.Builder(this@PlayerService, CHANNEL_ID)
            .setStyle(mediaStyle)
            .setSmallIcon(R.drawable.ic_app_logo)
            .build()

// Specify any actions which your users can perform, such as pausing and skipping to the next track. 
val pauseAction: Notification.Action = Notification.Action.Builder(
            pauseIcon, "Pause", pauseIntent
        ).build()
notification.addAction(pauseAction)

The small icon and app name are shown in the upper left of the media controls. The actions are shown in the bottom center.

Media controls UI and corresponding Notification fields

The remaining UI fields, such as track title and playback position, are obtained from the media session's metadata and playback state.

Here's how the metadata fields map to the UI.

mediaSession.setMetadata(
    MediaMetadataCompat.Builder()
        
        // Title. 
        .putString(MediaMetadata.METADATA_KEY_TITLE, currentTrack.title)

        // Artist. 
        // Could also be the channel name or TV series.
        .putString(MediaMetadata.METADATA_KEY_ARTIST, currentTrack.artist)
        
        // Album art. 
        // Could also be a screenshot or hero image for video content
        // The URI scheme needs to be "content", "file", or "android.resource".
        .putString(
            MediaMetadata.METADATA_KEY_ALBUM_ART_URI, currentTrack.albumArtUri)
        )

        // Duration. 
        // If duration isn't set, such as for live broadcasts, then the progress
        // indicator won't be shown on the seekbar.
        .putLong(MediaMetadata.METADATA_KEY_DURATION, currentTrack.duration) // 4

        .build()
)

This screenshot shows how these metadata fields are displayed in the media controls.

Media controls UI and corresponding metadata fields

The seek bar is updated using the media session's playback state in a similar way:

mediaSession.setPlaybackState(
    PlaybackStateCompat.Builder()
        .setState(
            PlaybackStateCompat.STATE_PLAYING,
                        
            // Playback position.
            // Used to update the elapsed time and the progress bar. 
            mediaPlayer.currentPosition.toLong(), 
                        
            // Playback speed. 
            // Determines the rate at which the elapsed time changes. 
            playbackSpeed
        )

        // isSeekable. 
        // Adding the SEEK_TO action indicates that seeking is supported 
        // and makes the seekbar position marker draggable. If this is not 
        // supplied seek will be disabled but progress will still be shown.
        .setActions(PlaybackStateCompat.ACTION_SEEK_TO)
        .build()
)

This screenshot shows how these playback state fields are displayed in the media controls.

Media controls UI and corresponding playback state fields

Your media controls should now look and function perfectly!

Media resumption

Ever wanted to continue listening to a podcast, TV episode or DJ set but couldn't remember where you left off, or even the app that was playing it? Media resumption solves this problem.

There are two stages to media resumption: discovering recent media apps and resuming playback.

Discovering recent media apps

After booting, Android will look for recent media apps and ask them what their most recently played content was. It will then create media controls for that content.

To be discoverable your app must provide a MediaBrowserService, typically using the MediaBrowserServiceCompat library from Android Jetpack.

On boot, Android will call your MediaBrowserServiceCompat's onGetRoot method, so it's imperative that you return quickly. Usually you would return the root of your media tree from this method but the system also specifies the EXTRA_RECENT hint.

You should treat EXTRA_RECENT as a special case and instead return the root of a media tree that contains the most recently played media item as the first element.

The system will call your onLoadChildren method to obtain this media tree, which is a list of MediaItem objects.

Here's a diagram showing how the system and a media app interact to retrieve the most recently played item.

How the system retrieves the most recently played item from the MediaBrowserService

For the first playable media item in this list the system will create static media controls with just a play button.

Static media controls

At this point no media session has been created. This is to save resources - the system doesn't know whether the user actually wants to resume playing that content yet.

Resuming playback

If the user taps the play button the system will make another call to onGetRoot with the EXTRA_RECENT hint. This is so you can prepare your previously played content as before, just in case anything has changed since the static controls were created.

Android will then connect to your media session and issue a play command to it. You should override the media session onPlay callback in order to start playback of your media content and create your MediaStyle notification.

Once you post the notification the static media controls will be swapped with the media controls created from your notification.

Figure 7: Diagram showing interaction between System UI and media app when resuming playback

Seamless media transfer

As well as being able to resume media sessions, Android 11 also allows you to easily transfer playback from one device to another. This is known as "seamless media transfer", and is done through the output switcher. The output switcher is shown in the upper right corner of the media notification that appears below.

Output Switcher (upper right corner)

The output switcher shows the name and icon of the current media route; and when you tap on it you'll see a list of media routes which this app supports.

Media routes available to the current app

By default, only local media routes are shown. If your app supports other media routes, such as remote playback you'll need to let the system know.

To do this add the MediaRouter jetpack library to your app.

dependencies {
    implementation 'androidx.mediarouter:mediarouter:1.2.0-alpha02'`
}

Seamless media transfer is supported from 1.2.0-alpha02.

Then, add the MediaTransferReceiver class to your Android manifest.

<receiver android:name="androidx.mediarouter.media.MediaTransferReceiver" />

Now in your app, obtain the MediaRouter singleton - this is an object that maintains the state of all currently available media routes.

router = MediaRouter.getInstance(this)

Create a MediaRouteSelector and specify the route categories which your app supports. The categories you define here determine the routes which are displayed in the output switcher.

Here we'll just specify the "remote playback" category which is used for Cast devices.

routeSelector = MediaRouteSelector.Builder() // Add control categories that this media app is interested in.
            .addControlCategory(MediaControlIntent.CATEGORY_REMOTE_PLAYBACK)
            .build()

If you want to support transfer from remote to local devices, you need to explicitly enable this using setTransferToLocalEnabled:

router.routerParams = MediaRouterParams.Builder().setTransferToLocalEnabled(true).build()

We can now use our selector when adding a media router callback.

router.addCallback(routeSelector, MediaRouterCallback(),
             MediaRouter.CALLBACK_FLAG_REQUEST_DISCOVERY);

We also supply a callback object so we can be informed of changes to media routes.

Here's the callback class:

    private class MediaRouterCallback : MediaRouter.Callback() {
        override fun onRouteSelected(
            router: MediaRouter,
            route: MediaRouter.RouteInfo,
            reason: Int
        ) {
            if (reason == MediaRouter.UNSELECT_REASON_ROUTE_CHANGED) {
                Timber.d("Unselected because route changed, continue playback")
            } else if (reason == MediaRouter.UNSELECT_REASON_STOPPED) {
                Timber.d("Unselected because route was stopped, stop playback")
            }
        }
    }

The method we override is onRouteSelected which will be called whenever a new media route has been selected.

When this happens we need to take into account the reason why it was selected.

If the existing route was disconnected (for example, bluetooth headphones were switched off) we should pause or stop playback.

If the route was actively changed, for example when switching from a phone to a Cast device, then we should continue playing the media from its previous playback position - this is the "seamless" part of "seamless media transfer" :)

Get started

To get started with media controls and related features on Android 11 take a look at the official documentation. Also be sure to check out UAMP which contains a reference implementation for many of the features mentioned in this article.

Good luck and remember to play nicely!

Source: Android Developers Blog

6 New ways to engage with users on Android TV

Posted by Dan Aharon, Product Manager, Android TV

This blog post is part of a weekly series for #11WeeksOfAndroid. This week we’re focusing on Android Beyond Phones. So what’s new on Android TV?.

With users asking for more TV shows, movies, and apps than ever, the big screen has become a big deal. There are now over 80% more Android TV monthly active devices than a year ago! Working with 7 of the top 10 Smart TV OEMs and over 160 TV Operators has helped give users more options to spruce up their living room with Android TV. But connecting with this many people wouldn’t have been possible without the developer ecosystem building ~7,000 apps for Google Play on Android TV. Together, our users can now watch, play, and do more on their TVs.

Over the past year, we’ve introduced new features to Android TV to make discovering and accessing your content even easier for users. We updated Google Play with a refreshed look and new app collections while making it easier for users to subscribe to apps. We made additions to the Android TV home screen to highlight trending and important content. And most recently, we released Cast Connect, so your users can cast their favorite content directly to its native Android TV app.

We’ve heard from you on how else we can help support you, and we are excited to announce new ways to help you continue to improve engagement and commerce on the TV:

Easier acquisition and monetization

Google Play Instant on TV: Get users into your app, fast. Google Play Instant allows users to try your app instantly, without installing it.

Let users try your app instantly on Google Play with Google Play Instant on TV

Android TV Emulator with Play Store support: Test your TV projects seamlessly. The Android TV emulator now supports Google Play, so you can test subscriptions faster through the emulator instead of testing on real devices.

PIN code purchases: Make purchases easy. Users will soon be able to purchase content with a PIN code instead of a password on Google Play.

More engaging user experiences

Gboard TV: Typing on TV made easier. New layouts and features are being added to the Google keyboard on TV, including speech-to-text and predictive typing.

Use Gboard TV to bring speech-to-text and predictive typing to your app.

Auto low latency mode: Make gaming on the TV even smoother. Ask Android TV to disable post-processing, and minimize latency whenever a gaming application is shown fullscreen.

Leanback Library Improvements: Simplify app navigation and compatibility with the latest from the leanback library: top tab navigation, paging through media titles and shared code bases across mobile and TV are all simpler now!

This is just the latest for developers. You can find videos, codelabs, and documentation to bring more key features to life on the #11weeksofAndroid site and the Android TV Developers site. Catch the “What’s new on Android TV” video for demos and more info about the features in this post.

If you are just getting started, check out our ADT-3 developer kit and Android 11 Developer Preview to start building your TV experience.

We are excited to see what you come up with next.

Source: Android Developers Blog

System hardening in Android 11

Posted by Platform Hardening Team

In Android 11 we continue to increase the security of the Android platform. We have moved to safer default settings, migrated to a hardened memory allocator, and expanded the use of compiler mitigations that defend against classes of vulnerabilities and frustrate exploitation techniques.

Initializing memory

We’ve enabled forms of automatic memory initialization in both Android 11’s userspace and the Linux kernel. Uninitialized memory bugs occur in C/C++ when memory is used without having first been initialized to a known safe value. These types of bugs can be confusing, and even the term “uninitialized” is misleading. Uninitialized may seem to imply that a variable has a random value. In reality it isn’t random. It has whatever value was previously placed there. This value may be predictable or even attacker controlled. Unfortunately this behavior can result in a serious vulnerability such as information disclosure bugs like ASLR bypasses, or control flow hijacking via a stack or heap spray. Another possible side effect of using uninitialized values is advanced compiler optimizations may transform the code unpredictably, as this is considered undefined behavior by the relevant C standards.

In practice, uses of uninitialized memory are difficult to detect. Such errors may sit in the codebase unnoticed for years if the memory happens to be initialized with some "safe" value most of the time. When uninitialized memory results in a bug, it is often challenging to identify the source of the error, particularly if it is rarely triggered.

Eliminating an entire class of such bugs is a lot more effective than hunting them down individually. Automatic stack variable initialization relies on a feature in the Clang compiler which allows choosing initializing local variables with either zeros or a pattern.

Initializing to zero provides safer defaults for strings, pointers, indexes, and sizes. The downsides of zero init are less-safe defaults for return values, and exposing fewer bugs where the underlying code relies on zero initialization. Pattern initialization tends to expose more bugs and is generally safer for return values and less safe for strings, pointers, indexes, and sizes.

Initializing Userspace:

Automatic stack variable initialization is enabled throughout the entire Android userspace. During the development of Android 11, we initially selected pattern in order to uncover bugs relying on zero init and then moved to zero-init after a few months for increased safety. Platform OS developers can build with `AUTO_PATTERN_INITIALIZE=true m` if they want help uncovering bugs relying on zero init.

Initializing the Kernel:

Automatic stack and heap initialization were recently merged in the upstream Linux kernel. We have made these features available on earlier versions of Android’s kernel including 4.14, 4.19, and 5.4. These features enforce initialization of local variables and heap allocations with known values that cannot be controlled by attackers and are useless when leaked. Both features result in a performance overhead, but also prevent undefined behavior improving both stability and security.

For kernel stack initialization we adopted the CONFIG_INIT_STACK_ALL from upstream Linux. It currently relies on Clang pattern initialization for stack variables, although this is subject to change in the future.

Heap initialization is controlled by two boot-time flags, init_on_alloc and init_on_free, with the former wiping freshly allocated heap objects with zeroes (think s/kmalloc/kzalloc in the whole kernel) and the latter doing the same before the objects are freed (this helps to reduce the lifetime of security-sensitive data). init_on_alloc is a lot more cache-friendly and has smaller performance impact (within 2%), therefore it has been chosen to protect Android kernels.

Scudo is now Android's default native allocator

In Android 11, Scudo replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap, such as:

Scudo does not fully prevent exploitation but it does add a number of sanity checks which are effective at strengthening the heap against some memory corruption bugs.

It also proactively organizes the heap in a way that makes exploitation of memory corruption more difficult, by reducing the predictability of the allocation patterns, and separating allocations by sizes.

In our internal testing, Scudo has already proven its worth by surfacing security and stability bugs that were previously undetected.

Finding Heap Memory Safety Bugs in the Wild (GWP-ASan)

Android 11 introduces GWP-ASan, an in-production heap memory safety bug detection tool that's integrated directly into the native allocator Scudo. GWP-ASan probabilistically detects and provides actionable reports for heap memory safety bugs when they occur, works on 32-bit and 64-bit processes, and is enabled by default for system processes and system apps.

GWP-ASan is also available for developer applications via a one line opt-in in an app's AndroidManifest.xml, with no complicated build support or recompilation of prebuilt libraries necessary.

Software Tag-Based KASAN

Continuing work on adopting the Arm Memory Tagging Extension (MTE) in Android, Android 11 includes support for kernel HWASAN, also known as Software Tag-Based KASAN. Userspace HWASAN is supported since Android 10.

KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs in the Linux kernel. Its Software Tag-Based mode is a software implementation of the memory tagging concept for the kernel. Software Tag-Based KASAN is available in 4.14, 4.19 and 5.4 Android kernels, and can be enabled with the CONFIG_KASAN_SW_TAGS kernel configuration option. Currently Tag-Based KASAN only supports tagging of slab memory; support for other types of memory (such as stack and globals) will be added in the future.

Compared to Generic KASAN, Tag-Based KASAN has significantly lower memory requirements (see this kernel commit for details), which makes it usable on dog food testing devices. Another use case for Software Tag-Based KASAN is checking the existing kernel code for compatibility with memory tagging. As Tag-Based KASAN is based on similar concepts as the future in-kernel MTE support, making sure that kernel code works with Tag-Based KASAN will ease in-kernel MTE integration in the future.

Expanding existing compiler mitigations

We’ve continued to expand the compiler mitigations that have been rolled out in prior releases as well. This includes adding both integer and bounds sanitizers to some core libraries that were lacking them. For example, the libminikin fonts library and the libui rendering library are now bounds sanitized. We’ve hardened the NFC stack by implementing both integer overflow sanitizer and bounds sanitizer in those components.

In addition to the hard mitigations like sanitizers, we also continue to expand our use of CFI as an exploit mitigation. CFI has been enabled in Android’s networking daemon, DNS resolver, and more of our core javascript libraries like libv8 and the PacProcessor.

The effectiveness of our software codec sandbox

Prior to the Release of Android 10 we announced a new constrained sandbox for software codecs. We’re really pleased with the results. Thus far, Android 10 is the first Android release since the infamous stagefright vulnerabilities in Android 5.0 with zero critical-severity vulnerabilities in the media frameworks.

Thank you to Jeff Vander Stoep, Alexander Potapenko, Stephen Hines, Andrey Konovalov, Mitch Phillips, Ivan Lozano, Kostya Kortchinsky, Christopher Ferris, Cindy Zhou, Evgenii Stepanov, Kevin Deus, Peter Collingbourne, Elliott Hughes, Kees Cook and Ken Chen for their contributions to this post.

Source: Android Developers Blog

Android 11 Developer Preview on Android TV

Posted by Xiaodao Wu, Developer Advocate

With the rise in quality content that’s keeping us glued to the big screen, it’s no surprise watch time on the TV continues to grow. As users spend more time in their living rooms, they are also looking to get more from their smart TVs and streaming devices. To help developers meet these needs, we are always working to support the latest Android features on Android TV.

Today, we are releasing an Android 11 Developer Preview for Android TV with many privacy, performance, accessibility and connectivity features. More information can be found on the Android 11 Developer Preview web page.

The Android 11 Developer Preview on TV is for developers (not for consumer use), this image is for ADT-3 developer devices only, it is available by manual download and flash. All user data on the ADT-3 device will be wiped out after flash. Once the device has been flashed to Android 11, you will not be able to go back to the previous Android 10 build.

Download the system image (link) and unzip the file.
Plug in the ADT-3 developer kit for Android TV and enable Developer options.
Run flash-all.sh in the unzipped folder to perform manual system image installation to the ADT-3 device.

The flash-all script uses fastboot and adb tools to upgrade the system. The latest version of fastboot is recommended; developers can find it in the Android SDK Platform-Tools package.

We encourage you to test your Android TV app on the Android 11 Developer Preview. If you have any feedback, please reach out to us. We’d love to hear from you.

Tune in to the Android Beyond Phones week of the #11WeeksOfAndroid on August 10th for even more developer resources from Android TV.

Source: Android Developers Blog

Messenger and Conversations

This blogpost is a collaboration between Google and Messenger from Facebook. Authored by Aaron Labiaga with support from Caleb Gomer and Samuel Guirado from Messenger.

Messenger is ubiquitous in the messaging app world and has pioneered the floating chat bubble. Bubbles help users keep conversations in view and accessible while multitasking, overlaying other UI elements in the foreground, and providing users easy access and visibility to their ongoing chats. Bubbles is one way Android 11 is making the platform more people-centric and expressive, reimagining the way we have conversations on our phones. Messenger’s early pioneering of the floating chat bubble, and the strong reception by users, helped lead to its native implementation in the framework.

Bubbles

The Bubbles API is built on top of the notifications API and is exclusively focused on people in Android 11. First Introduced in Android 10, what was previously an opt-in feature is now on by default. To use bubbles, the developer must create BubbleMetadata, which is set on the notification. This metadata describes the Activity to launch when a bubble is clicked, along with various behaviors relevant to the expanded bubble. The Activity must follow the criteria of being embeddable and resizable in order to use it in a bubble.

Notification bubbles are reserved for conversations with persons in context. These are MessagingStyle notifications with a set long-lived shortcut ID. Please see the following Bubbles code sample how.

A Q&A with the Messenger team

The Messenger team shares their experience with the migration and prospect of the impact of the changes.

How was the migration to bubbles, technical challenges, scope, and impact on codebase?

Prior to Bubbles, Messenger used the SYSTEM_ALERT_WINDOW for its implementation of Bubbles. It achieved our purpose, but hosting complex Android UI outside of Activities is challenging to implement and maintain. Using this natively supported API allowed us to build more traditional, Activity-based Android UI that works well in Bubbles and full screen. This new Bubbles-based chat experience is much simpler and more maintainable than our SAW-based one. We are excited that Android believes that it is a user experience that will help drive improvements in the conversation space.

Ensuring that bubble shortcuts were up-to-date with the latest state of the conversation thread was a technical challenge worth noting. Picture changed, conversation deleted or contact blocked are events that require the bubble shortcut to be updated or even deleted. The Shortcuts API allows for easily registering/unregistering shortcuts and for querying and updating existing ones, which made this whole process very straight forward.

What are your future prospects on the impact of Messenger messages in the conversation space?

The conversation section will give our messages the right visibility. Given that conversation section ranks high in the notification drawer, we definitely want to be present in that space.

A people-centric experience in Android 11

Bubbles are just one way that Android 11 puts people at the heart of the experience for Android; if you’re a messaging or chat app, you should consider using the Bubbles API to help your users as they multi-task. It’s great to see apps like Messenger navigate the openness of Android to create innovative new experiences, and we’re excited to make Bubbles a native experience in Android 11. For more information, please visit the Conversation API guidelines.