GitLab

When feature libraries for DFMs were introduced, the library name
matched the .so name (eg. libvr.so).  This made library loading
easier.  However, it necessitated placing these libraries into a build
subdirectory, so that Monochrome's libvr.so wouldn't collide with
Chrome's libvr.so (with the same applying to the test dummy module, and
any future DFMs).

Since then, we've learned that this puts a tax on other parts of the
system, such as stack decoding tools, when trying to locate such
libraries. Further, the module build framework has been improved to
package and load feature libraries automatically, which means the files
can have arbitrary names. This lets us move to a system where (using VR
as an example), we have libmonochrome.so and libmonochrome_vr.so created
in the conventional build output directory.

VR, for now, still has a factory that loads its own library. Normally,
this wouldn't be an issue, since loading a library twice results in a
no-op the second time. However, we've been warned that because the
soname ("vr") and the library file name don't match, that there could be
issues with Android actually loading the library twice.  This shouldn't
be a problem for VR, but if it is, we could temporarily blacklist VR
from being loaded by the module library, until it's native code is fully
in the VR DFM, and it's custom factory disappears.

Bug: 1015159
Change-Id: Icd20399756d1c4876df922d9c111cda0e67773d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1897910Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org>
Commit-Queue: Christopher Grant <cjgrant@chromium.org>
Cr-Commit-Position: refs/heads/master@{#712708}