We have known problems (docker; distros w/o user namespaces) which mean that we won't be turning this into a fatal error anytime soon. Also remove the bug report link, it's not useful to continue getting the same reports.
Change-Id: I271871d68150417ac938f074d3730cad4518e327
Test: treehugger
Adds the accessor function for retrieving the impl/header jars to the
librarySdkMemberType structure instead of passing it into its
buildSnapshot() method.
That enabled:
* The removal of the [header/impl]LibrarySdkMemberType structs.
* The removal of their implementations of BuildSnapshot.
* Replacing buildSnapshot() with BuildSnapshot()
This will make subsequent refactoring of the SdkMemberType interface
a little simpler.
Test: m nothing
Bug: 150451422
Change-Id: I1f96986bb497cf9d9df9916e40065f66b35a4704
Adds a CommonOS variant for sdk that depends on the os specific
variants and is used to generate a single sdk for multiple OsTypes,
e.g. host linux and android.
At the minute the member types only support a single OsType but the
basic mechanism for managing the CommonOS variant and collating the
variants across all of them is there.
The only visible effect of this change is that the location of the
generated snapshot is changed, it is no longer os specific and instead
is in the same location irrespective of which os it is built for.
A lot of tests needed to be changed to specify "common_os" as the
variant type instead of the specific os type. As that is the same across
all tests it is hard coded in CheckSnapshot method.
Test: m nothing
Bug: 150451422
Change-Id: If36be39b06d6910453649f7c288c2d34f688b2f4
When there is a runtime depedency (via runtime_libs property) to a
library providing stable C APIs, the dependency is considered as
crossing APEX boundary. Therefore, the requested lib doesn't need to be
made available to the APEX where the requesting lib is in.
Bug: 147813447
Test: m
Change-Id: I9cf8a5877850fb85b92c851e15fac921b8b7641b
If an APEX contains APKs and the manifest package name of the APKs are
overridden (either via override_android_app
orPRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES), that the path to the APK
(relative in the APEX) and the overridden manifest package name is
recorded in the bundle config file.
Bug: 148002117
Test: m
Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
bundle config file for apexes are auto-generated. It is included in the
<apex>-base.zip file, which is expected to be extracted and then fed
into the bundletool.
This change is in preparation for the upcoming change to include
information about embedded apks in the bundle confir file.
Bug: 148002117
Test: m
Change-Id: If25d75e0f62036dc777faf8593ed8eb9a74950b0
Remote execution and other tools can be confused by references to
build_number.txt without a dependency. Add an order-only dependency,
which maintains the current behavior.
Test: BUILD_NUMBER=1 && m aapt && aapt version # shows 1
BUILD_NUMBER=2 && m aapt && aapt version # shows 1
rm out/soong/.intermediates/frameworks/base/tools/aapt/aapt/linux_glibc_x86_64/aapt
BUILD_NUMBER=2 && m aapt && aapt version # shows 2
Change-Id: Icfa98d6840b1dc2e273ba29c33011635d1cf93b1
Simplifies debugging sdk membership code when it is only called if an
appropriate member is present.
Test: m nothing
Change-Id: I32bc93e0484c829bdbd6b050822249feb6404f89
Makes the tests more realistic as they cover what happens when an sdk
OS specific variant is disabled (Windows is disabled by default). This
will allow issues around disabled variants to be detected early during
Soong bootstrapping.
Test: m nothing
Change-Id: I7ec47dbca52e38750166d755daf706aadea12d15
Which is the list of JNI libraries that are embeded inside the apex.
jni_libs is handled just like native_shared_libs except that it is
stored in apex_manifest.
When linkerconfig finds an apex with JNI libs, it exposes the namespace
for the apex as visible so that libnativeloader can link the namespace
to the corresponding classloader-namespace.
Bug: 149363889
Test: m nothing(runs soong test)
Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
Embed common properties (apexNativeDependencies) so that the logic for
adding dependencies for native modules can be reused.
Bug: N/A
Test: m
Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
ensureExactContent shouldn't return immediately when it finds a match
from expected list of files.
Bug: N/A
Test: m nothing
Change-Id: Ie15c811f9cfcae7ede28dee0fcf203cee24659a0
Symlinking doesn't make sense for host APEXes.
Bug: 150255435
Test: m com.android.art.host and inspect the built APEX; there is
no symlink.
Merged-In: I28492dfaaef471117a430be05255fbef76e557b0
(cherry picked from commit 9b96418dfe)
Change-Id: I28492dfaaef471117a430be05255fbef76e557b0
Using $(call dist-for-goals,droidcore,...) for every apex
installed-files.txt causes every apex to be built for all builds,
causing a signficiant regression in build time. For now only
dist them in checkbuilds, which were going to build all of them
anyways.
Ideally we would like to dist the installed-files.txt only if
the apex was already built, but there is not currently a way to
express that.
Test: treehugger
Bug: 149979076
Change-Id: I21edbc90980f94ad6d497cb86ee80223dd782fe1
We plan to add boot image variants for host tests.
Distinguishing the variants by arch does not work,
since both host and device can have the same arch.
Change-Id: Iea73c77367affb074f97a0fc318389417ce537da
Use AndroidMkEntries so the next patch can use ExtraFooters, which
doesn't exist in AndroidMkData.
Test: manually diff out/soong/Android.aosp_x86_64.mk
Change-Id: Ia3006b6747813693cf7e2b536030b21f3109f538
Collect the number of modules and variants and some basic statistics
on memory usage inside soong_build by writing out a proto that is
read back in by soong_ui.
Test: examine soong.log
Change-Id: I6926876377a4f6229cf41fdbf166ae03c885ea55
Because APK-in-APEX embeds its jni_libs in it. We don't have to follow
deps of jni_libs.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
ls apex # there should be no /lib dir
Change-Id: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
