New features in Android Studio Preview

Android Studio 3.4 has been released to the stable channel. Android Studio 3.5 is currently in the Beta channel.

Android Studio 3.6 is currently in the Canary and Dev channels.

This page provides a summary of the new features and changes in these preview versions.

For the latest news on releases, including a list of notable fixes in each release, also see the Release updates.

If you encounter any problems using a preview version of Android Studio, please let us know. Your bug reports help to make Android Studio better.

Android Studio 3.5

This section provides a summary of the new features and changes in Android Studio 3.5.

Project Marble updates

Project Marble is an Android Studio initiative to significantly improve system health and feature polish, and reduce bugs. Android Studio 3.5 includes many improvements towards this goal, such as the following:

• Reduced UI latency in the editor window and improved smart editor features when using the Data Binding library
• Improved build speeds with incremental annotation processing
• Performance improvements when using the Android NDK
• Improved Lint check performance by mitigating several memory leaks
• On Windows, new notification actions to mitigate build speed regressions du to anti-virus software
• Significantly reduced CPU usage when using the Android Emulator
• Improved Gradle Sync performance by adjusting for deleted build cache
• Improved update experience to provide more information and actions to help you update the IDE and the Android Gradle plugin
• Improved performance and UX with the Layout Editor

For information about Project Marble updates, read the Android Developers blog post or the sections below.

Incremental annotation processing

When using Android Gradle plugin 3.5.0-beta01 and higher, even more annotation processors support incremental Java compilation, such as Data Binding. This optimization results in improved incremental build performance. For a full list, refer to the table of incremental annotation processors.

Additionally, KAPT 1.3.30 and higher also support incremental annotation processors, which you can enable by including the following in your gradle.properties file: kapt.incremental.apt=true

Memory management settings

If you use a 64-bit operating system that has at least 5 GB of RAM, you can now configure the maximum amount of RAM that your OS should allocate for Android Studio processes, such as the core IDE, Gradle daemon, and Kotlin daemon. Use these settings to provide the optimal amount of memory for each process to boost Android Studio performance.

You can access these new settings by selecting File > Settings (or Android Studio > Preferences on macOS), and then finding the Memory Settings section under Appearance & Behavior > System Settings.

Note: Allocating too much memory can degrade performance.

Memory usage report

Memory problems in Android Studio are sometimes difficult to reproduce and report. To help solve this problem, Android Studio now includes a memory usage report that you can send to the Android Studio team to help identify the source of the memory issues. For preview versions—canary, beta, and release candidates—Android Studio automatically monitors memory usage and triggers a memory heap analysis if it detects that the low memory threshold has been reached frequently.

After the heap analysis is triggered, Android Studio captures a heap dump locally and then analyzes the heap dump the next time that you run Android Studio. During the analysis, Android Studio removes any personal data and creates a summary of the memory state. This summary includes instances of classes and objects, as well as reference paths for memory allocations that are unusually large.

After the analysis is complete, Android Studio generates a report for you to review and displays a notification, as shown in figure 2. Click Review Report to see the contents of the memory usage report.

Before you send the report, you can review all of the information that’s included, as shown in figure 3. After you’ve finished your review, click Send. The Android Studio team reviews the report to help investigate and resolve the issues that you’re experiencing.

Important: Sending a memory usage report to our team does not include the raw data from the heap dump; the heap dump is deleted as soon as the analysis is complete. Although the generated report does not contain any personal data, it is used in accordance with the Google Privacy Policy.

To run the memory usage report manually, select Help > Analyze Memory Usage from the menu bar. When you choose this option, Android Studio dumps the heap and prompts you to restart the IDE. If you restart the IDE, the heap dump analysis starts immediately. Otherwise, the heap dump analysis starts the next time you run Android Studio. In either case, the IDE notifies you once the memory usage report is ready for you to review.

Conditional delivery for dynamic feature modules

Conditional delivery allows you to set certain device configuration requirements for dynamic feature modules to be downloaded automatically during app install. For example, you can configure a dynamic feature module that includes functionality for augmented reality (AR) to be available at app install for only devices that support AR.

This delivery mechanism currently supports controlling the download of a module at app install-time based on the following device configurations:

• Device hardware and software features, including OpenGL ES version
• User country
• API level

If a device does not meet all the requirements you specify, the module is not downloaded at app install-time. However, your app may later request to download the module on demand using the Play Core Library.

Before you get started, make sure you’re using Android Studio 3.5 Canary 11 or higher.

The following sections show you how to add support for conditional delivery to your dynamic feature modules. However, keep in mind that you’ll need to join the beta program for publishing apps with dynamic feature modules to Google Play.

Add a new module with conditional delivery options

The easiest way to create a new dynamic feature module with conditional delivery is through the New Module wizard, as follows:

1. To open the New Module dialog, select File > New > New Module from the menu bar.
2. In the New Module dialog, select Dynamic Feature Module and click Next.
3. Configure your module as you normally would and click Next.
4. In the Module Download Options section of the dialog, select Only include module at app install for devices with specified features from the following options:
   1. Do not include include module at app install (on-demand): Creates a module that is available as an on demand download for all device configurations running API level 21 or higher that your app supports.
   1. Include module at install-time: Creates a module that is included with your app at install-time.
   1. Only include module at install-time for devices with specified features: Creates a module that’s included with your app at app install-time on only devices with certain configurations that you can specify, such as device features or country.
5. If you want to limit automatic download of the module to certain countries or a minimum API level, click Finish to complete creating the module and then read the section about how to specify conditions based on country orminimum API level.

Otherwise, click + device feature to add a feature that a device requires in order to download the module at install-time.

• Next to device-feature, select one of the following options from the dropdown menu and specify its value:
  • Name: Allows you to specify a hardware or software feature that a device requires in order to download the module at install-time. The features that conditional delivery supports are the same as those listed as FEATURE_* constants by PackageManager.

If you select this option, start typing any part of the constant value of the feature, such as “bluetooth”, in the field next to the dropdown, and select one of the suggestions that appear.

• OpenGL ES Version: Allows you to specify a version of OpenGL ES that a device requires in order to download the module at install time. If you select this option, start typing the version, such as “0x00030001”, in the field next to the dropdown, and select one of the suggestions that appear.
• If you want to add multiple conditions based on available device features, click + device feature for each device feature condition you want to specify.
• When you’re done configuring module download options, click Finish.

After Android Studio finishes creating your dynamic feature module, you can inspect its manifest to see the condition specified in the <dist:delivery> node. An example is shown below.

<manifest …>
  <dist:module …>
    <dist:delivery>
      <dist:install-time>
        <dist:conditions>
          <!– Requires that the device support AR to download the module at
          app install-time.  –>
          <dist:device-feature dist:name=”android.hardware.camera.ar”/>
        </dist:conditions>
      </dist:install-time>
    </dist:delivery>
    …
  </dist:module>
</manifest>

Add conditional delivery options to an existing dynamic feature module

You can easily add conditional delivery options to an existing dynamic feature module through the module’s manifest. However, you should first read about the compatibility of conditional delivery options with other delivery options you may already have enabled.

To get started, you need to first migrate your manifest to the new <dist:delivery> element. The code snippet below shows an example of the older syntax:

<dist:module
  dist:title=”@string/title_dynamic_feature” dist:onDemand=”true”>
  <dist:fusing dist:include=”true”/>
</dist:module>

The delivery options above are now specified as follows.

<dist:module
  dist:title=”@string/title_dynamic_feature”>
  <dist:delivery>
      <dist:on-demand/>
  </dist:delivery>
  <dist:fusing dist:include=”true”/>
</dist:module>

You can then include conditional delivery options based on device features as follows.

<dist:module
    dist:title=”@string/title_dynamic_feature”>
    <dist:delivery>
      <dist:on-demand/>
      <dist:install-time>
        <dist:conditions>
          <!– Requires that the device support AR to download the module at
          app install-time.  –>
          <dist:device-feature dist:name=”android.hardware.camera.ar”/>
        </dist:conditions>
      </dist:install-time>
    </dist:delivery>
    <dist:fusing dist:include=”true”/>
</dist:module>

The sections below discuss other options for conditional delivery, such as by country or minimum API level.

Compatibility with other module download options

Because dynamic feature modules offer multiple options to configure how each feature is delivered to a user’s device, it’s important to understand how conditional delivery options are affected by other settings. The following table summarizes compatibility of conditional delivery with other module download options.

Module download option	Compatibility with conditional delivery
Fusing (<dist:fusing dist:include=”true”/>)	If a module sets this option to true, Google Play does not respect the conditional delivery options you specify when deploying your app to devices running API level 19 or lower. That is, dynamic feature modules that enable fusing are always included at install time for device running API level 19 or lower.
Instant-enabled (<dist:module dist:instant=”true”/>)	Conditional delivery options are not supported for instant-enabled dynamic feature modules.
On demand (<dist:on-demand/>)	By default, if you specify conditional delivery options, the module is also available on demand.

Specify conditions based on country

Conditional delivery also allows you to specify which countries you want to exclude (or include) from downloading your module at app install-time. Specifying this condition might be useful if, for example, your module implements a payment method that’s not available in certain regions.

In this context, the device country is typically determined by the user’s billing address registered on their Google Play account.

To specify countries for your module, include the following in the dynamic feature module’s manifest.

<dist:conditions>
   <!– Specify “true” to specify countries to exclude from downloading
   this module at app install-time, or “false” to specify countries that should
   download the module. By default, this is set to “false”. –>
  <dist:user-countries dist:exclude=”true”>
    <!– Specifies the two-letter  CLDR country code for regions that should
    not download the module at app install-time. –>
    <dist:country dist:code=”CN”/>
    <dist:country dist:code=”HK”/>
  </dist:user-countries>
</dist:conditions>

Specify conditions for minimum API level

Specifying a condition based on a device’s API level can be useful if you have dynamic feature modules that depend on APIs that are available in only certain versions of the Android platform.

To set a condition based on a minimum device API level, include the following in your dynamic feature module’s manifest. Keep in mind, the API level you specify as a condition should be greater or equal to the module’s own minSdkVersion.

<dist:conditions>
    <!– Specifies the minimum API level that the device must satisfy
          in order to download your module at app app install-time. –>
   <dist:min-sdk dist:value=”24″/>
</dist:conditions>

Apply Changes

Apply Changes lets you push code and resource changes to your running app without restarting your app—and, in some cases, without restarting the current activity. Apply Changes implements a completely new approach for preserving your app’s state. Unlike Instant Run, which rewrote the bytecode of your APK, Apply Changes redefines classes on the fly by leveraging the runtime instrumentation supported in Android 8.0 (API level 26) or higher.

Note: Some types of changes can’t be applied without restarting your app. For more information, see Limitations.

To use Apply Changes, do the following:

• If you want to apply only your code changes without restarting the current activity, click Apply Code Changes  or press Ctrl+Alt+F10 (or Command+Shift+Ctrl+R on macOS).

Generally, you should use Apply Code Changes if you have modified code in the body of a method but you have not modified any resources. When you’ve also modified resources, use Apply Changes and Restart Activity instead.

• If you want to apply your resource and code changes without restarting your app, click Apply Changes and Restart Activity  or press Ctrl+F10 (or Command+Ctrl+R on macOS).

This option lets you apply resource and code changes by restarting the current activity without restarting your app.

Enable Run fallback for Apply Changes

When changes that you’ve made can’t be applied without restarting the app, Android Studio prompts you to Run  your app again instead. However, if you don’t want to be prompted every time this occurs, you can configure Android Studio to automatically Run your app whenever your changes can’t be applied.

To enable this behavior, follow these steps:

1. Open the Settings or Preferences dialog:
   1. On Windows or Linux, select File > Settings from the menu bar.
   1. On macOS, select Android Studio > Preferences from the menu bar.
2. Navigate to Build, Execution, Deployment > Deployment.
3. Check the boxes to enable automatic Run fallback for either of the Apply Changes actions.
4. Click OK.

Note: Some types of changes don’t cause Apply Changes to fail, but still require you to restart your app manually before you can see those changes. For example, if you make changes to an activity’s onCreate method, those changes only take effect once the activity is relaunched, so you must restart your app to see those changes.

Limitations

Apply Changes has the following limitations:

• Apply Changes is only compatible with devices running Android 8.0 (API level 26) or higher.
• Like with Instant Run, certain code changes cannot be applied until the app is restarted, including the following:
  • Adding or deleting a class, method, or field
  • Changing the manifest
  • Changing method signatures
  • Changing modifiers of methods or classes
  • Renaming classes
  • Changing class inheritance
  • Adding or removing a resource
  • Changing native libraries (.so files)
  • Changing values in Enums

Known issues

Apply Changes has the following known issues:

• The speed of Apply Changes can sometimes be slower than Instant Run. The initial priority was for stability, and we’ll continue to improve performance throughout the coming months.
• You might see unexpected behavior if you use custom classloaders other than the system and application thread context.

IntelliJ IDEA 2019.1

The core Android Studio IDE has been updated with improvements from IntelliJ IDEA through the 2019.1 release, such as theme customization.

This also includes improvements from the following bug-fix updates:

• IntelliJ IDEA 2018.3.6
• IntelliJ IDEA 2018.3.5