Instrumenting Android and Java Applications as Easy as abc - Runtime Verification - page 374

the Jimple bodies are produced and before all other optimizations like dead
code elimination run. This allows us to exploit the transformations done in
the latter. If we needed a complete callgraph, we would use the whole-jimple-
transformation-pack wjtp instead.
In the remainder of this section, we will show how to programatically configure
and launch Soot, how to access the Jimple code of a method, and explain how
Jimple is structured.
5.1 Jimple: Java, But Simple
Jimple stands between full Java sourcecode on one side and Java/Dalvik byte-
code on the other side. While the first is impractically complex for static analysis
or program transformations, the latter is quite cumbersome to work with because
of its large number of (untyped) instructions. Jimple combines the advantages of
both sides: There is only a limited instruction set, data is stored in variables, and
statements are generally of a simple three-operand form. More complex state-
ments or expressions are broken up into simple single-operation pieces and a set
of intermediate variables. For instance, in Jimple a=b+c+2 would be transformed
to temp=b+c, a=temp+2 with a new intermediate variable temp .
Jimple contains two general concepts: locals which are local variables and units
which are statements. Every method body contains one chain of locals and one
ordered chain of units. Units are usually of some type derived from Stmt ,whichin
turn can contain references to expressions derived from Expr . Jimple generalizes
all Java constructs to units and locals. The Java this reference, for instance,
is assigned to a local at the beginning of an instance method. Afterwards, it
behaves just like an ordinary local variable. The same happens with method
parameters. These special assignments are called IdentityStatement s (c.f. lines
12 and 13 in Listing 1.9).
Assignments between locals, constants, and fields are done using AssignState-
ment s (c.f. line 23). Since Soot represents the AST as an object model in memory,
the left and right side of an assignment are references to the objects represent-
ing the expressions standing on either side. Programatically traversing Jimple
code thus simply means following chains of references. For instance, in line 16,
the right-hand side of the assignment is a typecast represented by a CastExpr
object.
To call methods, Jimple supports four different expressions, depending on the
type of the target method. The three most important ones are VirtualInvokeExpr
for a virtual dispatch invoke to an instance method (lines 15 and 18), StaticInvo-
keExpr for calling a static method (line 14), and InterfaceInvokeExpr for calling
a method of an object of which only its interface type is known (line 26). Any in-
voke expression can be part of standalone statement called InvokeStmt (lines 14,
22, and 30), but can also serve as the right side of an assignment (i.e. AssignStmt ,
e.g., in line 15) unless the return type is void .