Looking at JRebel for Android and Instant Run: how to update code and resources in Android application without wasting time on restarts.

This comparison between the methods JRebel for Android and Instant Run employ to update your code without restarting the app has originally been published on RebelLabs by Sten, the product owner of JRebel for Android.

People keep asking us about the differences between JRebel for Android and Google’s own Instant Run. Since Android Studio 2.0 has finally been released, this is a good time to compare the two.

Back in November of 2015, Google announced Android Studio 2.0. Complete with a totally new feature titled “Instant Run”. Delivering faster build times to Android developers by supporting hot swapping code and resources in an already running application. The idea itself is nothing that new — it has been present in Java for over a decade. JRebel, the Java code reloading tool for Java SE/EE, has been enhancing developers’ lives for the past 8 years. This leads us to JRebel for Android. A tool that is approximately 1.5 years old, bringing the same technology to Android developers.

Today, I will provide an overview of how Google’s Instant Run and JRebel for Android handle code and resource changes. Side by side.

Swapping code

Both Instant Run and JRebel for Android are all about “swapping” code or resources, live, inside a runtime environment. This means that you install the APK just once. When the APK is present on the target device, you can start sending over small, incremental patches that will be applied.

This is a huge timesaver in a multitude of ways:

• The build process no longer needs to package and build the code parts that have not changed — just rebuild the deltas.
• Less data needs to be pushed to the device over ADB.
• Once on the device, the dex2oat has a lot less work to do, compared to a full APK install.

There are 3 types of swaps in total — hot swap, warm swap and cold swap. The initially built APK has to be modified to support these swaps. On a high level, a client to server communication will be established between the application and Android Studio. The data itself is transferred via ADB. This way it can work both over wireless and over USB, depending on your setup.

Let us take a closer look at what the different kinds of swaps do.

Hot, warm, and cold swap

Hot swap updates your application code without a new APK. This is done by adding stub methods that will be executed the next time the method is called. For example: if you update something in a View.onDraw() method, the next time the method gets called, it will render the new content. It is important to remember that it is your responsibility as a developer to make sure the method does get called after the swap.

Warm swap is rather similar to hot swap. Its main use case is to update resources on the fly. As the resources are usually inflated in the starting stages of Activities and Fragments, it is useful to do an Activity.recreate() once the resource changes are detected. This saves us from having to manually navigate between screens or even worse — write some boilerplate code to enforce inflating of layouts.

Cold swap is used to make structural changes to the application that cannot be supported by hot or warm swapping. These changes are different for both tools and we will take a look at those in the next section. Cold swap differs from hot and warms swaps by having to restarting the application. This is still faster than a regular APK build and install — because no APK has to be built.

Here is the short version, code changes are handled this way:

• Hot Swap — New code is executed in the next call.
• Warm Swap — New code is executed after the activity restarts.
• Cold Swap — New code is executed after the application restarts.

Changes to resources have fewer options:

• Warm Swap — New resources are used after the activity restarts.
• Cold Swap — New resources are used after the application restarts.

Comparing JRebel for Android and Instant Run

Let us take a look at how JRebel for Android and Instant Run use these different swaps.
Once the updated code is transferred to the device, Instant Run will perform a hot or warm swap. This depends on the Android Studio > Preferences > Build, Execution, Deployment > Build Tools > Instant Run “Restart activity on code changes” setting. When enabled (and it is by default), you will get a warm swap. Existing resource changes with Instant Run will always be handled using a warm swap.

JRebel for Android does not have a separate “Restart activity on code changes” setting. Code and resource changes will always be handled by a warm swap. This is an acknowledged user experience decision that we made a long time ago. The main reason for why JRebel for Android does not “hot swap” is to make it easier for the user to understand what is happening — and what to expect after code or resources have been updated.

In conclusion, both hot swap and warm swap are awesome due to the time saved. There are multiple steps contributing to this — starting from skipping the APK install all the way to not having to re-navigate your entire application. Here is a table that shows which changes are supported by Google’s Instant Run and JRebel for Android with the combination of hot or warm swaps. In short: what keeps your application running.

Cold swap is used to make structural code changes to your application. Also, cold swap will not require building a new APK and it will still be faster than the classical build and install process. Instant Run supports cold swaps from API 21 and newer, falling back to a slower APK rebuild for older versions. JRebel for Android works from API level 15 and places no limitations on cold swapping by platform level. When a cold swap occurs, your application will be restarted and the state will be lost. Looking back at the table above, all changes that cannot be handled by hot/warm swap will be performed with a cold swap.

APK rebuild scenarios

There are still changes that will require building an APK and installing it on the device. This is mandatory for cases where an external process needs access to some of the resources. The most common examples include changes to AndroidManifest, widgets and notification resources. Both Instant Run and JRebel for Android share these limitations for now.

Summary

If you are an Android developer and new to both tools, you are going to find them to be a great benefit going forward and in becoming a more productive, less frustrated developer. Less context switching and time spent waiting will surely improve the quality of applications released into the wild.

Whether you decide to pick Google’s Instant Run or JRebel for Android is entirely up to you. If you find something that works for you, grab it and make use of it! There is no longer a need to waste time with build and install. Make sure you give these tools a spin and become more productive.

For more Android related posts or to learn more about JRebel for Android, check out our RebelLabs blog: https://zeroturnaround.com/tag/android/