Switch to GSI images for arm/arm64 sdk images.
BUG: 79941736
This cl does not impact real device images
Test: make -j110 PRODUCT-sdk_phone_armv7-sdk showcommands dist \
DIST_DIR=git_master-without-vendor-linux-sdk_x86-sdk sdk_repo
Change-Id: Ia50be068cc5e5307cdf7ee3a8e11014ed8019992
Merged-In: Ia50be068cc5e5307cdf7ee3a8e11014ed8019992
Scudo is a hardened usermode allocator that is part of LLVM's compiler-rt
project (home of the Sanitizers). clang allows for -fsanitize=scudo as a
possible command line option to link the shared Scudo library to a binary.
This patch add Scudo as a potential sanitize option. Scudo is not compatible
with ASan and TSan and will be disabled if either is enabled.
Test: aosp compiled with m -j
Test: local experiment with LOCAL_SANITIZE := scudo to ensure that a test
target (mediaserver) could be linked with scudo.
Change-Id: I462843b9d5512fba2c4a3ac1a0c356ca90bce4e5
Switch a use of `ndk` to the timestamp file that `ndk` depends on
itself.
Mark more module-specific rules as PHONY.
Test: diff build-aosp_arm.ninja (stripping _kati_always_build_)
Test: Turn on --warn_real_to_phony for Kati, see fewer warnings
Change-Id: I101ced4067780e38d18820f5d916596429087e49
These had been depending on the phony target for the library
(liblz4.vendor), not the actual built file and notice file.
Since we hadn't been saving the NOTICE file, and were only assuming the
installed notice file path. save that away for use during packaging.
Test: m vndk; diff out/target/product/generic/android-vndk-aosp_arm.zip
Test: m vndk; diff out/target/product/generic_arm64/android-vndk-aosp_arm64.zip
Change-Id: If9a4bed27030b7bd464cd3987739df94d32a0037
The common mk files form a long chain of generic sounding names that
don't make much sense. For instance, embedded, base, core_minimal, core
and core_base all inherit each other, but there's no logical ordering
of these names.
The common mks will be split based on destination partition, which will
create many new files. Merging some of the common ones before this split
keeps the total number of mks under control.
There are only 2 products inheriting this mk excluding base.mk (which
has over 300 descendants). The other levels in the hierarchy all have
multiple device categories rooted at them (e.g. wearables from base.mk,
tvs and cars from core_minimal.mk), but embedded.mk has not which
makes it a compelling target to remove.
Bug: 80410283
Test: diff products variables with multiproduct_kati
Change-Id: I35c05973dfefefb7a31686476215386b8b89a557
Merged-In: I35c05973dfefefb7a31686476215386b8b89a557
Merged-In: I2e25032645c87f084f911e14fade16bc802ff457
This reverts commit 4cd1a75d17.
PackageParser no longer treats minSdkVersion=Q as targetSdkVersion=Q
when targetSdkVersion is set to a number.
Bug: 110167203
Bug: 110353795
Change-Id: Ib44743e4c49e59cd29a57af1bf885090e380b1b6
Since this is a directory separator, it causes a good deal of
strangeness in the build whenever we include a module name in a path.
It becomes particularly problematic if used together with ".."
Test: build_test on downstream branches
Change-Id: I344eca0db3346cd6ffabff767c34159c85ebc051
System image of aosp_arm products is the new GSI in Pi.
Its arch variants need to be the same as the legacy GSI built
with aosp_arm_ab so it can pass related CTS/VTS tests.
Bug: 80401108
Test: $ lunch aosp_arm-userdebug; m -j; emulator # booted OK
$ lunch aosp_arm-userdebug; m -j cts
Change-Id: I29fffca3e02a2251913a327b54640fc622e77a8d
Merged-Id: I29fffca3e02a2251913a327b54640fc622e77a8d
(cherry picked from commit b2e58893c3)
If there happen to be any dependencies added to target of $(test_config),
it'll cause problem in the autogen_config. We fix it by using $< in
the autogen command.
BUG: 109736180
Test: lunch walleye_coverage-userdebug; make adbd_test
Change-Id: I22ab100c5a3f9fa058c1edd66f9e5cfdf5b7f855
Make it so that these can be used in other scripts by moving them from
functions defined in envsetup.sh to standalone scripts.
Test: stacks zygote64
Change-Id: Id8e5ce5b4da80e57f4226eb34edaf82b87393834
Fix stacks for the change in ANR trace location by using `debuggerd -j`
instead of manually fetching the traces file.
Also, dump zygote/zygote64 as native processes, since they don't
respond to SIGQUIT.
Test: stacks zygote
Test: stacks adbd
Test: stacks com.android.settings
Change-Id: I015458bdc2dd45624940204d42614365aacf8304
installed-files*.json provides hashes of each file, which will allow
a quick comparison of what has changed between builds.
Test: m checkbuild
Change-Id: I87f6c1fa89aaa83c7bcc7cbefb799e9e26d7bfa5
Add a script that can inject a <uses-sdk minSdkVersion=""> into
AndroidManifest.xml files. This will help with merging
LOCAL_STATIC_ANDROID_LIBRARIES, because ManifestMerger treats
a missing minSdkVersion as minSdkVersion=1 and throws errors
if libraries use a larger minSdkVersion. It will also help
with cases where an app has a manifest that specifies an old
minSdkVersion, but the build system is compiling the app in
a way that is not compatibile with old devices, for example
using a newer dex format.
Bug: 110167203
Test: m java
Change-Id: Ia60d462e8af9e93c57d75f423207fa8d221b1347
Some modules have manifests that ManifestMerger doesn't like, and
don't need manifest merging. Skip manifest merger if
LOCAL_DONT_MERGE_MANIFESTS is set.
Bug: 78447299
Test: m checkbuild
Change-Id: If1a58253c62e0194a6acfd79930b9bb10978abe5
Some modules generate their own custom AndroidManifest.xml file
to $(intermediates.COMMON)/AndroidManifest.xml file. Move the
build system's location to
$(intermediates.COMMON)/manifest/AndroidManifest.xml.
This location will also be used later for finding manifest files
from LOCAL_STATIC_ANDROID_LIBRARIES dependencies.
Bug: 78447299
Test: m checkbuild
Change-Id: I345f079bdd191451333b38d882418f2f7150b1e9
Merged-In: I345f079bdd191451333b38d882418f2f7150b1e9
(cherry picked from commit 00a6348e7dfa4fafc308ab92d8e7d06dcfcd01ba)
Previously we only created these if the device set
TARGET_FS_CONFIG_GEN, however there are now other targets that want to
depend on these. Instead of having those targets conditionally depend
on them, we always create them, defaulting to blank contents (by
reading /dev/null for TARGET_FS_CONFIG_GEN).
Test: builds succeed
Change-Id: Ie95286f5a800d891022eb66cd6fefcc967000c2e
All the products that inherit from base.mk add these packages, so moving
them up the hierarchy eliminates some duplication.
DownloadProvider
idmap
libneuralnetworks
mdnsd
MediaProvider
Bug: 80410283
Test: diff all product variables with multiproduct_kati
Change-Id: I133a385b3bc64261d73f616c416f7a905675c09d
Merged-In: I133a385b3bc64261d73f616c416f7a905675c09d
Setting PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS to be non-empty will
verify that when an inherited product file makes an path requirement
claim, no files other than the ones it produces are allowed inside its
paths. This allows more rigorous control of what goes where, and
specifically stops accidental inclusion of modules in the wrong places
(which is very easy to do otherwise).
In order to enable iterative improvements to current offenders, support
for a whitelist is also added (via the new
PRODUCT_ARTIFACT_PATH_REQUIREMENT_WHITELIST property). Verification is
done that this variable corresponds to exactly the list of current
offenders.
Example use:
PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := true
PRODUCT_ARTIFACT_PATH_REQUIREMENT_WHITELIST := system/priv-app/Dialer/Dialer.apk
Bug: 80410283
Test: In a downstream CL specifying the above.
Change-Id: I58047db08bde34da21759cfc55f398892b1c809a
The com.android.location.provider.xml is removed from the
PRODUCT_PACKAGES, because xml files will be generated and installed by
soong.
Bug:77577799
Test: make -j
Change-Id: Idfbc6b09ca4337795277df8b98c73f6fd5865aff
Many Android.bp files are now no longer needed (since they
are all scanned and subdirs are deprecated), so there are many
places in a tree where they aren't hit.
This still suffers from one bug, given this directory structure:
A/B/Android.bp
A/B/C/D/Android.bp
A/B/C/
A/B/C/E/Android.bp
if you call 'mma' from 'A/B/C', then it will make
MODULES-IN-A-B.
However, for now, this change makes it so given the following
directory structure:
A/B/C/D/Android.bp
A/B/C/
A/B/C/E/Android.bp
if you call 'mma' from 'A/B/C', then it will make
MODULES-IN-A-B-C as expected (since there are no makefiles in
parent directories). This is the expected behavior in this case
and it is common in directories where Android.bps have been
removed (since they only referenced subdirs) or outside of
git projects.
The reason why this usecase is supported is so that given this:
A/B/C/D/Android.bp
A/B/C/D/include/D/foo.h
You can, from A/B/C/D/include/D/ (for instance) do an mma, and
it will still make the modules defined in A/B/C/D/ which are
presumably related to this.
This change doesn't fix mm or other binaries. In the long term,
either we should just consider mma to make the current directory
(and not look for parent directories for the above 'feature') or
we should move more of the complexity in the build system itself
so that it can intelligently find the first parent directory
which contains a makefile in a subdirectory.
Fixes: 65407300
Test: mma from following dirs
system/tools/hidl/test/hash_test/bad/hash/1.0 MODULES-IN-system-tools-hidl-test-hash_test
system/tools/hidl/test/hash_test/ MODULES-IN-system-tools-hidl-test-hash_test
system/ MODULES-IN-system
hardware/ril/ MODULES-IN-hardware-ril
Change-Id: I072d3f382d40cd360ec3d14f8f5b060a4bde9289
Bo Hu