1# libnativehelper MTS tests
2
3These tests cover the API surface of libnativehelper that is applicable once
4the runtime is initialized.
5
6These tests do not cover the API surface relating to the binding of the ART
7runtime (DalvikVM), that preclude the initialization of the runtime, nor do
8they cover JNI_CreateJavaVM(). These APIs have been invoked before the test
9harness runs these tests.
10
11API surface not directly covered here are:
12
13```
14    JNI_GetCreatedJavaVMs
15
16    JniInvocationCreate
17    JniInvocationDestroy
18    JniInvocationInit
19    JniInvocationGetLibrary
20
21    jniUninitializeConstants
22```
23
24`JniInvocationInit()` is responsible for binding the ART runtime and
25specifically the following methods:
26
27```
28    JNI_CreateJavaVM
29    JNI_GetCreatedJavaVMs
30    JNI_GetDefaultJavaVMInitArgs
31```
32
33These tests do check that `JNI_GetCreatedJavaVMs()` and
34`JNI_GetDefaultJavaVMInitArgs()` behave as expected and are thus asserted to
35be correctly bound. `JNI_CreateJavaVM()` cannot be called in these tests
36because Android only supports a single runtime per process.
37
38`JniInvocationInit()` uses `JniInvocationGetLibrary()` to determine which
39runtime to load (release, debug, or custom). The code responsible for that
40decision is tested comprehensively in `libnativehelper_gtests`.
41
42`jniUninitializeConstants` is only intended to be called when the runtime is
43shutting down and unloading the managed core libraries.
44
45## Potential Issues
46
47The test harness depends on libnativehelper_compat_libc++ and the tests
48depend on libnativehelper. The former library is a subset of libnativehelper.
49There are potential ODR problems if the two libraries having overlapping
50global state. It would be better to have two separate test suites for these
51two libraries.
52