Fix libartpalette MCTS tests to not link the runtime statically.

Since the test starts up a VM, it'll load the boot classpath and among
other things register various internal native methods, which aren't
stable APIs. That may lead to problems if libart is linked statically
since the boot classpath is loaded from device and could potentially be
more recent than the libart instance in the test (on devices that don't
take Mainline modules).

Hence avoid art_standalone_gtest_defaults and instead link
libnativehelper dynamically to start the VM using libart on the device.

Note that earlier work in https://r.android.com/2375894 and
https://r.android.com/2384058 got rid of the direct dependency on the
runtime in the test (i.e. the art::CommonRuntimeTest inheritance), but
we still brought in runtime init code that got executed from
JNI_CreateJavaVM.

This (again) disables the JNI test on host. It's possible to solve but
not worth the effort (see comment in palette_test.cc).

Test: `atest art_standalone_libartpalette_tests` with a planted
      libart-vs-BCP inconsistency based on b/402238495
Bug: 404306250
Change-Id: I99817670ba58272cb9ef7df7e216a3df637472d3

0 files changed, 0 insertions, 0 deletions