AAPT2 is used everywhere now, remove support for AAPT1. Also
removes dpi_specific_apk.mk, it was never updated to use AAPT2
and has been generating bad APKs (resource ID mismatch between
the dex files and the resources) since AAPT2 was made the default
in May 2018 (I9b67fd2a9b3234798b2aac879b5242c2097b3863).
Bug: 80450981
Test: m checkbuild
Change-Id: I2ff768897360ff866dbae5562455bab22be270f7
Merged-In: I2ff768897360ff866dbae5562455bab22be270f7
/sbin was traditionally used for static binaries on the ramdisk for
Android, but now everything is a shared binary, so this directory is
empty and we do not want to encourage creation of new libraries in
this directory.
Bug: 73660730
Test: build
Change-Id: Ia82d892adfffb6fa325d0c570ae7999e7bb28dc2
When PRODUCT_BUILD_SYSTEM_IMAGE is false, avoid building artifacts and
intermediates that will not be used. This speeds up the build for these cases.
Bug: 123427297
Test: No change when building system image, smaller build when not
Change-Id: I438e4794af5376c897ffcc1d795a1e114dccd351
Running appcompat is missing a dependency on aapt/aapt2. There
is no need to switch between aapt and aapt2, so always use aapt2
and add the missing dependency.
Fixes: 130575935
Test: treehugger
Change-Id: If32c03410fbdb3945bf20f7405de13dc8cd83038
Test: m systemimage on cf_x86_phone-userdebug (in internal and AOSP).
Test: Check that the generated find command works on MacOS
Bug: 124293228
Change-Id: I5dfb534aa2bc24a8d0a75fde31b139a6ed86e6a5
This reverts commit c0ed5e7c56.
Reason for revert: this patch cause build breakage on aosp-master-throttled (aosp_qemu_trusty-userdebug)
Bug: 130376456
Change-Id: Iab03d21219674691bd8bf6b2e5004508ebb862b9
Add all the boot image files necessary of offline inspection and
compilation in a single zip file (boot.zip).
This replaces the previous boot_profiles_jars.zip which contained only the
jar files.
Bug: 130376456
Test: m dist
Change-Id: I7e711369e7d56630c168c01df60a8c2672d60927
Core platform API violation reporting is disabled by default and can be
enabled by setting the persist.debug.dalvik.vm.core_platform_api_policy
property. Set it to "just-warn" for non-user builds and leave disabled
on user builds.
Test: builds, boots
Bug: 125701194
Change-Id: I2f4be42373de9fdbc71c3178de6d34e07809f13a
We already have targets that build generic system images, which can be
applied (flashed) onto matching devices to replace their target-specific
system images. This CL adds PRODUCT_BUILD_GENERIC_OTA_PACKAGE that
allows building generic OTA packages to be installed over-the-air.
Since A/B and non-A/B OTAs have different package formats, currently the
support is limited to targets that use A/B OTAs. Note that this CL only
allows _building_ the package - will need additional changes for the
actual package install as well as targeting matching devices.
Bug: 122851610
Test: `m otapackage` on a target that sets
`PRODUCT_BUILD_GENERIC_OTA_PACKAGE := true`.
Test: TreeHugger
Change-Id: If6fd2da15d24c5aaee09618efe94514c6d83292d
So that we actually respect different LOCAL_REQUIRED_MODULES for the
host and device versions instead of unioning them. That got particularly
problematic when LOCAL_SHARED_LIBRARIES is implicitly added to
LOCAL_REQUIRED_MODULES. We also used to walk through device-only modules
when filling out the list of required modules, which triggered even more
extra installations.
This also changes the requirements for PRODUCT_HOST_PACKAGES so that it
no longer accepts target-only phony modules (since we can now
differentiate them). They were all removed in previous patches.
Test: treehugger; diff resulting builds
Test: diff list of product_target_FILES and product_host_FILES
Change-Id: I2ed8950320d31f5693323ad8cef6ec5b6780b7d4
This change moves the ro.build.require.* props extracted from
TARGET_BOARD_INFO_FILE to vendor/build.prop as opposed to
system/build.prop. These typically contain what bootloader and
baseband the build requires, which are very device-specific.
Bug: 130025216
Test: make, inspect props
Test: flash blueline
Change-Id: I48642485bdc853884d465d1fe00f2ceae69a4736
Merged-In: I48642485bdc853884d465d1fe00f2ceae69a4736
Some people apparently still talk to the network during their build.
Allow this temporarily with a BUILD_BROKEN_USES_NETWORK check.
Bug: 129992021
Test: attempt to talk to the network during the build with and without
this flag
Change-Id: I45612ad6165f92f123847b4057338c0dfc3424ee
* changes:
Only assert-max-image-size for static partitions.
sparse_img.py --get_partition_size return size of partition
Revert "Fix dynamic partition size check for devices with recovery"
Prior to this change the properties were in system/etc/default.prop.
These properties are device-specific and don't really belong on the
/system partition.
I anticipate further change to these properties in the future:
- pruning down the set of properties, as the .product. props
don't make much sense for the boot image
- moving them to the ramdisk instead
Bug: 130025216
Test: boot into recovery, observe title (shows bootimage fingerprint)
Change-Id: I9e92c1ec7068ae18fa0d709c77eac22a6b88c3d8
We only need to define it once. dex_preopt_libart.mk can be read
multiple times if there are many boot image.
Test: m && no warning
Bug:119800099
Change-Id: If5b8fbb0c3310eb42f676d7b5267dcee679f7e19
Looks like the reason for it existing has been fixed. It should probably
just be removed.
Bug: None
Test: WITH_TIDY=1 m
Change-Id: Ic001393da7211cd6ef2bbd5af6ef13c7fe8e00e7
assert-max-image-size doesn't make sense for
dynamic partitions, as build_image.py always find the
right size for the output image. Hence:
- build_image.py no longer need to write generated_*_info.txt
(which contains the size of the image).
- assert-max-image-size on the static BOARD_*IMAGE_PARTITION_SIZE. If
a partition is dynamic, that variable isn't set, and
assert-max-image-size becomes a no-op. If the partition is static,
assert-max-image-size checks the static partition size as it used
to be.
- Fix read-size-of-partitions to use the size of the partition by
reading the image directly (instead of using generated_*_info.txt).
For devices without AVB, with DAP enabled, and does not have
RESERVED_SIZE for partitions, because of right sizing, the original
code always warns about approaching size limits. Since such checks
doesn't make sense for dynamic partitions, remove them.
Test: builds on device with dynamic partitions
Test: builds on cuttlefish with DAP enabled (without AVB), no
more size limit warnings:
WARNING: out/target/product/vsoc_x86/vendor.img approaching size limit (X now; limit X)
Fixes: 122377935
Change-Id: I75e1b8322197cb18cf397d02aefd49d777bb6405
Reason for revert: size check is removed for devices
with dynamic partitions because it doesn't make sense.
Bug: 122377935
Bug: 120043292
Bug: 124489494
Test: build cuttlefish
This reverts commit accf09b2e0.
Change-Id: I289faf11a08acbcef36924eb747a15f55124ce79
If TARGET_USERIMAGES_SPARSE_EXT_DISABLED is set, don't provide
--sparse to lpmake, so that a non-sparse super image is built.
Test: build with the flag set.
Fixes: 120041578
Change-Id: I5a26e4c793b0e2ddc89e9c38c8828ac21044e78a
Complete the migration to use art/dexdump.
Bug: 22322814
Test: make -j 50 checkbuild test-art-host-dexdump
Change-Id: Ie69bed375dff79f66add5bdb6a8b1b7e14d8a173
The standard target modules stopped working when restrictions in
soong were introduced to which binaries are allowed to be used during
builds.
Listing a very large amount of modules in columns does not make it
more readable and harder to work with in tools so just drop it.
Bug: 129800175
Test: make modules
Change-Id: I26040479a03916161fb5d072de1af640d8080c7f
We used to add framework.jar to proguard via -systemjars option even
for the apks building againsd SDK. This was because the app might have
references to hidden APIs via static libraries, etc.
However, for vendor apks, the use of hidden API is strictly prohibited.
So it is fine to not include framework.jar. Furthermore, including
framework.jar even causes problems in some cases; if a java library
(e.g., android.hidl.base-V1.0-java) is statically linked to both the app
and the framework.jar, -systemjars frameworks.jar forcibly removes
classes in the library from the app to have references to the non-public
classes in framework.jar. This could fail some compliance tests.
Fixing the problem by not raising SDK for apks located in vendor or odm
partitions.
Bug: 128574081
Test: m
Change-Id: If2b658fead5b4bb4d8c023a37eb57a37ad9b741d
These files are pretty dense, and are difficult to read
without indentation.
Bug: 129323707
Test: noop on presubmits
Change-Id: I5fde5429120e80a8c6329ea43d32b3ee324a2632
Export more config values to Soong that will be use dto generate
robolectric's build.prop.
Bug: 122331577
Test: m checkbuild
Change-Id: I1e9dd165772a071cf78927b3bf1e29e01290a42e
We have developed a vendor module and set LOCAL_VENDOR_MODULE := true<space> (Added a space character at the end)
The android build system then can't installed it in the right partition until we removed the extra space character.
bug: 129725067
Change-Id: I081ffe7f39a9c850007ba304c815436500be694c
If a module is uninstallable, the shared library dependencies are not
set up and thus the ELF file check may fail incorrectly. In this case,
there is no need to check ELF files anyway.
Test: Build walleye with no-vendor-variant VNDK enabled and does not
see erroneous failure anymore.
Change-Id: Icd115fc82daedf11795800de5cbe87c87073586a
It is now in the Runtime APEX and considered internal there.
Test: Flash and boot
Test: atest CtsCompilationTestCases CtsBionicTestCases
Bug: 118374951
Bug: 124293228
Change-Id: I33bb9c238d7db46795deb592c9d20fe6591c1654
To avoid the confusion. super.img isn't intended to be flashed
during day-to-day development.
Test: m superimage
Bug: 128891161
Change-Id: I9d62e5929b415343b2d890ab21e6ae51175af2ae
This CL simplifies the PRODUCTS.$(INTERNAL_PRODUCT).X accesses of
product variables, and removes unnecessary stripping of them.
Replace: '\$\(PRODUCTS\.\$\(INTERNAL_PRODUCT\)\.([^\)]*)\)' with '$(\1)'
Replace: '\$\(strip\s*\$\(PRODUCT_([^\)]*)\)\)' with '$(PRODUCT_\1)'
A few minor manual tweaks.
Bug: 116769560
Test: presubmit
Change-Id: I70c54f1582e3cc780028535960147d99ebc2e0e1
With this change, all PRODUCT_ variables are treated the same
when it comes to stripping and assigning them to their final
variable name. In the past, all the PRODUCT variables needed
to be listed in two places to achieve this.
The documentation previously attached to the strip/assignment
is moved to the PRODUCT_ variable list in product.mk.
Also refactor some of the default value logic to cope with
the new automation.
Many places in the build system that currently refer to
$(PRODUCTS.$(INTERNAL_PRODUCT).X) can now be modified to
use $(X) directly.
Bug: 116769560
Test: verified noop on PRODUCT_ variables on all products in the tree
Change-Id: I5677c355e81359b1d3c0db2a2232941097a05047
package `init_vendor` is the only content of ramdisk so far.
We would get build error if we do not include init_vendor.
The patch fix the build error for the case that ramdisk is empty.
Bug: 129386309
Test: lunch aosp_arm64_ab-userdebug; make ramdisk -j
Test: Build pass
Change-Id: I7c7c828b5f29350268d4789393b90740dd68162d
Add cc_prebuilt_internal.mk and java_prebuilt_internal.mk. Now all
buisiness logic lives in individual per-class prebuilt mk files.
Fixes: 128609813
Test: Built and flashed a Pixel device image + TreeHugger
Change-Id: I3827f990642bb7587dc682d1a382b3a1ce22fe66
The recovery patch gets put in the SYSTEM directory. Placing the
recovery patch here doesn't make sense when not building the system
image, as is the case for merged (system + vendor) builds.
Bug: 128838154
Test: Running make droid dist for a device target that sets PRODUCT_BUILD_SYSTEM_IMAGE to false.
Change-Id: Ib5ce8c8490024199f82d0c093e9a7ae2de5f71f5
This change changes auto-generated RROs from DEVICE_PACKAGE_OVERLAYS
to be generated in the vendor partition, as opposed to /product where
they were generated in the past.
Note that PRODUCT_PACKAGE_OVERLAYS continue generating RRO packages
to /product, which means that a single app can be overlayed from
different partitions. These RROs have been given module and package
names based on their location.
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: I5cee70e28e3969e67b2d83eaf25d9c6e3a11102d
This is a stop-gap measure for a proper fix enforcing library "ownership" in
Soong: b/128708192
Test: m systemimage (with and without libs that exist in /system/lib)
Test: Check that this fails:
m systemimage
m out/target/product/taimen/system/lib/libjdwp.so
m systemimage-nodeps
Bug: 124293228
Change-Id: Iac0d0cec7d9e216028a0caccfbb76838514d4a7b
Due to the runtime APEX, the symbols directory now contains a symlink;
./apex/com.android.runtime -> com.android.runtime.debug (or .release).
Previously, this symlink itself was included in the symbols.zip file.
And this is causing problem to the online stack tool which does not
follow the symlink in the zip file. Instead of fixing the problem in the
stack tool side, this change let the packaging routine to follow the
symlink and copy the files behind the symlink as if they were under a
directory that isn't a symlink. (i.e.
./apex/com.android.runtime/bin/dex2oat is added)
Bug: 120846816
Test: m dist with marlin (flattened) and blueline (non-flattened)
examine symbols.zip file and check that unstripped shared libraries are
found under /apex/com.android.runtime directory
Change-Id: I1d1c787a2e8ab7209410dfa2cff749a7042e21b0
/product/etc/security/avb/system_other.avbpubkey is only needed
when BOARD_AVB_ENABLE is true. This fixes the build error of
Marlin/Sailfish.
Bug: 123611926
Bug: 129029207
Test: make
Change-Id: I73f948d84f91cd6fbe49a2de7bf12e46eebe6ede
When TARGET_VNDK_USE_CORE_VARIANT is set to true, the vendor variant of
VNDK libraries are by default not installed. Instead, the core variant
will be used by vendor binaries at runtime.
To ensure the core variant of VNDK libraries are installed, we also add
a flag LOCAL_VNDK_DEPEND_ON_CORE_VARIANT to indicate that the vendor
variant module depends on the core variant module. This flag should be
set by Soong for all VNDK libraries without the vendor variant
installed. When the flag is set, the vendor variant binary is also
compared against the core variant binary to ensure they are
functionally identical.
As we are merging the two variants for some libraries, we need a new
link type to denote a module is usable as both native:vndk and
native:platform. We add native:platform_vndk for this.
Bug: 119423884
Test: With the corresponding Soong change, build with
TARGET_VNDK_USE_CORE_VARIANT set to true.
Test: Add a dummy VNDK library and a dummy vendor binary that depends
on it. Build with no-vendor-variant VNDK and check the core
variant is installed.
Test: Add conditional compilation based on __ANDROID_VNDK__ in the
dummy VNDK library and check build fails.
Change-Id: I40000f2728e8193212113c1ee950e9d697f2d40d
This is similar to module-built-files, except that it only returns
files built for the target, not the host.
Bug: 119423884
Test: Build with the no-vendor-variant VNDK change that uses this
function.
Change-Id: I2a3d99003b05999eae01c0b90bb62b5263d65592
