Runtime Class for Android
Developers writing Android applications suffer from a dreadful redeploy time every time they need to test changes to the source code. While runtime class reloading systems are widely used for the underlying programming language, Java, there is currently no support for reloading code on the Android platform. This paper presents a new tool, JRebel.Android that enables automatic runtime class- and resource reloading capabilities for Android. The target of this paper is the Android developer as well as the researcher for which dynamic updating capabilities on mobile devices can serve as a basic building block within areas such as runtime maintenance or self-adaptive systems. JRebel.Android is able to reload classes in much less than 1 second, saving more than 91% of the total redeploy time for small apps, more than 95% for medium size apps, and even more for larger apps.
An acknowledged bottleneck in software development is the redeploy time, that being the total time to reflect code changes into a suitable test scenario. Some programming languages like PHP or JavaScript, by nature, does not suffer from long redeploy times, while others like Java or C# do. In this paper we focus on the Android Platform, [2] for which Java is the programming language utilized. Having inherited static typing from Java leaves Android platform developers without ability to perform class reloading to reflect code changes immediately while developing. While for the standard Java platform, developers can change method bodies of already defined classes, there is currently no such capability on the Android platform. Although, there are some well-adopted approaches for reloading classes in Java, such as, JRebel, [8] Spring Loaded, [1] and DCEVM, [11] (more details on related work in section V), supporting class reloading on the Android platform is further troubled by the fact that applications need to be packaged in a special archive (APK file) where standard Java classes have been transformed to a special register-based bytecode format called DEX. Hence, there is no direct link from a compiled class to its correspondent runtime class definition representation.CodeShoppy
In this paper we present a tool that allows seamless and immediate class reloading on the Android platform. Not only can classes be reloaded, but also changes to resources defined in XML-files etc. are reflected immediately on the running devices. The class reloading engine is based on the traditional JRebel core, with almost full class redefinition capabilities, including adding/removing fields, methods and constructors, making changes to public interface methods as well as changing static field values. The only changes that cannot be performed at the Java language level are changes to the ‘extends’- and the ‘implements’ clauses, rendering the tool able to perform almost any kind of change to the code. Section II will dig into the architectural overview of the tool and describe how the tool works and how it should be operated by developers using it. Section III will present a small proof-of-concept example around two sample apps, which is also showcased in the accompanying video of this tool demonstration paper. In section IV we evaluate the performance of the tool comparing the redeploy time with and without the tool. Section V discusses the most relevant related work, while section VI concludes the paper
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 or Gradle. 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.
https://codeshoppy.com/android-app-ideas-for-students-college-project.html