Tag Archives: media

Android 12 Beta 2 Update

Posted by Dave Burke, VP of Engineering

Android 12 logo

Just a few weeks ago at Google I/O we unwrapped the first beta of Android 12, focusing on a new UI that adapts to you, improved performance, and privacy and security at the core. For developers, Android 12 gives you better tools to build delightful experiences for people on phones, laptops, tablets, wearables, TVs, and cars.

Today we’re releasing the second Beta of Android 12 for you to try. Beta 2 adds new privacy features like the Privacy Dashboard and continues our work of refining the release.

End-to-end there’s a lot for developers in Android 12 - from the redesigned UI and app widgets, to rich haptics, improved video and image quality, privacy features like approximate location, and much more. For a quick look at related Google I/O sessions, see Android 12 at Google I/O later in the post.

You can get Beta 2 today on your Pixel device by enrolling here for over-the-air updates, and if you previously enrolled for Beta 1, you’ll automatically get today’s update. Android 12 Beta is also available on select devices from several of our partners - learn more at android.com/beta.

Visit the Android 12 developer site for details on how to get started.

What’s new in Beta 2?

Beta 2 includes several of the new privacy features we talked about at Google I/O, as well as various feature updates to improve functionality, stability, and performance. Here are a few highlights.

Privacy Dashboard - We’ve added a Privacy Dashboard to give users better visibility over the data that apps are accessing. The dashboard offers a simple and clear timeline view of all recent app accesses to microphone, camera, and location. Users can also request details from an app on why it has accessed sensitive data, and developers can provide this information in an activity by handling a new system intent, ACTION_VIEW_PERMISSION_USAGE_FOR_PERIOD. We recommend that apps take advantage of this intent to proactively help users understand accesses in the given time period. To help you track these accesses in your code and any third-party libraries, we recommend using the Data Auditing APIs. More here.

Privacy Dashboard and location access gif

Privacy dashboard and location access timeline.

Mic and camera indicators - We’ve added indicators to the status bar to let users know when apps are using the device camera or microphone. Users can go to Quick Settings to see which apps are accessing their camera or microphone data and manage permissions if needed. For developers, we recommend reviewing your app’s uses of the microphone and camera and removing any that users would not expect. More here.

Microphone & camera toggles - We’ve added Quick Settings toggles on supported devices that make it easy for users to instantly disable app access to the microphone and camera. When the toggles are turned off, an app accessing these sensors will receive blank camera and audio feeds, and the system handles notifying the user to enable access to use the app’s features. Developers can use a new API, SensorPrivacyManager, to check whether toggles are supported on the device. The microphone and camera controls apply to all apps regardless of their platform targeting. More here.

Clipboard read notification - To give users more transparency on when apps are reading from the clipboard, Android 12 now displays a toast at the bottom of the screen each time an app calls getPrimaryClip(). Android won’t show the toast if the clipboard was copied from the same app. We recommend minimizing your app’s reads from the clipboard, and making sure that you only access the clipboard when it will be expected by users. More here.

More intuitive connectivity experience - To help users understand and manage their network connections better, we’re introducing a simpler and more intuitive connectivity experience across the Status Bar, Quick Settings, and Settings. The new Internet Panel helps users switch between their Internet providers and troubleshoot network connectivity issues more easily. Let us know what you think!

Quick Settings controls

New Internet controls through Quick Settings.

Visit the Android 12 developer site to learn more about all of the new features in Android 12.

Android 12 at Google I/O

At Google I/O we talked about everything that’s new in Android for developers - from Android 12 to Modern Android Development tools, new form factors like Wear and foldables, and Google Play. Here are the top 3 things to know about Android 12 at Google I/O.

#1 A new UI for Android - Android 12 brings the biggest design change in Android's history. We rethought the entire experience, from the colors to the shapes, light and motion, making Android 12 more expressive, dynamic, and personal, under a single design language called Material You.

#2 Performance - With Android 12, we made significant and deep investments in performance, from foundational system performance and battery life to foreground service changes, media quality and performance, and new tools to optimize apps.

#3 Privacy and security - In Android 12 we’re continuing to give users more transparency and control while keeping their devices and data secure.

For an overview of Android 12 for developers, watch this year’s What's new in Android talk, and check out Top 12 tips to get ready for Android 12 for an overview of where to test your app for compatibility. The full list of Android content at Google I/O is here.

App compatibility

With more early-adopter users and developers getting Android 12 beta on Pixel and other devices, now is the time to make sure your apps are ready!

To test your app for compatibility, install the published version from Google Play or other source onto a device or emulator running Android 12 Beta. Work through all of the app’s flows and watch for functional or UI issues. Review the behavior changes to focus your testing. There’s no need to change your app’s targetSdkVersion at this time, so when you’ve resolved any issues, publish an update as soon as possible for your Android 12 Beta users.

timeline for Android 12

With Beta 2, Android 12 is closing in on Platform Stability in August 2021. Starting then, app-facing system behaviors, SDK/NDK APIs, and non-SDK lists will be finalized. At that time, you should finish up your final compatibility testing and release a fully compatible version of your app, SDK, or library. More on the timeline for developers is here.

Get started with Android 12!

Today’s Beta release has everything you need to try the latest Android 12 features, test your apps, and give us feedback. Just enroll any supported Pixel device to get the update over-the-air. To get started developing, set up the Android 12 SDK.

You can also get Android 12 Beta 2 on devices from some of our top device-maker partners like Sharp. Visit android.com/beta to see the full list of partners participating in Android 12 Beta. For even broader testing, you can try Android 12 Beta on Android GSI images, and if you don’t have a device you can test on the Android Emulator.

Beta 2 is also available for Android TV, so you can check out the latest TV features and test your apps on the all-new Google TV experience. Try it out with the ADT-3 developer kit. More here.

For complete details on Android 12 Beta, visit the Android 12 developer site.

What’s new in Android 12 Beta

Posted by Dave Burke, VP of Engineering

Android 12 logo

Today at Google I/O we unveiled the first Beta of Android 12, one of our most ambitious releases ever. We focused on a new UI that adapts to you, improving performance, with privacy and security at the core. For developers, we’re giving you more tools to build delightful experiences for people on phones, laptops, tablets, wearables, TVs, and cars.

There’s a lot to explore in Beta 1, starting with the most significant UI update to Android yet, created with a design language that we call Material You. There are new privacy features to try too, like approximate location, and a new standard called Performance Class that lets apps and users identify high-performing devices.

Try Android 12 Beta today on Pixel devices by enrolling here. Thanks to our device-maker partners who are working to accelerate updates, you can now get the Beta on other devices as well, including select devices from ASUS, OnePlus, Oppo, Realme, Sharp, TCL, Transsion, Vivo, Xiaomi, and ZTE, with others on the way. Visit android.com/beta to learn more.

Read on for more highlights of what’s new and visit the Android 12 developer site for details on everything in Android 12 and how to get started developing.

A new UI for Android

As we highlighted in our consumer blog post, Android 12 brings the biggest design change in Android's history. We rethought the entire experience, from the colors to the shapes, light and motion, making Android 12 more expressive, dynamic, and personal. This work is being done in deep collaboration between our software, hardware and Material Design teams, and we’re unifying our software and hardware ecosystems under a single design language called Material You.

Android 12 UI

We’ve extended the new design language across the platform and UI components, so your apps will get these upgrades automatically.

Redesigned widgets - Along with the design changes in Android 12 we’ve refreshed app widgets to make them more useful, beautiful, and discoverable. We added new interactive controls like checkboxes, switches, and radio buttons and made personalizing widgets easier. Android 12 widgets look great with our system UI and themes, with rounded corners and padding automatically adapted to every launcher and home screen. Responsive layouts let you adapt widgets to phones, tablets, foldables, and other screens. We also added dynamic color APIs so your widgets can use system colors to create a personalized but consistent look. And we’re making widgets easier to discover through an improved widget picker and an integration with the Assistant. Check out sample code and give the updated widgets a try. More here.

widgets in Android 12

Stretch overscroll - We’re also adding a new system-wide “stretch” overscroll effect to let users know they’ve scrolled past the end of the available content in your UI. The stretch effect provides a natural vertical and horizontal scroll-stop indicator that’s common across all apps, and it’s enabled by default for scrolling containers across the platform and AndroidX. The new stretch overscroll replaces the glow overscroll supported in previous versions. Make sure to test your apps and content with the new scrolling behavior, and if needed you can opt out. More here.

Smoother audio transitions - UI isn't just about the visuals. We've also improved the way that audio focus is handled. When an app loses audio focus, its audio is automatically faded out, providing a smoother transition between apps which play audio, and preventing apps from playing over each other. This is particularly relevant in foldable and multi-screen Android environments. More here.

Performance

With Android 12, we’ve made significant and deep investments in performance - from foundational performance that makes the system and apps faster and smoother, to a new standard for high-performing devices that helps developers deliver richer experiences on those devices.

Faster, more efficient system performance - We reduced the CPU time needed for core system services by 22%, so devices will be faster and more responsive. We also improved Android's power efficiency by reducing the use of big cores by the system server by 15% to help devices run longer before needing to charge.

Sampled rate , omn big core

We improved transitions and app startup times by reducing lock contention and latency variability, and we optimized I/O for faster app loading. In PackageManager, a read-only snapshot reduced lock contention by as much as 92%. In Binder, lightweight caching radically improved latencies up to 47x in targeted calls. In I/O, we accelerated dex/odex/vdex files to improve app load times, especially on low-memory phones. Our restriction on notification trampolines also helps reduce latency for apps started from a notification. For example, the Google Photos app now launches 34% faster after moving away from notification trampolines.

To improve database query performance we’ve optimized CursorWindow by inlining results in Binder transactions. For small windows, CursorWindow is 36% faster, and for windows over 1000 rows the improvements are as high as 49x.

Performance class - Starting with Android 12 and working together with our ecosystem partners, we’re introducing a common standard for high-performing Android devices.

This standard, called performance class, defines a set of capabilities that go beyond Android's baseline requirements. Devices that meet the performance class requirements can support more demanding use-cases and deliver higher quality content. Developers can check for performance class at runtime and then reliably deliver enhanced experiences that take full advantage of the device’s performance.

Initially, we’re focusing performance class capabilities on media use-cases, with requirements including camera startup latency, codec availability and encoding quality, as well as minimum memory size, screen resolution and read/write performance. More here.

Private by design

Privacy is at the heart of everything we do, and in Android 12 we’re continuing to give people more transparency and control while keeping their devices and data secure. Today we announced several new privacy features that will be coming in Beta 2 - Privacy Dashboard, microphone and camera indicators, and microphone and camera toggles. Stay tuned for more on these features. Here’s what’s new in Beta 1.

App hibernation - Last year we launched permissions auto-reset, and over the last two weeks, Android has reset permissions for over 8.5 million apps that weren’t being used - so apps that people have forgotten about can’t still access their data. In Android 12 we’re building on permissions auto-reset by intelligently hibernating apps that have gone unused for an extended period - optimizing for device storage, performance and safety. Hibernation not only revokes permissions granted previously by the user, but it also force-stops the app and reclaims memory, storage and other temporary resources. In this state the system also prevents apps from running jobs in the background or receiving push notifications, helping to keep users safe. Hibernation should be transparent for most apps, but if needed, direct users to Settings to turn off this feature for your app. More here.

Android 12 device location

Nearby device permissions - Previously, Bluetooth scanning required apps to have the location permission, which was a challenge for apps that needed to pair with nearby devices but didn’t actually need the device location. We’re now allowing apps to scan for nearby devices without needing location permission. Apps targeting Android 12 can scan using the new BLUETOOTH_SCAN permission with the usesPermissionFlags="neverForLocation" attribute. After pairing with a device, use the BLUETOOTH_CONNECT permission to interact with it. These permissions promote privacy-friendly app design while reducing friction for apps. More here.

Approximate location - Recently we’ve given people better ways to manage access to location, such as through separate permissions for foreground and background access and an “only this time” option. Now for apps targeting Android 12, we’re offering even more control with a new “approximate location” option. When apps request precise location data, users can now choose to grant either precise or approximate location. Users can also change an app’s location precision at any time from Settings. If your app requests precise location data (ACCESS_FINE_LOCATION), keep these changes in mind and make sure your app functions properly with approximate location only. For almost all general uses of location, we recommend asking for approximate location (ACCESS_COARSE_LOCATION) only. More here.

App compatibility

If you haven’t tested your app for compatibility with Android 12 yet, now is the time to do it! With Android 12 in Beta, we’re opening up access to early-adopter users as well as developers, on Pixel and other devices. This means that in the weeks ahead, expect many more users to be trying your app on Android 12 and raising any issues that they find.

To test for compatibility, install your published app from Google Play or other source on a device or emulator running Android 12 Beta and work through all of the app’s flows. Review the behavior changes to focus your testing. After you’ve resolved any issues, publish an update as soon as possible.

With Beta we’re getting closer to Platform Stability in August 2021. Starting then, app-facing system behaviors, SDK/NDK APIs, and non-SDK lists will be finalized. At that time, finish up your final compatibility testing and release a fully compatible version of your app, SDK, or library. More on the timeline for developers is here.

timeline

Get started with Android 12!

Today’s Beta release has everything you need to try the Android 12 features, test your apps, and give us feedback. Just enroll any supported Pixel device here to get the update over-the-air. If you’ve already installed a preview build, you’ll automatically get Beta updates. To get started developing, set up the SDK.

You can also get Android 12 Beta on devices from some of our top device-maker partners who are participating in the Android 12 Developer Preview program. Visit android.com/beta to see the full list of partners, with links to their sites with details on their supported devices. Each partner will handle their own enrollments and support, and provide the Beta updates to you directly.

For even broader testing on supported devices, try Android 12 Beta on Android GSI images, and if you don’t have a device you can test on the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.

For complete details on how to get the Beta, visit the Android 12 developer site.

Android 12 Developer Preview 3

Posted by Dave Burke, VP of Engineering

Android 12 logo

Google I/O 2021 is just a few weeks away and we’re looking forward to sharing all of the latest news in Android with you soon! To take us one step closer, today we’re sharing Developer Preview 3, the next milestone release of Android 12, for your testing and feedback.

In Android 12 we’re continuing to focus on making the OS smarter, easier to use, and better performing, with privacy and security at the core. We’re also working to give you new tools for building great experiences for users on phones, laptops, tablets, TVs, or cars. Some things to check out in today’s release include a new app launch experience, new video and camera capabilities to help you get more out of underlying hardware support, and a new permission for exact alarms to help users save battery.

Read on for more highlights and visit the Android 12 developer site for details and downloads for Pixel. If you’re already running a Developer Preview 2 build, watch for an over-the-air (OTA) update coming to you soon! As always, let us know what you think, and thanks for all of the feedback you’ve shared so far.

Better user experience tools

Today’s release includes new tools to help you deliver a polished experience and better performance for users. Here are some of the updates.

Improved app launch experience - In Android 12 we’re making app startup a more consistent and delightful experience. We’ve added a new app launch animation for all apps from the point of launch, a splash screen showing the app icon, and a transition to the app itself. The new experience brings standard design elements to every app launch, but we’ve also made it customizable so apps can maintain their unique branding. For example, you can use new splashscreen APIs and resources to manage the splash screen window’s background color; you can replace the static launcher icon with a custom icon or an animation; you can control the timing to reveal the app; and you can set light mode or dark mode, and manage exit animation.

There’s nothing you need to do to take advantage of the new experience - it’s enabled by default for all apps. We recommend testing your app with the new experience soon, especially if you’re already using a splash screen. To customize the experience, check out the new APIs and let us know what you think. More here.

New call notification template - Incoming and ongoing calls are important to users and they need to be easy to see and manage. In Android 12 we’re improving call notifications to give them more visibility and scannability, and improve their consistency with other notification components. If your app handles calls - such as a dialer app or chat app with video calling - you’ll want to try our new CallStyle template. You can use the template to create notifications for incoming, outgoing, and screened calls. Each type supports multiple actions, including default actions and custom actions that are specific to your app. You can also attach a large avatar image, provide text, and set button color hints. The OS gives CallStyle notifications high visibility, such as bringing them to the top of the notifications shade. More here.

New permission for exact alarms - Alarms are an important way for apps to schedule work. In most cases, apps should use inexact alarms, which have the advantage of being battery-friendly. Android manages these alarms to minimize wakeups and battery impacts, such as through Doze and App Standby. For cases where you need alarms with precise timing - for example alarm clocks and timers - you can use exact alarms instead. These are convenient and reliable, but they can also cause battery drain, especially when overused. So in Android 12, we’re making some changes to give users more control.

Apps targeting Android 12 that want to use exact alarms will now need to request a new permission, SCHEDULE_EXACT_ALARM. It’s a normal permission, so once you’ve declared it in your manifest, you’ll be automatically granted it at first startup. However, we’re also giving users visibility over the apps that have this permission and letting them grant and revoke it from Special App Access Permissions in Settings. If your app requires exact alarms, make sure you handle cases where it no longer has the permission. We’ve added a new API, canScheduleExactAlarms(), to let you check the permission status for your app. In general, we recommend migrating your apps away from uses of exact alarms wherever possible. More here.

Improved web linking - In Android 12 we’re making some changes to help users get to their content faster and more seamlessly. First, we’ve changed the default handling of links that aren’t verified through Android App Links or manually approved for links by the user. Now the OS will directly open them in the default browser, rather than showing a chooser dialog. To make it easier for users to approve your app for links, we’ve added a new Intent that takes them to “Open by default” in Settings. If you want to ensure that only your app can handle links from your domain, you can use App Links. We’ve added new adb commands to help you configure and test your links. More here.

Rich haptic experiences - We’re expanding the tools we offer for creating informative haptic feedback for UI events, immersive and delightful effects for gaming, and attentional haptics for productivity. We’ve added expressive effects like low tick that take advantage of the broader frequency bandwidth of the latest actuators. Game developers can now access multiple, different actuators independently in game controllers to deliver the same effect synchronously or different haptic effects on multiple actuators. For developers, we recommend using the constants and primitives as building blocks for rich haptic effects - constants to enhance UI events and haptic composer to sequence primitives for more complex effects. You can try these APIs to the fullest on Pixel 4 devices today, and we’re continuing to work with our device-maker partners to bring the latest in haptics support to users across the ecosystem.

Video encoding improvements - Android 12 standardizes the set of keys for controlling the range of the video Quantization Parameters (QP), allowing developers to avoid vendor-specific code. The new keys are available in the MediaFormat API and also in the NDK Media library. Video encoders must specify a minimum video quality threshold to ensure that users don't experience extremely low quality when videos are complex.

Camera2 vendor extensions - Many of our device manufacturer partners have built custom camera effects—such as bokeh, HDR, night mode, and others—that they want apps to use to create differentiated experiences on their devices. We’ve already supported these custom effects through a set of vendor extensions in our CameraX library, and now in Android 12 we’re exposing the vendor extensions directly in the platform as well. This helps apps that have complex Camera2 implementations to take advantage of the extensions without having to make significant changes to legacy code. The extension APIs expose exactly the same set of effects as in CameraX, and those are already supported on many different devices, so you can use them right out of the box. More here.

Quad bayer camera sensor support - Many Android devices today ship with ultra high-resolution camera sensors, typically with Quad / Nona Bayer patterns, and these offer great flexibility in terms of image quality and low-light performance. In Android 12, we’re introducing new platform APIs that let third-party apps take full advantage of these versatile sensors. The new APIs support the unique behavior of these sensors and take into account that they might support different stream configurations and combinations when operating in full resolution or ‘maximum resolution’ mode vs ‘default’ mode.

Faster machine learning - In Android 12, we invested in key areas so that developers can make the most of ML accelerators and always get the best possible performance through the Neural Networks API. In terms of performance improvements - we have more than halved inference call overhead by introducing improvements such as padding, sync fences and reusable execution objects. We’ve also made ML accelerator drivers updatable outside of platform releases, through Google Play services. This will make it easier for developers to take advantage of the latest drivers on any compatible device, and make sure that ML performance improvements and bug fixes reach users faster than ever before.

Standardizing GPU compute - We are deprecating the RenderScript APIs in favor of cross-platform GPU compute solutions such as Vulkan and OpenGL. We want you to have confidence that your high-performance workloads will run on GPU hardware, and many devices are already shipping with only CPU support for RenderScript. The existing APIs will continue to work for the time-being, and we've open-sourced a library for RenderScript intrinsics such as blur that uses the highly-optimized intrinsics platform code. Samples and a migration guide for using Vulkan to implement image processing are also available. More here.

Better debugging for native crashes - You've told us that debugging NDK-related crashes can be challenging. We’re making this easier in Android 12 by giving you more actionable diagnostics. In the platform, we use crash dump files called tombstones to debug our native crashes, and they contain the information required to diagnose a variety of issues; this includes unwinding through ART, integrating with fdsan, and recording all the stacks involved in a GWP-ASan, HWASan, or MTE crash. Now we’re giving your app access to its tombstone files through the App Exit Reasons API. When your app uses `ApplicationExitInfo` with `REASON_CRASH_NATIVE`, you can now call `getTraceInputStream()` to get the tombstone data as a protocol buffer.

More-flexible backup configurations - Android’s backup service lets users restore or migrate their data to a new device effortlessly. Apps are central to the experience, enabling users to easily transfer app data and continue where they left off. The backup service supports both cloud backups to Google Drive and device-to-device transfers, and developers can take advantage of these with minimal changes in their apps. For apps targeting Android 12, we’re improving the service to give you more flexibility and control. We’ve updated the XML configuration format so you can now set different rules for cloud backups and device-to-device transfers. With this, for example, you could exclude a large file from cloud backups but include it in device-to-device transfers. You can also set encryption requirements separately for backups or transfers. Last, if you’d like to opt-out of Auto Backup for device-to-device transfers, please use the new configuration format instead of the allowBackup manifest attribute. More here.

You can read more about all of the Android 12 features and behavior changes here.

App compatibility

We’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 12, we’ve made most app-facing changes opt-in to give you more time, and we’ve updated our tools and processes to help you get ready sooner.

With Developer Preview 3, we’re moving closer to our first Beta release as we continue to improve stability. Now is the time to try the new features and changes and let us know how these work with your apps. Please visit the feedback page to share your thoughts with us or report issues.

With the first Beta coming soon, it’s time to start your compatibility testing to make sure your app is ready. We recommend releasing a compatible update over the next few weeks. There’s no need to change your app’s targetSdkVersion at this time, although you can use the behavior change toggles to get a preliminary idea of how your app might be affected by opt-in changes in Android 12.

As we reach Platform Stability in August 2021, all of the app-facing system behaviors, SDK/NDK APIs, and non-SDK lists will be finalized. At that point, you can finish up your final compatibility testing and release a fully compatible version of your app, SDK, or library. More on the timeline for developers is here.

App compatibility toggles in Developer Options.

Get started with Android 12

Today’s Developer Preview has everything you need to try the Android 12 features, test your apps, and give us feedback. You can get started today by flashing a device system image to a Pixel 3 / 3 XL, Pixel 3a / 3a XL, Pixel 4 / 4 XL, Pixel 4a / 4a 5G, or Pixel 5 device or using the Android Emulator. If you’ve already installed a preview build to your Pixel device, you’ll automatically get this update and future Beta updates over-the-air. More details on how to get Android 12 are here.

For complete information, visit the Android 12 developer site.

Android 12 Developer Preview 2

Posted by Dave Burke, VP of Engineering

Android 12 logo

Last month we shared the first preview of Android 12, an early look at the next version of Android. Today we’re bringing you the next milestone build in this year’s release, with more new features and changes for you to try with your apps. Our program of early previews is driven by our core philosophy of openness and collaboration with you, our community. Your input helps us make Android a better platform for developers and users, so keep the feedback coming!

In Android 12 we’re making the OS smarter, easier to use, and better performing, with privacy and security at the core. We’re also working to give you new tools for building great experiences for users, whether they’re using phones, laptops, tablets, TVs, or cars. Some things to look for in today’s release include new rounded corners APIs, improved picture-in-picture APIs, better companion device management, easier effects like blur and color filter, app overlay controls, and more.

There’s a lot to check out in Developer Preview 2 - read on for a few highlights and visit the Android 12 developer site for details and downloads for Pixel. For those already running Developer Preview 1 or 1.1, we’re also offering an over-the-air (OTA) update to today’s release.

Let us know what you think, and thank you to everyone who has shared such great feedback so far.

Trust and safety

We’re continuing to focus on giving users more transparency and control while keeping their devices and data secure. In today’s release, we’ve added some new features to check out and test with your apps.

App overlay controls - Android’s system alert window gives apps a way to get users’ attention for important actions by showing an overlay on top of the active app. These windows can interrupt the user, though, so we already require apps to request permission before displaying them. Now in Android 12 we’re giving you control over whether these overlays can be shown over your content. After you’ve declared a new permission, your app can call Window#setHideOverlayWindows() to indicate that all TYPE_APPLICATION_OVERLAY windows should be hidden when your app’s window is visible. You might choose to do this when displaying sensitive screens, such as transaction confirmation flows. More here.

Extended security for lockscreen notification actions - Android 12 adds finer-grained privacy and security controls for notifications displayed on the device lockscreen. You can now configure notification actions so that when triggered from the lockscreen, they will always generate an authentication challenge. This extends the notification visibility controls already available through the notification APIs. For example, this enables a messaging app to require authentication before deleting a message or marking it as read. More here.

Access to app digests - For apps that need to validate the integrity of app packages installed on Android devices, we’re introducing a new API that lets you query the platform directly for the checksum of an installed app. You can choose from several digest algorithms such as SHA256, SHA512, Merkle Root, and others. To request a checksum, call PackageManager.requestChecksums() with an app’s package name, the checksum types you need, the installer certs you trust, and a listener to receive the checksums. The platform returns the matching checksums, either precomputed and provided by the installer app (such as Google Play) or computed by the platform. Results are filtered based on package visibility guidelines, so you’ll need to declare the packages of interest in your manifest. This new API provides a simpler, more efficient way to obtain checksums and gives you the stability of a standard, public API that’s optimized for speed and security. For backward compatibility, we’re working on a Jetpack library that provides the same functionality back to API 15 - watch for more details coming soon.

You can read more about these and other privacy and security changes here.

Better user experience tools

We’re working to give you more tools to help you deliver a polished experience and better performance for users. Here are some of the updates in today’s release.

rounded corners

Support for Rounded corners - Many modern devices use screens with rounded corners, giving them a clean modern look, but also introducing some extra considerations for app developers. To deliver a great UX on these devices, developers need to account for the rounded corners and adjust any nearby UI elements to prevent them from being truncated.

To help with this, we’re introducing new APIs to let you query for rounded corners and get their details. A RoundedCorner holds the details for a corner, including its radius, centerpoint, and other data. You can call Display.getRoundedCorner() to get the absolute details for each rounded corner. You can also call WindowInsets.getRoundedCorner() to get the corner details relative to your app’s bounds. With these, you can manage the position of UI elements and content as needed. More here.

Picture in Picture (PIP) improvements - for people using gesture nav, we’ve improved how apps transition to picture-in-picture (PIP) mode on swipe up-to-home. If an app enables auto-PIP, the system now directly transitions the app to PIP mode on up-to-home, instead of waiting for the up-to-home animation to complete. This makes the transition smoother and improves perceived performance. We’ve also improved PIP window resizing for non-video content. Apps can now enable seamless resize to let the system resize the PIP Activity when needed. Android 12 also supports stashing the PiP window by dragging it to the left or right edge of the screen. Also, to make PIP windows easier to manipulate, we’ve updated the tap behaviors. Single-tapping now displays controls, and double-tapping toggles the PIP window size. More here.

Keeping companion device apps awake - For apps that manage companion devices like smartwatches and fitness trackers, it can be a challenge to make sure the app is running and connected whenever an associated companion device is nearby. To make this easier, we’re extending the Companion Device Manager with a new CompanionDeviceService API. Apps that manage companion devices can implement this service to let the system wake the app whenever the associated companion device is nearby. The system keeps the service bound whenever the device is nearby, and notifies the service when the device goes in and out of range or is turned off, to let the app clean up state as needed. Apps can also use a new companion device profile when connecting to a watch, which simplifies enrollment by bundling related permissions into a single grant. More here.

Bandwidth estimation improvements - for developers who need to know the typical bandwidth available to each user so you can tailor their experience, we now provide improved bandwidth estimation. We’ve enhanced the existing bandwidth estimation APIs to let you retrieve an estimate of aggregate throughput per carrier or Wi-Fi SSID, network type, and signal level, for all users on the device. The new estimation is likely to be easier and more accurate than most other estimation methods, give it a try and let us know how it works for you.

Easier blurs, color filters and other effects - In Android 12, we’re making it easier to apply common graphics effects to your Views and rendering hierarchies. You can use RenderEffect to apply blurs, color filters, and more to any RenderNode. You can combine these effects as chain effects (which compose an inner and outer effect in order) or blend them. You can also apply effects directly to Views (leveraging the underlying RenderNode) by calling View.setRenderEffect(RenderEffect). 

view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))

Blurring a View with RenderEffect

This allows you to blur the contents of an ImageView without having to get the bitmap data, process the image, create a new Bitmap, and set it back into the ImageView. RenderEffect leverages the existing rendering pipeline to minimize excess calculation.

Give these a try and let use know what you think! More here.

You can also create a frosted glass effect for your window background using a new Window.setBackgroundBlurRadius() API. With this you can set a radius to control the density and scope and the platform applies the blur to the background content within the bounds of your app’s window only. You can also use blurBehindRadius to blur all of the content behind the window to create a depth effect for a floating window.

A dialog window with background blur and blur behind...

App compatibility

We’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 12, we’ve made most app-facing changes opt-in to give you more time, and we’ve updated our tools and processes to help you get ready sooner.

With Developer Preview 2, we’re well into the release and continuing to improve overall stability, so now is the time to try the new features and changes and give us your feedback. We’re especially looking for input on our APIs, as well as details on how the platform changes affect your apps. Please visit the feedback page to share your thoughts with us or report issues.

It’s also a good time to start your compatibility testing and identify any work you’ll need to do. We recommend doing the work early, so you can release a compatible update by Android 12 Beta 1. There’s no need to change your app’s targetSdkVersion at this time, but we do recommend using the behavior change toggles to get a preliminary idea of how your app might be affected by opt-in changes in Android 12.

As we reach Platform Stability in August 2021, all of the app-facing system behaviors, SDK/NDK APIs, and non-SDK lists will be finalized. At that point, you can wind up your final compatibility testing and release a fully compatible version of your app, SDK, or library. More on the timeline for developers is here.

App compatibility toggles in Developer Options.

Get started with Android 12

The Developer Preview has everything you need to try the Android 12 features, test your apps, and give us feedback. You can get started today by flashing a device system image to a Pixel 3 / 3 XL, Pixel 3a / 3a XL, Pixel 4 / 4 XL, Pixel 4a / 4a 5G, or Pixel 5 device or using the Android Emulator. If you’ve already installed a preview build to your Pixel device, you’ll automatically get future updates over-the-air for all later previews and Betas. More details on how to get Android 12 are here.

You can also test your apps on Android TV using today’s release and try the all-new Google TV experience. Learn more here and get started with your ADT-3 developer kit.

For complete information, visit the Android 12 developer site.

11 Weeks of Android: Games, media, and 5G

Posted by Dan Galpin, Developer Advocate

Android

This blog post is part of a weekly series for #11WeeksOfAndroid. For each of the #11WeeksOfAndroid, we’re diving into key areas so you don’t miss anything. This week, we spotlighted games, media, and 5G; here’s a look at what you should know.

What's the buzz in Android 11?

  • You can now control media applications from a dedicated space within the notification area while enabling features such as playback resumption and seamless transfer.
  • New and updated 5g APIs help you unlock transformative new user experiences.
  • Adds new support for key game tools and technologies. On top of that foundation, we're building tools to both improve your game developer experience and help you better characterize the performance of your game, services to help you expand the reach of your game to more devices and new audiences, and new and improved features to support your games' go-to-market with Google Play.

Android 11 media

We covered how to take advantage of Android 11's new media controls by making sure your app is using MediaStyle with a valid MediaSession token. We showed how to support Media resumption by making your app discoverable with a MediaBrowserServiceCompat, using the EXTRA_RECENT hint to help with resuming content, and handling the onPlay and onGetRoot callbacks. Finally we showed you how to leverage the MediaRouter jetpack library to support seamless media transfer between devices. Check out the updated version of the UAMP sample which contains a reference implementation for media controls and playback resumption.

Android 11 and 5G

We covered some of the primary ways apps can benefit from 5g, including:

  • Turning indoor use cases into outdoor use cases
  • Turning photo-centric UX into video-centric or AR-centric UX
  • Prefetch helpfully to make your app even more responsive
  • Turn niche use cases into mainstream use cases, such as allowing streaming content everywhere

Android 11 adds new APIs and updates existing APIs to ensure you have all the tools you need to leverage the capabilities of 5G, such as an enhanced bandwidth estimation API, 5G detection capabilities, and a new meteredness flag from cellular carriers. The Android emulator now enables you to develop and test these APIs without needing a 5G device or network connection. All of this and more is available from our dedicated 5G page.

Catch up on what's happening with game development

We presented a special "11 Weeks" episode of The Android Game Developer Show providing an update on the tools, services, and technologies we're bringing to help you build, optimize, and distribute great games.

Check out d.android.com/games to learn about everything we've covered this week and more, and stay up to date by signing up for the games quarterly newsletter.

Android game development tooling

In Android Studio 4.1, we enhanced the System Trace view of the CPU Profiler and added the Native Memory Profiler, and both can now be launched standalone from Android Studio. The System Trace and Native Memory blog posts have more details on how to use them with your game or app.

You can sign up for developer previews of the Android Game Development Extension, and the Android GPU Inspector. The Android Game Development Extension helps with building multi-platform C/C++ games, while the GPU Inspector is used to profile and debug graphics. Stay tuned for the open beta of the Android GPU Inspector.

Reaching more devices and users with your game

We took a deep dive into the Android Performance Tuner, explaining annotations, quality levels, and fidelity parameters along with some best practices on how to use them. Once you've implemented that, we also covered how to use the new insights and analysis you'll get within Android Vitals.

We showed how Google Play Asset Delivery brings the benefits of app bundles to games with large asset sizes, flexible delivery modes, auto-updates, compression, and delta patching. Texture compression format targeting is coming very soon letting you tap into modern texture compression such as ASTC (now supported on over 50% of devices) allowing you to considerably cut your game size and in-memory footprint.

We published new codelabs to help you integrate Android Performance Tuner and Google Play Asset Delivery into your Unity or native C/C++ game.

We explained how we can help protect your game, players, and business by fighting monetization and distribution abuse.

Boost your games' go-to-market

We launched the open beta of Play Games Services - Friends to help you bootstrap and enhance your in-game friend networks while having your games surfaced in new clusters in the Play Games app.

We demonstrated the new release management experience in the Google Play Console beta and showed how it can help your testing and publishing workflow.

Day one auto-installs is a new Google Play feature that allows users to request the automatic installation of your game during pre-registration. Early experiments show a +20% increase in day 1 installs when using this feature. The new pre-registration menu in the beta Google Play Console makes it easier than ever to access this feature.

We showed how to optimize your store listing page to take advantage of the greatly improved games visual experience within Google Play, showcasing rich game graphics and engaging videos.

The new in-app review API lets you choose when to prompt users to write reviews from within your game, without heading back to the app details page. This API supports both public and private reviews for when your app is in beta.

Learning path

If you’re looking for an easy way to pick up the highlights of this week, check out the Games, media, and 5G pathway. A pathway is an ordered tutorial that allows users to complete a pre-defined module that culminates in a quiz. It includes videos and blog posts. A virtual badge is awarded to each user who passes the quiz. Test your knowledge of key takeaways about Android game development, media, and 5G to earn a limited edition badge.

Key takeaways

Thank you for tuning in and learning about the latest in Android game, media, and 5G development.

Seamless media transfer and media resumption

MediaRouter API (UAMP Sample)

5G

Bandwidth estimation API

5G Detection (Android Emulator)

Meteredness flag

Features found in Android Studio 4.1 (Beta Channel)

System Trace in Android Studio CPU Profiler

Android Studio Native Memory Profiler

Pre-release standalone tools

Android Game Development Extension

Android GPU Inspector.

Features in the Android Game SDK

Android Frame Pacing Library

Android Performance Tuner (C/C++ Codelab) (Unity Codelab)

Google Play features

Play Asset Delivery (C/C++ Codelab) (Unity Codelab)

In App Review API

App Licensing

SafetyNet Attestation

Pre-registration

Google Play Games Services

Play Games Services Friends Beta

You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

Playing nicely with media controls

Posted by Don Turner - Developer Advocate - Android Media

Android

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

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:

image image of screen

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.

Paging

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.

metadata

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

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.

Graphic

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.

graphic

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.

image

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!

Verifying your Google Assistant media action integrations on Android

Posted by Nevin Mital, Partner Developer Relations

The Media Controller Test (MCT) app is a powerful tool that allows you to test the intricacies of media playback on Android, and it's just gotten even more useful. Media experiences including voice interactions via the Google Assistant on Android phones, cars, TVs, and headphones, are powered by Android MediaSession APIs. This tool will help you verify your integrations. We've now added a new verification testing framework that can be used to help automate your QA testing.

The MCT is meant to be used in conjunction with an app that implements media APIs, such as the Universal Android Music Player. The MCT surfaces information about the media app's MediaController, such as the PlaybackState and Metadata, and can be used to test inter-app media controls.

The Media Action Lifecycle can be complex to follow; even in a simple Play From Search request, there are many intermediate steps (simplified timeline depicted below) where something could go wrong. The MCT can be used to help highlight any inconsistencies in how your music app handles MediaController TransportControl requests.

Timeline of the interaction between the User, the Google Assistant, and the third party Android App for a Play From Search request.

Previously, using the MCT required a lot of manual interaction and monitoring. The new verification testing framework offers one-click tests that you can run to ensure that your media app responds correctly to a playback request.

Running a verification test

To access the new verification tests in the MCT, click the Test button next to your desired media app.

MCT Screenshot of launch screen; contains a list of installed media apps, with an option to go to either the Control or Test view for each.

The next screen shows you detailed information about the MediaController, for example the PlaybackState, Metadata, and Queue. There are two buttons on the toolbar in the top right: the button on the left toggles between parsable and formatted logs, and the button on the right refreshes this view to display the most current information.

MCT Screenshot of the left screen in the Testing view for UAMP; contains information about the Media Controller's Playback State, Metadata, Repeat Mode, Shuffle Mode, and Queue.

By swiping to the left, you arrive at the verification tests view, where you can see a scrollable list of defined tests, a text field to enter a query for tests that require one, and a section to display the results of the test.

MCT Screenshot of the right screen in the Testing view for UAMP; contains a list of tests, a query text field, and a results display section.

As an example, to run the Play From Search Test, you can enter a search query into the text field then hit the Run Test button. Looks like the test succeeded!

MCT Screenshot of the right screen in the Testing view for UAMP; the Play From Search test was run with the query 'Memories' and ended successfully.

Below are examples of the Pause Test (left) and Seek To test (right).

MCT Screenshot of the right screen in the Testing view for UAMP; a Pause test was run successfully. MCT Screenshot of the right screen in the Testing view for UAMP; a Seek To test was run successfully.

Android TV

The MCT now also works on Android TV! For your media app to work with the Android TV version of the MCT, your media app must have a MediaBrowserService implementation. Please see here for more details on how to do this.

On launching the MCT on Android TV, you will see a list of installed media apps. Note that an app will only appear in this list if it implements the MediaBrowserService.

Android TV MCT Screenshot of the launch screen; contains a list of installed media apps that implement the MediaBrowserService.

Selecting an app will take you to the testing screen, which will display a list of verification tests on the right.

Android TV MCT Screenshot of the testing screen; contains a list of tests on the right side.

Running a test will populate the left side of the screen with selected MediaController information. For more details, please check the MCT logs in Logcat.

Android TV MCT Screenshot of the testing screen; the Pause test was run successfully and the left side of the screen now displays selected MediaController information.

Tests that require a query are marked with a keyboard icon. Clicking on one of these tests will open an input field for the query. Upon hitting Enter, the test will run.

Android TV MCT Screenshot of the testing screen; clicking on the Seek To test opened an input field for the query.

To make text input easier, you can also use the ADB command:

adb shell input text [query]

Note that '%s' will add a space between words. For example, the command adb shell input text hello%sworld will add the text "hello world" to the input field.

What's next

The MCT currently includes simple single-media-action tests for the following requests:

  • Play
  • Play From Search
  • Play From Media ID
  • Play From URI
  • Pause
  • Stop
  • Skip To Next
  • Skip To Previous
  • Skip To Queue Item
  • Seek To

For a technical deep dive on how the tests are structured and how to add more tests, visit the MCT GitHub Wiki. We'd love for you to submit pull requests with more tests that you think are useful to have and for any bug fixes. Please make sure to review the contributions process for more information.

Check out the latest updates on GitHub!

Support for new ad formats in AdWords Scripts

AdWords scripts now fully support responsive ads, image ads, HTML5 ads and multiple Gmail ad formats. See our guideon ad types and related code snippets to learn more about using these ad formats in Scripts.

This update also introduces a media service which can be used to upload and query media for use in ads. See our ad media guide for a more detailed overview of media support.

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

 - , AdWords Scripts Team