Home | History | Annotate | Download | only in docs

Lines Matching full:dex

48     <li>Multiple classes are aggregated into a single "DEX" file.
49 <li>DEX files are mapped read-only and shared between processes.
67 archives with some meta-data files added. The Dalvik DEX data file
68 is always called <code>classes.dex</code>.
73 storing <code>classes.dex</code> without compression and padding out the zip
77 We need to extract <code>classes.dex</code> from the zip archive before
86 There are at least three different ways to create a "prepared" DEX file,
87 sometimes known as "ODEX" (for Optimized DEX):
97 / <code>apk</code> files are present, but the <code>classes.dex</code>
98 is stripped out. The optimized DEX is stored next to the original
105 names derived from the full path of the source DEX. On the device the
107 and has 0771 permissions, and the optimized DEX files stored there are
111 The bottom line is that you can read your own DEX file and those of most
114 Preparation of the DEX file for the "just in time" and "system installer"
121 Second, the <code>classes.dex</code> entry is extracted from the the zip
127 but no meaningful changes to the DEX file. We also do some basic
132 emulator, forcing just-in-time optimization of all relevant DEX files,
146 We want to verify and optimize all of the classes in the DEX file. The
156 initialization, loads zero or more DEX files from the bootstrap class
158 the target DEX. On completion, the process exits, freeing all resources.
160 It is possible for multiple VMs to want the same DEX file at the same
168 in every method in every class in a DEX file. The goal is to identify
230 when the DEX file is loaded, we can compute it now, saving heap
231 space and computation time in every VM where the DEX is loaded.
249 DEX, and that other DEX is updated, we need to ensure that our optimized
260 The optimized DEX file includes a list of dependencies on other DEX files,
262 <code>classes.dex</code> zip file entry. The dependency list includes the
267 An optimized DEX is dependent upon all of the DEX files in the bootstrap
268 class path. DEX files that are part of the bootstrap class path depend
269 upon the DEX files that appeared earlier. To ensure that nothing outside
270 the dependent DEX files is available, <code>dexopt</code> only loads the
271 bootstrap classes. References to classes in other DEX files fail, which
275 This means that splitting code out into many separate DEX files has a
277 non-boot DEX files can't be optimized. Because verification is pass/fail
279 classes in external DEX files can be optimized. This may be a bit
283 Another negative consequence: any change to a bootstrap DEX will result
284 in rejection of all optimized DEX files. This makes it hard to keep
287 Despite our caution, there is still a possibility that a class in a DEX
290 class in the DEX file being processed has the same name as a class in the
291 bootstrap DEX files, the class will be flagged as ambiguous and references
297 re-optimize the DEX file. If we can do a just-in-time <code>dexopt</code>
299 the DEX was shipped only in ODEX, then the VM has to reject the DEX.
309 <h2>Generated DEX</h2>
318 DEX files; may allow Java bytecode or Dalvik bytecode in instructions;