Patent Application
20240095152
The present disclosure describes computer methods for low-level code manipulations applicable to multidex Android applications for instrumentation purposes, such as code coverage measurement.
Android application (app) is a software program that can be uploaded, installed, and executed on an Android device. Android app contains compiled code and other supplementing materials such as icons, pictures, markup files, XML files. When executed the app is to provide particular services including visual experience to the end user of the Android device.
Android system accepts Android apps distributed in the form of binary packages having the APK extension. An app may be packaged into a single or more APK files.
The main package would be called then base.apk inside Android system installation directory. The base APK usually contains the main functioning app code and resources, while other APK files may contain libraries and supplementary material that may vary from one to another Android device.
The base APK comprises of at least one DEX file. DEX is the binary format for Android app executable. DEX files contain the actual binary code that Android system unpacks and translates into instructions directly executed on the Android device by the Android Runtime (ART).
For more complex applications compiler distributes code over multiple DEXs inside a single APK due to DEX format limitations. For example, Android limits the number of methods inside a single DEX file to only 65536. Thus, an app that contains multiple DEXs is called the multidex app [1]. Multidex challenge is well known Android developers.Java community. However, this common knowledge does not apply to our instrumentation approach since our solution processes already compiled multidex applications and works on the disassembled representation of the bytecode.
DEX files can be disassembled into the smali representation. When an Android application is disassembled, it results in a ‘smali’ directory that corresponds to the primary DEX file. All supplementary DEX files are disassembled into separate smali directories, typically denoted as ‘smali_classes2’, ‘smali_classes3’, and so forth. This work utilizes smali representation for measuring code coverage in 3rd party Android apps.
Code coverage is a metric to measure the amount of executed code for an app. It is often used to measure the efficiency of testing procedures by app producers and to highlight the actually executed code for future in-depth analyses.
Typically, code coverage tools insert so-called instrumentation probes—specific instructions placed through the original app code to track its execution. When executed, such probes mark the corresponding array cell referenced by the probe identifier. The code coverage tool then maps the resulting execution information onto the original lines of code to highlight the executed lines in the code coverage report.
In the study by Pilgun et al. [2] the code coverage measurement approach has been implemented in a tool called ACVTool. ACVTool is a publicly available state of the art tool that measures code coverage at instruction-, method- and class-level for third-party Android apps. ACVTool disassembles an app using apktool, inserts probes into the smali code (human readible representation of binary code) and assembles the app again. Thus, one can run the app, and generate the code coverage report among app classes in the smali representation. The presented approach works well on most of single-DEX Android apps.
In another study by Pilgun A. [3] the extended ACVTool version was integrated into the new tool called ACVCut to shrink single-DEX apps based on the code coverage produced by ACVTool.
However, the public version of ACVTool (as well as any other code coverage tool) does not address the multidex structure of Android apps and the corresponding DEX limitations. Besides the limit of 65536 methods inside a single DEX file, a class may fit up to 65536 fields, and a single method may fit up to 65536 instructions. Secondly, ACVTool instruments only one DEX file and creates supplementary code files in the same DEX increasing the number of classes, fields, methods, and instructions in that same DEX file. These limitations create a prohibitive challenge for code coverage measurement in a multidex Android app. Thus, the existing single-DEX approach needs an extension to support multidex instrumentation taking into account the Android DEX format limitations.
ACVTool utilizes Apktool to repackage Android apps. Further, Apktool handles APK resources and repackages its DEX files using the baksmali/smali library. The baksmali project utilizes the dexlib2 library that can read and transform only a single DEX file into the smali representation. The new initiative, called the multidexlib2 library, was rigorously discussed [4] and then implemented to allow for APK patching in multidex format [5].
However, the multidexlib2 library was created for the DexPatcher [6][7] tool. DexPatcher allows developers patching APKs directly in the Android Studio. The DexPatcher tool reflects the bytecode from multiple DEX files into Java code so that developers could read familiar Java code representation. In this case, the multidexlib2 library handles reading and writing multiple DEX files maintaining their initial structure. Furthermore, the multidexlib2 library checks the number of code entities (e.g. the number of methods, fields, types) for overflow and raises an exception when the DEX pool has overflown.
However, multidexlib2 only allows patching existing code while checking and raising overflow exception. Multidexlib2 does not implement creating and rearranging of additional DEX files when overflow conditions are encountered. Moreover, multidexlib2 can't handle too long classes when the number of fields exceeds the DEX limitation. Furthermore, multidexlib2 does not handle the length of method limitation. These features are required to instrument Android APKs for code coverage measurement. Thus, multidexlib2 is not a suitable solution for instrumenting multidex applications.
To the best of our knowledge there is no other state of the art solutions addressing the above mentioned DEX limitations. Thus, a person skilled in the art would not find the reported below solutions to achieve same of similar results.
The present invention addresses the deficiencies of the state-of-the-art Android app instrumenting technique applied on already compiled single-DEX APK files. The invention extends the fine-grained code coverage measurement on multidex Android apps.
In the description below it is shown that multidex Android apps can be instrumented for code coverage measurement by applying additional steps to overcome the above-mentioned DEX format limitations.
The original steps included: original Android app disassembling; probes placing into a single smali directory, supplementary smali classes adding into the same directory, assembling, the instrumented app executing, the probes execution information pulling, code coverage report generating for the corresponding DEX file.
According to advantageous embodiment, additional steps are required when instrumenting the Android app as follows: instrumenting multiple DEX files, supplementary smali_classes directories creating, adding supplementary smali classes to the newly created smali_classes directory, rearranging supplementary files into additional smali_classes directories if the initially created smali_classes directory surpasses the DEX limits, collecting probes execution information by reflecting the corresponding probes arrays and ordering according to the naming convention.
Thus, the solution enables fine-grained code coverage measurement among multiples DEX files of a multidex Android app by introducing a novel computer-implemented method for generating and storing smali classes with regards to app instrumenting.
The present invention expands the existing single-DEX instrumentation approach on multidex Android apps by addressing the above-mentioned DEX limitations. It aims at enabling whole app code coverage measurement at the instruction level in multidex Android apps.
Then, ACVTool creates the AcvReporter, smali class per each smali directory diracv The AcvReporter classes are placed into the diravc directory. Each AcvReporter class initializes arrays to keep information about probes execution. As soon as all smali directories are instrumented, ACVTool adds other supplementary classes into the diracv directory.
The next step is to check the diracv directory for exceeding the DEX format limitations. If the number of methods or the number of fields exceed 65535, an additional dir2acv is created. In this case, the AcvReporter classes that exceed these limits are moved to the dir2acv, directory. More smali directories may be created correspondingly if the dir2acv, directory has reached the limits, too.
In the subfigure (b) two more smali directories were added to keep the above-mentioned supplementary classes. The presence of the smali_classes10 directory confirms that ACV classes overflow the DEX limit of one smali_classes9 directory. Therefore a few AcvReporter, classes were moved to the additional smali_classes10 directory.
The AcvReporterFields class implements the functionality of reading AcvReporter* fields by using reflection API, ordering fields by relying on the fields naming 175 convention.
AcvStoring and Acvnstrumentation classes further store the final probes execution information to binary files, one file per each instrumented smali classes directory. Afterwards, the multidex code coverage report is to be generated by using probes execution information and the smali representation of the multidex Android app.
To generate code coverage report in multidex format, ACVTool processes each binary file (the .ec file) and the smali code tree for the corresponding DEX file the same way as it worked the single-DEX ACVTool version. ACVTool stores all generated HTML (or XML) files according to their class paths. Thus, the final directory contains all the smali coverage HTML files merged from multiple smali directories.
The embodiment of this invention is an extension to the publicly available software tool called ACVTool or a new software package alternatively implemented in any programming language.
Some embodiments of this invention may comprise a system that runs locally or hosted on a server. In case of a server, it could be responsible for preparing the instrumented version of an Android app. When the app is instrumented, the user would be able then to download it and test the app locally. Alternatively, app testing could be run on the server side provided that the user has the necessary functionality for test guidance. Finally, the code coverage report could be generated at the server side, too.
The terms and conventions used in the text of this disclosure and presented on the figures are to be considered as not restrictive and may not bound the scope of this invention. For example, names of directories mentioned in the text and on the figures may vary, names and the structure of implemented classes may vary, the probe storying mechanisms may vary, code coverage report format may vary. Moreover, the described methods may include additional steps, the steps may follow different order or can be done in parallel.
| Number | Date | Country | Kind |
|---|---|---|---|
| LU502820 | Sep 2022 | LU | national |
