This whitelist controls which partitions support installing an app's
libraries in the partition's lib folder as opposed to embedding
them in the APK itself. Update it to also include /product and
/product_services.
Also add some clarifying comments.
Bug: 111797707
Test: in internal branch
Change-Id: I756af46cc9b718ca669dacc9d25364edddb295f4
Vendor apk can now access /vendor/lib. So there is no need for us to
embed the vendor libs into vendor apks. Reverting the old commits.
Revert "Embedding the JNI lib is controlled by PRODUCT_FULL_TREBLE"
This reverts commit a6b038ff4c.
Revert "Embed jni libs in vendor apks for treble-ized devices"
This reverts commit 1cb8dea625.
Bug: 69272876
Test: m -j ModemDiagnosticSystem (a vendor apk having JNI libs in walleye)
unzip -l /vendor/app/ModemDiagnosticSystem/ModemDiagnosticSystem.apk does not
have libmdsdiag.so in it. The so file is found in /vendor/lib64.
Change-Id: I7b96aa56b39bc45aca4810e6fb3f41ce2a1fc095
- Prebuilts with LOCAL_MODULE_CLASS == APPS and BUILD_PACKAGE that
define LOCAL_COMPRESSED_MODULE := true will be installed compressed
in the system partition.
- The compression algorithm is simple gzip for now.
In addition :
- Compressed modules are not dex-preopted.
- JNI shared libraries are always embedded inside compressed modules,
they are never installed as separate files on the FS.
Test: Manual
Bug: 63802184
Change-Id: Id12b1ff0b1d68791ec1178783f7e78910e122a33
JNI libs used by bundled APKs have been installed outside of the APK
(e.g. /system/lib and /vendor/lib) to save space because multiple APKs
may share the same set of JNI libs.
However, this causes problem for treble-ized devices where access to
/vendor/lib is prohibited for system processes including Java apps.
So, the JNI libs are embedded into the APK when the APK is installed to
/vendor partition and the device is fully treble-ized.
Bug: 37491282
Test: Move an APK and its JNI libraries to vendor partition by setting
LOCAL_PROPRIETARY_MODULE := true and build:
The jni lib does not exist under /system or /vendor. unzipping
the apk reveals the jni lib under ./lib/<abi> directory.
Change-Id: I8389761dfbd28d181869d79f0bf988a1e4df2fca
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Ic3666dc72bf17cd293787414dd185470b365f967
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Icf07e0998ac3602e6e05e80fed836fbafca33e01
Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in
multilib build.
The build system will package jni of both archs to the apk, or install
them to the right location on the system image and create symlinks,
extract .so files from prebuilt apk, etc if appropriate.
Bug: 15849902
Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
We already support pure 32-bit and 64-bit-by-default multilib build.
With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build.
This will be lest disruptive during the period we transition to
64-bit-by-default.
Bug: 13751317
Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
Use LOCAL_PREBUILT_JNI_LIBS to install prebuilt JNI libraries extracted
from the prebuilt apk, or prebuilts as source, to the app specific lib path.
LOCAL_PREBUILT_JNI_LIBS accepts 2 kinds of files:
- Files like @path/to/libfoo.so (path inside the apk) are JNI libs
extracted from the prebuilt apk. In this case, all embedded JNI libs
inside the prebuilt apk are stripped.
- Files like path/to/libfoo.so (path relative to LOCAL_PATH) are
prebuilts in the source tree.
Those prebuilt JNI libs are not defined as modules in the build system,
so this works around possible module name conflict.
Bug: 13170859
Change-Id: I91bb844cc11b3621a85733bc7e8910f168957ef0
Previously we have to use LOCAL_REQUIRED_MODULES to install jni
libraries for an apk in bundled build.
With this change, we'll use LOCAL_JNI_SHARED_LIBRARIES alone to
install jni shared libraries.
The new rules are:
- If we are doing unbundled build, or the apk isn't going to be
installed to system partitions, we'll embed the jni libs in the
built apk.
- Otherwise, the jni libraries will be installed to the system
lib path, and symlinks created in the app specific lib path.
Change-Id: Id6bd5301eb632bda3593664acee580f0d8b1d5d4
