dalivk tools

dexlist -- list all concrete methods found in a DEX file

dexdump

dexdump: [-c] [-d] [-f] [-h] [-i] [-l layout] [-m] [-t tempfile] dexfile...

 -c : verify checksum and exit
 -d : disassemble code sections
 -f : display summary information from file header
 -h : display file header details
 -i : ignore checksum failures
 -l : output layout, either 'plain' or 'xml'
 -m : dump register maps (and nothing else)
 -t : temp file name (defaults to /sdcard/dex-temp-*)

/*
 * The "dexdump" tool is intended to mimic "objdump".  When possible, use
 * similar command-line arguments.
 *
 * TODO: rework the "plain" output format to be more regexp-friendly
 *
 * Differences between XML output and the "current.xml" file:
 * - classes in same package are not all grouped together; generally speaking
 *   nothing is sorted
 * - no "deprecated" on fields and methods
 * - no "value" on fields
 * - no parameter names
 * - no generic signatures on parameters, e.g. type="java.lang.Class<?>"
 * - class shows declared fields and methods; does not show inherited fields
 */

dexdeps -- DEX external dependency dump
This tool dumps a list of fields and methods that a DEX file uses but does
not define.  When combined with a list of public APIs, it can be used to
determine whether an APK is accessing fields and calling methods that it
shouldn't be.  It may also be useful in determining whether an application
requires a certain minimum API level to execute.

Basic usage:

  dexdeps [options] <file.{dex,apk,jar}>

For zip archives (including .jar and .apk), dexdeps will look for a
"classes.dex" entry.

Supported options are:

  --format={brief,xml}

    Specifies the output format.

    "brief" produces one line of output for each field and method.  Field
    and argument types are shown as descriptor strings.

    "xml" produces a larger output file, readable with an XML browser.  Types
    are shown in a more human-readable form (e.g. "[I" becomes "int[]").

java -jar dexdeps.jar package.apk

dexopt

/*
 * Command-line DEX optimization and verification entry point.
 *
 * There are three ways to launch this:
 * (1) From the VM.  This takes a dozen args, one of which is a file
 *     descriptor that acts as both input and output.  This allows us to
 *     remain ignorant of where the DEX data originally came from.
 * (2) From installd or another native application.  Pass in a file
 *     descriptor for a zip file, a file descriptor for the output, and
 *     a filename for debug messages.  Many assumptions are made about
 *     what's going on (verification + optimization are enabled, boot
 *     class path is in BOOTCLASSPATH, etc).
 * (3) On the host during a build for preoptimization. This behaves
 *     almost the same as (2), except it takes file names instead of
 *     file descriptors.
 *
 * There are some fragile aspects around bootclasspath entries, owing
 * largely to the VM's history of working on whenever it thought it needed
 * instead of strictly doing what it was told.  If optimizing bootclasspath
 * entries, always do them in the order in which they appear in the path.
 */
dex-preopt

[--build-dir=path/to/out] [--dexopt=path/to/dexopt]
  [--product-dir=path/to/product] [--boot-dir=name]
  [--boot-jars=list:of:names] [--bootstrap]
  [--verify=type] [--optimize=type] [--no-register-maps]
  [--uniprocessor] path/to/input.jar path/to/output.odex

#
# Usage: dex-preopt [options] path/to/input.jar path/to/output.odex
#
# This tool runs a host build of dalvikvm in order to preoptimize dex
# files that will be run on a device.
#
# The input may be any sort of jar file (including .apk files), as long
# as it contains a classes.dex file. Note that optimized versions of
# bootstrap classes must be created before this can be run on other files;
# use the "--bootstrap" option to do this.
#
# The "output.odex" file must not already exist.
#
# This is expected to be running in a user build environment, where
# "dexopt" is available on the host.
#
# Options:
#   --build-dir=path/to/out -- Specify where the base of the build tree is.
#     This is typically a directory named "out". If not specified, it is
#     assumed to be the current directory. The specified input and output
#     paths are taken to be relative to this directory.
#   --dexopt=path/to/dexopt -- Specify the path to the dexopt executable.
#     If unspecified, there must be a unique subdirectory of the build-dir
#     that looks like host/ARCH/bin which must contain dexopt.
#   --product-dir=path/to/product -- Specify the path, relative to the build
#     directory, where the product tree to be used is. This directory should
#     contain the boot classpath jar files. If not specified, then there
#     must be a unique directory in the build named "target/product/NAME",
#     and this is the directory that will be used.
#   --boot-dir=path/to/bootclasspath -- Specify the path, relative to the
#     product directory, of the directory where the boot classpath files
#     reside. If not specified, this defaults to "system/framework"
#   --boot-jars=list:of:jar:base:names -- Specify the list of base names
#     of bootstrap classpath elements, colon-separated. Order is significant
#     and must match the BOOTCLASSPATH that is eventually specified at
#     runtime on the device. This defaults to "core". However, this really
#     needs to match the target product's BOOTCLASSPATH, which, as of this
#     writing, doesn't have a super-strict way of being defined within the
#     build. You can find variations of it in different init.rc files under
#     system/core/rootdir or under product-specific directories.
#   --bootstrap -- Process the bootstrap classes. If this is specified,
#     then, instead of processing a specified input file, no other arguments
#     are taken, and what is processed is the entirety of the boot jar
#     list, in order.
#   --verify={none,remote,all} -- Specify what level of verification to
#     do. Defaults to "all".
#   --optimize={none,verified,all} -- Specify which classes to optimize.
#     Defaults to "verified".
#   --no-register-maps -- Indicate that the output should not contain
#     register maps. By default, register maps are created and included.
#   --uniprocessor -- Indicate that the output should target a uniprocessor.
#     By default, optimizations will be made that specifically target
#     SMP processors (which will merely be superfluous on uniprocessors).