Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
Previously, while sdk tests would pass the sdk code would often fail
in androidmk processing. This change makes the tests more realistic
and will catch the errors earlier.
Bug: 142935992
Test: m nothing
Change-Id: Ifd0b2d7cf24e941c919f6b6e0beb2403a67d4308
goma can't handle the --system argument that Android must pass to
javac.
Bug: b/143658984
Test: treehugger
Change-Id: I207668d8baa4ab28160938732a38f696aeac3f44
VNDK and vendor snapshot singleton work in a single thread, so globbing
in singleton results in ridiculus running time. Moving codes to
GenerateAndroidBuildActions to reduce running time.
Bug: 150406226
Test: VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: vendorSnapshotSingleton build time became 0.56s (from 10s)
Test: build.ninja building time became 1m11s (from 1m21s)
Change-Id: I4a081eef5847c62ca00280ca426f5b4e10f87b59
Following how NDK also creates its own install path.
Bug: 142935992
Test: cc_sdk_test.go, java_sdk_test.go
Change-Id: I98a3656903f37f6d7c90e6cf609431b2461a6161
apex { name: "foo" }
override_apex { name: "override_foo", base:"foo" }
PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES := foo:com.android.foo
Previously, the override was done only for the overridden package "foo",
but not for "override_foo". Fixing this issue by using ctx.ModuleName()
when finding the package name to use.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 150645663
Test: m
Merged-In: I2947e5c75369216a4bbce8749503236be86771c3
(cherry picked from commit a519c54dd3)
Change-Id: I2947e5c75369216a4bbce8749503236be86771c3
To build vndk-ext for product variants use `vndk.extends` property
with `product_specific: true` as for the vndk-ext for vendor
variants. For example:
cc_library {
name: "libvndk_ext_product",
product_specific: true,
vndk: {
enabled: true,
extends: "libvndk",
},
}
It will install the vndk-ext libs for product variants in
product/lib[64]/vndk/
Test: m nothing
Bug: 147778025
Change-Id: If1ee5be93c579abad302f44f18e6316f27e70019
This is an unchanged copy of build/make/tools/generate-notice-files.py
After this change, the make implementation of generate-notice-files.py
will change to take a required parameter for $(PRODUCT_OUT) and will
only include notices for files built under $(PRODUCT_OUT).
Because soong has the ability to walk dependency trees, the soong
version will likely change in the future to use that ability causing
both versions to move in different directions.
After those changes are complete, we can look into factoring out any
remaining shared logic.
Test: run manually and system image notices checked for changes
Change-Id: Id139a66503457615548b46e7996349ca0817e831
Removing XOM had the side effect of removing "-z separate-code", which
was needed to override a new default after a recent toolchain update.
This led to some performance regressions in some tests. For now, add
this flag to the global arm64 device flags to return to the previous
behavior.
Bug: 150506341
Test: m -j
Change-Id: I54787954141d133e245dfd259a37bf4c3c8e7caa
FirstUniquePaths is called on some long lists where the O(n^2)
behavior is problematic. Use a map-based implementation for
longer lists.
Test: TestFirstUniqueStrings
Change-Id: I7181aba869e5ccc0f99c2fa7b8f03839f06e4307
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
This is rarely used feature but cost alot for the local build and build
inra.
Bug: 150506627
Test: m
Change-Id: Iec3ada4a97c7b228f2818563fa0e81b407f2715a
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
Jooyung Han