Resource Reloading for Android
JRebel.Android has two components – agent running on an Android device and service running on the host (developer’s machine). The primary responsibility of the service component is to watch for changes in the classes and resources directories. Upon finding changes to files the service component prepares them for later reloads by transforming the bytecode according to JRebel’s inner workings and sends them to the agent, telling the agent to perform a reload task. Whenever the agent component receives the files from the service component, it triggers the runtime reloading operation, thus making the offline changes that were picked up by the service component active on the device. The tool is designed with ease of use in mind, so the only required input parameter for the service is the root directory of an Android project. Given this directory the service component automatically locates the Android manifest file, class and resource directories as well as any external libraries and project dependencies. Typically one of two build systems are used when developing Android applications, that being Ant orGradle. JRebel.Android supports both layouts, and there is even support for some custom project layouts built-in. The first time the service component is started for a given target Android project, it utilizes the Android Debug Bridge (ADB), [3] connection to install the agent as part of the existing Android application. For all subsequent runs, having an ADB connection available is optional. The only requirement thereafter is that the agent is either reachable by ADB or through the network somehow. Again, this is a clear sign of the ease-of-use design principle taken for JRebel.Android, given that it is not always be desirable to test Android applications on physical devices using cables, if the nature of the application requires the user to e.g. move around, or rotate the device a lot. Every time the service component starts up it transforms the bytecode of all classes, prepares resources and sends them to the agent now installed on the device. Upon receiving the preprocessed files the agent component restarts the underlying application now using the reload-enabled files. In order to make reload operations fast, the service component only processes changed files, meaning that the files sent to the agent component for reloads are small. For carrying out class reloading two main features are required – instrumenting the classes, thus preparing them for later reloads as described above and dynamically loading new classes into the runtime. As mentioned earlier, Android defines a custom bytecode format so the runtime neither has java.lang.instrument package, that on standard JDKs can be used to hook into the class loading process, nor can it hot-swap method bodies during a remote debugging session. In general, in order to run an Android application with a set of changed class files (contained within one or more DEX files), there are two options to consider. The first option would be to instrument the classes, then trigger the normal build sequence that prepares the full APK file and install onto the device. The second option is to utilize Android’s Instrumentation API replacing the application’s class loader on startup. With a custom classloader at hand it is possible to load classes from anywhere, including the changed DEX file(s). Hence, this approach benefits from the fact that the original APK file can be used, only the classes need to be replaced behind the scenes by the custom classloader. JRebel.Android uses the latter approach. This ensures that the same class loader is responsible for loading both the initial (transformed) classes and classes added later by reload operations. One additional benefit is the ability to quickly disable JRebel.Android simplyby restarting the application without Instrumentation in order to compare the behavior with and without our tool enabled. When classes are changed JRebel.Android collects the classes and tracks them inside a reload change set. This is done to allow atomic reloading of multiple classes, by flipping a single field inside the correspondent runtime representation of the reload change set. For this to work all reloadable classes must have a synthetically generated field that can hold a reload change set object. For every change set we invoke the DX tool to convert the changed class files into a DEX file. This task is always performed on the service side, since the assumption is that usually the hardware on the host machine is superior. CodeShoppy
Porting the JRebel standard core to Android has some major challenges. For example, the service component has to know the full class path up front to enable processing of all classes before they are sent to the device. Also, given the fact that system classes in general cannot be altered before loading, means that all of the hooks for handling reflection, serialization, dynamic proxies, hiding JRebel artifacts from the stacktrace to name a few, cannot be installed. For this reason JRebel.Android instead injects client-side hooks to method calls to specific methods within system classes, enabling enhanced behavior. This is quite effective, but works only when called from application classes and the set of libraries, for which the service component must also locate each one for installing the said client-side hooks. In the past decade more advanced class reloading capabilities have been proposed and to a large extent adopted by the Java community. Leading the pack currently is the commercial redeployment tool JRebel [8], which were recently enhanced with the capabilities brought in by the technology developed for Javeleon, [6]. DCEVM constitutes a completely different approach to class reloading in Java in the sense that it operates at the JVM-level enhancing the current HotSwap mechanism to allow arbitrary changes to code at runtime. Unfortunately, it does not work on all JVM’s and moreover requires the user to patch the JDK installation. In addition, DCEVM has no support for the Android platform whatsoever. To the best of our knowledge the only tool that does have some class reloading support for Android is InstaReloader, [7]. It supports adding/removing method, fields and classes, but it does not support changes to constructors as JRebel.Android does. Also, the Reflection API is not properly supported meaning that synthetically added members will show up in n this paper we have presented a tool for reloading classes and resources on the Android platform. With this tool developers writing apps can benefit from a close to zero build time and immediate feedback of changes made, without the need to go through a painful scenario of rebuilding and restarting the entire app. One major area of focus has been ease of use, which manifests in a number of ways, including the minimized requirements for setup. We have shown that it works on two sample applications one of which is quite large, and that the productivity gained by not having to restart is significant. Please make sure to watch the accompanying video of the tool in action.