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 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:
Mod Developers
We'll get to how to make the modification files for Smali soon...
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:
Code:
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...