| bd3dba4346223593ac6033a3d2a7d8ec6f20738b |
|
16-Mar-2011 |
Jesse Wilson <jessewilson@google.com> |
Don't emit multiple copies of annotations when merging dex files.
This change requires all annotations to be loaded into memory
so they can be sorted. There does not appear to be a required
order to the annotations in .dex files. Loading annotations also
requires loading encoded values, which makes this into a large
refactoring.
Change-Id: Ib7e2656c595018be4e9936eb84a22f1c1de56750
http://b/4090053
|
| dfc5e8e159e7df3efa47d553b7725be22839665d |
|
14-Jan-2011 |
Jesse Wilson <jessewilson@google.com> |
Read Dex files from a byte[] rather than a RandomAccessFile.
This improves time to merge a trivial file with core.dex from
3.8 seconds to 0.8 seconds.
Also fixing read method names to be consistent with the spec.
Change-Id: I9033bcb497afe7a0d73e00cca14fa046b53a62bf
|
| 081c7142b29ccd6e1744b26e097b6a4d7c12f2bd |
|
04-Jan-2011 |
Jesse Wilson <jessewilson@google.com> |
New tool merge two dex files into one.
This code isn't yet ready for general use, but I have booted a device
using a core.jar from the product of a merge. In particular, I still
need to better size the output dex.
The motivation is to support incremental builds in dx. Given a
"--incremental" flag, dx would create a dex file containing only those
classes newer than the target .dex. Then it would merge that small
.dex with the current .dex. Hopefully this yields a nice speedup
over dexing everything.
It would also be possible to use this to do parallel builds. We would
manually partition the input files, dx them, and then merge the result
together.
Change-Id: I8997fb3c8bfe73b64ef38a7cb3d6456fbe799d0f
|