tools/layoutlib/create/README.txt

   1 # Copyright (C) 2008 The Android Open Source Project
   2
   3
   4 - Description -
   5 ---------------
   6
   7 Layoutlib_create generates a JAR library used by the Eclipse graphical layout editor
   8 to perform layout.
   9
  10
  11 - Usage -
  12 ---------
  13
  14  ./layoutlib_create path/to/android.jar destination.jar
  15
  16
  17 - Design Overview -
  18 -------------------
  19
  20 Layoutlib_create uses the "android.jar" containing all the Java code used by Android
  21 as generated by the Android build, right before the classes are converted to a DEX format.
  22
  23 The Android JAR can't be used directly in Eclipse:
  24 - it contains references to native code (which we want to avoid in Eclipse),
  25 - some classes need to be overridden, for example all the drawing code that is
  26   replaced by Java 2D calls in Eclipse.
  27 - some of the classes that need to be changed are final and/or we need access
  28   to their private internal state.
  29
  30 Consequently this tool:
  31 - parses the input JAR,
  32 - modifies some of the classes directly using some bytecode manipulation,
  33 - filters some packages and removes some that we don't want to end in the output JAR,
  34 - injects some new classes,
  35 - and generates a modified JAR file that is suitable for the Android plugin
  36   for Eclipse to perform rendering.
  37
  38 The ASM library is used to do the bytecode modification using its visitor pattern API.
  39
  40 The layoutlib_create is *NOT* generic. There is no configuration file. Instead all the
  41 configuration is done in the main() method and the CreateInfo structure is expected to
  42 change with the Android platform as new classes are added, changed or removed.
  43
  44 The resulting JAR is used by layoutlib_bridge (a.k.a. "the bridge"), also part of the
  45 platform, that provides all the necessary missing implementation for rendering graphics
  46 in Eclipse.
  47
  48
  49
  50 - Implementation Notes -
  51 ------------------------
  52
  53 The tool works in two phases:
  54 - first analyze the input jar (AsmAnalyzer class)
  55 - then generate the output jar (AsmGenerator class),
  56
  57
  58 - Analyzer
  59 ----------
  60
  61 The goal of the analyzer is to create a graph of all the classes from the input JAR
  62 with their dependencies and then only keep the ones we want.
  63
  64 To do that, the analyzer is created with a list of base classes to keep -- everything
  65 that derives from these is kept. Currently the one such class is android.view.View:
  66 since we want to render layouts, anything that is sort of the view needs to be kept.
  67
  68 The analyzer is also given a list of class names to keep in the output.
  69 This is done using shell-like glob patterns that filter on the fully-qualified
  70 class names, for example "android.*.R**" ("*" does not matches dots whilst "**" does,
  71 and "." and "$" are interpreted as-is).
  72 In practice we almost but not quite request the inclusion of full packages.
  73
  74 With this information, the analyzer parses the input zip to find all the classes.
  75 All classes deriving from the requested bases classes are kept.
  76 All classes which name matched the glob pattern are kept.
  77 The analysis then finds all the dependencies of the classes that are to be kept
  78 using an ASM visitor on the class, the field types, the method types and annotations types.
  79 Classes that belong to the current JRE are excluded.
  80
  81 The output of the analyzer is a set of ASM ClassReader instances which are then
  82 fed to the generator.
  83
  84
  85 - Generator
  86 -----------
  87
  88 The generator is constructed from a CreateInfo struct that acts as a config file
  89 and lists:
  90 - the classes to inject in the output JAR -- these classes are directly implemented
  91   in layoutlib_create and will be used to interface with the renderer in Eclipse.
  92 - specific methods to override (see method stubs details below).
  93 - specific methods to remove based on their return type.
  94 - specific classes to rename.
  95
  96 Each of these are specific strategies we use to be able to modify the Android code
  97 to fit within the Eclipse renderer. These strategies are explained beow.
  98
  99 The core method of the generator is transform(): it takes an input ASM ClassReader
 100 and modifies it to produce a byte array suitable for the final JAR file.
 101
 102 The first step of the transformation is changing the name of the class in case
 103 we requested the class to be renamed. This uses the RenameClassAdapter to also rename
 104 all inner classes and references in methods and types. Note that other classes are
 105 not transformed and keep referencing the original name.
 106
 107 The TransformClassAdapter is then used to process the potentially renamed class.
 108 All protected or private classes are market as public.
 109 All classes are made non-final.
 110 Interfaces are left as-is.
 111
 112 If a method has a return type that must be erased, the whole method is skipped.
 113 Methods are also changed from protected/private to public.
 114 The code of the methods is then kept as-is, except for native methods which are
 115 replaced by a stub. Methods that are to be overridden are also replaced by a stub.
 116
 117 Finally fields are also visited and changed from protected/private to public.
 118
 119
 120 - Method stubs
 121 --------------
 122
 123 As indicated above, all native and overridden methods are replaced by a stub.
 124 We don't have the code to replace with in layoutlib_create.
 125 Instead the StubMethodAdapter replaces the code of the method by a call to
 126 OverrideMethod.invokeX(). When using the final JAR, the bridge can register
 127 listeners from these overridden method calls based on the method signatures.
 128
 129 The listeners are currently pretty basic: we only pass the signature of the
 130 method being called, its caller object and a flag indicating whether the
 131 method was native. We do not currently provide the parameters. The listener
 132 can however specify the return value of the overridden method.
 133
 134 An extension being worked on is to actually replace these listeners by
 135 direct calls to a delegate class, complete with parameters.
 136
 137
 138 - Strategies
 139 ------------
 140
 141 We currently have 4 strategies to deal with overriding the rendering code
 142 and make it run in Eclipse. Most of these strategies are implemented hand-in-hand
 143 by the bridge (which runs in Eclipse) and the generator.
 144
 145
 146 1- Class Injection
 147
 148 This is the easiest: we currently inject 4 classes, namely:
 149 - OverrideMethod and its associated MethodListener and MethodAdapter are used
 150   to intercept calls to some specific methods that are stubbed out and change
 151   their return value.
 152 - CreateInfo class, which configured the generator. Not used yet, but could
 153   in theory help us track what the generator changed.
 154
 155
 156 2- Overriding methods
 157
 158 As explained earlier, the creator doesn't have any replacement code for
 159 methods to override. Instead it removes the original code and replaces it
 160 by a call to a specific OveriddeMethod.invokeX(). The bridge then registers
 161 a listener on the method signature and can provide an implementation.
 162
 163
 164 3- Renaming classes
 165
 166 This simply changes the name of a class in its definition, as well as all its
 167 references in internal inner classes and methods.
 168 Calls from other classes are not modified -- they keep referencing the original
 169 class name. This allows the bridge to literally replace an implementation.
 170
 171 An example will make this easier: android.graphics.Paint is the main drawing
 172 class that we need to replace. To do so, the generator renames Paint to _original_Paint.
 173 Later the bridge provides its own replacement version of Paint which will be used
 174 by the rest of the Android stack. The replacement version of Paint can still use
 175 (either by inheritance or delegation) all the original non-native code of _original_Paint
 176 if it so desires.
 177
 178 Some of the Android classes are basically wrappers over native objects and since
 179 we don't have the native code in Eclipse, we need to provide a full alternate
 180 implementation. Sub-classing doesn't work as some native methods are static and
 181 we don't control object creation.
 182
 183 This won't rename/replace the inner static methods of a given class.
 184
 185
 186 4- Method erasure based on return type
 187
 188 This is mostly an implementation detail of the bridge: in the Paint class
 189 mentioned above, some inner static classes are used to pass around
 190 attributes (e.g. FontMetrics, or the Style enum) and all the original implementation
 191 is native.
 192
 193 In this case we have a strategy that tells the generator that anything returning, for
 194 example, the inner class Paint$Style in the Paint class should be discarded and the
 195 bridge will provide its own implementation.
 196
 197
 198 - References -
 199 --------------
 200
 201
 202 The JVM Specification 2nd edition:
 203   http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
 204
 205 Understanding bytecode:
 206   http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/
 207
 208 Bytecode opcode list:
 209   http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings
 210
 211 ASM user guide:
 212   http://download.forge.objectweb.org/asm/asm-guide.pdf
 213
 214
 215 --
 216 end