Android Studio 3.4 has been released to the stable channel. Download it here.
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
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.
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.
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:
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:
- To open the New Module dialog, select File > New > New Module from the menu bar.
- In the New Module dialog, select Dynamic Feature Module and click Next.
- Configure your module as you normally would and click Next.
- 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:
- 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.
- Include module at install-time: Creates a module that is included with your app at install-time.
- 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.
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 or minimum 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
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
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
<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|
||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.|
||Conditional delivery options are not supported for instant-enabled dynamic feature modules.|
|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
<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 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.
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
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
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:
Open the Settings or Preferences dialog:
- On Windows or Linux, select File > Settings from the menu bar.
- On macOS, select Android Studio > Preferences from the menu bar.
Navigate to Build, Execution, Deployment > Deployment.
Check the boxes to enable automatic Run fallback for either of the Apply Changes actions.
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 (
- Changing values in Enums
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:
Android Studio 3.6
This section provides a summary of the new features and changes in Android Studio 3.6.
You can now add a class and then deploy that code change to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity .
To learn more about the difference between these two actions, see Apply Changes.
The following updates support native (C/C++) development in Android Studio.
The following NDK features in Android Studio, previously supported in Java, are now also supported in Kotlin:
- Navigate from a JNI declaration to the corresponding implementation function in C/C++. View this mapping by hovering over the C or C++ item marker near the line number in the managed source code file.
Automatically create a stub implementation function for a JNI declaration. Define the JNI declaration first and then type “jni” or the method name in the C/C++ file to activate.
Unused native implementation functions are highlighted as a warning in the source code. JNI declarations with missing implementations are also highlighted as an error.
When you rename (refactor) a native implementation function, all corresponding JNI declarations are updated. Rename a JNI declaration to update the native implementation function.
Signature checking for implicitly-bound JNI implementations.
Other JNI improvements
- Type hints for parameter and return values are shown in JNI implementation functions.
JNI-mangled function names can be folded.
Auto-completion for the method declaration name, parameter types, and return type.
Rename refactoring of the method declaration name.
Signature-checking for bound JNI functions.
Other JNI function assistance
- Auto-completion, inspection, navigation, and rename refactoring support
for string literals in the following:
- Various inspections for the following:
- Auto-completion, inspection, navigation, and rename refactoring support for string literals in the following:
IntelliJ IDEA 2019.2
The core Android Studio IDE has been updated with improvements from IntelliJ IDEA through the 2019.2 release, such as the Services tool window.
To learn more about the improvements from other IntelliJ versions that are included cumulatively with version 2019.2, see the following pages: