assemble_cvd was updated to include a flag which would disable insecure
launcher options.
Bug: 182005319
Test: local boot on cuttlefish
Change-Id: I3aabd594bf742a7639d4f57a1276a2733545c03e
The test is to enture that the boot flow explained in
microdroid/README.md is not broken.
Bug: 181860941
Test: atest MicrodroidHostTestCases
Change-Id: Ic084ed2fe82f971092f28de776182e77ee360350
Vsock test depends on two process groups running simultanously:
VirtManager+CrosVM and vsock_server. This was orchestrated by a Java
test runner running on the PC. With all the recent changes to the test,
it is now possible to run the former from AndroidTest.xml (and
eventually that will be completely removed) and convert vsock_server to
a GTest binary installed and invoked directly by TradeFed.
A common GTest class VirtualizationTest is added for hosting individual
test cases and sharing common code. Vsock test is converted to a single
TEST_F instance.
The test target is now called VirtualizationTestCases (dropped Host).
Bug: 181615964
Test: atest VirtualizationTestCases
Change-Id: I5a64d25ecc8f278250cfc3b196b8910ca8b8af52
We want to have virtmanager (and its dependencies) inside the APEX so
that they can be updated.
Bug: 180297657
Test: com.android.virt
Change-Id: I79935c99f8884a3260fc19f797466b47b3dc6583
The init ramfs used by the test is now built using the soong module type
`android_filesystem`. This not only simplifies the build script, but
also verifies that the new build system construct correctly creates the
ramdisk image.
In addition, only the test data (kernel, initramfs, and the server) that
match with the target architecture are copied.
Bug: 178978059
Test: atest VirtualizationHostTestCases
Change-Id: Ibacc66fc5842f950c9ea16001e62bd44ed9b867c
kernel modules moved to a different location
Bug: 170677468
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: I361ad86fae3199d5394dde7b5f57399394385d3f
Add VsockTest host-side test that runs a vsock server in Android and
spawns a VM with a client that connects to it. The client sends a
message to the server. The host-side driver validates that the message
received by the server matches the message given to the client via
kernel command-line arguments.
Bug: 168589743
Test: atest VirtualizationHostTestCases
Change-Id: Id6d1f1c5ff10066a73606ee5b14387ba4474a3f8
Add base class VirtTestCase for host-side Java virtualization tests.
It provides common methods for pushing necessary files to the device and
spawning a VM using CrosVM.
Test: VirtualizationHostTestCases
Change-Id: Ieeb129b7af772f8ab70205819766c946ae70ed11
The guest VM ramdisk is a combination of "base ramdisk" (containing
the init process and test binaries/resources) and a "vendor ramdisk"
(containing kernel modules).
This CL adds build rules that concatenate the base and vendor ramdisks.
This can be done as a simple `cat x1 x2` because both LZ4 and CPIO
formats are concatenable.
One ramdisk per target architecture is generated because genrules cannot
be specialized using the 'arch' field.
Test: m virt_hostside_tests_initramfs-{arm64,x86_64}
Change-Id: I7f52226ea68b8bfb497e481538eb35267578c38f
The guest VM ramdisk is a combination of "base ramdisk" (containing the
init process and test binaries/resources) and a "vendor ramdisk"
(containing kernel modules).
This CL adds build rules that build the base ramdisk, an LZ4-compressed
CPIO archive built using a genrule. Sources are specified as target
modules and paths within the CPIO archive are provided in the same order.
A Bash script parses the information and places all files into a common
directory before calling `mkbootfs` on that directory and compressing
the result.
Test: m virt_hostside_tests_initramfs_base
Change-Id: Id9b4f0c87c97c7167572d4196497676c6d9469ad
Guest VMs need an init process to be invoked by the GKI kernel. This
process needs to do two things:
1) load vendor kernel modules
For example, GKI does not come with vsock-virtio built in. The ramdisk
will contain vsock-virtio as a kernel module and it is the init's job to
load it.
2) execute a test binary
The init process is given parameters from the kernel command line
(/proc/cmdline). We will use these parameters to invoke a test binary
packaged in the ramdisk, eg. /bin/vsock_server. When init is done with
everything else, it calls execve() to run the specified binary and
passes remaining arguments to it.
This CL adds an init process as a static C++ binary. C++ was chosen
because of dependency on libmodprobe for loading kernel modules.
Test: m virt_hostside_tests_guest_init
(may not work until later in the series due to path depth limits)
Change-Id: I7b461504850174c435b0e4d666117b97836dff4f
Andrew Walbran
Jiyong Park
Ram Muthiah
David Brazdil
Bob Badour
Roman Kiryanov