It’s Time to Update Android Studio 3.5!

Happy weekend, everyone! Here’s some valuable information for you. I’ve been writing since early this morning, so let’s get straight to the point: at the Google I/O 2018 conference, developers complained that Google should focus more on the quality and stability of Android Studio rather than constantly introducing new features. There’s always been some jokes: “garbage software, ruining my youth.”

So, after the Google I/O 2018 conference, Google launched a special project for Android Studio: code-named

Project Marble

, which aims to focus on making the Integrated Development Environment (IDE) as solid as a rock. The

Marble Project

mainly focuses on three core areas: system health, feature optimization, and online bug fixes. Below, I will present this area separately.

System Health — Memory

For me, I started using

Android Studio

tools back in 2014. Although

Studio

was born in 2013, almost no one used it. Many people were still using

Eclipse

for development, while I had already switched to Android Studio, which was originally

IntelliJ IDEA

. However, high memory consumption has always been a significant feature of Android Studio. When opening more than two projects, the IDE runs very slowly. The reason behind this experience is due to unexpectedly reaching memory pressure or IDE memory leaks. The Google team focused on this pain point after the 2018 I/O conference and conducted in-depth research in this area. By the 2019 I/O conference, they had already resolved over 33 impactful memory leak issues. They mainly achieved this through

extensive quality monitoring

. When the internal dashboard continuously measures memory shortages, they analyze the underlying stack data. Starting from Android Studio 3.5, when the IDE runs out of memory, it will capture some high-level statistical information about memory heap size and major objects in the heap. With this data, the IDE can do two things: suggest better memory settings and provide deeper memory analysis.

System Health — Automatic Memory Settings Recommendations

By default, the maximum heap size for Android Studio is 1.2 GB. For many large projects, this amount may not be sufficient. Even if your machine has plenty of RAM, the IDE will not exceed this value. In Android Studio 3.5, the IDE will recognize when an application project needs more memory on machines with higher memory capacity and notify you to increase the heap size. Alternatively, you can also adjust it in the new settings panel under

Appearance & Behavior → Memory Settings

.

System Health — Memory Heap Analysis Report Submission

Sometimes it is difficult to capture and reproduce memory issues and report them to the Android Studio team. To address this issue, Android Studio 3.5 allows developers to trigger a memory heap dump (

Help → Analyze Memory Use

), where the IDE will perform local cleanup of personal data, analyze it, and create a report. Developers can submit this memory usage report to the Android Studio development team to rule out performance issues.

System Health — Exception Monitoring

By modifying the exception reporting channel, we can locate and discover common exception signals for developers earlier. During the canary release process, priority can be determined and issues fixed earlier than before, reducing the flickering red exception report icons in the IDE.

System Health — User Interface Freezing

User interface (UI) freezing has always been a complaint among users. It manifests as the application becoming unresponsive, where there is a significant delay in response after input. This has been quite frustrating. In Android Studio 3.5, Google extended the underlying IntelliJ platform’s infrastructure, gaining a greater understanding of the areas frequently used by developers while continuously using Android Studio, in order to focus on resolving freezing issues. For example, during the development of the Marble project, the Google team found that the speed of editing XML code in the IDE was significantly slow. With this data point, the Google team optimized the XML types and achieved better performance in Android Studio 3.5. As seen in the two images below, the improvement in input latency allows for faster editing of XML data binding expressions.

Android Studio 3.4

Feel the difference with Android Studio 3.5

System Health — Build Speed

Build speed has always been a painful operation; every time I build, I feel like dying, especially when our project has a lot of code. It can take 7-10 minutes, which is frustrating even for a single line of code change. However, there are too many factors affecting build speed, such as whether there are previous compilation caches. If you clean the project and then rebuild, it can be a nightmare. So, unless necessary, I avoid cleaning the project. In the Google Marble project, the speed was improved by adding

incremental build

support to top-level annotation processors, including

Glide, AndroidX Data Binding, Dagger, Realm, and Kotlin (KAPT)

. Incremental support can have a significant impact on build speed. For example, in initial analysis, simply adding incremental support for Kotlin reduced the non-ABI submodule changes of the Google I/O schedule application from 9.1 seconds to 3.6 seconds—a 60% improvement.

System Health — IDE Speed

In the past, like many of you, when I felt the IDE was running slow, I would disable some Android Studio plugins, such as

Android NDK

support, to improve performance and make it more efficient for me to use. This time, starting from Android Studio 3.5, the Google team removed some unnecessary performance hotspots that previously affected the overall speed of the IDE.

System Health — Lint Code Analysis

Lint code analysis is familiar to everyone. Yesterday, I used it at work to scan for some error prompts and useless files, and it can even catch potential null pointer situations, which is very convenient.

Android Lint

is a code analysis framework in Android Studio that helps identify common programming errors. However, my projects generally involve C/C++, and the analysis takes a long time, about 20-30 minutes. This severely dampened my enthusiasm. The Google team, after some digging, found and fixed several significant memory leaks that improved Lint performance by about 2 times in Android Studio 3.5. You can try it yourself.

System Health — Windows I/O File Access

Many users of Android Studio are using Microsoft Windows. With daily use, build times and installation speeds have become slower. The Google team discovered that some antivirus programs target the Android Studio build and installation directory for active scanning. As these folders create and delete many small files over time, I/O and CPU usage can be partially occupied, affecting the overall build/sync performance of Android Studio. Therefore, turning off the antivirus software can also improve the efficiency of Android Studio. The image below shows a comparison before and after turning off the antivirus software.

System Health Check

Starting from Android Studio 3.5, the IDE will check various directories that may be affected by this slowdown, including the project build directory, and compare them with the excluded antivirus directory list. If Android Studio finds inconsistencies, you will see a pop-up notification and a link to guide you through the best settings.

System Health — Emulator CPU Usage

Since I found the built-in Android Studio emulator too difficult to use, I have rarely used it. For example, I usually use

Genymotion

or just a real device. After Android Studio 3.5, the Google team found through research that the Android emulator consumed too many CPU cycles, even when the emulator was idle, triggering the cooling fan on the laptop. After extensive data analysis, it was found that

Google Play Services

and related services were actively running in the background because the emulator was set to AC charging by default instead of battery discharging. We switched the default to battery discharging, reducing background CPU usage by more than three times. So from now on, you can use it confidently.

Next is the second part, feature optimization.

Apply Changes

The ability to quickly edit and view code changes without restarting the application is highly efficient for application development. For example, if I change a line of Java code, I can use

Apply Changes

and then run it. Two years ago, Google attempted to solve this pain point using the Instant Run mechanism, but it never achieved the expected results. In Android Studio 3.5, they rebuilt and implemented a more practical method called Apply Changes. Apply Changes uses platform-specific APIs from

Android Oreo

and higher to ensure reliable and consistent behavior; unlike the Instant Run mechanism, Apply Changes does not modify the APK. To support these changes, the Google team redesigned the entire deployment pipeline architecture to improve deployment speed and adjusted the run and deployment toolbar buttons for a smoother experience.

Sync Recompilation

Even when there are no issues with the project, you can compile and run it on the phone, but there are red symbols in the application code, which is quite frustrating. Many people, including myself, have encountered this issue, and the solution is to sync the Gradle again. The root cause of many red symbol events is that these caches were periodically deleted in recent Gradle changes to save disk space. After Android Studio 3.5, the Google team added conditional logic to check for this state, so similar situations will become less frequent.

Android Studio Upgrade

The current upgrade process for Android Studio is not seamless because it should address many issues related to fixing Gradle plugin errors. In Android Studio 3.5, we updated the user experience of output windows, pop-ups, and dialog boxes to help developers clearly understand when an upgrade is genuinely needed. In recent versions, the IDE and Gradle plugins can actually be updated independently. Below is the iteration process of Android Studio.

Layout Editor

Google has improved a range of interactions from constraint selection and deletion to better device preview resizing.

Android Studio 3.4

Android Studio 3.5

Data-Binding

The Google team has researched the long-standing data binding issues. From a performance perspective, it was found that creating data binding expressions in XML files caused significant hangs in the code editor. After fixing this issue, improvements were made in code completion, navigation, and refactoring.

Application Deployment Process

The deployment process has been simplified, adding a new dropdown menu to easily view and change the device to deploy to, as well as a new menu item to deploy to multiple devices. This is something I feel is similar to iOS’s XCode tool.

C++ Improvements

For me, these C++ improvements are a significant breakthrough. C++ project support is also a key area in the Marble project. For large projects, CMake builds are now 25% faster. Additionally, there is an improved single build variable user interface panel that allows developers to specify ABI architecture targets individually. Finally, Android Studio 3.5 allows for the parallel use of multiple versions of the Android NDK’s Gradle version in builds, which means multiple builds and alleviates incompatibility between NDK versions and the Android Gradle plugin.

IntelliJ Platform Updates

Starting from Android Studio 3.5, the features and quality enhancements of the 2019.1 IntelliJ platform version have been updated. The updates from IntelliJ 2019.1 include a series of improvements from custom themes to better version control system integration.

Dynamic Feature Support

Android Studio 3.5 enhances support for app bundle features, adding dynamic feature support to app bundles. Developers can set conditional delivery based on hardware features (like OpenGL version, AR support) or based on API levels and user countries.

Emulator Folding and Google Pixel Device Support

This IDE version includes Android emulator skins for Pixel 3a and Pixel 3a XL. Additionally, Android Studio supports creating collapsible Android virtual devices.

Chrome OS Support

Android Studio 3.5 now officially supports Chrome OS 75 and higher versions that support high-end Chromebook operating systems based on x86. For example, on Chrome OS, an Android Studio installer supports application deployment to externally connected Android devices via USB.

The final part is about the numerous online bug fixes; check out these bugs and here’s a link:

https://source.android.com/source/report-bugs#developer-tools

If you have bugs, you can report them too.

Looking is also a form of recognition