This change corrals most of the bit shifting and ORing needed to encode Dex
instructions into EncodeXXX functions that follow the naming scheme at
https://source.android.com/devices/tech/dalvik/instruction-formats. Overall, it
makes the code easier to follow and probably even less error prone because we
only have to make the format right in one place.
Bug: 111895153
Change-Id: I902ec3c8bca6b5dc4ad900503af7aef58d4bbf5f
This change also includes support for calling methods with more that one
argument. In fact, we can go up to four.
Bug: 111895153
Change-Id: I49472171cefcf57cdfce2ac4d41646ed4df29074
This CL adds support for the if-eqz instruction. It should be easy to add
additional comparisons as needed.
This also introduces a new kind of Value called a Label. Labels may be created
any time and then must be bound to a location in code at some point. References
to labels are tracked, and when a label is bound all references are patched to
refer to the concrete address.
Bug: 111895153
Change-Id: I15424aec75425004f0f1f4bbc6e760bac3a6c7de
These tests verify that code produced by DexBuilder can be loaded and run on
device. It works by introducing a new tool, dex_testcase_generator, which writes
out a couple of DEX files with test cases. This tool runs as a build step. The
generated DEX are then copied over to the device where they are loaded and run
the on-device DexBuilderTest.
Bug: 111895153
Change-Id: I06f5edd0e3e2f4e9ec2d14a0db7d22b75b424119
The Dex builder can now generate calls to methods (although not in all forms
yet). To help do this, we add a new virtual Instruction and Value class. This is
needed to generate code with values that are not known until the entire method
has been generated. In particular, we can now refer to function parameters.
The test method now accepts a String and returns the the length of the string.
Bug: 111895153
Change-Id: I11d52b083ae51d8151fccb1a65e45d40ff05fd81
This is planned to ship on device, so by convention the view_compiler should not
be in a tools directory.
Change-Id: I0eb03812d77ec38edc3908725acb40bacb345ecd
This change begins work on DexBuilder, which will allow us to generate DEX files
directly from layouts. This version is rather limited, but we will expand its
functionality in future CLs. The DexBuilder in this CL can create a DEX file
from scratch, define classes, and define methods on those classes. Within
methods, it supports extremely simple instructions, such as storing a small
constant in a register and returning a value from a register. Additionally,
there are tests to make sure that at least at a structural level, the generated
DEX files are valid.
DexBuilder and its associated builder classes use functionality from
libartdexfile and the Dex Slicer tool to support the actual encoding of DEX
files.
Test: atest, also manually tested by loaded a generated DEX file in an Android
app and verifying its behavior.
Change-Id: Iaa01aa7e3a0c7e4d5f4fa8dbce1492499c93c222
Also add support for temporarily disabling selinux
while running the iorap binder integration tests.
Test: atest --test-mapping frameworks/base/startop/iorap
Bug: 72170747
Change-Id: I0a5a006e28d4e1775aea4087c1b4731ebd3898a4
Connects to the binder 'iorapd' service as a client
and tests round-trip callback functionality.
Also adds mockito-inline to the test build, allowing us to mock
any class/methods, even if it's static or final.
Note: selinux is currently not supported, need to use
$> adb shell setenforce 0
Prior to running any tests relying on binder connectivity.
Bug: 72170747
Test: atest libiorap-java-tests
Change-Id: Id5ba579845105e331d764838c357924810a64c6c
This is an initial step towards a tool for pre-compiling layout XML files. It
accepts an XML file and produces a Java language class called CompiledView with
a static method, inflate. Calling CompiledView.inflate should then return a view
object that is equivalent to calling LayoutInflater.inflate on the same
resource.
There are still several important limitations, but this works well enough to do
some experimentation. The limitations include:
* Currently only one layout can be compiled at a time.
* `merge` and `include` nodes are not supported.
* View compilation is a manual process that requires code changes in the
application.
* The tests in this CL do not yet exercise any interesting behavior.
Bug: 111895153
Change-Id: I3e6880b08c52087d24ae7486495bd7fa282f4ff7
Fix remote_pkill function to work on multiple pids,
this was breaking chrome (which has 3 pids).
Fix activity inference to the "$pkg/$activity"
pattern where previously it could accidentally parse
the wrong token.
Fix app launching to handle activities with '$' in
the name which adb shell treated as a variable.
Test: manual
Change-Id: Ifc9a72f1b9bb5e1416c7602f27f4614efd003849
Adds a new script which is used by app_startup_runner.py and
run_app_with_prefetch in order to force the compilation filter.
Example:
$> ./query_compiler_filter.py --package com.google.android.calculator
speed-profile unknown arm64
(For example compiling to speed is extremely slow, compiling to
speed-profile is just marginally slow.)
Matching the compiler filter with what we actually need to measure is
extremely important as the performance will vary greatly.
Change-Id: I78ae76504208a672a7d17bab5001d11ab796d9d4
Example: ./force_compiler_filter --package com.google.android.apps.maps --compiler-filter speed-profile
Run the app just slightly enough to fully start up, then force it to
dump the profile and recompile the application with dex2oat under the
speed-profile filter.
(Also supports any other compilation filter such as quicken, speed,
etc).
Subsequently, this command can be used to manually validate that the
compiler filter was indeed changed:
$ adb shell dumpsys package com.google.android.apps.maps | grep -A10 "Dexopt state"
Dexopt state:
[com.google.android.apps.maps]
path: /data/app/com.google.android.apps.maps-D7s8PLidqqEq7Jc7UH_a5A==/base.apk
arm64: [status=speed-profile] [reason=unknown]
Test: Manual (see above)
Change-Id: Iea6067f90dc287d1de651d1ab36df69d23b2e9c1
