Use the new VMCompilationPerformance profile when running the
compilation VM to speed up. To do so, VirtualMachine{App|Raw}Config
parcelables are extended and the vm tool was also extended to accept
"--task-profiles" flag.

Bug: 223790172
Test: adb shell /apex/com.android.compos/bin/composd_cmd test-compile
Change-Id: I4b24ea353b6f93316ecdfe1023b3b8d315d57cc8

The effect of this is that the VM started by compos_verify is smaller,
as well as only using 1 CPU. (It does very little, so this should be
fine.)

And that should reduce its impact on boot time.

Compilation: "--mem" "1024" "--cpus" "8"
Verification: "--mem" "1024" "--cpus" "8"

Bug: 220824234
Test: staged-apex-compile, reboot, check logs.
Change-Id: I1101965fb532abe7923ec133920d62f5eacfd108

This change makes it eaiser to expend the composd_cmd CLI to various
debugging options, starting with using staged APEX.

Bug: 220341414
Test: Stage an APEX. Run test-compile with and without --prefer-staged
      # See VS' debug log with corresponding APEX path
Change-Id: I155681bc74f716e75ababb439e6bf48f43e0ce67

Delete a load of no longer needed code.

We no longer support persisting keys in the host. CompOS no longer
accesses DICE directly (compos_key_helper handles that).

We retain the instance image files, but rename pending to current
(it's created before reboot with the staged APEXes and used after
reboot with the current APEXes, but there's no point renaming it).

Remove the attempt to start an existing instance when running
compilation - it is slow, and vanishingly unlikely to work.

Sadly this also deletes all the CompOS unit tests. (But there are some
new ones in compos_key_tests.)

Bug: 218494522
Test: Manual; atest ComposTestCase; atest CompOsSigningHostTest
Change-Id: I0175270341d5dcad614106432b7d2650229cf8a6

We'll now return an error if there is an actual error reading the
property, rather than treating it the same as the property not being
set.

Bug: 217728265
Test: mm
Change-Id: I81f22d9ed07443b094f9a64a0737f4d24a2afe15

Note that this doesn't change verify_key (so it always uses 1 vCPU)
because the system property is specific to compilation.

For unknown reason, odrefresh takes longer when running with multiple
vCPU in the VM. See b/216557997.

Bug: 197358423
Test: Run `composd_cmd test-compile` on oriole. See 8 cpu in /proc/cpuinfo
Change-Id: Ie1a0bd4db3f33fef20d186af1718064f7094725b

In early boot, if dalvik.vm.boot-dex2oat-threads is not specified,
dex2oat will run in #CPU threads.

Currently, we're still using one CPU in the VM if
dalvik.vm.boot-dex2oat-threads not specified. This change gives the VM
the same number of CPUs, which will allow dex2oat to leverage all CPUs.

Bug: 197358423
Test: Run `composd_cmd staged-apex-compile` on oriole
      # Before: ~90s
      # After:  ~60s
Test: enable adb, check /proc/cpuinfo
Change-Id: Ifb8908ab44eacf42960f6e4d9b12edca6370d594

Bug: 210998077
Test: atest ComposHostTestCases
Change-Id: I50bb4cb96e0eb4033c531d47f6620ba8ede78553

The properties on the host side are now used to configure the number of
vCPUs and their affinity to the host CPU for the compos VM. Then inside
the VM, the system property is set to the number of vCPU so that the
concurrency level of dex2oat inside the VM is controlled by the
host-side system property.

Bug : 197358423
Test: adb shell setprop dalvik.vm.boot-dex2oat-thread 2
adb shell setprop dalvik.vm.boot-dex2oat-cpu-set 0,1
adb shell /apex/com.android.compos/bin/composd_cmd
staged-apex-compile

Crosvm is run with --cpus 2 and --cpu-affinity 0,1
`top` shows that (host) CPU usage is over 100%

Change-Id: I4239a6e1656a9fb852fdd7db3e0ba716290ea5bc

Add a new VM config file to be used when we want staged APEXes.

Add an option to compos_key_cmd to use staged APEXes.

Modify compos_client to allow the VM config to be overridden, and use
it to select staged APEXes in start_pending_instance.

Bug: 205296305
Test: stage an APEX, run composd_cmd staged-apex-compile
Change-Id: I379416b9798856d41492b32f6c0042262123a43b

Add a new method to IIsolatedCompilationService which will eventually
run compilation over staged APEXes. Currently it doesn't, but it is
slightly more realistic than the test compile (which I'm leaving in
place since it's useful for testing) - we use the pending instance of
compos (so odsign will attempt to verify the keys) and we run
odrefresh --compile instead of --force-compile. For now the artifacts
are still written to the test-artifacts directory so odsign doesn't
see them.

Bug: 205296305
Test: composd_cmd staged-apex-compile
Change-Id: If4d449878e38a97aa0f1f1dbb71c9df9b86ca4d5

This is useful in case the tests fail, and during development.

While I was refactoring this I also arranged to not create a new
instance of VirtualizationService when we already have one to hand.

Bug: 186126194
Test: Presubmits
Test: Manual: Was able to get VM logs again
Change-Id: I1540979c9f80f8e32c31bd1b382d14576233117d

The motivation for this is mostly to allow us to run this on real
devices in teamfood without worrying that it will break things. It's
also preparation for extending composd to do more useful things as
well as running tests.

Modify ComposTestCase to always write to /test instead of
/dalvik-cache (both inside & outside the VM).

Improve the support for multiple instances in composd, rename the
force-compile method to make it clear it does test things, and make
sure it uses a test instance of composd (so odsign will ignore it).

Modify composd_cmd to take a parameter telling it what to do.

Plus some gratuitous tweaks / reformats.

Bug: 186126194
Bug: 200020887
Test: atest ComposTestCase
Test: adb shell apex/com.android.compos/bin/composd_cmd forced-compile-test
Change-Id: I7899fe6393b556e04d9e7f8a07671d96e72bb018

It seems to be complex enough to merit its own file and not have
everything effectively public.

I renamed it to InstanceStarter, since what it does is start an
instance (possibly creating/re-creating it first). And did a little
related renaming.

This is intended as a pure refactoring; no functionality changes.

Bug: 186126194
Test: adb shell apex/com.android.compos/bin/composd_cmd
Change-Id: Ib42e1c23594d436b845c28bcfe38803e119d1106

At startup we validate the files needed for the current instance exist
and are valid; if anything goes wrong we re-create them.

Bug: 186126194
Test: Manual, via composd_cmd.
Change-Id: Iaf19a74df14a91436c4cb4435f0286fa09307db8

composd now keeps track of the running instance of the CompOS VM and
will proxy compilation requests to it. (I was going to return an
ICompOsService, but mixing RPC and normal binder isn't allowed.) This
avoids giving odrefresh any access to vsock_socket at all.

pvm_exec now connects to composd rather than directly to the VM if a
magic CID value is specified. (It also logs errors more volubly, which
was helpful.)

Modify pvm_exec

Bug: 186126194
Test: Run composd_cmd, artifacts generated
Change-Id: If80cf53287bd1bac9c97c992da7e121b1a64aaaa