16-10-2012, 03:39 PM
Reloading Android Application Resources at Runtime
Reloading Android Application Resources at Runtime.pdf (Size: 225.4 KB / Downloads: 72)
Introduction
In the last four years the adoption of smartphones has risen sharply. This has created a new
market of mobile applications for the developers. Android is one of the leading platforms with
50.9% market share at the end of the fourth quarter of 2011 [1].
Android is an open source platform that can be freely licensed by any mobile device
manufacturer. This has resulted in availability of a wide variety of Android devices – in
addition to mobile smartphones Android has made its way onto tablets, television set-top
boxes and tablet-laptop hybrids. Even within a device class the devices have varying screen
sizes and resolutions, sensors, keyboard options, etc.
A part of the Android SDK has been devoted to the management of resources across different
configuration classes – it is possible for an application to specify different layouts, bitmaps
and values for different device configurations. An application may have separate layouts for
tablets and smartphones, making optimal use of the different screen sizes. The Android SDK
enables the developer to define multiple resource sets from a single codebase but this comes
with a cost – the resource system is complex and difficult to grasp for new developers. As the
resources are compiled and bundled with the application at build it increases the build and
turnaround times when developing Android applications. This is especially evident for
applications with large number of resources.
This thesis explores a method to reload Android application resources at runtime. The method
is used as a basis to construct a tool for developers called Catalyst that enables an Android
developer to see results inflicted by resource changes near realtime and without rebuildingredploying
or restarting the application.
Chapter 1 gives a general overview of Android application development process along with
the tools used to build Android applications. Chapter 2 describes the Android resource
framework in detail by listing various resource types, their basic usage and the way Android
represents and interprets them internally. Chapter 3 is an overview of various technologies and
techniques used to implement Catalyst. Chapter 3 also provides a short set of measurements
done with and without using Catalyst. The full source code for the utility developed is stored
on a compact disc which is included with this thesis as Appendix 1.
1. Development Process of Android Applications
Android Architecture
The Android operating system is based on a modified fork of Linux kernel. On top of the
kernel there are 3 distinct layers - a set of native system libraries, the Android runtime
consisting of Dalvik Virtual Machine with its support libraries and the Application Framework
which is commonly referred to as the official API [2].
The Dalvik VM is a register-based VM that runs Dalvik bytecode, which is heavily optimized
for mobile applications. Java bytecode can be converted to Dalvik bytecode by the dx tool
bundled with Android SDK. This makes developing applications with Java possible.
The Application Framework is a collection of frameworks enabling applications to use UI
widgets/libraries and to interface with other system components including, but not limited to:
applications via IPC, the native system libraries and system hardware. The visible part of the
Application Framework is the public API and extensively documented by Google. The
framework also provides facilities for application resource retrieval.
Structure of an Android Application
An Android package consists of four categories of contents [3]:
1. Dalvik bytecode files (optional)
2. An indexed resource table (optional, present if the package has resources)
3. Uncompiled resources bundled with the application (optional)
4. Manifest file (required)
Android SDK contains tools to convert and package source files for these components. Google
has provided two toolchains – an Eclipse plugin called ADT (Android Developer Tools) and a
number of command line tools enabling the packaging of applications without the Eclipse
IDE. Every package is uniquely identified by a package name, a string identifier consisting of
latin characters and dot characters. The package name follows Java package naming
conventions and is defined in the manifest file.
According to Google the build process of the ApiDemos sample takes roughly 20 seconds [4].
ApiDemos is a medium-sized sample Android application distributed with the Android SDK
and has around 500 resource files. Larger projects may have a greater amount of resource files
– up to multiple thousands. In these cases build times can take more than 2 minutes.
The Build Process
The default build procedure for Android applications consists of the following sequence of
steps [5]:
1. Android asset packaging tool (aapt) crawls through the resource folder and generates
an integer ID for every resource. These ID’s are written into R.java source file under
generated sources folder where they can be accessed from application code.
2. Java compiler (javac) compiles the application’s java source files along with generated
source files (including R.java).
3. Dexer (dx) translates the compiled Java bytecode into Dalvik bytecode (dex) format.
4. Aapt takes resource ID’s and the resource folder as input and:
1. Runs pngcrunch, a PNG compression tool, on any bitmaps under resource
folder
2. Adds 9-patch PNG chunks to 9-patch images
3. Compiles any XML resources into Android XML binary format
4. Constructs a resource table that contains the identifiers and configurations for
all resources. Also contains primitive resources (scalars).
5. Apkbuilder zips the resource table, application code and compiled resource into an apk
file.
The SDK tools starting from version r14 skip some parts of this process if possible. Lets
consider the case where developer makes changes to application code - in that case the tools
can simply rerun steps 2., 3. and 5. as no resources were changed. This helps to save some
time.
5
If a single resource is changed, e.g. a bitmap file, then steps 1., 2. and 3. can be omitted - the
code hasn’t changed and there were no changes in resource ID’s (no resource added nor
deleted). If a developer adds a new resource file then all of the build steps have to be executed
because resource ID’s have to be generated again.
The Impact of Build Times on Development
There are two ways to develop UI for Android applications: one either creates and composes
widgets from the code or alternatively uses the standard layouts. Developing user interfaces is
usually an iterative process and for that reason the long deployment times are a major hurdle
for developers. A brief survey in a small Tartu IT company (Mobi Solutions OÜ) revealed that
on average an Android developer makes 25-100 rebuilds every day.
There are a few ways to mitigate this problem:
1. One can use the layout editor view bundled with the Android Eclipse plugin (ADT).
The layout editor bundled with ADT is based on a x86 port of the resource framework
present on the ARM builds of Android. This fairly straightforward approach works for
simpler layouts. It fails however in cases where the visual state is dependent on the
business logic of the application, e.g., when displaying a dialog for a specific event or
dynamic data inside the layouts. Some developers use stub values when using the
graphical layout editor but this approach is error-prone as such stub values may end up
in production code due to developer errors.