Tag Archives: Android Studio

An Update on Android TLS Adoption

Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security

banner illustration with several devices and gaming controller

Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS).

Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.

Percentage of apps that block cleartext by default.

Percentage of apps that block cleartext by default.

Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.

The latest releases of Android Studio and Google Play’s pre-launch report warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration.

Example of a warning shown to developers in Android Studio.

Example of a warning shown to developers in Android Studio.

Example of a warning shown to developers as part of the pre-launch report.

Example of a warning shown to developers as part of the pre-launch report.

What can I do to secure my app?

For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions.

If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
        <domain includeSubdomains="true">insecure.cdn.example.com</domain>
    </domain-config>
</network-security-config>

If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your element inside a element. This ensures the connections in the production version of your app are secure.

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

What can I do to secure my library?

If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.

Android’s built-in networking libraries and other popular HTTP libraries such as OkHttp or Volley have built-in Network Security Config support.

Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams

Android Studio 3.5: Project Marble goes into stable

Posted by Jamal Eason, Product Manager, Android

Android Studio logo

Have you ever wished that Android Studio was faster, more performant, and more memory efficient? If so, then download Android Studio 3.5 today. This stable version of Android Studio is a different kind of release where the Android Studio team took a step back from large feature work for eight months and instead focused on product quality to further accelerate your day-to-day app development. We called this initiative Project Marble, and it focused on making the fundamental features and flows of Android Studio & Emulator rock-solid by looking at three core areas: system health, feature polish, and bugs. Working on Project Marble was is in direct response to feedback from you and we continue to welcome any further feedback you have.

To improve system health in Android Studio, we first created a new set of infrastructure and internal dashboards to better detect performance problems. We did this to establish a safety net to catch issues that are typically difficult to catch with regular unit testing. Then, the team addressed a range of issues from fixing over 600 bugs, 50 memory leaks, 20 IDE hangs, and improving XML & Kotlin typing latency. Additionally, for the Android Emulator, we decreased the CPU and memory impact on your development machine. Project Mable was a focused period to work on the IDE and Android Emulator system health but it also uncovered a set of quality areas we will continue to work on going forward.

On top of memory and performance, we spent time polishing and fixing core user facing feature areas. For example, we took a look at the app deployment flow to a device, and completely re-architectured and replaced Instant Run with Apply Changes so that it’s more reliable and trusted. With Apply Changes, we no longer modify an APK during your build but instead, we use runtime instrumentation to redefine classes on the fly. If you want to quickly edit code and see code changes, you should try Android Studio 3.5 today.

Lastly, over the course of Project Marble we fixed bugs which landed in Android Studio in 3.5. We are thankful to those who filed bug reports and engaged with us on social media. We are especially thankful for the over 40 external contributors in the Android community that diligently worked with us in filing and resolving critical quality issues in Android Studio 3.5. Project Marble is not the end of quality work for the Android Studio team, but this latest stable release is a major milestone of our on-going quality investment into the IDE. With the quality work and new infrastructure put in place during Project Marble, we hope that you are even more productive in developing Android apps when you download and use Android Studio 3.5.

There are many quality changes we made to Android Studio 3.5. To see the full list of changes, see the Android Studio 3.5 beta release blog and release notes. But you can dive into some of the highlights of the changes below:

System Health

System health improvements during Project Marble was a combination of memory performance, typing & user interfaces freezes, build speed, CPU usage, and I/O performance. For each of these areas we created new ways to detect issues during development and a better process to analyze your feedback both from opt-in analytics and bugs that you file.

Our system health work has many under the hood improvements but a few notable changes include:

Auto-recommend Memory Settings

With Android Studio 3.5, the IDE will recognize when an app project needs more RAM on a machine with higher RAM capacity and will notify you to increase the memory heap size or you can adjust the settings yourself under Appearance & Behavior → Memory Settings.

Memory Settings

Memory Settings

User Interface Freezes

During the Project Marble development timeframe, we found in our opt-in product analytics that XML code editing was notably slower in the IDE. With this data point, we optimized XML typing, and have measurably better performance in Android Studio 3.5. You can see below that editing data binding expressions in XML is faster due to typing latency improvements.

Code Editing Before

Code Editing Before - Android Studio 3.4

Code Editing After - Android Studio 3.5

Build Speed

For Android Studio 3.5 we made many speed improvements but a significant change is the addition of incremental build support to the top annotation processors including Glide, AndroidX data binding, Dagger, Realm, and Kotlin (KAPT). Incremental support can make a notable impact on build speed. Learn more here.

Disk I/O File Access Speed

For users on Microsoft® Windows®, we found that disk I/O access times were notable higher on average than other platforms. Digging into the data, we found the default configuration of anti-virus scanners did not optimally exclude build output folders. In Android Studio 3.5, we detect this situation and help guide you through the optimal setup.

System Health Notification

System Health Notification - Anti-virus Check

Feature Polish

In addition to improving system health we relooked at a few critical users flows to address bugs and user friction. The areas we looked at ranged from data binding, layout editor, ChromeOS support to project upgrades. One notable area of improvement to highlight is the app deployment flow:

Apply Changes

During the Project Marble time period, we removed Instant Run and re-architectured and implemented from the ground-up a more practical approach in Android Studio 3.5 called Apply Changes. Unlike Instant Run, Apply Changes does not modify your APK which means it is realbile and has a predictable behavior. To support the changes, we re-architected the entire deployment pipeline to improve deployment speed, and also tweaked the run and deployment toolbar buttons for a more streamlined experience.

Apply Changes Buttons

Apply Changes Buttons

App Deployment User Flow

App Deployment User Flow

To recap, Android Studio 3.5 has hundreds of bug fixes and notable changes in these core areas:

System Health

  • Memory Settings
  • Memory Usage Report
  • Reduce Exceptions
  • User Interface Freezes
  • Build Speed
  • IDE Speed
  • Lint Code Analysis
  • I/O File Access
  • Emulator CPU Usage

Feature Polish

  • Apply Changes
  • Gradle Sync
  • Project Upgrades
  • Layout Editor
  • Data Binding
  • App Deployment
  • C++ Improvements
  • Intellij 2019.1 Platform Update
  • Conditional Delivery for Dynamic Feature Support
  • Emulator Foldables & Google Pixel Device Support
  • Chrome OS Support

Check our the Android Studio release notes page for more details and read about deep dives into several areas of Project Marble in the following Medium blog posts & Google I/O talk:

Opt-In & Feedback

The specific areas and the approach we took to optimize Android Studio for Project Marble were all based on your feedback and metrics data. The aggregate metrics you can opt-in to inside of Android Studio allow us to figure out if there are broader problems in the product for all users, and the data also allows the team to prioritize feature work appropriately. There are are a couple pathways to help us build better insights. At a baseline, you can opt-in to metrics, by going to Preferences /Settings → Appearance & Behavior → Data Sharing.

IDE Data Sharing

IDE Data Sharing

Additionally, throughout the year, you might see user sentiment emojis in the bottom corner of the IDE. Those icons are a lightweight way to inform the Android Studio team on how things are going and to give us in-context feedback, and the fastest way to log a bug and send to the team.

IDE User Feedback

IDE User Feedback

Getting Started

Download

Download Android Studio 3.5 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio.

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.1.9 downloaded via the Android Studio SDK Manager.

As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

Moving Android Studio and Android Emulator to 64-bit versions

Posted by Sam Lin, Product Manager, Android

With Project Marble, the Android Studio team focused our efforts on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Performance is an underlying tenant to delivering a high quality IDE. To this end, we are sharpening our product focus and we will only support 64-bit operating systems going forward. Using Android Studio with an 64-bit operating systems enables efficient access to memory for both the IDE and the Android Emulator, and overall leads to a better development experience. While this change will not affect most Android Studio users, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. To aid in this transition for those developers using 32-bit versions of Microsoft Windows, we want to give you details on the upcoming depreciation timeline plus steps to take to be ready for this upcoming change.

Timeline

To minimize the impact of this change towards exclusively supporting 64-bit operating systems, we will first deprecate the 32-bit version. During the depreciation phase, both Android Studio and the Android Emulator will continue to work but the products will not receive new feature updates. During this transition period you can still download the product from the Android Studio web site. After one year, we will officially end product support and will remove the 32-bit product version download links. Note, if you have the 32-bit version of Android Studio previously installed during this period then the product should continue to work, but we will not provide a link for you to re-download the product. The exact dates for the depreciation and end-of-support period are in the table below:

Supported 32-bit Product Version Deprecation from End of Support on
Android Studio IDE 3.6 December 31, 2019 December 31, 2020
Android Emulator 28.0.25 Jun 30, 2019 December 31, 2020

Advantages of a 64-bit development environment

There are a few advantages to using a 64-bit version of Android Studio, which include:

  • Performance - The IDE can perform better because it can access more than 4GB of memory. The increase in memory especially provides a better experience when you are working on a large project.
  • 64-bit App Support - You can build both 32-bit and 64-bit versions of apps if your app uses C/C++ native code. Testing on both architectures can help you to get ready for the 64-bit requirement on Google Play which starts on August 1st, 2019.
  • Testing on Emulators - Both the 32-bit and 64-bit Android Emulator system images are supported by the 64-bit version of the Android Emulator. This flexibility makes it easier to test your app in different Android environments with one development machine.

Next steps

To recap, before ending support for the 32-bit version of Android Studio, we want to inform you in advance, provide guidance, and allow for a one-year lead time to help you migrate to a 64-bit operating system. You can still use 32-bit versions of Android Studio, but be mindful that these version will not receive future updates. Therefore, if you want to migrate we suggest you start planning early so that you can continue to get the latest product updates and take advantage of the performance improvements of a 64-bit development environment.

What’s New with Android Jetpack

Posted by Karen Ng, Group Product Manager and Jisha Abubaker, Product Manager, Android

Last year, we launched Android Jetpack, a collection of software components designed to accelerate Android development and make writing high-quality apps easier. Jetpack was built with you in mind -- to take the hardest, most common developer problems on Android and make your lives easier.

Jetpack has seen incredible adoption and momentum. Today, 80% of the top 1,000 apps in the Play store are using Jetpack. We’ve also heard feedback from so many of you across our early access developer programs and user studies, as well as Reddit, Stack Overflow, and Slack, that has helped shape these APIs. Very humbly, thank you.

What’s New in Jetpack

Today, we are excited to share with you 11 Jetpack libraries that can be used in development now and an early-development, open-source project called Jetpack Compose to simplify UI development.

Now in Alpha

CameraX

We've heard from many of you that developing camera apps or integrating camera functionality within your existing apps is hard. With the new CameraX library, we want to enable you to create great camera-driven experiences in your application without worrying about the underlying device behavior. This API is backwards compatible to Android 5.0 (API 21) or higher, ensuring that the same code works on most devices in the market. While it leverages the capabilities of camera2, it uses a simpler, use case-based approach that is lifecycle-aware eliminating significant amount of boilerplate code vs camera2. Finally, it enables you to access the same functionality as the native camera app on supported devices. These optional Extensions enable features like Portrait, Night, HDR, and Beauty.

LiveData and Lifecycles w/ coroutines

We heard you loud and clear and agree that LiveData must support your common one-shot asynchronous operations. With Lifecycle & LiveData KTX, you can do so with Kotlin coroutines that are lifecycle-aware. Kotlin coroutines have been well received by the developer community for how they simplify the way concurrency is handled within Android apps. We want to simplify it even further and enabling you to use them safely by offering coroutine scopes tied to lifecycles, coroutine dispatchers that are lifecycle-aware, and support for simple asynchronous chains with the new liveData builder.

Benchmark

The Benchmark library provides you a quick way to benchmark your app code, whether it is written in Kotlin, the Java programming language or native code. We use this library to continuously benchmark Jetpack libraries we release to ensure we do not introduce any latency into your code. You can now do the same right within your development environment in Android Studio, easily measuring database queries, view inflation, or a RecyclerView scroll. The library takes care of what is needed to provide reliable and consistent results like handling warm-up periods, removing outliers, and locking CPU clocks.

Security

To maximize security of an application’s data at-rest, the new Security library implements security best practices for you. It provides strong security that balances encryption with performance for consumer apps like banking and chat. It also provides a maximum level of security for apps that require a hardware-backed keystore with user presence and simplifies many operations including key generation and validation.

ViewModel with SavedState

ViewModel provided you an easy way to save your UI data in the event of a configuration change. It did not save your app state in the event of process death, and many of you have been relying on SavedInstanceState alongside ViewModel. With the ViewModel with SavedState module, you can eliminate boilerplate code and gain the benefits of using both ViewModel and SavedState with simple APIs to save and retrieve data right from your ViewModel.

ViewPager2

ViewPager2, the next generation of ViewPager, is now based on RecyclerView and supports vertical scrolling and RTL (Right-to-Left) layouts. It also provides a much easier way to listen for page data changes with registerOnPageChangeCallback.

Now in Beta

ConstraintLayout 2.0

ConstraintLayout 2.0 brings up new optimizations, and new way of customizing layouts, with the addition of helper classes. As part of ConstraintLayout 2.0, MotionLayout provides an easy way to manage motion and widget animation in your applications. You can easily describe transitions between layouts and animation of properties. MotionLayout is fully declarative in XML, allowing you to describe even complex transitions without requiring any code.

Biometrics Prompt

Users are accustomed to biometric credentials on their phones, but if your app requires a biometric login, it is important to make sure that users are provided a consistent and safe way to enter their credentials. The Biometrics library provides a simple system prompt giving the user a trustworthy experience.

Enterprise

With the Jetpack Enterprise library, your managed enterprise apps can send feedback back to Enterprise Mobility Management providers in the form of keyed app states, while taking advantage of backwards compatibility with managed configurations.

Android for Cars

With the Android for Cars libraries, you can provide your users a driver-optimized version of your app that will be automatically installed onto the vehicle’s infotainment system in vehicles equipped with the Android Automotive OS. It also allows your apps to work with the Android Auto app, providing the driver-optimized version anytime on their device.

Now in Stable

And in case you missed it, we announced stable releases of Jetpack WorkManager (background processing) and Jetpack Navigation (in-app navigation) just a few months ago.

Jetpack Compose

Today, we open-sourced an early preview of Jetpack Compose, a new unbundled toolkit designed to simplify UI development by combining a reactive programming model with the conciseness and ease-of-use of Kotlin. We have always done our best work when we did it with you - our developer community. That’s why we decided to develop Jetpack Compose in the open, starting today.

In that vein, we took a step back and chatted with many of you. We heard strong feedback from developers that they like the modern, reactive APIs that Flutter, React Native, Litho, and Vue.js represent. We also heard that developers love Kotlin, with over 53% of professional Android developers using it and with 20% higher language satisfaction ratings than the Java programming language. Kotlin has become the fastest-growing language in terms of number of contributors on GitHub.

So, we decided to invest in the reactive approach to declarative programming and create an easier way to build UIs with Kotlin.

We are building Compose with a few core principles:

  • Build with the benefits that Kotlin brings -- concise, safe, and fully interoperable with the Java programming language. Designed to drastically reduce the amount of boilerplate code you have to write, so you can focus on your app code, and help avoid entire classes of errors.
  • Fully declarative for defining UI components, including drawing and creating custom layouts. Simply describe your UI as a set of composable functions, and the framework handles UI optimizations and updates to the view hierarchy under the hood.
  • Provide reusable building blocks that let you build custom widgets easier, and without starting from scratch.
  • Compatible with existing views so you can mix and match and adopt at your own pace with direct access to all of the Android and Jetpack APIs.
  • Material Design out of the box and animations from the start, so it’s easy to create beautiful apps that are full of motion.
  • Accelerate development with tools like live preview and apply changes.

A Compose application is made up of composable functions that transform application data into a UI hierarchy. A function is all you need to create a new UI component. To create a composable function just add the @Composable annotation to the function name. Under the hood, Compose uses a custom Kotlin compiler plug-in so when the underlying data changes, the composable functions can be re-invoked to generate an updated UI hierarchy. The simple example below prints a string to the screen.

We know that adopting any new framework is a big change for existing projects and codebases, which is why we’ve designed Compose like all of Jetpack -- with individual components that you can adopt at your own pace and are compatible with existing views.

If you want to learn more about Jetpack Compose or download its source to try it for yourself, check out http://d.android.com/jetpackcompose

We'd love to hear from you as we iterate on this exciting future together. Send us feedback by posting comments below, and please file any bugs you run into on AOSP or directly through the feedback buttons in the Android Studio Jetpack Compose build in AOSP. Since this is an early preview, we do not recommend trying this on any production projects.

Happy Jetpacking!

Android Studio 3.5 Beta

Posted by Jamal Eason, Product Manager, Android

Android Studio 3.5 Beta is ready to download today. Last year, at Google I/O, we heard from many of you that you wanted us to focus even more on quality and stability over features. Consequently, we kicked off Project Marble, focused on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Android Studio 3.5 is the culmination of this effort. The results of Project Marble are focused on three core areas: system health, feature polish, and bugs. We are seeking your final round of feedback to make sure we didn't miss a key area that matters to you, so download Android Studio 3.5 on the beta channel today to let us know what you think.

Many times it can be difficult to see the range of changes that go into a quality release. Therefore, this post and our Google I/O talk on What’s New in Android Development Tools walk through a variety of changes in each of the major focus areas of Project Marble within Android Studio 3.5. We are certainly not done improving quality with Android Studio, but with the work and new infrastructure put into Project Marble for long term quality tracking we hope that you are even more productive in developing Android apps.

What's New in Android Development Tools (Google I/O'19)

System Health - Memory

One of the major points of feedback on Android Studio is how slow the IDE runs over time. Many times the reason behind this experience is due to unexpectedly reaching memory pressure or IDE memory leaks. We dug into this area, and as part of Project Marble, we have addressed over 33 impactful memory leaks. To identify leaks, we now measure out-of-memory exceptions on an internal dashboard on an on-going basis for those who opt-in to share data with us which enables us to focus and fix the most impactful issues. Starting with Android Studio 3.5, when the IDE runs out of memory, we capture some high level statistics about the size of the memory heap and dominant objects in the heap. With this data the IDE can do two things: suggest better memory settings and offer to do a deeper memory analysis.

  • Auto-recommend Memory Settings - By default, Android Studio has a maximum memory heap size of 1.2 GB. For those of you with large projects this amount may not be enough. Even if you have a machine with a large amount of RAM, the IDE will not exceed this value. With Android Studio 3.5, the IDE will recognize when an app project needs more RAM on a machine with higher RAM capacity and will notify you to increase the memory heap size in a notification. Alternatively, you can make adjusts in the new settings panel under Appearance & Behavior Memory Settings.

Memory Settings

  • Easier to report memory problems with Memory Heap Analysis - It can sometimes be hard to capture and reproduce memory problems to report them to the Android Studio team. To solve this, Android Studio 3.5 allows you to trigger a memory heap dump (Help → Analyze Memory Use) that the IDE locally sanitizes for personal data, analyzes, and creates a report. You can opt to share this memory usage report with the Android Studio team to troubleshoot performance problems.

Memory Usage Report

System Health - Exceptions

We have revamped our exception process backend pipeline. Now with the opt-in data we have earlier signals of common exceptions in aggregate which lets us prioritize and fix issues earlier in the canary release process than before. Moreover, we reduced the amount of times we prompt you for exceptions, since the analytics and opt-in crash reports are now more actionable for our team. The net result is that you should see the blinky red exception report icon in the lower status bar of the IDE less frequently.

Android Studio Exception Bubble

System Health - User Interface Freezes

User Interface (UI) freezes are another common issue we heard from you. In Android Studio 3.5, we extended the infrastructure of the underlying Intellij platform, and now measure UI thread stops that last longer than a few moments. Over time, we will have a bigger picture of the top hit spots to focus our efforts on. For example, during the Project Marble development, we found in our data that XML code editing was notably slower in the IDE. With this data point, we optimized XML typing, and have measurably better performance in Android Studio 3.5. You can see below that editing data binding expressions in XML is faster due to typing latency improvements.

Code Editing Before - Android Studio 3.4 (left) and Code Editing After - Android Studio 3.5 (right)

System Health - Build Speed

We continued our investment in build speed. For those developers with larger projects, it is the number one concern. As we uncovered in our recent Medium blog post on build speed, many elements can affect build performance, sometimes slowing it down more than we can improve. However, during Project Marble, we made speed improvements by adding incremental build support to the top annotation processors including Glide, AndroidX data binding, Dagger, Realm, and Kotlin (KAPT). Incremental support can make a notable impact on build speed. For example, in our preliminary analysis, adding incremental support just for Kotlin has improved submodule non-ABI code changes for the Google I/O schedule app from 9.1 seconds to 3.6 seconds – a 60% improvement. Read more about the performance changes to the build system here.

System Health - IDE Speed

In the past, a pro-tip some developers used to do is to turn off Android Studio plugins such as Android NDK support to improve performance. While there is nothing wrong with disabling plugins to remove extra menus or options that you don't need, we removed some unnecessary performance hotspots for the Android NDK support that impacted overall IDE speed.

System Health - Lint Code Analysis

Android Lint is a code analysis framework in Android Studio that helps identify common programming mistakes. However, we learned from several user reports that Lint could be too slow—especially when running in batch analysis mode on large projects. After some digging, we found and fixed several large memory leaks, leading to a roughly 2x speedup in Lint performance. We also published a profiling tool that can help identify bottlenecks in individual Lint checks. Read more about the analysis and tool here.

System Health - I/O File Access for Windows

Many users of Android Studio use Microsoft Windows. Over time, we received a range of reports from users on this platform that build times and installation speeds were increasingly getting slower. After investigating the problem during Project Marble, we realized that recent anti-virus programs included Android Studio build and installation directories as active scan targets. Since these folders have many small files created and removed over time, the I/O and CPU are partially taxed and consequently impacts the overall build/sync performance of Android Studio.

Google Internal Data, 2.2GHz quad-core Intel Core i7, April 2019

  • System Health Check - Starting with Android Studio 3.5, the IDE will check various directories that could be impacted by this slowdown, including the project build directory, and compare them against the list of excluded antivirus directories. If Android Studio finds an inconsistency, you will see a pop-up notification and link to help guide you through the optimal setup. Learn more here .

System Health Notification - Anti-virus Check

System Health - Emulator CPU Usage

Many app developers enjoy the fast and responsive emulator which has had dramatic performance improvements in the last few years. However, we heard from you that the Android Emulator seems to take an inordinate amount of CPU cycles and triggers the cooling fans on laptops even when the emulator is idle in the background. After investigation and measurement, we found that Google Play Services and related services were aggressively running in the background because by default the emulator was set to AC charging instead of battery discharging. We switched the default to battery discharging, and background CPU usage declined by more than 3x. This change is just of the many optimizations we made to the Android Emulator during Project Marble. Learn more about the Android Emulator and Project Marble here.

Google Internal Data on Apple MacBook Pro (15” 2016), Emulator: Pixel 3 API 28

Feature Polish - Apply Changes

Being able to quickly edit and see code changes you have made without restarting your app is great for app development. Two years ago, the Instant Run feature was our attempt to enable this flow, but it ultimately fell short of expectations. During the Project Marble time period, we re-architectured and implemented from the ground-up a more practical approach in Android Studio 3.5 called Apply Changes. Apply Changes uses platform-specific APIs from Android Oreo and higher to ensure reliable and consistent behavior; unlike Instant Run, Apply Changes does not modify your APK. To support the changes, we re-architected the entire deployment pipeline to improve deployment speed, and also tweaked the run and deployment toolbar buttons for a more streamlined experience. Learn more about the architecture behind Apply Changes here.

Apply Changes Buttons

Feature Polish - Gradle Sync

A recent and annoying pain point in Android Studio is to have your project unexpectedly trigger red symbols across your app code, especially when re-opening your project. The Gradle build system retains a cache of all the dependencies in your home directory that allows the IDE to quickly sync without re-downloading new artifacts. The root cause for many of the recent incidents of red symbols appearing is that in a recent Gradle change, these caches were periodically deleted to save hard drive space. The IDE was unaware of the discrepancy and consequently generated red symbols for missing dependencies. Starting with Android Studio 3.5, we now have the conditional logic to check for this state. We certainly have more we can do in this area, but this is just one example of the types of issues we addressed for project sync during Project Marble.

Feature Polish - Project Upgrades

Ideally, the Android Studio team would like you to be on the latest version of the IDE since this is where the team does active feature development, bug fixing and performance improvements. We know that upgrading your Android Studio is not a seamless process as it should be with many issues revolving around fixing gradle plugin errors. With Android Studio 3.5, we have updated the user experience on output windows, pop-ups and dialog boxes to help clarify when you actually need to upgrade, plus we made more sync & build upgrade errors more actionable.

From a recent developer survey, we heard that many developers upgrade the Android Studio IDE and the Gradle plugin at the same time. As of the last several releases, the IDE and your gradle plugin can actually be updated independently. This means if you want the latest build system speed and correctness improvements, you can upgrade your Gradle plugin, but you can also wait until you're ready. Whether or not you upgrade you Gradle plugin at the same time as the IDE, we encourage you to be on the latest release of Android Studio 3.5 to start using all the enhancements from Project Marble.

Feature Polish - Layout Editor

Based on user research on the layout editor and input from you, we know that there are several performance and error-prone usability issues that make editing XML the only path forward, especially when working with ConstraintLayout. To address the general usability of the layout editor, we refined a wide range of interactions from constraint selection and deletion, to better device preview resizing. While XML code editing is still a click away, we hope you can see that these interaction refinements can be a big productivity boost when creating and editing layouts in Android Studio. Learn more about the full range of layout editor changes here.

Layout Editor Before - Android Studio 3.4 (left) and Layout Editor After - Android Studio 3.5 (right)

Feature Polish - Data Binding

During Project Marble, we also took a look at long standing issues with data binding. From a performance perspective, we found that creating data binding expressions in XML files would lead to severe hangs in the code editor. After fixing this issue we also improved code completion, navigation, and refactoring.

Feature Polish - App Deployment Flow

We streamlined the deployment flow during Project Marble, by adding a new dropdown to easily see and change the device you intend to deploy to and a new menu item to deploy to multiple devices.

App Deployment User Flow

Feature Polish - C++ Improvements

C++ project support was also a focus area during Project Marble. CMake builds are now up to 25% faster for large projects because the IDE now invokes parallel Ninja targets. Additionally, you will find an improved single build variant user interface panel that allows you to specify ABI targets separately.. And lastly, Android Studio 3.5 allows you to use multiple versions of the Android NDK side-by-side in your build.gradle file. This should allow you to have more reproducible builds and mitigate incompatibilities between NDK versions and the Android gradle plugin.

Single Variant Selection by ABI

Feature Polish - Intellij Platform Update

This release of the Android Studio includes the features and quality enhancements of the 2019.1 Intellij platform release. The 2019.1 Intellij updates has a range of improvements from custom themes to better version control system integration.

Feature Polish - Conditional Delivery for Dynamic Feature Support

Android Studio 3.5 enhances app bundle feature support with the addition of conditional delivery features for your app bundle. Conditional delivery allows you to set certain device configuration requirements for dynamic feature modules to be downloaded automatically during app install. You can set conditional delivery based on hardware features such as OpenGL versions, support for Augmented Reality, or you set conditions based on API level and user country.

Module Selection for Conditional Delivery

Feature Polish - Emulator Foldables & Pixel Device Support

This release of the IDE includes the Android Emulator skins for Pixel 3a and Pixel 3a XL. Additionally, the Android Studio supports the creation of foldable Android Virtual Devices.

Android Emulator - Foldable Support

Feature Polish - Chrome OS Support

Android Studio 3.5 is now officially supported on Chrome OS 75 and higher on high-end x86 based Chromebooks. During Project Marble we refined a few usability issues, and now have an installer for Android Studio and support app deployment to external USB connected Android devices. Learn more how to setup the IDE on Chrome OS here.

Android Studio on Chrome OS

To recap, Android Studio 3.5 has hundreds of bug fixes and notable changes in these core areas:

System Health

  • Memory Settings
  • Memory Usage Report
  • Reduce Exceptions
  • User Interface Freezes
  • Build Speed
  • IDE Speed
  • Lint Code Analysis
  • I/O File Access
  • Emulator CPU Usage

Feature Polish

  • Apply Changes
  • Gradle Sync
  • Project Upgrades
  • Layout Editor
  • Data Binding
  • App Deployment
  • C++ Improvements
  • Intellij 2019.1 Platform Update
  • Conditional Delivery for Dynamic Feature Support
  • Emulator Foldables & Pixel Device Support
  • Chrome OS Support

Check our the Android Studio preview release notes page for more details and read about deep dives into several areas of Project Marble in the following Medium blog posts:

Opt-In & Feedback

The specific areas and the approach we took to optimize Android Studio for Project Marble were all based on your feedback and metrics data. The aggregate metrics you can opt-in to inside of Android Studio allow us to figure out if there are broader problems in the product for all users, and the data also allows the team to prioritize feature work appropriately. There are are a couple pathways to help us build better insights. At a baseline, you can opt-in to metrics, by going to Preferences /Settings → Appearance & Behavior → Data Sharing.

IDE Data Sharing

Additionally, throughout the year, you might see user sentiment emojis in the bottom corner of the IDE. Those icons are a lightweight way to inform the Android Studio team on how things are going and to give us in-context feedback, and the fastest way to log a bug and send to the team.

IDE User Feedback

Getting Started

Download

Download the beta version of Android Studio 3.5 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and beta release versions of Android Studio at the same time. Learn more.

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.0.6 downloaded via the Android Studio SDK Manager.

As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

Android Studio 3.4

Posted by Jamal Eason, Product Manager, Android

After nearly six months of development, Android Studio 3.4 is ready to download today on the stable release channel. This is a milestone release of the Project Marble effort from the Android Studio team. Project Marble is our focus on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. On top of many performance improvements and bug fixes we made in Android Studio 3.4, we are excited to release a small but focused set of new features that address core developer workflows for app building & resource management.

Part of the effort of Project Marble is to address user facing issues in core features in the IDE. At the top of the list of issues for Android Studio 3.4 is an updated Project Structure Dialog (PSD) which is a revamped user interface to manage dependencies in your app project Gradle build files. In another build-related change, R8 replaces Proguard as the default code shrinker and obfuscator. To aid app design, we incorporated your feedback to create a new app resource management tool to bulk import, preview, and manage resources for your project. Lastly, we are shipping an updated Android Emulator that takes less system resources, and also supports the Android Q Beta. Overall, these features are designed to make you more productive in your day-to-day app development workflow.

Alongside the stable release of Android Studio 3.4, we recently published in-depth blogs on how we are investigating & fixing a range of issues under the auspices of Project Marble. You should check them out as you download the latest update to Android Studio:

The development work for Project Marble is still on-going, but Android Studio 3.4 incorporates productivity features and over 300 bug & stability enhancements that you do not want to miss. Watch and read below for some of the notable changes and enhancements that you will find in Android Studio 3.4.

Develop

  • Resource Manager - We have heard from you that asset management and navigation can be clunky and tedious in Android Studio, especially as your app grows in complexity. The resource manager is a new tool to visualize the drawables, colors, and layouts across your app project in a consolidated view. In addition to visualization, the panel supports drag & drop bulk asset import, and, by popular request, bulk SVG to VectorDrawable conversion. These accelerators will hopefully help manage assets you get from a design team, or simply help you have a more organized view of project assets. Learn more.

Resource Manager

  • Import Intentions - As you work with new Jetpack and Firebase libraries, Android Studio 3.4 will recognize common classes in these libraries and suggest, via code intentions, adding the required import statement and library dependency to your Gradle project files. This optimization can be a time saver since it keeps you in the context of your code. Moreover, since Jetpack libraries are modularized, Android Studio can find the exact library or minimum set of libraries required to use a new Jetpack class.

Jetpack Import Intentions

  • Layout Editor Properties Panel - To improve product refinement and polish we refreshed the Layout Editor Properties panel. Now we just have one single pane, with collapsible sections for properties. Additionally, errors and warnings have their own highlight color, we have a resource binding control for each property, and we have an updated color picker.

Layout Editor Properties Panel

  • IntelliJ Platform Update - Android Studio 3.4 includes Intellij 2018.3.4. This update has a wide range of improvements from support for multi-line TODOs to an updated search everywhere feature. Learn more.

Build

  • Project Structure Dialog - A long standing request from many developers is to have a user interface front end to manage Gradle project files. We have more plans for this area, but Android Studio 3.4 includes the next phase of improvement in the Product Structure Dialog (PSD). The new PSD allows you to see and add dependencies to your project at a module level. Additionally, the new PSD displays build variables, suggestions to improve your build file configuration, and more! Although the latest Gradle plugin v3.4 also has improvements, you do not have to upgrade your Gradle plugin version number to take advantage of the new PSD. Learn more.

Project Structure Dialogue

  • R8 by Default - Almost two years ago we previewed R8 as the replacement for Proguard. R8 code shrinking helps reduce the size of your APK by getting rid of unused code and resources as well as making your actual code take less space. Additionally, in comparison to Proguard, R8 combines shrinking, desugaring and dexing operations into one step, which ends up to be a more efficient approach for Android apps. After additional validation and testing last year, R8 is now the default code shinker for new projects created with Android Studio 3.4 and for projects using Android Gradle plugin 3.4 and higher. Learn more.

Test

  • Android Emulator Skin updates & Android Q Beta Emulator System Image - Inside of Android Studio 3.4 we released the latest Google Pixel 3 & Google Pixel 3 XL device skins. Also with this release, you can also download Android Q Beta emulator system images for app testing on Android Q. Please note that we do recommend running the canary version of Android Studio and the emulator to get the latest compatibility changes during the Android Q Beta program.

Android Emulator - Pixel 3 XL Emulator Skin

To recap, Android Studio 3.4 includes these new enhancements & features:

Develop

  • Resource Manager
  • Import Intentions
  • Layout Editor Properties Panel
  • IntelliJ 2018.3.4 Platform Update

Build

  • Incremental Kotlin annotation processing (Kotlin 1.3.30 Update)
  • Project Structure DialogR8 by Default

Test

  • Emulator Device Skins
  • Android Q Beta Emulator System Image Support

Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.

Getting Started

Download

Download the latest version of Android Studio 3.4 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v28.0.22 downloaded via the Android Studio SDK Manager.

We appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

Google Play services discontinuing updates for API levels 14 and 15

Posted by Sam Spencer, Technical Program Manager, Google Play

The Android Ice Cream Sandwich (ICS) platform is seven years old and the active device count has been below 1% for some time. Consequently, we are deprecating support for ICS in future releases of Google Play services. For devices running ICS, the Google Play Store will no longer update Play Services APK beyond version 14.7.99.

What does this mean as an Application developer:

The Google Play services SDK contains the interfaces to the functionality provided by the Google Play services APK, running as background services. The functionality required by the current, released SDK versions is already present on ICS devices with Google Play services and will continue to work without change.

With the SDK version changes earlier this year, each library can be independently released and may update its own minSdkVersion. Individual libraries are not required to change based on this deprecation. Newer SDK components may continue to support API levels 14 and 15 but many will update to require the higher API level. For applications that support API level 16 or greater, you will not need to make any changes to your build. For applications that support API levels 14 or 15, you may continue to build and publish your app to devices running ICS, but you will encounter build errors when updating to newer SDK versions. The error will look like this:

Error:Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 14 cannot be smaller than version 16 declared in library [com.google.android.gms:play-services-FOO:16.X.YY]
        Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage

Unfortunately, the stated suggestion will not help you successfully run your app on older devices. In order to use the newer SDK, you will need to use one of the following options:

1. Target API level 16 as the minimum supported API level.

This is the recommended course of action. To discontinue support for API levels that will no longer receive Google Play services updates, simply increase the minSdkVersion value in your app's build.gradle to at least 16. If you update your app in this way and publish it to the Play Store, users of devices with less than that level of support will not be able to see or download the update. However, they will still be able to download and use the most recently published version of the app that does target their device.

A very small percentage of all Android devices are using API levels less than 16. You can read more about the current distribution of Android devices. We believe that many of these old devices are not actively being used.

If your app still has a significant number of users on older devices, you can use multiple APK support in Google Play to deliver an APK that uses Google Play services 14.7.99. This is described below.

2. Build multiple APKs to support devices with an API level less than 16.

Along with some configuration and code management, you can build multiple APKs that support different minimum API levels, with different versions of Google Play services. You can accomplish this with build variants in Gradle. First, define build flavors for legacy and newer versions of your app. For example, in your build.gradle, define two different product flavors, with two different compile dependencies for the stand-in example play-services-FOO component:

productFlavors {
    legacy {
        minSdkVersion 14
        versionCode 1401  // Min API level 14, v01
    }
    current {
        minSdkVersion 16
        versionCode 1601  // Min API level 16, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services-FOO:16.0.0'
    currentCompile 'com.google.android.gms:play-services-FOO:17.0.0'
}

In the above situation, there are two product flavors being built against two different versions of play-services-FOO. This will work fine if only APIs are called that are available in the 16.0.0 library. If you need to call newer APIs made available with 17.0.0, you will have to create your own compatibility library for the newer API calls so that they are only built into the version of the application that can use them:

  1. Declare a Java interface that exposes the higher-level functionality you want to perform that is only available in current versions of Play services.
  2. Build two Android libraries that implement that interface. The "current" implementation should call the newer APIs as desired. The "legacy" implementation should no-op or otherwise act as desired with older versions of Play services. The interface should be added to both libraries.
  3. Conditionally compile each library into the app using "legacyCompile" and "currentCompile" dependencies as illustrated for play-services-FOO above.
  4. In the app's code, call through to the compatibility library whenever newer Play APIs are required.

After building a release APK for each flavor, you then publish them both to the Play Store, and the device will update with the most appropriate version for that device. Read more about multiple APK support in the Play Store.

Unfolding right now at #AndroidDevSummit!

Posted by Stephanie Cuthbertson, Director of Product Management

Today, at the Computer History Museum in Mountain View, CA, we kicked off the Android Dev Summit, taking a look back at the last 10 years of Android and then jumping into some important new features for Android developers. Here's a look at some of the things we shared!

Unfolding Android into new experiences

As early as Android 1.6, Android and our partners have contemplated different screen sizes and densities, enabling the platform to power a broad category of form factors and new experiences like Android TV, Android Auto, Wear OS and even Android apps on Chromebooks. Phone screens are an area where Android partners set the bar, introducing "phablets" when phone screens were small. Fast forward to today, when a phablet is... just a phone, a standard size users have come to love.

Now we see a Android device makers creating a new category: Foldables. Taking advantage of new flexible display technology, the screen can literally bend and fold.

There are two variants broadly speaking: two-screen devices and one-screen devices. When folded, foldables look like phones, fitting in your pocket or purse. When unfolded, their defining feature is what we call screen continuity. For example, start a video with the folded smaller screen - and later you can sit down and unfold the device to get a larger tablet-sized screen for a beautiful, immersive experience. As you unfold, the app seamlessly transfers to the bigger screen without missing a beat. We're optimizing Android for this new form factor. And, making changes to help developers everywhere take advantage of the possibilities this creates for amazing new experiences, new ways to engage and delight your users. Tune in to the Foldables session at Dev Summit this week to learn more. Expect to see Foldables coming from several Android manufacturers, including one Samsung previewed today and plans to offer next year.

Kotlin: updates to the fastest growing language

We made Kotlin a first class language on Android in 2017. This month we had over 118,000 new projects using Kotlin started in Android Studio - from those users who opt in to share metrics. That's a 10X increase from last year. It's become the fastest growing language in terms of growth of number of contributors on GitHub, and voted the #2 most loved language on Stack Overflow. In our surveys, the more developers use Kotlin, the higher their satisfaction.

Last week, JetBrains released the latest version of Kotlin, 1.3, which brings new language features, APIs, bug fixes, and performance improvements:

  • Inline classes allow you to create a type which doesn't allocate unless boxed. For the constrained devices that Android apps target, avoiding allocation while retaining type-safety is a big advantage.
  • Unsigned numbers are now part of the Kotlin standard library including UInt, UByte, and ULong. These new types are built using inline classes.
  • Multiplatform code previously written for Android or the JVM can now also target Javascript or native. This unlocks the possibility of reusing parts of your codebase on even more platforms.
  • Coroutines support is now stable. The language and library support combine to simplify how you interact with asynchronous operations and perform concurrent work–things that are essential to every Android app.

All of these new features of Kotlin 1.3 will be integrated into the Kotlin-specific APIs that we provide–a majority of which are through KTX extensions as part of Jetpack.

Android Jetpack: Navigation, Work Manager, and Slices

At Google I/O we announced Jetpack, the next generation of tools and Android APIs to accelerate Android application development. Jetpack builds on the foundations laid out by Support Library and Architecture. Already, 80% of top 1,000 apps and games are using one of the new Jetpack libraries in production.

This summer we moved AndroidX - Jetpack's evolution of the original Android Support Library - to public AOSP. This means you can see features and bug fixes implemented in real-time, and contribute to any of the AndroidX libraries. You can learn more about contributing here.

We've been working to get as much feedback and refinement as possible on two new Architecture Component libraries: Navigation and Work Manager, and we plan to move both to Beta this month. The Navigation Architecture Component offers a simplified way to implement Android's navigation principles in your application, using a single Activity. Plus, the new Navigation Editor in Android Studio creates and edits your navigation architecture. This eliminates navigation boilerplate, gives you atomic navigation operations, easier animated transitions and more. WorkManager makes it easy to perform background tasks in the most efficient manner, choosing the most appropriate solution based on the application state and device API level.

Navigation Editor

We're also excited to see Android Slices move to public Search experiments! At I/O this year we introduced Slices, a new way to bring users to your app. Slices are like a mini snippet of your app, where you can surface content and actions. You can book a flight, play a video, or call a ride. Slices is another example where we want to be open very early, but we want to take the time to get it right. We're moving into public EAP this month with Doist, Kayak and others. We'll run experiments surfacing Slices in Google search results. To learn more, there's also a session today at Dev Summit with more info and best practices.

Android Studio: focusing on productivity, build speed, quality and fundamentals

Android Studio is our official IDE for Android development. We asked where do you spend the most time? When we gather data from Android Studio's opted-in users we see that build time are getting faster with every release, sometimes as fast as 20%, but we also see build time getting slower and slower over time. So, how can both things be true? We've been digging in hard to understand.

It turns out build is a pretty complicated ecosystem. Developer choices makes a huge difference. Our developers are using a very broad (and growing) combination of OSes, custom plug-ins, annotation processors, languages. All of these can significantly affect times. In one case, a plugin some users like to add was silently slowing build speeds by up to 45%. Learning this, we realized we need build profiling and analysis tools so you can easily understand what's slowing your build down. We're also investing more in our own plugins to accelerate performance to make sure we continue to improve the performance of core build.

Android Studio 3.3 launches beta 3 today. In coming releases expect to see a strong focus on quality and fundamentals: reducing the number of crashes and hangs, optimizing memory usage, and fixing user-impacting bugs. We also announced today that we're making Android Studio an officially supported IDE on Chrome OS early next year; learn more here.

Android App Bundles and dynamic features

App sizes have grown dramatically, up 5x since 2012. But larger apps have downsides: lower install conversion rates, lower update rates, and higher uninstalls. This is why we built the Android App Bundle, the new publishing format that serves only the code and resources a user needs to run your app on their specific device; on average apps see 35% size savings compared to a universal APK. The app bundle also saves you time and effort with each release since you don't need to use incomplete solutions like multi-APK. Android Studio 3.2 brought full IDE support of app bundles, and there are now thousands of app bundles in production totaling billions of installs, including Google's apps like YouTube, Google Maps, Google Photos, and Google News.

The app bundle now supports uncompressed native libraries; with no additional developer work needed, the app bundle now makes apps using native libraries an average of 8% smaller to download and 16% smaller on disk on M+ devices.

Once you switch to the app bundle you can also start modularizing your app. With dynamic feature modules, you can load any app functionality on demand instead of at install time. You don't need to keep big features that are only used once, on every single device forever; dynamic features can be installed and uninstalled dynamically when your app requests them.

In-app Updates API

We've heard that you'd like more controls to ensure that users are running the latest and greatest version of your app. To address this, we're launching an In-app Updates API. We're testing the API with early access partners and will be launching it to all developers soon.

You'll have two options with this API; the first is a full-screen experience for critical updates when you expect the user to wait for the update to be applied immediately. The second option is a flexible update, which means the user can keep using the app while the update is downloaded. You can completely customize the update flow so it feels like part of your app.

Instant discovery

We're also making instant apps easier than ever to adopt. We recently made using web URLs optional, enabling you to take your existing play store deep link traffic and send users to your instant experience if it's available. Additionally, we've raised the instant app size limit to 10MB for the Try Now button on the Play Store and web banners to make it even easier to adopt.

In the Android Studio 3.3 beta, you can now build an instant-enabled app bundle. This means that you can now build and deploy both your Instant and installed experiences from a single Android Studio project, and include them in a single Android App Bundle. You only have to upload just ONE artifact for both instant and installed app.

As developers, your feedback has been critical in shaping these investment areas; you are part of how we work, from early ideas, to EAPs and canaries, Beta, and iterating after launch. We hope you join us for the next two days whether you're watching the 30+ sessions on the livestream, joining social, or with us in-person in Mountain View. From the team, a sincere thank you for all your thoughtful feedback and contributions. We hope you enjoy Android Dev Summit.

Android Studio 3.2

Posted by Jamal Eason, Product Manager, Android

Today, Android Studio 3.2 is available for download. Android Studio 3.2 is the best way for app developers to cut into the latest Android 9 Pie release and build the new Android App bundle. Since announcing this update of Android Studio at Google I/O '18, we have refined and polished 20+ new features and focused our efforts on improving the quality for this stable release of Android Studio 3.2.

Every developer should use Android Studio 3.2 to transition to using an Android App Bundle, the new app publishing format. With very minimal work, you can generate an app bundle with Android Studio. Once you upload your app bundle to Google Play you can distribute smaller, optimized apps to your users. Early adopters have already seen between 11% - 64% in app size savings with app bundles over the legacy APK app size.

Another feature you do not want to miss is the Energy Profiler. This new profiler gives you a set of tools that will help you diagnose and improve the energy impact of your app. Better device battery life is one of the top most user requests, and with the Energy Profiler in Android Studio 3.2, you can do your part in improving device battery life by making sure your app is using the right amount of energy at the right time.

Lastly, you should also check out the new Android Emulator Snapshots feature. By using this feature, you can quickly take a snapshot of the current state of your emulator which includes the current state of the screen, apps, and settings. You can resume or boot into your emulator snapshot in under 2 seconds. For any app developer looking for super- fast boot times, or seeking to run tests in a predictable Android environment, Android Emulator Snapshots is a game changing feature for app development

On top of these major features, there are 20 new features plus many under-the-hood quality refinements in Android Studio 3.2. By using Android Studio 3.2, you can also develop for the latest technologies ranging from Android Jetpack, to the latest in Google Artificial Intelligence (AI) APIs with Android Slices.

Thank you to those who gave your early feedback on both the canary and beta releases. Your feedback helped us improve the quality and features in Android Studio 3.2. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 3.2 is ready to download for you to get started.

Below is a full list of new features in Android Studio 3.2, organized by key developer flows.

Develop

  • Slices support - Slices is a new way to tap into the built-in Android AI capabilities by surfacing app content in Google Search suggestions and the Google Assistant. Android Studio 3.2 has a built-in template to help you extend your app with the new Slice Provider APIs as well as new lint checks to ensure that you're following best practices when constructing the slices. To use, right-click on a project folder, and navigate to NewOtherSlice Provider. Learn more.

Slices Provider Template

  • Sample Data - This feature allows you to use placeholder data to aid in the design of your app. This will help you visualize layouts that depend on runtime data. You can add built-in sample data to populate views such as RecyclerViews, ImageViews, and TextViews via a popup-window in the Layout Editor. Learn more.
  • Material Design Update - When you start migrating from the Android Design support library to the new MaterialComponents app theme and library, Android Studio 3.2 will offer you access to new and updated widgets such as BottomAppBar, buttons, cards, text fields, new font styles and more. Learn more.
  • CMakeList Editing Support - For those using C/C++ in their app, Android Studio has better support for CMake. With this release of Android Studio 3.2, code completion and syntax highlighting now works on common CMakeList build script commands.
  • What's New Assistant - Android Studio 3.2 has a new assistant panel that opens automatically after an update to inform you about the latest changes to the IDE. You can also open the panel by navigating to Help → What's New in Android Studio.
  • AndroidX Refactoring Support - One of the components of Android Jetpack is the introduction of the Android extension libraries (AndroidX) as a replacement for the Android Support Libraries. To add AndroidX to a new project you just need to add android.useAndroidX=true to your gradle.properties file. Additionally, Android Studio 3.2 has a new built-in refactoring action to help migrate your project the new namespace and dependencies. Also if you have any Maven dependencies that have not migrated to the AndroidX namespace, the Android Studio build system will automatically convert those project dependencies as well. Learn more.
  • IntelliJ Platform Update - Android Studio 3.2 includes the IntelliJ 2018.1.6 platform release. This IntelliJ release adds many improvements to dataflow analysis, debugging, new inspections, inline external annotations, partial Git commits, plus much more. Learn more.
  • Kotlin Update - Android Studio 3.2 bundles Kotlin 1.2.61, with support for the Kotlin-friendly Android 9 Pie SDK. Learn more.

Build

  • Android App Bundle - The Android App Bundle is the new app publishing format designed to help you deliver smaller APKs to your users and reduce download size of your app. Google Play's new app serving model, called Dynamic Delivery, processes your app bundle to generate and serve optimized APKs for each user's device configuration, so they download only the code and resources they need to run your app. With Android Studio 3.2 or via the command line, you can easily build your code as an app bundle and get the benefit of smaller APKs based on language, screen density, and ABIs with no changes to your app code. Learn more.

Build Android App Bundle

  • D8 Desugaring - In some cases, new Java Language features require new bytecodes and language APIs. However, older Android devices may not support these features. Desugaring allows you to use these features on older devices by replacing new bytecodes and language APIs with older ones during the build process. D8 desugaring is turned on by default for Android Studio 3.2 and you can now use most of the latest language changes while targeting older devices.
  • R8 Optimizer - Starting with Android Studio 3.2, we are starting the transition to use R8 as a replacement for ProGuard to optimize and shrink Java language bytecode. R8 is still experimental, so we do not recommend publishing your app using R8 yet, but it is a good time to give the Android Studio team early feedback so we can make any adjustments before R8 fully replaces ProGuard. Learn more.

Test

  • Emulator Snapshots - The latest release of the Android Emulator allows you to create a snapshot of the current state of your emulator and boot up and switch into any snapshot in under 2 seconds. Built upon the Android Emulator Quickboot feature, Android Snapshots are even faster to save and load with this stable release due to under-the-hood speed enhancements. When testing and developing your app, Android snapshots allow you to pre-configure an Android Virtual Device (AVD) snapshot with the presets, apps, data and settings that you want in-place, and repeatedly go back to the same snapshot. Learn more.

Android Emulator Snapshots

  • Microsoft® Hyper-V™ Support - You can now run the Android Emulator on Windows® 10 computers that have Hyper-V enabled. Intel HAXM is still the default hypervisor for the fastest Android Emulator experience. However,thanks to recent open source contributions by Microsoft, and the addition of the new Windows Hypervisor Platform (WHPX) API, the Android Emulator can coexist with other Hyper-V-backed applications, like local Virtual Machines, using the new Hyper-V Support. Learn more.
  • AMD® Processor Support - AMD Processors are now supported by the Android Emulator on Windows 10. Previously running the Android Emulator was limited to slow software emulation when running Windows, but developers who have an AMD processor can now have hardware accelerated performance. Learn more.
  • Screen Record in Android Emulator - You can now record both screen and audio on any Android API level with the new screen record feature in the Android Emulator. In the past, screen recording on a physical Android device only worked on Android 4.4 KitKat (API 19) and above with no audio, with limited Android Emulator support. With the latest Android Emulator (v28.0.+) you no longer have this restriction. As an added bonus, there is a built-in conversion to output to GIF and WebM. You can trigger the new screen record feature via the Android Emulator Extended Controls panel, command line and from Android Studio. Lean more
  • Virtual Scene Camera for Android Emulator - The new Virtual Scene camera in the Android Emulator helps you to develop for ARCore, Google's platform for building augmented reality experiences. The emulator is calibrated to work with ARCore APIs for AR apps and also allows you to inject virtual scene bitmap images. The virtual scene camera can also be used as a regular HAL3 compatible camera. Learn more.
  • ADB Connection Assistant - Android Studio 3.2 has a new assistant system to help troubleshoot your Android ADB device connections issues. The ADB Connection Assistant walks you through common troubleshooting steps to connect your Android device to your development machine. You can trigger the assistant from the Run dialog box or by navigating to ToolsConnection Assistant . Learn more.

Optimize

  • Energy Profiler - Battery life is a key concern for many phone users, and your app may impact battery life more than you realize. The new Energy Profiler in the Android Studio performance profiler suite can help you understand the energy impact of your app on an Android device. You can now visualize the estimated energy usage of system components, plus inspect background events that may contribute to battery drain. To use the energy profiler, ensure you are connected to an Android device or emulator running Android 8.0 Oreo (API 26) or higher. Learn more.

Energy Profiler

  • System Trace - The new System Trace feature in the CPU Profiler allows you to inspect how your app interacts with system resources in fine-grained detail. Inspect exact timings and durations of your thread states, visualize where your CPU bottlenecks are across all cores, and add custom trace events to analyze. To use system trace, start profiling your app, click into the CPU Profiler, and then choose the System Trace recording configuration. Learn more.
  • Profiler Sessions - We now automatically save Profiler data as "sessions" to revisit and inspect later while you have Android Studio open. We've also added the ability to import and export your CPU recordings and heap dumps for later analysis or inspection with other tools. Learn more.
  • Automatic CPU Recording - You can now automatically record CPU activity using the Debug API. After you deploy your app to a device, the profiler automatically starts recording CPU activity when your app calls startMethodTracing(String tracePath), and stops recording when your app calls stopMethodTracing(). Similarly, you can also now automatically start recording CPU activity on app start-up by enabling Start Recording a Method Trace on Startup option in your run configuration. Learn more.
  • JNI Reference Tracking - For those of you who have C/C++ code in your Android app, Android Studio 3.2 now allows you to inspect the memory allocations of your JNI code in the Memory Profiler. As long as you deploy your app to a device running Android 8.0 Oreo (API 26) and higher, you can drill down into the allocation call stack from your JNI reference. To use the feature, start a memory profiler session, and select the JNI Heap from the Live Allocation drop-down menu. Learn more.

To recap, the latest canary of Android Studio 3.2 includes these new major features:

Develop

  • AndroidX Refactoring
  • Sample Data
  • Material Design Update
  • Android Slices
  • CMakeList editing
  • What's New Assistant
  • New Lint Checks
  • Intellij Platform Update
  • Kotlin Update

Build

  • Android App Bundle
  • D8 Desugaring
  • R8 Optimizer
Test
  • Android Emulator Snapshots
  • Screen Record in Android Emulator
  • Virtual Scene Android Emulator Camera
  • AMD Processor Support
  • Hyper-V Support
  • ADB Connection Assistant

Optimize

  • Energy Profiler
  • System Trace
  • Profiler Sessions
  • Automatic CPU Recording
  • JNI Reference Tracking

Check out the release notes for more details.

Getting Started

Download the latest version of Android Studio 3.2 from the download page. If you are using a previous canary release of Android Studio, make sure you update to Android Studio Canary 14 or higher. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v28.0.7+ downloaded via the Android Studio SDK Manager.

We appreciate any feedback on things you like, and issues or features you would like to see. Please note, to maintain high product quality, a couple features (e.g. Navigation Editor) you saw in earlier release channels are not enabled by default in the stable release channel. 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.

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!