Detailed explanation of new features of Android Studio

Google I/O conference held earlier in 2021, we detailed the main features of Android Studio Arctic Fox, which is currently available for download stable Android Studio Arctic Fox mainly focuses on the following three areas of improvement:

1. : Arctic Fox is the first stable release to include support for Jetpack Compose and a number of design tools and checkers to make it easier to create and preview interfaces.
2. Android device support : Arctic Fox includes a number of features for Android devices, such as a heart rate sensor on Wear OS, and a new Android TV emulator that supports Google TV.
3. Development efficiency improvement : We have improved the bottom layer of Android Studio, and also brought the WorkManager tool to help developers improve development efficiency.

You may have noticed that Arctic Fox's successor, Android Studio BumbleBee, is now available for Beta release channel. We've added many exciting improvements to this release, including support for Material You for the first time, further optimizations to the Jetpack Compose tool, and more development productivity improvements. You can also scale your Android 12L device with BumbleBee to scale your application. Next, we'll detail the features and improvements that are representative of this release, and give you a sneak peek at the latest features we've developed for future versions of Android Studio.

https://www.bilibili.com/video/BV1eb4y1H78x/?aid=635650668&cid=486034607&page=1

△ Detailed explanation of new features of Android Studio

build related

Before you can experience the new features of Android Studio, you may need to upgrade your project. You can use the AGP (Android Gradle Plugin) upgrade assistant to help you with this task. When importing your project, you can click "Begin Update" in the lower right corner, and then click "Show Usage", at this time, the interface will show what changes will happen to the project. You can simply accept these suggestions and run the import.

△ Use the AGP upgrade assistant to upgrade the project

build configuration cache

After the project's AGP has been upgraded to the latest version, we can start building the project. After the build is complete, we can open the Build Analyzer panel and see some of the suggestions provided here. In these recommendations, we focus on Build Configuration time.

We click on "Optimize this" and in the following screen click on the "Try Configuration cache in a build" button and Android Studio will run your build with configuration caching enabled. This process checks if your build is compatible with the configuration cache - in this case it is. Click the "Enable Configuration Cache" button to enable the configuration cache to improve the build speed of the project.

△ Enable configuration cache

Enabling the configuration cache essentially sets the environment variable org.gradle.unsafe.configuration-cache=true in the project's gradle.properties file. In the present embodiment, gradle.properties document also provided android.enableJetifier=true , the environment variable for the Support package dependencies equivalent Android X migration package. We plan to add a setting in the Build Analyzer to check if enabling Jetifier is necessary. You can try closing Jetifier yourself, if you can still build successfully after closing it, you can reduce the build time of the project.

supports non-transitive R class

Another build-related feature is support for non-transitive R classes. To demonstrate this feature, I switched to a larger project - the k-9 mail app. We first click on "Refactor" and then select "Migrate to Non-Transitive R Classes". This will analyze the entire project, find all source files referencing resources, and rewrite them as project local files, while also adding android.nonTransitiveRClass=true to gradle.properties to enable specific settings in the build system. This will allow the build to skip a lot of resource merging, which can help improve performance. If your project contains a lot of modules and resources, it is highly recommended that you try this feature.

Lint Incremental Cache

The last feature about build speed has to do with lint. One of the frequent requests we get from users is that lint will run faster on the CI server. As a result, we support incremental lint tasks and caching starting with Bumblebee Canary 13, which also includes remote caching.

Our k-9 project consists of about 30 modules with a total of about 100,000 lines of code distributed over about 1,100 source files. With caching enabled and no changes made to the project, we first clean the project to ensure that there are no lint reports in the project. Next we ran lint again and saw that our task only took a few seconds to import these reports from the cache.

△ Lint pulls the cache when simulating a CI task

Next we go a step further and make changes to the contents of the file, which is a new event for lint. Repeat the previous operation again: run clean, then run lint (simulating the CI build process), you can see that the lint task only re-analyzes this changed module and imports a lot of cached results again. Now we can see the project's updated lint report in 17 seconds, compared to the three and a half minutes the old lint took.

interface stuck tracking

Now that we've talked about performance, let's take a look at the Profiler. One of the features we're currently putting the finishing touches on is the ability to track stutters in Android Studio. Stuttering refers to the phenomenon that the interface cannot keep up with the frame rate. To track stutter, you first need to record a track in Profiler.

Next we can switch to the Frames view. In Android 11 and 12 it is now possible to capture the life cycle of a frame, as shown in the image below is the captured frame. I will sort these frames by their duration in the app.

△ In the recorded track, the result after the frame duration is sorted

In this example, frame 1748 looks very slow. When we select it, we can see the life cycle of the frame on the left side of the pane. This part of the display is color-coded, with the current frame corresponding to purple, and the same purple bar is shown where the GPU and composition are waiting. We can just zoom out the view a bit to see when it appears on the screen. As you can see, the previous frame stayed on the screen for a long time, which is what we call stuttering.

△ Frame life cycle

The next step is to look at the application and rendering threads. We can swipe to select an area in the interface, and we can see what the app has done during this period to find out the source of the lag. I think in this recording the app was trying to load a bunch of textures at the same time and that's what caused the stutter.

Graphics Editor

We switched our focus from performance to graphical editors. Suppose we have a camera interface, the top half is the viewfinder, and the bottom half contains some labels for pictures. What we want to achieve is for the camera interface to rotate appropriately when the device is moved between landscape and portrait.

△ The camera interface in this example

MotionLayout rotation animation

We can use MotionLayout to achieve this functionality. The camera has two states: normal portrait state and landscape state. We only need to set the corresponding constraintRotate attribute in the XML file of MotionLayout; then in AndroidManifest.xml, lock the screen orientation of Activity to portrait.

<ConstraintSet
    android:id="@+id/portrait_L90"
    motion:deriveConstraintsFrom="@id/landscape_left"
    motion:constraintRotate="left">

</ConstraintSet>

△ Configure the constraintRotate property

You can play the transition animation through the graphics editor to verify the effect of the modification:

△ Preview the rotation animation effect of the control in the graphics editor

Embedded Emulator & Device Manager

You can check how the above code works in a real device through the emulator. We've embedded the emulator into Android Studio and spent a year enhancing its stability and making many optimizations. Starting with Bumblebee, the embedded emulator will be the default configuration. After launching the example project, you may notice that when the camera is active, Android Studio gives hints on how to navigate within the camera's virtual scene. We can move the perspective in the virtual scene that the simulator presents to the camera by simply holding down the Shift key.

Embedded emulators can also access all extended controls. For example, you can set up navigation routes, access virtual sensors, and more. In this example, we can change the device pose to test the effect of rotating the screen. As you can see in the image below, as I rotate the device to the side, the simulator's interface is updating to keep the rotation in sync with the sensor.

△ Change the device attitude by extending the control

The simulator is still a bit cumbersome to do this kind of operation, if you want to use a physical device for testing, you will use another new feature - Device Manager. We removed the AVD dialog and integrated the device into Device Manager. Now, both virtual devices in the emulator and physical devices connected to the computer are displayed together here.

We're also exploring a feature that will make it easier for you to test animations in the Design interface without having to run the project on a physical device. Earlier, you've seen how to play animations in the Design interface. As shown in the image below, you can also rotate the screen in the Design interface. This allows you to test the animation while editing it.

△ Simulate rotating screen in the graphics editor

Android 12L Screen Adaptation & Visual Linting

Let's look at another layout. Below is a welcome screen where we animate the "WELCOME" message from the edge to the center of the screen. So the animation starts off screen.

△ Sample interface

Android 12L adds the concept of device classes, whose primary task is to deal with view compatibility issues between different types of large-screen devices. Android Studio's graphical editor provides a number of reference devices. I switch the view to tablet mode and can see that the "WELCOME" message is not offscreen, it is displayed at the beginning. That way I can tell that the animation doesn't work well on the big screen.

In this case, I found the problem by looking at a variety of different screen sizes, but we don't want you to do this every time. So we're working on a new feature, tentatively named "Visual Linting". Click the Alert button to open the problem view, and you can see that a button in the alert layout is partially hidden. We can look at different preview configurations, and if one view is displayed on one screen, it is best to be displayed on the other screen as well. We can open the Layout Validation view and check the layout on various screen sizes here; open the Problems view below, which shows inconsistencies between several layouts.

△ Check the layout under different screen sizes

Let's look at a more practical application. The image below is a task tracker. Open the issues panel to see a list of some of the issues found. Let's open the Layout Validation view again to see the message here. As you can see, the first hints at the view inconsistency we just saw, and it also states that the bottom bar only needs to be displayed in narrower layouts; another problem is that in very wide layouts, the lines of text The number of characters exceeds 120, which reduces the usability of the app. Crucially, we don't have to review all of these configurations ourselves, Android Studio helps us check in the background. We also plan to expand the scope of inspections beyond just screen size issues. For example, you can check for unexpected line breaks in a specific language or locale, and so on.

△ Visual Linting will check for problems in the view and give us hints

Jetpack Compose

Finally, let's talk about the equally important Compose. We have full support for Compose in Arctic Fox, but in Bumblebee we've added several new features to it.

Interactive Preview & Animation Check

Clicking the touch icon next to the preview interface will initiate the interactive mode, which usually takes less than two seconds. Now we can run the application in the Design interface and perform interactive testing. For example, I can click to open the cart, open the menu, etc. We can use this feature to do some simple testing of the app, and it starts and quits quickly.

△ Interactive preview

Another feature related to this is animation inspection support. Similar to the interactive mode, click the animation check icon next to the preview screen to see a view of all animation curves in the animation. You can drag to see different animations, or loop them. This is a handy way to see how the animations fit together when we need to adjust certain curves. By the way, in the Canary version, there will be a configuration icon next to the preview annotation, which allows you to open the configuration picker to easily change and configure the preview.

△ Animation check

Literal real-time editing

An important feature of Compose is the ability to iterate over the interface and change the code to see the effect immediately. However, build speed can have a lot of negative impact on this, so we're working on some features to help with this. One such feature is real-time editing of literals, including strings, numbers, and booleans.

Take our Rally banking app, for example. I can directly change the text of the reminder dialog in the app. As you can see in the image below, the preview is updated almost in real time as I type. This also works for numbers, i.e. I can change the padding to a large value if necessary.

△ Real-time updated text modification

Note that this feature is not only for previews, it also works fine on physical devices. I can change the text just like I did, and the same way I can change numbers and booleans.

Long-term planning

Just now I showed you what's available in Arctic Fox and Bumblebee, as well as some of Chipmunk's in-development features. Next, I'll give you a sneak peek at some of the features we're working on for future releases.

Compose Live Editing

The first is Compose real-time editing. This function is a generalization of the "literal real-time editing" function shown above. It supports editing needs in more scenarios, not just modifying constants and strings. For example, we can add a checkbox to the preview, and after a few seconds, we can see the checkbox appear in the interface.

The same feature doesn't just apply to previews. We know that for Compose development, it can be very helpful to have an embedded emulator side-by-side when testing application logic. We're making live editing work on the emulator as well. The picture below is our running Compose application, we can not only change the string as we just did, but also comment out some parts of the interface, reorder, and change the parameters... As you can see, these operations are in Edits are applied to the interface within milliseconds.

△ Real-time updated fuzzy state

The above example takes a side-by-side trial of blurring in Android 12. We support blur effects in both layout preview and design preview.

This is a very exciting feature. But the lesson we've learned from Instant Run is that before releasing a feature, you have to make sure it's very reliable. So we're going to spend more time making sure this feature doesn't go wrong when it's incorporated into Android Studio.

Light Mode

The next feature is the exact opposite of what was shown above, and this is the lightweight mode. Because of the live editing feature, Android Studio does a lot of calculations as you type to display the updated interface in real time as quickly as possible; and if Visual Linting is used, Android Studio runs analysis in the background to discover Potential issues in different screen sizes, etc. With lightweight mode, you can tell the IDE that you want it to consume less resources during your usage.

Lightweight mode is built on top of IntelliJ's power saving mode. After entering light mode, the Compose live editing feature shown above will no longer work; and when opening a layout XML file, the split view will not be displayed by default as usual, but only the source file.

While editing a Kotlin file in lightweight mode, you won't perform the various common and expensive editor validations that you normally do, but you can still use "Go to Statement" and similar basic editing features. If I type something meaningless, it would normally produce a red warning, but it doesn't do that now. And if I save the file, it temporarily unblocks light mode so you can get the basic authentication you need.

We're optimizing features in Android Studio to appropriately reduce your workload when you're in Lite mode. For example, the layout editor will perform tasks such as image scaling and antialiasing that are less expensive. We're also trying to disable some editor features, like in power save mode. These features are also in the early stages of exploration, but promising and hopefully we will get some results.

summary

The above is all the content introduced in this article, which covers the improvements in three directions that the Android Studio BumbleBee version focuses on, including Jetpack Compose, development efficiency optimization, and adaptation to Android 12L large-screen devices.

We've also introduced you to the latest features coming to Chipmunk releases. In addition to what was described earlier, this release adds new features included in IntelliJ IDEA 2021.2, a resizable emulator for Android 12L, and many more. Due to space limitations, we cannot introduce them to you one by one. If you're interested in these new features, you can download and try Chipmunk and let us know what you think.

We look forward to seeing you using Android Studio and creating great apps!

You are welcome click here to submit feedback to us, or share your favorite content and found problems. Your feedback is very important to us, thank you for your support!