The marked library(ies) were available to the APEXes via the hand-written whitelist in build/soong/apex/apex.go. Trying to remove the whitelist by adding apex_available property to the Android.bp of the libraries. Bug: 150999716 Test: m Change-Id: Id68e7417f98307cbadea251f9e8a96b0697d8bec
The library can be used to build binaries for translated architectures. Bug: http://b/77159578 Test: make Change-Id: I62667b465f4720ec91a74dc9b308ba6def34bdf5
Downloaded from https://www.7-zip.org/sdk.html. Test: builds Change-Id: Ibde10dfd8f5aca8e2e441524e9a703331a8c6d31
Libraries that are direct or indirect dependencies of modules installed to recovery partition (e.g. adbd) are marked as recovery_available: true. This allows a recovery variant of the lib is created when it is depended by other recovery or recovery_available modules. Bug: 79146551 Test: m -j Change-Id: I9595392f797875275afe0c4cdb441bd816e522f1
Downloaded from https://www.7-zip.org/a/lzma1805.7z Test: mma Change-Id: I95bf31512854191c040e94cc677794f9abc4c46a
Bug: 66996870 Test: build with WITH_TIDY=1 Change-Id: I9fa5d3d346b4f73f3878d15214ec022da5ad6162
As a VNDK/VNDK-SP module, Android.bp must have 'vndk' tag as well as 'vendor_available: true'. For a VNDK module, the 'vndk' tag has 'enabled: true'. It will be installed system/lib(64)/vndk as a vendor variant. For a VNDK-SP module, the 'vndk' tag has 'support_system_process: true' as well as 'enabled: true'. It will be installed system/lib(64)/vndk-sp as a vendor variant. Bug: 63866913 Test: build and boot with BOARD_VNDK_VERSION=current Merged-In: Ib7793f92de90512fcffcd123b57d726e71051897 Change-Id: Ib7793f92de90512fcffcd123b57d726e71051897 (cherry picked from commit d89bc9355d50461c895a884ac102a5d3da975ed7)
This was downloaded from http://www.7-zip.org/a/lzma1604.7z
The bin folder was excluded like in previous updates
All files were deleted and replaced with those from the SDK.
The embedded projects Tukaani, xz-embedded and android build
files where not touched.
The changelog since the 9.38 beta is:
16.04 2016-10-04
-------------------------
- The bug was fixed in DllSecur.c.
16.03 2016-09-28
-------------------------
- SFX modules now use some protection against DLL preloading attack.
- Some bugs in 7z code were fixed.
16.02 2016-05-21
-------------------------
- The BUG in 16.00 - 16.01 was fixed:
Split Handler (SplitHandler.cpp) returned incorrect
total size value (kpidSize) for split archives.
16.01 2016-05-19
-------------------------
- Some internal changes to reduce the number of compiler warnings.
16.00 2016-05-10
-------------------------
- Some bugs were fixed.
15.12 2015-11-19
-------------------------
- The BUG in C version of 7z decoder was fixed:
7zDec.c : SzDecodeLzma2()
7z decoder could mistakenly report about decoding error for some 7z
archives
that use LZMA2 compression method.
The probability to get that mistaken decoding error report was about
one error per 16384 solid blocks for solid blocks larger than 16 KB
(compressed size).
- The BUG (in 9.26-15.11) in C version of 7z decoder was fixed:
7zArcIn.c : SzReadHeader2()
7z decoder worked incorrectly for 7z archives that contain
empty solid blocks, that can be placed to 7z archive, if some file is
unavailable for reading during archive creation.
15.09 beta 2015-10-16
-------------------------
- The BUG in LZMA / LZMA2 encoding code was fixed.
The BUG in LzFind.c::MatchFinder_ReadBlock() function.
If input data size is larger than (4 GiB - dictionary_size),
the following code worked incorrectly:
- LZMA : LzmaEnc_MemEncode(), LzmaEncode() : LZMA encoding functions
for compressing from memory to memory.
That BUG is not related to LZMA encoder version that works via
streams.
- LZMA2 : multi-threaded version of LZMA2 encoder worked incorrectly,
if
default value of chunk size (CLzma2EncProps::blockSize) is changed
to value larger than (4 GiB - dictionary_size).
Change-Id: I6b3974015c605fba3c0d4d897fab5a166174f441
By setting vendor_available, the following may become true: * a prebuilt library from this release may be used at runtime by in a later releasse (by vendor code compiled against this release). so this library shouldn't depend on runtime state that may change in the future. * this library may be loaded twice into a single process (potentially an old version and a newer version). The symbols will be isolated using linker namespaces, but this may break assumptions about 1 library in 1 process (your singletons will run twice). Background: This means that these modules may be built and installed twice -- once for the system partition and once for the vendor partition. The system version will build just like today, and will be used by the framework components on /system. The vendor version will build against a reduced set of exports and libraries -- similar to, but separate from, the NDK. This means that all your dependencies must also mark vendor_available. At runtime, /system binaries will load libraries from /system/lib*, while /vendor binaries will load libraries from /vendor/lib*. There are some exceptions in both directions -- bionic(libc,etc) and liblog are always loaded from /system. And SP-HALs (OpenGL, etc) may load /vendor code into /system processes, but the dependencies of those libraries will load from /vendor until it reaches a library that's always on /system. In the SP-HAL case, if both framework and vendor libraries depend on a library of the same name, both versions will be loaded, but they will be isolated from each other. It's possible to compile differently -- reducing your source files, exporting different include directories, etc. For details see: https://android-review.googlesource.com/368372 None of this is enabled unless the device opts into the system/vendor split with BOARD_VNDK_VERSION := current. Bug: 36426473 Bug: 36079834 Test: Android-aosp_arm.mk is the same before/after Test: build.ninja is the same before/after Test: build-aosp_arm.ninja is the same before/after Test: attempt to compile with BOARD_VNDK_VERSION := current Change-Id: I7625075aea9c5c8b1ffdc8794776df624365263a