Lines Matching refs:to
7 Layoutlib_create generates a JAR library used by the Eclipse graphical layout editor to perform
14 ./layoutlib_create destination.jar path/to/android1.jar path/to/android2.jar
21 generated by the Android build, right before the classes are converted to a DEX format.
24 - they 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 replaced by Java 2D
27 - some of the classes that need to be changed are final and/or we need access to their private
35 - generates a modified JAR file that is suitable for the Android plugin for Eclipse to perform
38 The ASM library is used to do the bytecode modification using its visitor pattern API.
41 is done in the main() method and the CreateInfo structure is expected to change with the Android
61 The goal of the analyzer is to create a graph of all the classes from the input JAR with their
64 To do that, the analyzer is created with a list of base classes to keep -- everything that derives
65 from these is kept. Currently the one such class is android.view.View: since we want to render
66 layouts, anything that is sort of a view needs to be kept.
68 The analyzer is also given a list of class names to keep in the output. This is done using
73 The analyzer is also given a list of classes to exclude. A fake implementation of these classes is
76 With this information, the analyzer parses the input zip to find all the classes. All classes
78 are kept. The analysis then finds all the dependencies of the classes that are to be kept using an
80 belong to the current JRE are excluded.
82 The output of the analyzer is a set of ASM ClassReader instances which are then fed to the
90 - the classes to inject in the output JAR -- these classes are directly implemented in
91 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 for which to delegate calls.
94 - specific methods to remove based on their return type.
95 - specific classes to rename.
96 - specific classes to refactor.
98 Each of these are specific strategies we use to be able to modify the Android code to fit within the
102 to produce a byte array suitable for the final JAR file.
104 The first step of the transformation is to implement the method delegates.
106 The TransformClassAdapter is then used to process the potentially renamed class. All protected or
110 changed from protected/private to public. The code of the methods is then kept as-is, except for
111 native methods which are replaced by a stub. Methods that are to be overridden are also replaced by
114 Finally fields are also visited and changed from protected/private to public.
117 to be renamed. This uses the RenameClassAdapter to also rename all inner classes and references in
121 The class is then fed to RefactorClassAdapter which is like RenameClassAdapter but updates the
122 references in all classes. This is used to update the references of classes in the java package that
124 modified to update all references to these non-desktop classes. An alternate implementation of
128 class version (version of the JDK used to compile the class) to 50 (corresponding to Java 6), if the
131 valid StackMapTable. As a side benefit of this, we can continue to support Java 6 because Java 7 on
134 ReplaceMethodCallsAdapter replaces calls to certain methods. This is different from the
136 changes the calls to a method in each class instead of changing the implementation of the method.
140 The ClassAdapters are chained together to achieve the desired output. (Look at section 2.2.7
150 code to replace with in layoutlib_create. Instead the StubMethodAdapter replaces the code of the
151 method by a call to OverrideMethod.invokeX(). When using the final JAR, the bridge can register
164 We currently have 6 strategies to deal with overriding the rendering code and make it run in
172 - OverrideMethod and its associated MethodListener and MethodAdapter are used to intercept calls to
176 - AutoCloseable and Objects are part of Java 7. To enable us to still run on Java 6, new classes are
180 added to the Dalvik VM for performance reasons. An implementation that is very close to the
182 were in part of the java package, where we can't inject classes, all references to these have been
188 As explained earlier, the creator doesn't have any replacement code for methods to override. Instead
189 it removes the original code and replaces it by a call to a specific OveriddeMethod.invokeX(). The
200 original class name. This allows the bridge to literally replace an implementation.
202 An example will make this easier: android.graphics.Paint is the main drawing class that we need to
203 replace. To do so, the generator renames Paint to _original_Paint. Later the bridge provides its own
209 native code in Eclipse, we need to provide a full alternate implementation. Sub-classing doesn't
217 This is very similar to the Renaming classes except that it also updates the reference in all
218 classes. This is done for classes which are added to the Dalvik VM for performance reasons but are
225 inner static classes are used to pass around attributes (e.g. FontMetrics, or the Style enum) and
235 This strategy is used to override method implementations. Given a method SomeClass.MethodName(), 1
240 b- A brand new implementation of SomeClass.MethodName() which calls to a non-existing static method