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
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
Remove my_full_libs_manifest_deps by making AndroidManifest.xml an
implicit output of the prebuilt aar unzipping rule.
Bug: 78447299
Test: m checkbuild
Change-Id: I26934d16fd646d45bf57c9527dbb191112cb627b
Merged-In: I26934d16fd646d45bf57c9527dbb191112cb627b
(cherry picked from commit 2b5829e1a6)
The sepolicies are emulator specific and are installed
under vendor partition, move them to the right location.
BUG: 110030159
Change-Id: I6acc27a3b787a3fafd9373c84492537185b184c5
Merged-In: I6acc27a3b787a3fafd9373c84492537185b184c5
When a product adds a path requirement, the build system will verify
that all its artifacts are produced inside these paths, and fail
otherwise.
The paths are all relative to PRODUCT_OUT, and the macro also supports
giving a whitelist, for known existing offenders in the hierarchy. The
build will fail if redundant whitelist entries are present.
Example invocation:
_paths := $(TARGET_COPY_OUT_SYSTEM)/
_whitelist := root/init root/init.rc
$(call require-artifacts-in-path $(_paths), $(_whitelist))
Bug: 80410283
Test: Downstream with a new product definition.
Change-Id: I235de681f65254087a42e345af69b2113b682072
This way, the logic can be reused for multiple products during
the same build step. This will be used to track files output
by different subtrees in the product makefile hierarchy.
Bug: 80410283
Test: diff produt_FILES before and after
Change-Id: I6dd1cf586410b9809fdd9d75441128acb07cab08
Bo Hu