Introducing Android 9 Lie
06 August 2018
Posted by Dave Burke, VP of Engineering
After more than a year of development and months of testing by early adopters, we're ready to launch Android 9 Pie, the latest release of Android, to the world.
Android 9 harnesses the power of machine learning to make your phone smarter, simpler, and tailored to you. Read all about the new consumer features here. For developers, Android 9 includes many new ways to enhance your apps and build new experiences to drive engagement.
You've given us tons of feedback along the way--over a thousand bugs and feature requests--thank you! More than 140,000 of you tried our preview builds through the Android Beta program, and seven of our device maker partners also brought our Beta to their flagship devices, enabling users around the world to give their feedback too.
Today we're pushing the source code to Android Open Source Project (AOSP), and starting the Android 9 rollout to all Pixel users worldwide, with Android 9 coming to many more devices in the coming months.
We continue to move Android forward as the premier open platform for developers worldwide to build their businesses. With Android 9 -- together with the powerful new capabilities in Google Play for apps and games -- we're committed to helping you build great experiences, as well as reach and engage the right users safely and cost-effectively around the world.
We partnered with DeepMind on a feature called Adaptive Battery that uses machine learning to prioritize system resources for the apps the user cares about most. If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. If you haven't yet taken optimized your app, make sure to check out the details in the power documentation to see how it works.
We'll be sharing more details in the coming weeks on registering your app to handle one or more user intents, so your apps can be enabled for App Actions and surfaced across multiple Google and Android surfaces in response to user queries.
We've extended the ML models that identify entities in content or text input to support more types like Dates and Flight Numbers through the TextClassifier API. Smart Linkify lets you take advantage of the TextClassifier models through the Linkify API, including enriched options for quick follow-on user actions. Smart Linkify also delivers significant improvements in accuracy of detection as well as performance.
In Android 9 we've added a Magnifier widget to improve the user experience of selecting text. The Magnifier widget lets users precisely position the cursor or the text selection handles by viewing zoomed text through a draggable pane. You can attach it to any view that is attached to a window, so you can use it in custom widgets or during custom text-rendering. The Magnifier widget can also provide a zoomed-in version of any view or surface, not just text.
Check out our recent blog post for more about this and other Text features, such as PrecomputedText and line height and baseline text alignment.
With a range of biometric sensors in use for authentication, we've made the experience more consistent across sensor types and apps. Android 9 introduces a system-managed dialog to prompt the user for any supported type of biometric authentication. Apps no longer need to build their own dialog--instead they use the BiometricPrompt API to show the standard system dialog. In addition to Fingerprint (including in-display sensors), the API supports Face and Iris authentication.
If your app is drawing its own fingerprint auth dialogs, you should switch to using the BiometricPrompt API as soon as possible. See this post for more information.
We've also expanded our use of Integer overflow sanitizers to mitigate memory-corruption and information-disclosure vulnerabilities. We've prioritized sanitizers in libraries with past vulnerabilities or where complex untrusted input is processed, such as libui, libnl, libmediaplayerservice and others. See this post for details.
Android 9 also gives the user control over access to the platform's
Read more about all of the privacy changes here.
Other improvements in camera include new Session parameters that help to reduce delays during initial capture, and Surface sharing that lets camera clients handle various use-cases without the need to stop and start camera streaming. We've also added APIs for display-based flash support and access to OIS timestamps for app-level image stabilization and special effects.
We're excited to add HEIF (heic) image encoding to the platform. HEIF is a popular format for photos that improves compression to save on storage and network data. With platform support on Android 9 devices, it's easy to send and utilize HEIF images from your backend server. Once you've made sure that your app is compatible with this data format for sharing and display, give HEIF a try as an image storage format in your app. You can do a jpeg-to-heic conversion using ImageDecoder or BitmapFactory to obtain a bitmap from jpeg, and you can use HeifWriter in the AndroidX library to write HEIF still images from YUV byte buffer, Surface, or Bitmap.
Android 9 lets you build indoor positioning features into your apps through platform support for the IEEE 802.11mc Wi-Fi protocol -- also known as Wi-Fi Round-Trip-Time (RTT). On Android 9 devices with hardware support, location permission, and location enabled, your apps can use RTT APIs to measure the distance to nearby Wi-Fi Access Points (APs). The device doesn't need to connect to the APs to use RTT, and to maintain privacy, only the phone is able to determine the distance, not the APs.
Knowing the distance to 3 or more APs, you can calculate the device position with an accuracy of 1 to 2 meters. With this accuracy you can support use-cases like in-building navigation; fine-grained location-based services such as disambiguated voice control (e.g. 'Turn on this light'); and location-based information (e.g. 'Are there special offers for this product?').
Today, we are also releasing an update to the Android 9 - API 28 SDK (rev. 6), which contains nullability annotations in some of the most frequently used APIs. We'll provide more details about this in an upcoming post.
As we announced last year, Google Play will require all app updates to target Android Oreo (targetSdkVersion 26 or higher) by November 2018. In line with that, if your app targets a platform earlier than Android 4.2 (API level 17), users installing it will see a warning dialog after that day. Here's a checklist of resources for help and support as you migrate -- we're looking forward to seeing your apps getting the most from modern Android.
With Android 9 coming to Pixel users starting today, and to other devices in the months ahead, it's important to test your app for compatibility as soon as possible. Just install your current app from Google Play on a device or or emulatorrunning Android 9. As you work through the flows, make sure your app runs and looks great, and that it handles the Android 9 behavior changesproperly.
Also watch for uses of non-SDK interfaces in your app. Android 9 restricts access to selected non-SDK interfaces, so you should reduce your reliance on them. See our recent post for details.
After you've made any necessary updates, we recommend publishing to Google Play right away. without changing the app's platform targeting. This lets you ensure a great experience for Android 9 users while you work on enhancing your app with Android 9 APIs and targeting.
To get started, just download the official API 28 SDK and the latest tools and emulator images into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project's compileSdkVersion and targetSdkVersion to API 28. When you change your targeting, make sure your app supports all of the applicable behavior changes.
As soon as you're ready, publish your APK updates to Google Play. A common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users and then do a staged rollout to production.
Visit the Android 9 site for details and developer documentation. Also check out this videoand the Google I/O Android Playlist for more on what's new in Android 9 for developers.
As always, the system images for Pixel devices are available here for manual flash and download. If you're looking for the Android 9 source, you'll find it here in the Android Open Source Project repository under the Android 9 branches.
Thanks again to the many developers and early adopters who participated in the Android 9 Developer Preview and public beta. Your contributions have been critical to making the Android 9 platform a great one for developers and consumers.
After more than a year of development and months of testing by early adopters, we're ready to launch Android 9 Pie, the latest release of Android, to the world.
Android 9 harnesses the power of machine learning to make your phone smarter, simpler, and tailored to you. Read all about the new consumer features here. For developers, Android 9 includes many new ways to enhance your apps and build new experiences to drive engagement.
You've given us tons of feedback along the way--over a thousand bugs and feature requests--thank you! More than 140,000 of you tried our preview builds through the Android Beta program, and seven of our device maker partners also brought our Beta to their flagship devices, enabling users around the world to give their feedback too.
Today we're pushing the source code to Android Open Source Project (AOSP), and starting the Android 9 rollout to all Pixel users worldwide, with Android 9 coming to many more devices in the coming months.
We continue to move Android forward as the premier open platform for developers worldwide to build their businesses. With Android 9 -- together with the powerful new capabilities in Google Play for apps and games -- we're committed to helping you build great experiences, as well as reach and engage the right users safely and cost-effectively around the world.
What's in Android 9?
A smarter smartphone, with machine learning at the core
Android 9 helps your phone learn as you use it, by picking up on your preferences and adjusting automatically. Everything from helping users get the most out of their battery life to surfacing the best parts of the apps they use all the time, right when they need it most, Android 9 keeps things running smoother, longer.Adaptive Battery
We partnered with DeepMind on a feature called Adaptive Battery that uses machine learning to prioritize system resources for the apps the user cares about most. If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. If you haven't yet taken optimized your app, make sure to check out the details in the power documentation to see how it works.Slices
Slices can help users perform tasks faster by enabling engagement outside of the fullscreen app experience. It does this by using UI templates that can display rich, dynamic, and interactive content from your app from within the Google Search app and later in other places like the Google Assistant. You can learn more about building Slices to enhance your app here.App Actions
App Actions is a new way to raise the visibility of your app and drive engagement. Actions take advantage of machine learning to surface your app to the user at just the right time, based on your app's semantic intents and the user's context.We'll be sharing more details in the coming weeks on registering your app to handle one or more user intents, so your apps can be enabled for App Actions and surfaced across multiple Google and Android surfaces in response to user queries.
Text Classifier and Smart Linkify
We've extended the ML models that identify entities in content or text input to support more types like Dates and Flight Numbers through the TextClassifier API. Smart Linkify lets you take advantage of the TextClassifier models through the Linkify API, including enriched options for quick follow-on user actions. Smart Linkify also delivers significant improvements in accuracy of detection as well as performance.
Neural Networks API 1.1
Android 9 adds an updated version of the Neural networks API, to extend Android's support for accelerated on-device machine learning. Neural Networks 1.1 adds support for nine new ops -- Pad, BatchToSpaceND, SpaceToBatchND, Transpose, Strided Slice, Mean, Div, Sub, and Squeeze. A typical way to take advantage of the APIs is through TensorFlow Lite.Getting the most from your phone -- more easily
We're excited about making your smartphone more intelligent. But it's also important that the technology fades to the back for users. In Android 9, we've evolved Android's UI to be simpler and more approachable -- for developers, these changes help improve the way users find, use, and manage your apps.New system navigation
Android 9 introduces a new system navigation that we've been working on for more than a year. The new design helps make Android's multitasking more approachable and makes discovering apps much easier. You can swipe up from anywhere to see full-screen previews of recently used apps and simply tap to jump back into one of them.Display cutout
Now your app can take full advantage of the latest edge-to-edge screens through display cutout supportin Android 9. For most apps, supporting display cutout is seamless, with the system managing status bar height to separate your content from the cutout. If you have immersive content, you can use the display cutout APIs to check the position and shape of the cutout and request full-screen layout around it. To help with development and testing, we've added a Developer Option that simulates several cutout shapes on any device.
Apps with immersive content can display content fullscreen on devices with a display cutout.
Notifications and smart reply
Android 9 makes notifications even more useful and more actionable. Messaging apps can take advantage of the new MessagingStyle APIs to show conversations, attach photos and stickers, and even suggest smart replies. You'll soon be able to use ML Kit to generate smart reply suggestions for your app.
MessagingStyle notifications with conversations and smart replies [left], images and stickers [right].
Text Magnifier
In Android 9 we've added a Magnifier widget to improve the user experience of selecting text. The Magnifier widget lets users precisely position the cursor or the text selection handles by viewing zoomed text through a draggable pane. You can attach it to any view that is attached to a window, so you can use it in custom widgets or during custom text-rendering. The Magnifier widget can also provide a zoomed-in version of any view or surface, not just text.
Check out our recent blog post for more about this and other Text features, such as PrecomputedText and line height and baseline text alignment.
Security and privacy for users
Biometric prompt
With a range of biometric sensors in use for authentication, we've made the experience more consistent across sensor types and apps. Android 9 introduces a system-managed dialog to prompt the user for any supported type of biometric authentication. Apps no longer need to build their own dialog--instead they use the BiometricPrompt API to show the standard system dialog. In addition to Fingerprint (including in-display sensors), the API supports Face and Iris authentication.
If your app is drawing its own fingerprint auth dialogs, you should switch to using the BiometricPrompt API as soon as possible. See this post for more information.
Protected Confirmation
Android 9 introduces Android Protected Confirmation, which uses the Trusted Execution Environment (TEE) to guarantee that a given prompt string is shown and confirmed by the user. Only after successful user confirmation will the TEE then sign the prompt string, which the app can verify.Stronger protection for private keys
We've added StrongBox as a new KeyStore type, providing API support for devices that provide key storage in tamper-resistant hardware with isolated CPU, RAM, and secure flash. You can set whether your keys should be protected by a StrongBox security chip in your KeyGenParameterSpec.DNS over TLS
Android 9 adds built-in support for DNS over TLS, automatically upgrading DNS queries to TLS if a network's DNS server supports it. Users can manage DNS over TLS behavior in a new Private DNS Mode in Network & internet settings. Apps that perform their own DNS queries can use a new API, LinkProperties.isPrivateDnsActive(), to check the DNS mode. More in this post.HTTPS by default
As part of a larger effort to move all network traffic away from cleartext (unencrypted HTTP) to websites secured with TLS (HTTPS), we're changing the defaults for Network Security Configuration to block all cleartext traffic. You'll now need to make connections over TLS, unless you explicitly opt-in to cleartext for specific domains. See the details here.Compiler-based security mitigations
In Android 9 we've expanded our use of compiler-level mitigations to harden the platform through run-time detection of dangerous behavior. Control Flow Integrity (CFI) techniques help to prevent code-reuse attacks and arbitrary code execution. In Android 9 we've greatly expanded CFI usage within the media framework and other security-critical components, such as NFC and Bluetooth. We've also introduced CFI kernel support into the Android common kernel when building with LLVM.We've also expanded our use of Integer overflow sanitizers to mitigate memory-corruption and information-disclosure vulnerabilities. We've prioritized sanitizers in libraries with past vulnerabilities or where complex untrusted input is processed, such as libui, libnl, libmediaplayerservice and others. See this post for details.
Privacy for users
Android 9 safeguards privacy in a number of new ways. The system now restricts access to mic, camera, and all SensorManager sensors from apps that are idle. While your app's UID is idle, the mic reports empty audio and sensors stop reporting events. Cameras used by your app are disconnected and will generate an error if the app tries to use them. In most cases, these restrictions should not introduce new issues for existing apps, but we recommend removing these requests from your apps.Android 9 also gives the user control over access to the platform's
build.serial identifier by putting it behind the READ_PHONE_STATE permission. To access the build.serial identifier, you should use the Build.getSerial() method.Read more about all of the privacy changes here.
New experiences in camera, audio, and graphics
Multi-camera API and other camera updates
With Android 9 you can now open streams from two or more physical camerassimultaneously on devices that support the multi-camera API. On devices with either dual-front or dual-back cameras, you can create innovative features not possible with just a single camera, such as seamless zoom, bokeh, and stereo vision. The API also lets you call a logical or fused camera stream that automatically switches between two or more cameras.Other improvements in camera include new Session parameters that help to reduce delays during initial capture, and Surface sharing that lets camera clients handle various use-cases without the need to stop and start camera streaming. We've also added APIs for display-based flash support and access to OIS timestamps for app-level image stabilization and special effects.
HDR VP9 Video and HEIF image compression
Android 9 adds built-in support for HDR VP9 Profile 2, so you can now deliver HDR-enabled movies to your users on HDR-capable devices.We're excited to add HEIF (heic) image encoding to the platform. HEIF is a popular format for photos that improves compression to save on storage and network data. With platform support on Android 9 devices, it's easy to send and utilize HEIF images from your backend server. Once you've made sure that your app is compatible with this data format for sharing and display, give HEIF a try as an image storage format in your app. You can do a jpeg-to-heic conversion using ImageDecoder or BitmapFactory to obtain a bitmap from jpeg, and you can use HeifWriter in the AndroidX library to write HEIF still images from YUV byte buffer, Surface, or Bitmap.
Enhanced audio with Dynamics Processing
The Dynamics Processing API lets you use a new audio effect to isolate specific frequencies and lower loud or increase soft sounds to enhance the acoustic quality of your app. For example, you can improve the sound of someone who speaks quietly in a loud, distant or otherwise acoustically challenging environment. The API gives you access to a multi-stage, multi-band dynamics processing effect that includes a pre-equalizer, a multi-band compressor, a post-equalizer and a linked limiter.ImageDecoder for bitmaps and drawables
An ImageDecoder API gives you an easier way to decode images to bitmaps or drawables. You can create a bitmap or drawable from a byte buffer, file, or URI. The API offers several advantages over BitmapFactory, including support for exact scaling, single-step decoding to hardware memory, support for post-processing in decode, and decoding of animated images. You can read more here.Connectivity and location
Wi-Fi RTT for indoor positioning
Android 9 lets you build indoor positioning features into your apps through platform support for the IEEE 802.11mc Wi-Fi protocol -- also known as Wi-Fi Round-Trip-Time (RTT). On Android 9 devices with hardware support, location permission, and location enabled, your apps can use RTT APIs to measure the distance to nearby Wi-Fi Access Points (APs). The device doesn't need to connect to the APs to use RTT, and to maintain privacy, only the phone is able to determine the distance, not the APs.
Knowing the distance to 3 or more APs, you can calculate the device position with an accuracy of 1 to 2 meters. With this accuracy you can support use-cases like in-building navigation; fine-grained location-based services such as disambiguated voice control (e.g. 'Turn on this light'); and location-based information (e.g. 'Are there special offers for this product?').
Data cost sensitivity in JobScheduler
JobScheduler is Android's central service to help you manage scheduled tasks or work across Doze, App Standby, and Background Limits. In Android 9, JobScheduler handles network-related jobs better for the user, coordinating with network status signals provided separately by carriers. Jobs can now declare their estimated data size, signal prefetching, and specify detailed network requirements—carriers can report networks as being congested or unmetered. JobScheduler then manages work according to the network status. For example, when a network is congested, JobScheduler might defer large network requests. When unmetered, it can run prefetch jobs to improve the user experience, such as prefetching headlines.Open Mobile API for NFC payments and secure transactions
Android 9 adds an implementation of the GlobalPlatform Open Mobile API to Android. On supported devices, apps can use the OMAPI API to access secure elements (SE) to enable smart-card payments and other secure services. A hardware abstraction layer (HAL) provides the underlying API for enumerating the variety of Secure Elements (eSE, UICC, and others) available.Performance for apps
ART performance
Android 9 brings performance and efficiency improvements to all apps through the ART runtime. We've expanded ART's use of execution profiles to optimize apps and reduce the in-memory footprint of compiled app code. ART now uses profile information for on-device rewriting of DEX files, with reductions up to 11% across a range of popular apps. We expect these to correlate closely with reductions in system DEX memory usage and faster startup times for your apps.Optimized for Kotlin
Kotlin is a first-class language on Android, and if you haven't tried it yet, you should! We've made an enduring commitment to Kotlin in Android and continue to expand support including optimizing the performance of Kotlin code. In Android 9, you'll see the first results of this work--we've improved several compiler optimizations, especially those that target loops, to extract better performance. We're also continuing to work in partnership with JetBrains to optimize Kotlin's generated code. You can get all of the latest Kotlin performance improvements just by keeping Android Studio's Kotlin plugin up-to-date.Today, we are also releasing an update to the Android 9 - API 28 SDK (rev. 6), which contains nullability annotations in some of the most frequently used APIs. We'll provide more details about this in an upcoming post.
Modern Android
As part of Android 9 we are modernizing the foundations of Android and the apps that run on it, as part of our deep, sustained investments in security, performance, and stability.As we announced last year, Google Play will require all app updates to target Android Oreo (targetSdkVersion 26 or higher) by November 2018. In line with that, if your app targets a platform earlier than Android 4.2 (API level 17), users installing it will see a warning dialog after that day. Here's a checklist of resources for help and support as you migrate -- we're looking forward to seeing your apps getting the most from modern Android.
Get your apps ready for Android 9!
With Android 9 coming to Pixel users starting today, and to other devices in the months ahead, it's important to test your app for compatibility as soon as possible. Just install your current app from Google Play on a device or or emulatorrunning Android 9. As you work through the flows, make sure your app runs and looks great, and that it handles the Android 9 behavior changesproperly.
Also watch for uses of non-SDK interfaces in your app. Android 9 restricts access to selected non-SDK interfaces, so you should reduce your reliance on them. See our recent post for details.
After you've made any necessary updates, we recommend publishing to Google Play right away. without changing the app's platform targeting. This lets you ensure a great experience for Android 9 users while you work on enhancing your app with Android 9 APIs and targeting.
Enhance your app with Android 9 features and APIs
When you're ready, dive into Android 9 and build with the new features and APIs in Android 9.To get started, just download the official API 28 SDK and the latest tools and emulator images into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project's compileSdkVersion and targetSdkVersion to API 28. When you change your targeting, make sure your app supports all of the applicable behavior changes.
As soon as you're ready, publish your APK updates to Google Play. A common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users and then do a staged rollout to production.
Visit the Android 9 site for details and developer documentation. Also check out this videoand the Google I/O Android Playlist for more on what's new in Android 9 for developers.
Coming to a device near you
Starting today, an over-the-air update to Android 9 will begin rolling out to Pixel phones. And devices that participated in the Beta program from Sony Mobile, Xiaomi, HMD Global, Oppo, Vivo, OnePlus, and Essential, as well as all qualifying Android One devices, will receive this update by the end of this fall! We are also working with a number of other partners to launch or upgrade devices to Android 9 this year.As always, the system images for Pixel devices are available here for manual flash and download. If you're looking for the Android 9 source, you'll find it here in the Android Open Source Project repository under the Android 9 branches.
What's next?
Now that we've reached the official release, we're bringing the Developer Preview to a close. We'll soon be closing the Developer Preview issue tracker to new issues, so if you have feedback, feel free to file a new issue against Android 9 in the AOSP issue tracker.Thanks again to the many developers and early adopters who participated in the Android 9 Developer Preview and public beta. Your contributions have been critical to making the Android 9 platform a great one for developers and consumers.
Supporting display cutouts on edge-to-edge screens
30 July 2018
Posted By Megan Potoski, Product Manager, Android System UI
Smartphones are quickly moving towards smaller bezels and larger aspect ratios. On these devices, display cutouts are a popular way to achieve an edge-to-edge experience while providing space for important sensors on the front of the device. There are currently 16 cutout devices from 11 OEMs already released, including several Android P beta devices, with more on the way.
These striking displays present a great opportunity for you to showcase your app. They also mean it's more important than ever to make sure your app provides a consistently great experience across devices with one or two display cutouts, as well as devices with 18:9 and larger aspect ratios.
The good news is, for the most part your app should work as intended even on a cutout device. By default, in portrait mode with no special flags set, the status bar will be resized to be at least as tall as the cutout and your content will display in the window below. In landscape or fullscreen mode, your app window will be letterboxed so that none of your content is displayed in the cutout area.
However, there are a few areas where your app could have issues on cutout devices.
You can use layoutInDisplayCutoutMode, a new window layout mode, to control how your content is displayed relative to the cutout. By default, the app's window is allowed to extend into the cutout area if the cutout is fully contained within a system bar. Otherwise, the window is laid out such that it does not overlap with the cutout. You can also set layoutInDisplayCutoutMode to always or never render into the cutout. Using SHORT_EDGESmode to always render into the cutout is a great option if you want to take advantage of the full display and don't mind if a bit of content gets obscured by the cutout.
If you are rendering into the cutout, you can use getDisplayCutout() to retrieve a DisplayCutout that has the cutout's safe insets and bounding box(es). These let you check whether your content overlaps the cutout and reposition things if needed.
To make it easier to manage your cutout implementation across API levels, we've also added DisplayCutoutCompat in the AndroidX library, which is now available through the SDK manager.
For more about the display cutout APIs, take a look at the documentation.
We strongly recommend testing all screens and experiences of your app to make sure that they work well on cutout devices. We recommend using one of the Android P Beta Devices that features a cutout, such as the Essential PH-1.
If you don't have a device, you can also test using a simulated cutout on any device running Android P or in the Android Emulator. This should help you uncover any issues that your app may run into on devices with cutouts, whether they are running Android 8.1 or Android P.
First, devices must ensure that their cutouts do not negatively affect apps. There are two key requirements:
We highly encourage you to support flexible aspect ratios so that your app can leverage the full display area, no matter what device it's on. You should test your app on different display ratios to make sure it functions properly and looks good.
Here are some guidelines on screens support to keep in mind as you are developing, also refer to our earlier post on larger aspect ratios for tips on optimizing. If your app can't adapt to the aspect ratios on long screens, you can choose to declare a max aspect ratio to request letterboxing on those screens.
Thanks for reading, and we hope this helps you deliver a delightful experience to all your users, whatever display they may have!
Smartphones are quickly moving towards smaller bezels and larger aspect ratios. On these devices, display cutouts are a popular way to achieve an edge-to-edge experience while providing space for important sensors on the front of the device. There are currently 16 cutout devices from 11 OEMs already released, including several Android P beta devices, with more on the way.
These striking displays present a great opportunity for you to showcase your app. They also mean it's more important than ever to make sure your app provides a consistently great experience across devices with one or two display cutouts, as well as devices with 18:9 and larger aspect ratios.
Examples of cutout devices: Essential PH-1 (left) and Huawei P20 (right).
Make your app compatible with display cutouts
With many popular and upcoming devices featuring display cutouts, what can you do to make sure your app is cutout-ready?The good news is, for the most part your app should work as intended even on a cutout device. By default, in portrait mode with no special flags set, the status bar will be resized to be at least as tall as the cutout and your content will display in the window below. In landscape or fullscreen mode, your app window will be letterboxed so that none of your content is displayed in the cutout area.
However, there are a few areas where your app could have issues on cutout devices.
- Watch out for any sort of hard-coding of status bar height -- this will likely cause problems. If possible, use WindowInsetsCompat to get status bar height.
- In fullscreen, be careful to consider when to use window vs. screen coordinates, as your app will not take up the whole screen when letterboxed. For example, if you use MotionEvent.getRawX/Y() to get screen coordinates for touch events, make sure to transform them to the view's coordinates using getLocationOnScreen().
- Pay special attention to transitions in and out of fullscreen mode.
Take advantage of the cutout area
Rendering your app content in the cutout area can be a great way to provide a more immersive, edge-to-edge experience for users, especially for content like videos, photos, maps, and games.
An example of an app that has requested layout in the display cutout.
In Android P we added APIs to let you manage how your app uses the display cutout area, as well as to check for the presence of cutouts and get their positions.You can use layoutInDisplayCutoutMode, a new window layout mode, to control how your content is displayed relative to the cutout. By default, the app's window is allowed to extend into the cutout area if the cutout is fully contained within a system bar. Otherwise, the window is laid out such that it does not overlap with the cutout. You can also set layoutInDisplayCutoutMode to always or never render into the cutout. Using SHORT_EDGESmode to always render into the cutout is a great option if you want to take advantage of the full display and don't mind if a bit of content gets obscured by the cutout.
If you are rendering into the cutout, you can use getDisplayCutout() to retrieve a DisplayCutout that has the cutout's safe insets and bounding box(es). These let you check whether your content overlaps the cutout and reposition things if needed.
<style name="ActivityTheme"> <item name="android:windowLayoutInDisplayCutoutMode"> default/shortEdges/never </item> </style>
Attribute for setting layoutInDisplayCutoutMode from the Activity's theme.
For devices running Android 8.1 (API 27), we've also back-ported the layoutInDisplayCutoutMode activity theme attribute so you can control the display of your content in the cutout area. Note that support on devices running Android 8.1 or lower is up to the device manufacturer, however.To make it easier to manage your cutout implementation across API levels, we've also added DisplayCutoutCompat in the AndroidX library, which is now available through the SDK manager.
For more about the display cutout APIs, take a look at the documentation.
Test your app with cutout
We strongly recommend testing all screens and experiences of your app to make sure that they work well on cutout devices. We recommend using one of the Android P Beta Devices that features a cutout, such as the Essential PH-1.
If you don't have a device, you can also test using a simulated cutout on any device running Android P or in the Android Emulator. This should help you uncover any issues that your app may run into on devices with cutouts, whether they are running Android 8.1 or Android P.
What to expect on devices with display cutouts
Android P introduces official platform support for display cutouts, with APIs that you can use to show your content inside or outside of the cutout. To ensure consistency and app compatibility, we're working with our device manufacturer partners to mandate a few requirements.First, devices must ensure that their cutouts do not negatively affect apps. There are two key requirements:
- In portrait orientation, with no special flags set, the status bar must extend to at least the height of the cutout.
- In fullscreen or landscape orientation, the entire cutout area must be letterboxed.
- You won't see multiple cutouts on a single edge, or more than two cutouts on a device.
- You won't see a cutout on the left or right long edge of the device.
Special mode
Some devices running Android 8.1 (API level 27) or earlier may optionally support a "special mode" that lets users extend a letterboxed fullscreen or landscape app into the cutout area. Devices would typically offer this mode through a toggle in the navigation bar, which would then bring up a confirmation dialog before extending the screen.
Devices that offer "special mode" allow users to optionally extend apps into the cutout area if supported by the app.
If your app's targetSdkVersion is 27 or higher, you can set the layoutInDisplayCutoutModeactivity theme attribute to opt-out of special mode if needed.Don't forget: larger aspect ratios too!
While you are working on cutout support, it's also a great time to make sure your app works well on devices with 18:9 or larger aspect ratios, especially since these devices are becoming increasingly common and can feature display cutouts.We highly encourage you to support flexible aspect ratios so that your app can leverage the full display area, no matter what device it's on. You should test your app on different display ratios to make sure it functions properly and looks good.
Here are some guidelines on screens support to keep in mind as you are developing, also refer to our earlier post on larger aspect ratios for tips on optimizing. If your app can't adapt to the aspect ratios on long screens, you can choose to declare a max aspect ratio to request letterboxing on those screens.
Thanks for reading, and we hope this helps you deliver a delightful experience to all your users, whatever display they may have!
AndroidX Development is Now Even Better
26 July 2018
Posted by Aurimas Liutikas, software engineer on AndroidX teamAndroidX (previously known as Android Support Library) started out as a small set of libraries intended to provide backwards compatibility for new Android platform APIs and, as such, its development was strictly tied to the platform. As a result, all work was done in internal Google branches and then pushed to the public Android Open Source Project (AOSP) together with the platform push. With this flow, external contributions were limited to a narrow window of time where the internal and AOSP branches were close in content. On top of that, it was difficult to contribute -- in order to do a full AndroidX build and testing, external developers had to check out >40GB of the full Android platform code.
Today, the scope of AndroidX has expanded dramatically and includes libraries such as AppCompat for easier UI development, Room for database management, and WorkManager for background work. Many of these libraries implement higher-level abstractions and are less tied to new revisions of the Android platform, and all libraries are designed with backwards compatibility in mind from the start. Several libraries, such as RecyclerView and Fragment, are purely AndroidX-side implementations with few ties to the platform.
Starting a little over two years ago, we began a process of unbundling -- moving AndroidX out of Android platform builds into its own separate build. We had to do a great deal of work, including migrating our builds from make to Gradle as well as migrating all of our API tracking tools and documentation generation out of the platform build. With that process completed, we reached a point where a developer can now check out a minimal AndroidX project, open it in Android Studio, and build using the public SDK and public Android Gradle Plugin.
The Android developer community has long expressed a desire to contribute more easily to AndroidX; however, this was always a challenge due to the reasons described above. This changes today: AndroidX development is moving to public AOSP. That means that our primary feature development (except for top-secret integrations with the platform 😀) and bug fixes will be done in the open using the r.android.com Gerrit review tool and changes will be visible in the aosp/androidx-master-dev branch.
We are making this change to give better transparency to developers; it gives developers a chance to see features and bug fixes implemented in real-time. We are also excited about receiving bug fix contributions from the community. We have written up a short guide on how to go about contributing a patch.
In addition to regular development, AOSP will be a place for experimentation and prototyping. You will see new libraries show up in this repository; some of them may be removed before they ship, change dramatically during pre-alpha development, or merge into existing libraries. The general rule is that only the libraries on maven.google.com are officially ready for external developer usage.
Finally, we are just getting started. We apologize for any rough edges that you might have when contributing to AndroidX, and we request your feedback via the public AndroidX trackerif you hit any issues.
Today, the scope of AndroidX has expanded dramatically and includes libraries such as AppCompat for easier UI development, Room for database management, and WorkManager for background work. Many of these libraries implement higher-level abstractions and are less tied to new revisions of the Android platform, and all libraries are designed with backwards compatibility in mind from the start. Several libraries, such as RecyclerView and Fragment, are purely AndroidX-side implementations with few ties to the platform.
Starting a little over two years ago, we began a process of unbundling -- moving AndroidX out of Android platform builds into its own separate build. We had to do a great deal of work, including migrating our builds from make to Gradle as well as migrating all of our API tracking tools and documentation generation out of the platform build. With that process completed, we reached a point where a developer can now check out a minimal AndroidX project, open it in Android Studio, and build using the public SDK and public Android Gradle Plugin.
The Android developer community has long expressed a desire to contribute more easily to AndroidX; however, this was always a challenge due to the reasons described above. This changes today: AndroidX development is moving to public AOSP. That means that our primary feature development (except for top-secret integrations with the platform 😀) and bug fixes will be done in the open using the r.android.com Gerrit review tool and changes will be visible in the aosp/androidx-master-dev branch.
We are making this change to give better transparency to developers; it gives developers a chance to see features and bug fixes implemented in real-time. We are also excited about receiving bug fix contributions from the community. We have written up a short guide on how to go about contributing a patch.
In addition to regular development, AOSP will be a place for experimentation and prototyping. You will see new libraries show up in this repository; some of them may be removed before they ship, change dramatically during pre-alpha development, or merge into existing libraries. The general rule is that only the libraries on maven.google.com are officially ready for external developer usage.
Finally, we are just getting started. We apologize for any rough edges that you might have when contributing to AndroidX, and we request your feedback via the public AndroidX trackerif you hit any issues.
Final preview update, official Android P coming soon!
25 July 2018
Posted By Dave Burke, VP of Engineering
Android P is almost here! As we put the finishing touches on the new platform, today we're bringing you Android P Beta 4.
Beta 4 is the last preview milestone before we launch the official Android P platform later this summer. Take this opportunity to test your apps and publish updates, to make sure you offer a great experience for users transitioning to Android P!
With the consumer launch coming soon, it's important to test your app for compatibility with Android P. Just install your current app from Google Play on an Android P Beta device or emulator. As you work through the flows, make sure your app runs and looks great, and that it handles the Android P behavior changes properly.
Also watch for uses of non-SDK interfaces in your app. Android P restricts access to selected non-SDK interfaces, so you should reduce your reliance on them. See our recent post for details..
After you've made any necessary updates, we recommend publishing to Google Play right away without changing the app's platform targeting. This lets you ensure a great experience for Android P users while you work on enhancing your app with Android P APIs and targeting.
To build with the new APIs, just download the official API 28 SDK and tools into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project's compileSdkVersion and targetSdkVersion to API 28. When you change your targeting, make sure your app supports all of the applicable behavior changes.
As soon as you're ready, publish your APK updates that are compiled against, or optionally targeting, API 28. A common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users and then do a staged rollout to production.
Visit the Developer Preview site for details and documentation. Also check out this video and the Google I/O Android playlist for more on what's new in Android P for developers.
How do I get Beta 4?
It's easy - you can get Android P Beta 4 on Pixel devices by enrolling here. If you're already enrolled in our Android Beta program, you'll automatically get the Beta 4 update soon. As always, downloadable system images for Pixel devices are also available. Partners who are participating in the Android P Beta program will also be updating their devices to Beta 4 over the coming weeks.
Thanks for your feedback so far, and thank you to everyone who participated in our recent Reddit AMA on r/androiddev!
Android P is almost here! As we put the finishing touches on the new platform, today we're bringing you Android P Beta 4.
Beta 4 is the last preview milestone before we launch the official Android P platform later this summer. Take this opportunity to test your apps and publish updates, to make sure you offer a great experience for users transitioning to Android P!
What's in this update?
Today's Beta 4 update includes a release candidate build with final system behaviors and the official Android P APIs (API level 28), available since Beta 2. It includes everything you need to wrap up your testing in time for the upcoming official Android P release.Get your apps ready for Android P
With the consumer launch coming soon, it's important to test your app for compatibility with Android P. Just install your current app from Google Play on an Android P Beta device or emulator. As you work through the flows, make sure your app runs and looks great, and that it handles the Android P behavior changes properly.
Also watch for uses of non-SDK interfaces in your app. Android P restricts access to selected non-SDK interfaces, so you should reduce your reliance on them. See our recent post for details..
After you've made any necessary updates, we recommend publishing to Google Play right away without changing the app's platform targeting. This lets you ensure a great experience for Android P users while you work on enhancing your app with Android P APIs and targeting.
Enhance your app with Android P features and APIs
When you're ready, dive into Android P and learn about the new features and APIs that you can use in your apps, like multi-camera support, display cutout, enhanced notifications, ImageDecoder, TextClassifier, and others.To build with the new APIs, just download the official API 28 SDK and tools into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project's compileSdkVersion and targetSdkVersion to API 28. When you change your targeting, make sure your app supports all of the applicable behavior changes.
As soon as you're ready, publish your APK updates that are compiled against, or optionally targeting, API 28. A common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users and then do a staged rollout to production.
Visit the Developer Preview site for details and documentation. Also check out this video and the Google I/O Android playlist for more on what's new in Android P for developers.
How do I get Beta 4?
It's easy - you can get Android P Beta 4 on Pixel devices by enrolling here. If you're already enrolled in our Android Beta program, you'll automatically get the Beta 4 update soon. As always, downloadable system images for Pixel devices are also available. Partners who are participating in the Android P Beta program will also be updating their devices to Beta 4 over the coming weeks.
What's next?
Stay tuned for the official Android P launch coming soon! You can continue to share your feedback or requests in the meantime, and feel free to use our hotlists for platform issues, app compatibility issues, and third-party SDK issues.Thanks for your feedback so far, and thank you to everyone who participated in our recent Reddit AMA on r/androiddev!
Updating your games for modern Android
20 July 2018
Posted by Tom Greenaway, Senior Partner Developer Advocate
Last year we announced that starting from August 2018 Google Play will require all new apps and games to target a recent Android API level – set to API level 26 (Android 8.0 Oreo), or higher. Additionally, this requirement will extend to updates for existing apps and games starting from November 2018.
Every new Android version introduces changes that bring significant security and performance improvements – and enhance the user experience of Android overall. Updating your games to target the latest API level ensures that your users can benefit from these improvements, while still allowing your games to run on older Android versions.
Simple next steps:
Remember, updating the target API level is just the first step – make sure your game is compatible with the behavior changes between your current target API level and API level 26. Check out further guidance on the changes in past versions of Android to help in your migration process. These policy changes are important for moving the Android ecosystem forward and keeping it healthy for our users – and yours.
How useful did you find this blog post?
★ ★ ★ ★ ★
Last year we announced that starting from August 2018 Google Play will require all new apps and games to target a recent Android API level – set to API level 26 (Android 8.0 Oreo), or higher. Additionally, this requirement will extend to updates for existing apps and games starting from November 2018.
Every new Android version introduces changes that bring significant security and performance improvements – and enhance the user experience of Android overall. Updating your games to target the latest API level ensures that your users can benefit from these improvements, while still allowing your games to run on older Android versions.
Simple next steps:
- Install the Android 8.0 Oreo SDK (API level 26) via Android Studio by navigating to (Tools > Android > SDK Manager > Android SDK > SDK Platforms).
- Update your game to target API level 26 and see whether your game has any incompatibilities or issues as soon as possible. Update any external dependencies as necessary. Learn more about the incremental changes between versions of Android here.
- If you are using an advertising network, SDK or plugin which is incompatible with API level 26, reach out to your contacts and find out their timeline for supporting target API level 26. The sooner they're aware of these changes the better.
- If you build your game with Unity, support for target API 26 is built into Unity 5.6.6 and beyond. Simply ensure the latest target API level is selected in your Android build settings for Unity (Build Settings > Android > Player Settings). For versions of Unity 5.6.5 and prior, consult this documentation which includes a workaround for versions dating back to 4.3.
- For games built with Unreal, check your Android platform settings has the "Target SDK Version" set to 26.
- If you use Cocos2D-X, check the target API level in the gradle.properties file that is generated.
- Since API 23, we have required permissions be requested at runtime which helps streamline the app install process.
- Since API 24, apps can no longer dynamically link against non-NDK libraries. If your app (including third-party static libraries) contains native code, you should only be using public NDK APIs.
- If your game uses Android push notifications, the Google Play Services SDK in your game will need to be updated to version 10.2.1 or above for your game to support API level 26.
- If your game uses opaque binary blobs (OBB), then your game must check if it can access the directory before attempting to access the OBB files themselves. We recommend explicitly requesting permission for access using the Runtime Permissions API, and gracefully handling cases wherein the permission is not granted. Additionally, add an entry in the manifest for the external storage access:
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
Remember, updating the target API level is just the first step – make sure your game is compatible with the behavior changes between your current target API level and API level 26. Check out further guidance on the changes in past versions of Android to help in your migration process. These policy changes are important for moving the Android ecosystem forward and keeping it healthy for our users – and yours.
★ ★ ★ ★ ★
How creating an Action can complement your Android app
10 July 2018
Posted by Neto Marin - Actions on Google Developer Advocate
There are millions of apps in the Android ecosystem, so helping yours get discovered can require some investment. Your app needs to offer something that differentiates it from other similar apps to stand out to users.
Building a companion Action is a fast and simple way to increase your Android app's potential reach by creating a new entrypoint from devices covered by the Google Assistant. This lets you bring your services to users without needing to install anything through voice, and can bring people into your app when it can provide more value.
Your companion Action complements your Android app's experience by offering some of your services through the Google Assistant, which is available on more than 500 million devices including speakers, phones, cars, headphones, and more. Creating an Action provides a frictionless way for users to start engaging with your services wherever the Google Assistant is available.
Creating an Action for the Assistant will extend your brand presence, bringing your services to new devices and contexts as users interact with the Google Assistant.
Let's take a look at a hypothetical example. Imagine you have a mobile commerce app. Some features include searching for products, navigating to different categories, adding payment information, and checking out. You could build an Action for the Assistant with most of the same functionality, but we encourage you to look for what makes the most sense in a conversational experience.
In this case, your Action could focus on everything that a user would want to know after they've purchased a product through your Android app or web page. You could offer a quick way to get updates about a purchase's status (if you provide different states for payment/purchase process) and shipment information, or provide an interface for re-ordering a user's favorite products. Then, your users would be able to ask something like, "Hey Google, ask Voice Store about my last purchase."
Or, to reach users who have never made a purchase before, you could create an Action to offer exciting deals for common products. For example, you could create an Action that is invoked with, "Hey Google, ask Voice Store what are the deals on TVs today".
As you can see, starting with a "hero" use case for your Action is an exciting way to introduce conversational features that complement your Android app, and it will take less time than you think.
At Google I/O 2018, we presented a talk, "Integrating your Android apps with the Google Assistant" which contains more details and examples for developers.
Google Play Billing offers a series of tools, APIs, and documentation to help developers manage the subscription life-cycle, build server-side validation, and much more. If you are new to in-app billing, check out the Google Play Billing Overview page.
Now, Android developers can expand where users can access these goods or upgraded experiences by offering them through Actions, as well. This expansion is accomplished by honoring the user's entitlements on Google Play across different surfaces and devices, reaching users when they can't (or don't want to) use an app, like while cooking or driving.
For non-Android platforms, you'll need to ask your users to link their accounts. You can then use your user's account history to identify what purchases they've made on other surfaces.
Check the Accessing Digital Purchases page for a step-by-step guide on how to enable access to the user's purchases and request and parse the purchase data.
Stay tuned for more posts about how to improve your Android app experience with Actions on Google.
Thanks for reading!
There are millions of apps in the Android ecosystem, so helping yours get discovered can require some investment. Your app needs to offer something that differentiates it from other similar apps to stand out to users.
Building a companion Action is a fast and simple way to increase your Android app's potential reach by creating a new entrypoint from devices covered by the Google Assistant. This lets you bring your services to users without needing to install anything through voice, and can bring people into your app when it can provide more value.
Your companion Action complements your Android app's experience by offering some of your services through the Google Assistant, which is available on more than 500 million devices including speakers, phones, cars, headphones, and more. Creating an Action provides a frictionless way for users to start engaging with your services wherever the Google Assistant is available.
Creating an Action for the Assistant will extend your brand presence, bringing your services to new devices and contexts as users interact with the Google Assistant.
Feature what your app does better
It is probably a mistake to try to rewrite all of your Android app as a conversational Action, since voice is a different modality with different constraints and usage patterns. Instead, you should start by selecting the most important or popular features in your app that translate well into a voice context and can be more easily accomplished there. Then, you can create your conversational experience to offer these features on Google Assistant devices. Check out the Conversation design site, which has several articles and guides about how to create a great voice UI.Let's take a look at a hypothetical example. Imagine you have a mobile commerce app. Some features include searching for products, navigating to different categories, adding payment information, and checking out. You could build an Action for the Assistant with most of the same functionality, but we encourage you to look for what makes the most sense in a conversational experience.
In this case, your Action could focus on everything that a user would want to know after they've purchased a product through your Android app or web page. You could offer a quick way to get updates about a purchase's status (if you provide different states for payment/purchase process) and shipment information, or provide an interface for re-ordering a user's favorite products. Then, your users would be able to ask something like, "Hey Google, ask Voice Store about my last purchase."
Or, to reach users who have never made a purchase before, you could create an Action to offer exciting deals for common products. For example, you could create an Action that is invoked with, "Hey Google, ask Voice Store what are the deals on TVs today".
As you can see, starting with a "hero" use case for your Action is an exciting way to introduce conversational features that complement your Android app, and it will take less time than you think.
At Google I/O 2018, we presented a talk, "Integrating your Android apps with the Google Assistant" which contains more details and examples for developers.
Delivering user's purchases across surfaces
In-app purchases, subscriptions, and one-time products have proven successful for Android developers when it comes to monetization, allowing developers to offer different kinds of digital goods and additional value for paying users. These types of monetization are proven to drive user conversion and make the app more profitable.Google Play Billing offers a series of tools, APIs, and documentation to help developers manage the subscription life-cycle, build server-side validation, and much more. If you are new to in-app billing, check out the Google Play Billing Overview page.
Now, Android developers can expand where users can access these goods or upgraded experiences by offering them through Actions, as well. This expansion is accomplished by honoring the user's entitlements on Google Play across different surfaces and devices, reaching users when they can't (or don't want to) use an app, like while cooking or driving.
For non-Android platforms, you'll need to ask your users to link their accounts. You can then use your user's account history to identify what purchases they've made on other surfaces.
Check the Accessing Digital Purchases page for a step-by-step guide on how to enable access to the user's purchases and request and parse the purchase data.
What's next?
If you are not familiar with Actions on Google yet, start by checking out our overview page, which describes the platform in detail and tells you all you need to know to create your Actions for the Google Assistant.Stay tuned for more posts about how to improve your Android app experience with Actions on Google.
Thanks for reading!
Android Emulator - AMD Processor & Hyper-V Support
09 July 2018
Posted by Jamal Eason, Product Manager, Android
Since the major revamp of the Android Emulator two years ago, we have focused on delivering a fast and feature-rich emulator to help you build great app experiences for users. Today, the Android Emulator is the top device deployed to from Android Studio — more than 2x over physical Android devices. We are humbled to hear from many of you that the Android Emulator has come a long way, but we are not done yet.
Making the Android Emulator faster is one of the top priorities for the Android Studio team. Over the last few releases, we have launched quick boot & emulator snapshots for quickly starting and resuming emulator sessions in under 2 seconds. Up until now, our emulator experience has almost universally worked on macOS® and Linux computers. But for users of Microsoft®Windows® or the Microsoft® Hyper-V™ platform, our hardware accelerated speed enhancements for the Android Emulator only worked with computers with Intel® processors. Support for AMD® processors and Microsoft Hyper-V hypervisor are two long-standing user requests from the Android developer community that we are happy to address with this Android Emulator update.
Today, you can download the latest Android Emulator release, which is enabled to run x86 based Android Virtual Devices (AVD) on computers that use AMD processors. This exciting update makes the Android Emulator more accessible to a new set of Android app developers that were previously limited to software emulation, but can now have hardware accelerated performance. Moreover, for those of you who use Hyper-V to run your local app backend, the Android Emulator can now also coexist with other Hyper-V-backed applications on Windows® 10.
Thanks to a new Microsoft Windows Hypervisor Platform (WHPX) API and recent open-source contributions from Microsoft, even more Android app developers can take advantage of all the speed improvements and features in the Android Emulator.
If you use Linux for Android app development, the Android Emulator will continue to use the native Kernel-based Virtual Machine (KVM) hypervisor for both Intel and AMD based computers for a fast and performant virtualization solution. An update to the v27.3.8 Android Emulator will offer you the new snapshots UI along with improvements to performance, reliability and resource usage.
For OS X v10.10 Yosemite and higher, the Android Emulator uses the built-in Hypervisor.Framework by default, and falls back to using the Intel Hardware Accelerated Execution Manager (HAXM) if Hypervisor.Framework fails to initialize (such as when running on OS X v10.9 or earlier). Once you update to the latest Android Emulator on macOS, you will also have access to the new snapshots UI along with under the hood performance and reliability improvements.
On Intel x86-based computers, the Android Emulator will continue to use Intel HAXM by default. Intel HAXM is a mature and open-sourced hypervisor solution developed by Intel. Thanks to on-going development by Intel, the fastest emulator performance on Windows is still with Intel HAXM. To download the latest Intel HAXM v7.2.0, check for updates in the Android SDK Manager.
If you have an AMD processor in your computer you need the following setup requirements to be in place:
Again, for existing Windows users who have an Intel-based processor, the Android Emulator will continue to use the faster and recommended Intel HAXM configuration. For those using AMD processors, and those who use Hyper-V hypervisors, this should be an exciting step forward to start using the Android Emulator.
Download the latest Android Emulator from the Android Studio 3.2 Beta SDK Manager for the latest performance updates across all supported platforms that you are using. We are going to continue to invest in performance improvements for each of the platforms and we look forward to your feedback and feature requests.
If you find a bug or issue, feel free to file an issue. Connect with us -- the Android Studio development team ‐ on our Google+ page or on Twitter.
Since the major revamp of the Android Emulator two years ago, we have focused on delivering a fast and feature-rich emulator to help you build great app experiences for users. Today, the Android Emulator is the top device deployed to from Android Studio — more than 2x over physical Android devices. We are humbled to hear from many of you that the Android Emulator has come a long way, but we are not done yet.
Making the Android Emulator faster is one of the top priorities for the Android Studio team. Over the last few releases, we have launched quick boot & emulator snapshots for quickly starting and resuming emulator sessions in under 2 seconds. Up until now, our emulator experience has almost universally worked on macOS® and Linux computers. But for users of Microsoft®Windows® or the Microsoft® Hyper-V™ platform, our hardware accelerated speed enhancements for the Android Emulator only worked with computers with Intel® processors. Support for AMD® processors and Microsoft Hyper-V hypervisor are two long-standing user requests from the Android developer community that we are happy to address with this Android Emulator update.
Today, you can download the latest Android Emulator release, which is enabled to run x86 based Android Virtual Devices (AVD) on computers that use AMD processors. This exciting update makes the Android Emulator more accessible to a new set of Android app developers that were previously limited to software emulation, but can now have hardware accelerated performance. Moreover, for those of you who use Hyper-V to run your local app backend, the Android Emulator can now also coexist with other Hyper-V-backed applications on Windows® 10.
Thanks to a new Microsoft Windows Hypervisor Platform (WHPX) API and recent open-source contributions from Microsoft, even more Android app developers can take advantage of all the speed improvements and features in the Android Emulator.
Android Emulator running on Windows 10 with AMD Processor Screenshot Configuration: Asus ROG Strix GL 702ZC, Processor: AMD® Ryzen™ 7 1700 Processor, Chipset: AMD 5350, Graphics: AMD® Radeon™ RX580
Support for these technologies was initially available in the v27.3.8 Android Emulator canary release and today we are releasing this set of preview features (AMD processor & Hyper-V support) on the stable channel for more feedback. Alongside this update, we have added additional speed improvements in loading emulator snapshots for those developers using the Intel® Hardware Accelerated Execution Manager (HAXM).How to use
Linux
If you use Linux for Android app development, the Android Emulator will continue to use the native Kernel-based Virtual Machine (KVM) hypervisor for both Intel and AMD based computers for a fast and performant virtualization solution. An update to the v27.3.8 Android Emulator will offer you the new snapshots UI along with improvements to performance, reliability and resource usage.
macOS
For OS X v10.10 Yosemite and higher, the Android Emulator uses the built-in Hypervisor.Framework by default, and falls back to using the Intel Hardware Accelerated Execution Manager (HAXM) if Hypervisor.Framework fails to initialize (such as when running on OS X v10.9 or earlier). Once you update to the latest Android Emulator on macOS, you will also have access to the new snapshots UI along with under the hood performance and reliability improvements.
Android Emulator - Snapshots Extended Controls
Microsoft Windows
On Intel x86-based computers, the Android Emulator will continue to use Intel HAXM by default. Intel HAXM is a mature and open-sourced hypervisor solution developed by Intel. Thanks to on-going development by Intel, the fastest emulator performance on Windows is still with Intel HAXM. To download the latest Intel HAXM v7.2.0, check for updates in the Android SDK Manager.
If you have an AMD processor in your computer you need the following setup requirements to be in place:
- AMD Processor - Recommended: AMD® Ryzen™ processors
- Android Studio 3.2 Beta or higher - download via Android Studio Preview page
- Android Emulator v27.3.8+ - download via Android Studio SDK Manager
- x86 Android Virtual Device (AVD) - Create AVD
- Windows 10 with April 2018 Update
- Enable via Windows Features: "Windows Hypervisor Platform"
Windows Hypervisor Platform setting in Windows 10
If you want to use Hyper-V at the same time as the Android Emulator on your Intel processor-based computer, you will also need the same Android Studio and Android Emulator versions as listed above, but with the additional requirements:- Enable via Windows Features: "Hyper-V" - Only available for Windows 10 Professional/Education/Enterprise
- Intel Processor : Intel® Core™ processor that supports Virtualization Technology (VT-x), Extended Page Tables (EPT), and Unrestricted Guest (UG) features. Additionally VT-x needs to be enabled in the BIOS.
Again, for existing Windows users who have an Intel-based processor, the Android Emulator will continue to use the faster and recommended Intel HAXM configuration. For those using AMD processors, and those who use Hyper-V hypervisors, this should be an exciting step forward to start using the Android Emulator.
Next Steps & Feedback
Download the latest Android Emulator from the Android Studio 3.2 Beta SDK Manager for the latest performance updates across all supported platforms that you are using. We are going to continue to invest in performance improvements for each of the platforms and we look forward to your feedback and feature requests.
If you find a bug or issue, feel free to file an issue. Connect with us -- the Android Studio development team ‐ on our Google+ page or on Twitter.
