The minimum set of supported features are different between Android and
Linux with X86_64. So while the list of variants and features are still
technically correct, and may be shared more in the future, the default
needs to be configured differently.
Bug: 120208462
Test: add `host_supported: true` to libopus; m libopus
Change-Id: Ib79707d17b852f77341026085230c026b6386b78
Java binary modules expect the order of modules in Soong's Android.mk
to match the variant order. Instead of sorting by name and then
subdir, which will alphabetize the variants, only sort by name and
use sort.Stable to keep the ordering of modules with the same name.
Test: m
Change-Id: Icf3d22bdc9f9c73945d01c2c47468cc1c361035d
When PRODUCT_DEFAULT_DEV_CERTIFICATE is set to /vendor/foo/devkeys/test,
then the public/private key pairs for an apex_key is searched at
/vendor/foo/devkeys directory.
To be specific,
/system/timezone/Android.bp:
apex_key {
name: "timezone.key",
public_key: "com.android.tzdata.avbpubkey",
private_key: "com.android.tzdata.pem",
}
When PRODUCT_DEFAULT_DEV_CERTIFICATE isn't set, the keys are searched at
/system/timezone, which is the path where Android.bp is located.
With PRODUCT_DEFAULT_DEV_CERTIFICATE set to /vendor/foo/devkeys/test,
the keys are searched at /vendor/foo/devkeys.
Bug: 121224311
Test: m (apex_test updated)
Test: m with crosshatch (PRODUCT_DEFAULT_DEV_CERTIFICATE is set to
/vendor/google/...)
Test: m with cheets (PRODUCT_DEFAULT_DEV_CERTIFICATE is set, but there
is no apex key there. The product is with TARGET_FLATTEN_APEX := true)
Change-Id: I213bbb96c433d851f9cc982871459fd7fb4fe47d
Only if enforcement option is enable, it makes build error when there is apk located at system partition but signed with system certificate.
Bug: 74699609
Test: m -j
Change-Id: I23c41f2665dd97abac3e77d1c82d81ff91b894eb
It is a list of <module_name>:<manifest_name> pairs. When the module
name of an APK or an APEX matches with <module_name>, then its app
manifest name is overridden to <manifest_name>.
<module_name> and <manifest_name> can be patterns as in
com.android.%:com.mycompany.android.%.release
Note that, in case of APEXes, the manifest name refers to the name of
the zip container. The apex manifest name (which is specified in
apex_manifest.json) is not overridden.
Test: m with PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES for
1) an APK in Android.mk
2) an APK in ANdroid.bp
3) an APEX
and check that manifest names are modified as specified
Change-Id: Ie58882d90884695e893944c43d9c8803b283e93d
Add methods to TestingModule that return an empty BuildParams instead
of panicking, which can be used to test if a module has a matching
rule. Also add godoc to the TestingModule methods.
Test: m
Change-Id: Iea2ab9be57d3f3f60437041f4e5a7e2100e1fe48
This solves a problem where javac fails to find patch-module targets
when a build diretory is not under the project root.
Bug: 117770838
Test: java_test.go + manual build
Change-Id: If70d0d388a3f6c87b3f78a927df2063616d50c8a
This commit renames `_platform` suffix to `` (empty string) so that
non-apex variations are not renamed to `_core_shared_platform` or
`_vendor_shared_platform`.
This commit makes sure that `_core_shared` and `_vendor_shared` is
always under `$OUT_DIR/soong` regardless the usages from apex modules.
Furthermore, this avoids the confusing stale lsdump files (e.g. both
`_core_shared` and `_core_shared_platform exist) while creating
reference ABI dumps for VNDK ABI checks.
Bug: 121986692
Test: lunch aosp_arm64-userdebug; make # no more _platform variants.
Change-Id: Ic02a60ac45f982580349661c22331d114617fd92
Mainline modules are tightly coupled to the platform, and should
build against the current SDK from source and not prebuilts. Add
a flag UNBUNDLED_BUILD_SDKS_FROM_SOURCE to specify that a
TARGET_BUILD_APPS build should build the current SDK instead of
using the prebuilts.
Bug: 121194841
Bug: 121231426
Test: no change to out/build-aosp_sailfish.ninja
Test: forrest unbundled build
Test: forrest master apps build
Test: forrest mainline modules build
Change-Id: I45a40a335483dae2fe192721df9b31bdbab97ee5
Port the dexpreopt logic from Make to the dexpreopt package in Soong,
and use it to dexpreopt Soong modules. The same package is also
compiled into the dexpreopt_gen binary to generate dexpreopt scripts
for Make modules.
This relands Ib67e2febf9ed921f06e8a86b9ec945c80dff35eb and
I462182638bd57b1367b5bfb0718e975c11ae66f7, along with multiple fixes
to depsfile generation in dexpreopt_gen that caused .odex files for
modules in defined make to be missing dependencies on boot.art, and
a fix to not dexpreopt and strip tests.
Bug: 119412419
Bug: 120273280
Test: no differences to dexpreopt outputs on aosp_sailfish system/,
only expected changes to dexpreopt outputs on system_other
(.vdex files for privileged Soong modules no longer incorrectly
contain .dex contents).
Test: OUT_DIR=$PWD/out m
Test: NINJA_ARGS="-t deps out/target/product/sailfish/obj/APPS/Contacts_intermediates/dexpreopt.zip" m
Change-Id: I6bb2c971cee65d2338839753aa0d84939f335b1b
MaybeRel was failing with an error when comparing an absolute out
path to a relative source path. Make it return false instead, and
add tests.
Bug: 119412419
Test: paths_test.go
Change-Id: I462182638bd57b1367b5bfb0718e975c11ae66f7
Port the dexpreopt logic from Make to the dexpreopt package in Soong,
and use it to dexpreopt Soong modules. The same package is also
compiled into the dexpreopt_gen binary to generate dexpreopt scripts
for Make modules.
Bug: 119412419
Bug: 120273280
Test: no differences to dexpreopt outputs on aosp_sailfish system/,
only expected changes to dexpreopt outputs on system_other
(.vdex files for privileged Soong modules no longer incorrectly
contain .dex contents).
Change-Id: Ib67e2febf9ed921f06e8a86b9ec945c80dff35eb
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
When the stubs variant of a library is dependend by a platform component
and the library is included in one or more APEX, the library is not
installed to the platform, because it is provided by APEX.
Bug: 120266448
Test: m
Test: add stubs: { versions: ["1"], }, to libnetd_resolv
then build netd. libnetd_resolv.so does not exist under /system.
Change-Id: I09b78e38df285033ef6e9c85f7ea4b0274e85070
When a native module is built for an APEX and is depending on a native
library having stubs (i.e. stubs.versions property is set), the stubs
variant is used unless the dependent lib is directly included in the
same APEX with the depending module.
Example:
apex {
name: "myapex",
native_shared_libs: ["libX", "libY"],
}
cc_library {
name: "libX",
shared_libs: ["libY", "libZ"],
}
cc_library {
name: "libY",
stubs: { versions: ["1", "2"], },
}
cc_library {
name: "libZ",
stubs: { versions: ["1", "2"], },
}
In this case, libX is linking to the impl variant of libY (that provides
private APIs) while libY is linking to the version 2 stubs of libZ. This is
because libY is directly included in the same apex via
native_shared_libs property, but libZ isn't.
Bug: 112672359
Test: apex_test added
Change-Id: If9871b70dc74a06bd828dd4cd1aeebd2e68b837c
Draft APIs are available to the platform and to CTS to allow
developers to iterate on an API, but hidden from the NDK artifacts to
avoid releasing the API until it is ready.
Test: Mark binder_ndk headers and library as drafts, make checkbuild,
build-ndk-prebuilts.sh, verify missing from NDK artifact.
Bug: http://b/120091134
Change-Id: I8685e92bdaaea581e17fe98e7a2bfb9388f9f132
Also, replace all notice file references with the parent directory
pattern(../) with filegroups. This new version has
ALLOW_MISSING_DEPENDENCIES support, so shouldn't break branches that
don't contain the libwinpthread project.
Bug: 118899640
Test: Manual build + forrest runs on previously failed branches.
Change-Id: I13e70e8dab547f82c1c8f15eccc7ae116e480ad5
Adds build system support for generating AArch64 binaries with
execute-only memory layouts via a new xom module property. Also adds
support for an ENABLE_XOM build flag for global builds.
Bug: 77958880
Test: make -j ENABLE_XOM=true
Change-Id: Ia2ea981498dd12941aaf5ca807648ae37527e3ee
Support Kryo 385 cpu variant which should be used for
Qualcomm Snapdragon 845.
Motivation:
kryo385 CPU *IS NOT* an Arm Cortex-A75.
Particular problem:
Cortex-A75 CPU must support optional ARMv8.2 dot product
feature; kryo385 CPU (Qualcomm Snapdragon 845) doesn't
support it.
Test: Builds when kryo385 is used as cpu variant.
Test: Pixel 3 boots to GUI with kryo385 as CPU variant
with this patch on AOSP 9.0.0 r16.
Bug: 119564566
Change-Id: I62ffb46b1977b48446c6c1ca1400b1b39f7a8457
These are enough to compile bootanimation with Soong.
Test: build bootanimation on internal branch
Change-Id: I8474b54ea196ab71ce178c517eb261bdc22b2e01
When dist'ing a library or binary that has use_version_lib set, always
distribute the stamped version, even for the device.
Test: m test_build_version_test dist
Change-Id: I2995ec516b1d182ce18f099aeaa4d186ffbcf01f
Also, replace all notice file references with the parent directory
pattern(../) with filegroups.
Bug: 118899640
Test: Manual build
Change-Id: I841345d747f41a3bb5beea66ad87a979734c39a4
This reverts commit 555c114283.
Reason for revert: The namespace issue in the pi-dev-plus-aosp-without-vendor branch is now fixed.
Change-Id: I26ed591447797a8ee505f43bdd209162418b6c5e
When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which
means files in an APEX is not packaged into the mini file system image,
but instead directly copied to the system partition.
This option is for devices where kernel does not support loopback
devices or the maximum number of loopback devices is too small (though
the threshold is TBD as of now).
This CL also fixes a bug that jars having bytecode are installed instead
of those having dex.
Bug: 118485880
Test: TARGET_FLATTEN_APEX=true m apex.test; tree
out/target/product/.../system/apex/apex.test shows list of files in it.
Test; m apex.test, then a file out/target/product/.../system/apex/apex
.test.apex exists.
Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
Base name of the output file of a prebuilt_etc is by default the module
name. This default behavior can be customized by either via the
'filename' property or the new 'filename_from_src' property. The former
explicitly sets the base name while the latter makes the file name to be
that of the source file.
Test: m (prebuilt_etc_test added)
Change-Id: Ic2900417bda62993f6de2612d993234b82b74479
Arch property struct types are created at runtime. Go has a limit
of 2**16 bytes for the name of a type, and the type of a struct
created at runtime is a string containing all the names and types
of its fields. To avoid going over the limit, split the runtime
created structs into multiple shards.
Also undo MoreBaseLinkerProperties now that it is no longer
required.
Bug: 80437643
Test: m checkbuild
Test: no change to out/soong/build.ninja
Change-Id: I035b20332ec63f3d4b1696855c5b0b0a810597b7
