Support LOCAL_MODULE_RELATIVE_PATH
Most users of LOCAL_MODULE_PATH are setting a subdirectory of the
normal install path, for example to install HALs into system/lib/hw.
This is problematic for multiarch builds, where the install location
depends on the arch. Allow modules to specify LOCAL_MODULE_RELATIVE_PATH.
HALs will generally use:
LOCAL_MODULE_RELATIVE_PATH := hw
Change-Id: I4e4ceec61d026bbe74ba604554c06104bde42e5e
diff --git a/core/build-system.html b/core/build-system.html
index 397eef4..182580c 100644
--- a/core/build-system.html
+++ b/core/build-system.html
@@ -383,7 +383,7 @@
if you need them again later.</p>
<p>By default, on the target these are built into /system/bin, and on the
host, they're built into <combo>/host/bin. These can be overridden by setting
-<code>LOCAL_MODULE_PATH</code>. See
+<code>LOCAL_MODULE_PATH</code> or <code>LOCAL_MODULE_RELATIVE_PATH</code>. See
<a href="#moving-targets">Putting targets elsewhere</a>
for more.</p>
@@ -533,16 +533,27 @@
<h3><a name="moving-modules"/>Putting modules elsewhere</h3>
<p>If you have modules that normally go somewhere, and you need to have them
-build somewhere else, read this. One use of this is putting files on
-the root filesystem instead of where they normally go in /system. Add these
-lines to your Android.mk:</p>
+build somewhere else, read this.</p>
+<p>If you have modules that need to go in a subdirectory of their normal
+location, for example HAL modules that need to go in /system/lib/hw or
+/vendor/lib/hw, set LOCAL_MODULE_RELATIVE_PATH in your Android.mk, for
+example:</p>
+<pre>
+LOCAL_MODULE_RELATIVE_PATH := hw
+</pre>
+<p>If you have modules that need to go in an entirely different location, for
+example the root filesystem instead of in /system, add these lines to your
+Android.mk:</p>
<pre>
LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT_SBIN)
LOCAL_UNSTRIPPED_PATH := $(TARGET_ROOT_OUT_SBIN_UNSTRIPPED)
</pre>
-<p>For executables and libraries, you need to also specify a
-<code>LOCAL_UNSTRIPPED_PATH</code> location, because on target builds, we keep
-the unstripped executables so GDB can find the symbols.</code>
+<p>For executables and libraries, you need to specify a
+<code>LOCAL_UNSTRIPPED_PATH</code> location if you specified a
+<code>LOCAL_MODULE_PATH</code>, because on target builds, we keep
+the unstripped executables so GDB can find the symbols.
+<code>LOCAL_UNSTRIPPED_PATH</code> is not necessary if you only specified
+<code>LOCAL_MODULE_RELATIVE_PATH</code>.</p>
<p>Look in <code>config/envsetup.make</code> for all of the variables defining
places to build things.</p>
<p>FYI: If you're installing an executable to /sbin, you probably also want to
@@ -818,6 +829,13 @@
to.</p>
<p>See <a href="#moving-modules">Putting modules elsewhere</a> for more.</p>
+<h4>LOCAL_MODULE_RELATIVE_PATH</h4>
+<p>Instructs the build system to put the module in a subdirectory under the
+directory that is normal for its type. If you set this you do not need to
+set <code>LOCAL_UNSTRIPPED_PATH</code>, the unstripped binaries will also use
+the relative path.</p>
+<p>See <a href="#moving-modules">Putting modules elsewhere</a> for more.</p>
+
<h4>LOCAL_UNSTRIPPED_PATH</h4>
<p>Instructs the build system to put the unstripped version of the module
somewhere other than what's normal for its type. Usually, you override this