Resource configs should not be deduped when building RROs since it
would be impossible to override some resource configs with the same
value as the default config. Also, aapt2 removes resources that do not
have default configurations. If an overlay attempts to overlay a
non-default configuration without overlaying the default, the resource
will be removed and the value will not be overlaid at all.
Bug: 146227008
Test: m-j
Change-Id: I1465b599cbf7f464d1b5b75a87e7dafa2cf734b0
Building device_manifest.xml or device_compatibility_matrix.xml only
builds vendor manifest / matrices, but not all device manifest /
matrices (e.g. vintf_fragments, ODM manifest, etc.). Make the name more
accurate.
Test: m check-vintf-all
Change-Id: Ib017507c421355263d53a9e5b357f169c77da36d
They are moved into check-vintf-all, which is more
accurate and do not require building full OS images.
Also move kernel check code down to check_vintf_compatible. There
is no assembled manifest to put kernel configs now, but they are still
required for build time OTA VINTF checks.
Test: builds
Test: change a vintf_fragment file to cause a conflict with main manifest file
(add health@2.0 to boot@1.1.xml), and check_vintf_vendor_log fails
Change-Id: I9791abc440a40e1537b4387eb67575ff2e22df08
There are currently no classes on the bootclasspath that live in the
unnamed package (empty package name). This CL explicitly forbids it.
This has the side effect of guarding against some classes of bugs,
for example R8 has functionality to generate some helper classes in
the unnamed package that should not be on the to bootclasspath
because they would hide corresponding classes in Applications.
Strictly speaking I believe that the "not package_name or " part
of the condition in the touched script is not needed because
LoadWhitelist() already skips empty lines and doesn't add "^$" to
the whitelist regex, but relying on this seems very fragile. If
there ever is a need to have classes in the bootclasspath's
unnamed package in future then we can always change this again.
Bug: 147480264
Test: Treehugger
Change-Id: Ic310dd0779dde133b3a5c3039ea5b70d31331a9b
PRODUCT_PRODUCT_VNDK_VERSION will be automatically set to true for
the devices with PRODUCT_SHIPPING_API_LEVEL newer than 29.
Bug: 146621746
Test: build with PRODUCT_SHIPPING_API_LEVEL set to 30
Change-Id: I78cd81d1d61e9089b163169bc495df8a880463da
Add target that checks VINTF compatibility of the current build
(in $PRODUCT_OUT) properly. The target:
- Doesn't require a full build
- Won't run for system-only AOSP targets
A verbose log is printed if `m check-vintf-compatible` is executed,
but it won't show up if `m` is executed.
(After this patch, adding product / system_ext matrices is as simple
as defining a vintf_compatibility_matrix in Soong, and VINTF
compatibility is properly checked.)
Test: m check-vintf-all
Test: delete */etc/vintf and m check-vintf-all
Test: m
Test: m check-vintf-all on device with vendor/odm and ODM SKU-specific
manifests
Test: change manifest.xml to be incompatible and m check-vintf-all fails
Bug: 140280874
Bug: 140360109
Change-Id: I6ee79910d745d29cfc9b05b1435e26f91b7c10f7
Jars in APEXes have Make module names <jar_name>.<apex_name>. e.g.
updatable-apex.com.android.media. Previously, we have used <jar_name>
which actually meant the platform variant of the jar. This is not only
incorrect, but also is causing problem as the platform variant is no
longer available when the jar is configured to be available only for the
corresponding APEX (via the apex_available property).
Fixing the problem by correctly using <jar_name>.<apex_name> scheme.
Bug: N/A
Test: m
Change-Id: I6e255ce88c9bd80120b29197fb2637a64010f531
Merged-In: I6e255ce88c9bd80120b29197fb2637a64010f531
jacoco-report-classes-all.jar now depends on all installed files
including apks in /apex. Previously, it depended only on files under
system.img and as a result jacoco for other partitions were missing.
Bug: 147296855
Test: m
Change-Id: I755de1205ebc43c197af36a13cca5f4b49e275e8
They are now created from Soong, and therefore put in a separate config file
out/soong/dexpreopt_soong.config.
Test: m
Bug: 145934348
Change-Id: I27e710f09c37e64e8975b8e763d13434e5de71b3
Now that ninja uses lstat and can support installing arbitrary symlinks,
switch jni lib symlinks from LOCAL_POST_INSTALL_CMDS to real rules.
Bug: 128577186
Test: List of files under PRODUCT_OUT is the same before/after this change
Test: out/target/product/generic/.installable_files now includes the symlinks
Test: m installclean; m NfcNci -> symlinks installed with correct dest
Test: m NfcNci; m NfcNci -> ninja: no work to do
Change-Id: I078dca53ab3d93f74c36fa66d5577e6e3e0640d6
Earlier CL Ida40dfae8c83bf7c2e737d5c7ea418e1197ad826 introduced
Soong-generated Make variable 'DEXPREOPT_IMAGE_LOCATIONS'. That CL was
erroneous in that it did not take JIT-zygote config into account and
generated identical location for "boot" and "apex" boot images.
This caused build breakages, because in case of JIT-zygote config the
two variables 'DexPreoptImages' and 'DexPreoptImageLocations' in the
module's dexpreopt.config were out of sync: 'DexPreoptImages' was
for the "apex" image, and 'DexPreoptImageLocations' was for the "boot"
image.
CL I9a91fc48e54d7d43abec2cb2b5a11e3581db380b introduced a workaround
for this problem: incorrect 'DexPreoptImageLocations' from the module
dexpreopt.config was ignored, and instead boot image location was
manually reconstructed from 'DexPreoptImages'. This workaround would
not work when we start using boot image extension and location will
become more complex.
This CL fixes the way 'DexPreoptImageLocations' is generated by
spliting the 'DEXPREOPT_IMAGE_LOCATIONS' variable in two variables
depending on the boot image flavour "boot" of "apex". This is
aligned with the way other similar variables are generated.
Test: aosp_walleye-userdebug boots.
Test: walleye_jitzygote-userdebug builds
(on git_rvc-release branch with this CL cherry-picked).
Change-Id: I449c968909635dd8cc431323fccbc7fce440fea5
unpack_bootimg in conjunction with mkbootimg can be used to re-create
boot.img with a different kernel image and ramdisk.
Change-Id: I9615facc9335885989772a0dd7f08217e2143a45
These are a (partial) list of files that we'd install with a default
build. The idea is that if something is removed from this list, soong_ui
can remove it from the installed location before running ninja.
It's okay if there are things missing from this list, it's not intended
to be a 100% solution replacing installclean / CleanSpec.mk, just
something that handles 80% of the cases without user involvement.
In particular, if something is removed from PRODUCT_PACKAGES, we'll
remove it from disk, but not necessarily rebuild the image files. That's
the same as most use cases of CleanSpec.mk today, and often some other
change will trigger the necessary images to be rebuilt.
We should be able to fix that by changing all of the image creation
rules to depend on the (partial) list of files they care about, or by
fixing ninja to rebuild things when their list of dependencies change.
(Other tools run into this same problem)
The list of test files is also included so that we can remove obsolete
tests from their "installed" locations within test suites and the
testcases folders.
Test: remove a module from PRODUCT_PACKAGES, see the print and file removed
Test: change the name of a cts test, see the old one removed from cts
Change-Id: I67f270a6713369099ca523aaf991ee3beb815c0a
See the Changes.md and the paired soong change for more information.
Test: Add BUILD_BROKEN_NINJA_USES_ENV_VARS := OLDPWD
ALLOW_NINJA_ENV=false m nothing; check out/soong.log
Change-Id: I2167eac52166b513318bc48feb71c9d0b80e5fd4
android_app and android_test modules were not built as part of
javac-check, which resulted in not running them in the Error Prone
build.
Fixes: 146455923
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I278d7ee0cdc3f49aa8fa4d4f13309e29d700f2ba
My change to clean up obsolete copy headers would remove valid ones if
thhe LOCAL_COPY_HEADERS_TO path wasn't cleaned. I'm seeing this most
with values that just end in '/', so we end up with a '//' in the path,
which isn't textually equivalent, and we remove it.
Test: No longer seeing constant removals on internal products
Test: Set LOCAL_COPY_HEADERS_TO := ..
Test: Set LOCAL_COPY_HEADERS_TO := ../foo
Test: Set LOCAL_COPY_HEADERS_TO := /foo
Change-Id: Idbeeb207a2bb2a8da766473dbded877cec7c9cc1
Use ro.product.vndk.version to show the VNDK version that the product
partition is using.
When PRODUCT_PRODUCT_VNDK_VERSION is set, add ro.product.vndk.version
in /product/build.prop.
If PRODUCT_PRODUCT_VNDK_VERSION is "current", ro.product.vndk.version
will have the VNDK version in PLATFORM_VNDK_VERSION. Otherwise, it
will have the value defined in PRODUCT_PRODUCT_VNDK_VERSION.
Bug: 144534640
Test: Check if /product/build.prop has "ro.product.vndk.version"
Change-Id: If5e7e3a6c155de45f88f68700f16175656896afe
Dist ramdisk-recovery.img and misc_info.txt. This is useful for
re-creating boot.img without having to download a huge target_files zip
file.
Change-Id: I2e1c1d547c95ca3433f89c68428c0c98fa4d19cd
The check is implemented in Soong via the apex_available property.
For a module that should be in the APEX named "foo" and shouldn't be in
any other APEX and also in the platform (the non-updatable part), the
property can be set to "foo" (without "//apex_available:platform")
to express the restriction and then Soong will enforce it.
Bug: 128708192
Test: m
Change-Id: Ia1aaaacd685f466447b61deae2849cb0aa83def3
The test was to ensure that bionic libs are not installed to the
non-updatable part of the platform (e.g. system/lib). However, for
bionic libs, we actually have been installing them for bootstrapping.
Specifically, they are installed to /system/lib/bootstrap, not
/system/lib. The test has passed just because it didn't look into
/system/lib/bootstrap. Removing the unnecessary check.
Bug: 128708192
Bug: 133140750
Test: m
Test: m out/target/prduct/$(TARGET_DEVICE)/system/lib/libc.so doesn't
work
Change-Id: I93cbd74972cdd2daea45612136d5133fa49ab76a
