Mobile

Deep dive into Live Edit for Jetpack Compose UI


Posted by Alan Leung, Staff Software Engineer, Fabien Sanglard, Senior Software Engineer, Juan Sebastian Oviedo, Senior Product Manager

A closeup look into how the Android Studio team built Live Edit; a feature that accelerates the Compose development process by continuously updating the running application as code changes are made.

What’s Live Edit and how can it help me?

Live Edit introduces a new way to edit your app’s Jetpack Compose UI by instantly deploying code changes to the running application on a physical device or emulator. This means that you can make changes to your app’s UI and immediately see their effect on the running application, enabling you to iterate faster and be more productive in your development. Live Edit was recently released to the stable channel with Android Studio Giraffe and can be enabled in the Editor settings. Developers like Plex and Pocket Casts are already using Live Edit and it has accelerated their development process for Compose UI. It is also helping them in the process of migrating from XML views to Compose.

Moving image illustrating Live Edit in action on Android Studio Hedgehog
Live Edit in action on Android Studio Hedgehog

When should I use Live Edit?

Live Edit is a different feature from Compose Preview and Apply Changes. These features provide value in different ways:

Feature

Description

When should I use it?

Live Edit [Kotlin only, supports live recomposition] Make changes to your Compose app’s UI and immediately see their effect on the running application on an emulator or physical device. Quickly see the effect of updates to UX elements (such as modifier updates and animations) on the overall app experience while the application is running.
Compose Preview [Compose only] Visualize Compose elements in the Design tab within Android Studio and see them automatically refresh as you make code changes. Preview individual Compose elements in one or many different configurations and states, such as dark theme, locales, and font scale.
Apply Changes Deploy code and resource updates to a running app without restarting it—and, in some cases, without restarting the current activity. Update code and resources in a non-Compose app without having to redeploy it to an emulator or physical device.

How does it work?

At a high level, Live Edit does the following:

  1. Detects source code changes.
  2. Compiles classes that were updated.
  3. Pushes new classes to the device.
  4. Adds a hook in each class method bytecode to redirect calls to the new bytecode.
  5. Edits the app classpath to ensure changes persist even if the app is restarted.

Illustration of Live Edit architechture
Live Edit architecture

Keystroke detection

This step is handled via the Intellij IDEA Program Structure Interface (PSI) tree. Listeners allow LE to detect the moment a developer makes a change in the Android Studio editor.

Compilation

Fundamentally, Live Edit still relies on the Kotlin compiler to generate code for each incremental change.

Our goal was to create a system where there is less than 250ms latency between the last keystroke and the moment the recomposition happens on the device. Doing a typical incremental build or invoking an external compiler in a traditional sense would not achieve our performance requirement. Instead, Live Edit leverages Android Studio’s tight integration with the Kotlin compiler.

On the highest level, the Kotlin compiler’s compilation can be divided into two stages.

The analysis performed as the first step is not entirely restricted to a build process. In fact, the same step is frequently done outside the build system as part of an IDE. From basic syntax checking to auto-complete suggestions, the IDE is constantly performing the same analysis (Step 1 of Diagram 1) and caching the result to provide Kotlin- and Compose-specific functionality to the developer. Our experiment shows that the majority of the compilation time is spent in the analysis stage during build. Live Edit uses that information to invoke the Compose compiler. This allows compilation to happen within 200ms using typical laptops used by developers. Live Edit further optimizes the code generation process and focuses solely on generating code that is only necessary to update the application.

The result is a plain .class file (not a .dex file) that is passed to the next step in the pipeline, desugaring.

How to desugar

When Android app source code is processed by the build system, it is usually “desugared” after it is compiled. This transformation step lets an app run on a set of Android versions devoid of syntactic sugar support and recent API features. This allows developers to use new APIs in their app while still making it available to devices that run older versions of Android.

There are two kinds of desugaring, known as language desugaring and library desugaring. Both of these transformations are performed by R8. To make sure the injected bytecode will match what is currently running on the device, Live Edit must make sure each class file is desugared in a way that is compatible with the desugaring done by the build system.

Language desugaring:

This type of bytecode rewrite aims to provide newer language features for lower targeted API level devices. The goal is to support language features such as the default interface method, lambda expression, method reference, and so on, allowing support down to the min API level. This value is extracted from the .apk file’s DEX files using markers left in there by R8.

API desugaring:

Also known as library desugaring, this form of desugaring aims to support JAVA SDK methods and classes. This is configured by a JSON file. Among other things, method call sites are rewritten to target functions located in the desugar library (which is also embedded in the app, in a DEX file). To perform this step, Gradle collaborates with Live Edit by providing the JSON file used during library desugaring.

Function trampoline

To facilitate a rapid “per-key-stroke” speed update to a running application, we decided to not constantly utilize the JVMTI codeswap ability of the Android Runtime (ART) for every single edit. Instead, JVMTI is only used once to perform a code swap that installs trampolines onto a subset of methods within the soon-to-be modified classes inside the VMs. Utilizing something we called the “Primer” (Step 3 of Diagram 1), invocation of the methods is redirected to a specialized interpreter. When the application no longer sees updates for a period of time, Live Edit will replace the code with traditional DEX code for performance benefits of ART. This saves developers time by immediately updating the running application as code changes are made.

Illustration of Function trampoline process
Function trampoline process

How code is interpreted

Live Edit compiles code on the fly. The resulting .class files are pushed, trampolined (as previously described), and then interpreted on the device. This interpretation is performed by the LiveEditInterpreter. The interpreter is not a full VM inside ART. It is a Frame interpreter built on top of ASM Frame. ASM Frame handles the low level logistics such as the stack/local variables’s push/load, but it needs an Interpreter to actually execute opcode. This is what the OpcodeInterpreter is for.

Flow chart of Live Edit interpretation
Live Edit interpretation flow

Live Edit Interpreter is a simple loop which drives ASM/Interpreter opcodes interpretation.

Some JVM instructions cannot be implemented using a pure Java interpreter (in particular invokeSpecial and monitorEnter/Exit are problematic). For these, Live Edit uses JNI.

Dealing with lambdas

Lambdas are handled in a different manner because changes to lambda captures can result in changes in VM classes that are different in many method signatures. Instead, new lambda-related updates are sent to the running device and loaded as new classes instead of redefining any existing loaded classes as described in the previous section.

How does recomposition work?

Developers wanted a seamless and frictionless new approach to program Android applications. A key part of the Live Edit experience is the ability to see the application updated while the developer continuously writes code, without having to explicitly trigger a re-run with a button press. We needed a UI framework that has the ability to listen to model changes within the application and perform optimal redraws accordingly. Luckily, Jetpack Compose fits this task perfectly. With Live Edit, we added an extra dimension to the reactive programming paradigm where the framework also observes changes to the functions’ code.

To facilitate code modification monitoring, the Jetpack Compose compiler supplies Android Studio with a mapping of function elements to a set of recomposition group keys. The attached JVMTI agent invalidates the Compose state of a changed function in an asynchronous manner and the Compose runtime performs recomposition on Composables that are invalidated.

How we handle runtime errors during recomposition

Moving image of Live edit handling a runtime error
Live Edit handling a runtime error

While the concept of a continuously updating application is rather exhilarating, our field studies showed that sometimes when developers are writing code, the program can be in an incomplete state where updating and re-executing certain functions would lead to undesirable results. Besides the automatic mode where updates are happening almost continuously, we have introduced two manual modes for the developer who wants a bit more control on when the application gets updated after new code is detected.

Even with that in mind, we want to make sure common issues caused by executing incomplete functions do not cause the application to terminate prematurely. Cases where a loop’s exit condition is still being written are detected by Live Edit to avoid an infinite loop within the program. Also, if a Live Edit update triggers recomposition and causes a runtime exception to be thrown, the Compose runtime will catch such an exception and recompose using the last known good state.

Consider the following piece of code:

var x = y / 10

Suppose the developer would like to change 10 to 50 by deleting the character 1 and inserting character 5 after. Android Studio could potentially update the application before the 5 is inserted and thus create a division-by-zero ArithmeticException. However, with the added error handling mentioned, the application would simply revert to “y / 10” until further updates are done in the editor.

What’s coming?

The Android Studio team believes Live Edit will change how UI code is written in a positive way and we are committed to continuously improve the Live Edit development experience. We are working on expanding the types of edits developers can perform. Furthermore, future versions of Live Edit will eliminate the need to invalidate the whole application during certain scenarios.

Additionally, PSI event detection comes with limitations such as when the user edits import statements. To solve this problem, future versions of Live Edit will rely on .class diffing to detect changes. Lastly, the full persisting functionality isn’t currently available. Future versions of Live Edit will allow the application to be restarted outside of Android Studio and retain the Live Edit changes.

Get started with Live Edit

Live Edit is ready to be used in production and we hope it can greatly improve your experience developing for Android, especially for UI-heavy iterations. We would love to hear more about your interesting use cases, best practices and bug reports and suggestions.

Java is a trademark or registered trademark of Oracle and/or its affiliates.