[Nook Touch Android Development] Renate:
This is a new thread on the subject of modifying the system or

applications on the Nook. I'd like to see a separate thread on

modifying the kernel, but let's keep that off this.

The Basics

A bit of the system or an app is usually written in Java. Different

tools are used to compile and process it to the final product.

The Java Runtime Environment (JRE) is what allows you to run various tools and program on your host computer.

The Java Development Kit (JDK), version 6, update 33 contains the tools you need to work with Java

javac - the Java compiler

jarsigner - a tool for signing products

Android Software Development Kit (SDK), with downloads for Level 7 API.

Android Asset Packaging Tool (AAPT) - processes resources like images and layouts

Android Debug Bridge (ADB) - allows connection and debugging to your device

The final product is either an APK file or a JAR file, both of which

are basically ZIP files. Both of these contain a file called

classes.dex which contain the executable code. An APK file also

contains resources in a directory hierarchy. Some of these items,

like regular PNG graphics are exactly as you'd find them anywhere.

Other items, like "9 patch files" (9.png), are modified and others,

like XML files, are compressed. An APK file also contains a file

called AndroidManifest.xml that describes the product. Both APK

and JAR files can also contain signatures in the META-INF

directory.

Reverse Engineering

In the best of all worlds, you would have the original Java code that

the developers used to make the product. This is seldom available.

To work around this you need to backwards step the entire

process to get back to the original Java code. There is a problem,

the backwards process is not unambiguous. Yes, you can

backtrack to some Java code, that if compiled would work the

same as the original, but it would not look the same. Often the

intent of a piece of software is apparent from its layout. Also, you

will have none of the comments in the original code.

We can easily backtrack to an intermediate place between source

Java code and the final product. This is a place that does not really

exist in the original product generation process. We can take the

raw executable code out of a product and display it in a human

readable (and editable) form. "Smali" is the name of this

representation. It is analogous to assembly code. As stated, it

really does not exist as a language in the original compilation.

There is a software tool for taking apart a product and dissecting

it into the Smali code and the resources (if any). This tool also can

be used for compiling the Smali code back into the modified

product.

apktool, a tool for reverse engineering Android files

One of the main actions of the apktool is to take apart classes.dex

and generate a whole tree of files that end in the extension ".smali".

These files will have names like:

\NeatoApp\smali\com\bigcompany\neatoapp\MainView$23.smali

Modifying a Product

So, we can take a finished product, use apktool on it to take it apart

to pieces, modify some piece, then put it back together with

apktool. Modifying a resource like a graphic is easy, just modify

it (except 9.png, more later). Changing the wording of a popup

message is also easy. Changing the language of the interface

takes a bit more care to do it correctly. Modifying the Smali code

takes a bit of knowledge and done incorrectly can even brick your

device (repairable with a backup). If you have a chunk of Smali

code that someone modified for some reason, it's not too difficult

to open up your extracted Smali file, edit in the chunk, save it and

run apktool to put everything back together.

The Problem

We see this problem with kernels all the time, that some users want

a kernel with A, B, C and others want it with C, D, E. The number

of competing configuration gets out of hand. Moreover if you

come up with feature F, then you have to find a way to package

it up with A, B, C, for the first user and D, E for the second user.

A Solution

One possible solution is to let the user decide. You can distribute

options A-F independently and let the user install them themselves.

In principle, this means the user takes whatever version of

something they have on their device, apply a specific patch, then

reinstall it on their device. This would also open things up to

modifying different versions (for example Nook Touch vs. Nook

Glow) with the same mod.

mergesmali

mergesmali is a new tool for managing modifications to Smali

code. There is no particular magic behind it. It simply can replace

sections of Smali in a text file. It is agile enough to not rely on line

numbers or exact specifics of the Smali file. Here is a simple

example how you would use it to modify something:

adb pull /system/framework/android.policy.jar
apktool d android.policy.jar \Policy
mergesmali /v \Policy\smali\com\android\internal\policy\impl\LockScreen.smali landscapemod.smali
apktool b \Policy android.policy.jar
adb push android.policy.jar /system/framework

Mod Developers

We'll get to how to make the modification files for Smali soon...