Android Resource Manager

Android Resource Management 02-Mar-10

Technical Paper Version 1.0

Android Resource Management

More about Aftek Draft Copy Page 1 of 8



Table Of Contents

Problem Statement ......................................................... 3

Background .................................................................... 3

Approaches adopted ....................................................... 4
1. Using exported jar from eclipse ................................................................................................4

2. Using aapt with two different resource directories ....................................................................4

3. Programmatically merging two resource tables of component and application ...........................5

The things you also would like to know ........................... 5
Aapt : .............................................................................................................................................6

Resource.cpp ..............................................................................................................................6

ResourceTable.cpp ......................................................................................................................7

ResourceTable data storage .........................................................................................................7

ResTable data storage .................................................................................................................7

Id Generation .................................................................................................................................7




Problem Statement

The component development with android has one big difficulty in the way – Resource Management of
Android. The resources provided in components are not accessible in the easy way when the component
is embedded in any application. Android doesn’t keep any distinguishing factor to separate the
component resources with application resources so that at runtime the respective component get its
own resources. The intent is to find out any workaround to mix up the resources of the application and
the component it uses in a fashion so that the application will get its resources and the component will
get its resources.

Background

1. Android keeps all the resources under res directory in the application .apk (archive like jar for
java – apk for android).

2. Android keeps all the needed information about resources in resource table dumped as
“resources.arsc” file. The resource table keeps track of the resources, their associated ids, and
their packages.

To build any android project – there are predefined steps that we need to take:

1. Android Asset Packaging Tool (aapt.exe)

It An Android SDK tool that generates a resource table from the <res> directory of an android
application whose assets (resources) are to be packaged together. It takes the android jar as
base library, Android Manifest file and application <res> folder for generating the resource
table. The resource table generated is dumped as “resources.arsc” file. The mapping of
resources and their associated ids are dumped into an “R.java” file for reference to develop
java classes of the application. The “resources.arsc” file along with the needed resources in
“res” folder is bundled within the application apk file. This <res> folder generated in apk file
contains the binary equivalent xml files in the res folder provided as input except for the xml
files from the values folder.

2. javac

Compile all the application java files along with the R.java generated by the aapt tool.

3. dex




It generates a .dex file from all the classes. Dex file is nothing but all classes combined in Dalvik
Byte code format. This generates a classes.dex file of all the converted class files.

4. apkbuilder

It prepares the final apk file from the dex file and the initial apk file. By default it signs the apk
with the debug keystore of the android. We can also provide our keyStore. We also can opt for
unsigned apk file by specifying the ‘–u’ option.

5. apk signing if needed.

If we opt for unsigned apk in apkbuilder, then we need to sign that apk by our own.

Approaches adopted

The approaches adopted involved two Android applications primarily using resources in the
form of layouts and values. Other resource of type anim, drawable etc were to be dealt with
later. One of the android applications acted as a component derived from an Android View and
made use of a basic layout with values resources used to layout a simple Text View. The other
application acted as the main Android application making use of the component by instantiating
it and using the generated View as a child in the main layout.

Hence, it was required that the component be compiled into a library with dependant resources
which would be resolved at runtime when the application statically links to the component.

1. Using exported jar from eclipse
Export the component classes and resources as jar from eclipse and provide it to application as
external library. By this all the classes and resources in the component get merged with
application. The final apk prepared by this method was having all the resources in the res folder
and the R.java was generated for all these resources merged. So the ids for component
resources too again got generated. This approach compiled fine but failed at runtime, since the
resource ids from component R.java and those generated in apk did not match. The application
gave ResourceNotFoundException for the resource id provided in component R.java which it
won’t find in application resources.

2. Using aapt with two different resource directories
Provide two different resources directories to aapt, one for application and one for component,
using ‘–S’ argument. In this approach, it gave us errors related overlay since the xml files in both
the packages were different. So we tried to generate the R.java like first approach and kept the
class file in the component package. But that approach too failed since the R.java contains all




static final values which get inline replaced in the class files which used the previous R class.
Hence at runtime, the component classes looked for a mapping of resources with the s ame ids
with which the R.java was generated.

3. Programmatically merging two resource tables of component and
application
Tried to change the aapt tool source code to merge the component resource table with
application resource table and then store the table in application apk so that class files in
component get all the references as generated during their compilation time. We partly
succeeded in this trial and were able to generate different resource ids for the application
resources. But when we merged the resource tables and dumped both the tables in the
“resources.arsc” file, it gave us exception at code in aapt for verification of the generated
“resources.arsc” file mentioning that the application can’t have two packages. This is because
android assumed one package unique for the application and derived all the things related to
the application using that package. So the final approach remained is to add all the resource
information of the component under application package.

During implementation of this approach, we added one –L option to provide the component jar
file. When aapt tool is run using this option along with –x option, it generates different resource
ids for the application resources.

The thing remained is to reverse engineer how the ResTable parse the resources.arsc file and
use the logic to add the component resources under application package.

The things you also would like to know

1. When we provide the component jar to android it combines all the resources in the res
folder of the component and the application, and keep them in the res folder.

2. Android has different way of processing resources under values directory and other
directories. The resources (xml files) under values directory can have following types of xml files
specifying the resources –

Attributes (attrs.xml): To store the attributes for your component developed that
would be accepted through the xml files in resources.

Strings: To store the string constants defined.

Types: To store the types used in the xml files.




The jar of the component developed should contain its generated compiled
AndroidManifest.xml file, resources.arsc and the compiled java classes for reference at the time
of the development.

To prepare this jar, use the apk generated my eclipse, rename it to xyz.jar. remove the .dex file
from the jar, remove all certificate information from META-INF folder and add the compiled java
classes of the component from the bin folder to the jar. Your jar is prepared now.

3. Android uses aapt tool to create initial apk file and R.java having mapping between
resource ids and resources. The initial apk file created by aapt tool contains the resources.arsc
and the needed resources in the res folder

In all this procedure, aapt tool is the one that we targeted. Since all the resource management is done
by aapt tool.

Aapt

Android has two classes for handling all resources information. “ResTable” and “ResourceTable”. The
“ResTable” class is used in android core libs to maintain all the resource table. It just reads the
“resources.arsc” file and loads the table into instance.

The ResourceTable class is used in aapt tool only to create the resources.arsc file. It just maintains the
unprocessed information about the resources. Aapt iterates through all the resources and keeps on
adding the resource information in ResourceTable. When it finishes with all the resources, it reorders
the resources in the table and then generates the ids and dumps the information in the resources.arsc
file.

There are few important files in aapt tool –

Resource.cpp

This file has the important function buildResources() which builds resource table from all the resources
of the application. This buildResources function has the following procedure to build the resources.

a. First include all the library resources. This is done though
ResourceTable::addIncludedResources() function. In this function it loads the resource tables
from the “resource.arsc” files in the provided libraries (jar files). Again to load table data from
“resources.arsc” files it uses ResTable class object. Android allows only one jar file (android.jar)
to be provided as base library. To load more than one jar as library, user should use ‘–x’
argument to specify that the libraries provided contain extended libraries. The only thing we
currently know about extended libraries is that, extended libraries mean the libraries other than
base library (android.jar). It loads only package information (package id and package name) in




the ResourceTable object. So that the used package ids in associated libraries should not get
generated again. For ID generation see-----------

b. It iterates through all the directories under provided resources directory and parses all the xml
files to add resource information into the resource table.

c. Then it assigns ids to all the resources included in the resource table.

ResourceTable.cpp

This file has the ResourceTable class implemented. The important functions in this file would be
addIncludedResources() and flatten() of the ResourceTable class.

addIncludedResources() function is used to add the packages information from the provided jars into
the ResourceTable’s orderedPackages vector.

Flatten() function is used to write the resources.arsc file from the resourceTable instance. This is also am
important function that would help to understand the structure of the resourceTable and resources.arsc
file.

ResourceTable data storage

In resource table, all the data is stored in tree like structure. It stores all the base ‘packages’ in
‘mOrderedPackages’ vector. Each package object contains a vector of ‘types’ named ‘mOrderedTypes’.
Each type object contains a vector of ‘ConfigLists’. Each ‘ConfigList’ object contains a vector of ‘Entries’.
Each entry stores the resource entry. So you can see, all the resources are noted down at the l eaf of the
table with entries object. All the objects in this hierarchy have one index associated with it except the
package which has its id generated at the start while including the base packages. When ‘getResId’ on
each of these resources is called, all the ids from top package to the leaf resource is mixed and the id is
generated.

ResTable data storage

In ResTable also all the data is stored in tree like structure but with a slight difference. On the top of the
tree is PackageGroup that stores the group of packages loaded in the table. One table here can hold any
number of packages. Each package contains its id and the package information. Package stores the
Types in the package. Package also stores the strings and keys data in string pool format. We don’t know
very much about this. Each key stores the configs and entries. But still we are unaware of how it stores
the entries of the resources and the ids of the resources.

Id Generation

The base library is identified by the package id of the “android” package which is always “1”. It starts
allocating package ids to new packages from 127. That means if the application not using any other




library than android.jar have its package id as 127 (0x7F). That’s why you will see almost all the R.java
generated for applications starts with package ids 0x7F. The ids for each resource is nothing but the
combination of the ids – PackageId, typeId, nameId from the ResourceTable.


Android Resource Manager

More Related Content

What's hot

Viewers also liked

Similar to Android Resource Manager

Recently uploaded

Android Resource Manager