I am going to tell you a story. It's a bit of a complicated story so sit down and get a comfy chair.

TL;DR
When building the unit_tests_apk with {is_official_build=true, is_component_build=false}, the final apk ends up with two .so(s) libchrome.so and lib_unit_tests__library.so. libchrome.so is not needed an shouldn't be there. It's presence is not only unnecessary but harmful. 
Because we LoadLibrary() both, we end up in a weird situation where, depending on the scenario, we can hit code from both .so(s) **within the same call-stack**. libchrome.so is there because of a build-time only dependency required for the resource_whitelist generation and accidentally ends up in the apk causing problems.

Chapter 1: follow the white rabbit in the ODR violation hole
------------------------------------------------------------
Everything started with Issue 739510. bauerb@ got a minified repro case that was creating a call stack like this:
test_runner::main() -> [A] C++ function ->  [B] call into a Java function via JNI -> [C] call into another C++ function via JNI.
bauerb@ got into an absurd situation where the state of global variables in [A] was different from the ones in [C]. Looked like globals were re-initialized in [C].
After a long debugging session we figured out that even if the functions in [A] and [C] were defined in the same translation unit, their addresses were strongly different. Specifically they were being pulled from two different .so(s). So the actual call stack looked like this:

test_runner::main() [lib_unit_tests__library.so]
A_CppFunc()         [lib_unit_tests__library.so]
B_javaFunction()    [Some classes.dex]
C_AnotherCppFunc()  [libchrome.so]

Not only the addresses of these functions were different but, because of position-independent-code, also the addresses of their globals. So effectively [C] would see an entirely new world where everything is fresh and clean. But then imagine things like TLS pointers, which instead get initialized early and stashed in a register, which still refer to the old [A] world. At this point you can imagine the surprise, the shock, the sense of outrage, the indignation and the grief coming from those printf("%p %p %p\n", ...) statements.

(Also, because of reasons I'll tell you later, this happens only in official builds. The days of those leaving on the is_official_build=false planet are joyful, trouble-less and ODR-compliant)

The main reason for this odd situation is:
- the presence of the two .so() in the apk
- the fact that we System.LoadLibrary() both.

Chapter 2: Deciding which .so to load, how hard can it be?
----------------------------------------------------------
Why do we load both? In some cases (the all CrazyLinker story makes this a bit more complicated, but let's skip this part) they are loaded according to the list defined in //base/android/java/templates/NativeLibraries.template.

That content of that template is written by //build/android/gyp/write_ordered_libraries.py (yes it says "gyp", but that's just a legacy name, let's also skip this).

That script is ran by build/config/android/rules.gni, which in turn uses GN's magic write_runtime_deps = ... [1] to ask the build-system to expose the runtime-dependencies for a target into a file.

So essentially GN, at build time, writes the runtime dependencies of the target to a file which is consumed by write_ordered_libraries.py which produces a .json file, which is fed back to another GN action that uses jinja to expand the NativeLibraries.template into a NativeLibraries.java which then becomes part of the build, which then contains an array of ["filename.so"] which then is iterated at runtime calling System.LoadLibrary(). It's just that easy!


Chapter 3: What is "deps", baby don't hurt me, don't hurt me, no more. 
----------------------------------------------------------------------
The action target itself is a template (generate_resource_whitelist) [2] which in turn is used by targets like //chrome:resource_whitelist [3].
I am not too familiar with resource_whitelist, but this seems to be a host tool that scans a .so (well some extra artifacts produced by the compiler_wrapper, really) and extracts a whitelist of various IDS_ resources (translations strings and that stuff) referenced by the various translation units.

Hold on, how do we get from unit_tests to this point? Here's the dependency chain:
$ gn path out/droid //chrome/test:unit_tests  //chrome/android:chrome
//chrome/test:unit_tests --[private]-->
//chrome:packed_resources --[private]-->
//chrome:resource_whitelist --[private]-->
//chrome/android:chrome

Essentially the unit_tests target, other than depending on the lib_unit_tests__library.so itself (this is right and expected), depends on the packed_resources. This is also expected, as there is nothing bad about the test depending on our .pak files.
But in official_builds (which makes enable_resource_whitelist_generation=true), packed_resources depends on the resource_whitelist target.
This is also fine, I guess we want to get coverage for that whitelist.
In turn resource_whitelist depends on libchrome.so. Also this seems legit. We want to whitelist the resources used by the main executable, not by the test.

But now we ended up with two .so(s) in the same apk: lib_unit_tests__library.so. libchrome.so. These .so re-define a lot of the same symbols. They both have their own copy of v8, content, etc. This leads to the weird situation above (let's not get into symbol-resolution rules for JNI->C++ calls)


Chapter 4: run-time vs build-time deps, where's the line?
---------------------------------------------------------
So, where is the problem then? Let's merge the two discussions above.

resource_whitelist needs to "depend" on libchrome.so only at build-time in order to generate the resource whitelist.
the test apk needs to "depend" on lib_unit_tests__library.so on build-time AND run-time because, well, that contains the code of the test.

This is the part where I start getting lost. GN seems to have different notions of deps and I think we are mixing them.
I think that what we want to say here is:
the test apk depends:
  - At build time: on both libchrome.so and lib_unit_tests__library.so
  - At run-time (which in turn generates the .so list that end up in the apk): on lib_unit_tests__library.so only

I don't know what is wrong link of the chain here. I think that the issue starts when chrome:resource_whitelist declares a 
generate_resource_whitelist("resource_whitelist") {
    deps = [ "//chrome/android:chrome" ]
...
}

At this point libchrome.so becomes a runtime_dep for the test apk, which in turn causes the write_ordered_libraries to include it.
I have no idea how to express the fact that chrome:packed_resources depends at build-time only on //chrome/android:chrome.
The other GN deps I found, data_deps, seem more oriented at the opposite scenario (run-time only dependency).

This is where our story ends for today...


[1] https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/reference.md#write_runtime_deps
[2] tools/resources/generate_resource_whitelist.gni 
[3] https://cs.chromium.org/chromium/src/chrome/BUILD.gn?type=cs&q=chrome+%5C%22resource_whitelist&sq=package:chromium&l=1777