This was causing the viewcompiler to crash on deeper layout hierarchies.
We fix this by reserving several scratch registers. When an invoke instruction
uses registers that don't fit in a 4-bit field, we move all of these values into
the scratch registers and use an invoke/range instruction instead. The scratch
registers are all above the highest allocated register, so they are guaranteed
not to clobber meaningful values.
Supporting more registers for invoke also required supporting
register-to-register moves, which some how we'd gotten by without so far.
Finally, to make viewcompiler fail more loudly when things go wrong, many
DCHECKs have been changed to CHECKs.
Bug: 123517491
Test: atest
Change-Id: I9eb7c9bcf1fc7d713e664b331804bdcddafc95a4
PrecompiledLayoutTest makes sure that layouts generated by the viewcompiler are
equivalent to inflating from the resource XML file. We'll want to run these
tests when making changes to the viewcompiler.
Bug: 111895153
Test: atest
Change-Id: Iffa6f0f01c3f43d43feaabd1a5cd36be76650975
libdexfile.so is moving to APEX and the external API doesn't include
the features needed for startop.
Bug: 119632407
Test: Builds
Change-Id: I6d33e8737341a508637321921ca732af913827a3
This is needed to be able to launch the viewcompiler from installd. We only
support FD-input mode when reading from APKs. For output to an FD, we rely on
stdout redirection.
Bug: 111895153
Change-Id: I3025d83c60494485bada5f2f4cd67e25354d1d53
We'll need this binary on device to be able to compile views at application
install time. There will be a followup CL to the build system to make sure
viewcompiler is built and installed by default.
Bug: 111895153
Change-Id: I2c98864118dfeca79e36be760bd44b9afa03b4d4
This moves some helper functions into our own namespace to avoid conflicting
with other util.h files.
Bug: 111895153
Change-Id: I2b4c77732a97b34a8528d69867c15ed802686703
TEST_MAPPING supports both host and device tests now, so we should run both.
Test: atest
Bug: 111895153
Change-Id: I48f26093fc0ae3cdaa9e5295375945b5a519e1c2
* Add explicit to conversion constructors/operators
Bug: 28341362
Test: make with WITH_TIDY=1 DEFAULT_GLOBAL_TIDY_CHECKS=-*,google-explicit-constructor
Change-Id: I9e7b929cfa65c68f4cdb4710c1c5c6760d56e4d5
Layout validation walks over a layout resource and verifies that the layout only
uses features the layout compiler supports.
Currently this means we reject layouts that use any of the following tags:
* include
* fragment
* merge
* view
In the future, we will extend the layout compiler to handle these, but for now
we want to be liberal in what we reject.
Bug: 111895153
Test: atest view-compiler-tests
Change-Id: I8dca30c035a83b6763497a36fc60c68438fa1b0c
This CL adds the ability to generate code that calls static and virtual methods
which return objects, as well as the not-equal-to-zero comparison operator.
Bug: 111895153
Change-Id: I4ae9b3cb2edc6540671112b73c02bf6380d23051
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
