The method can be used when printing string list in a well-formated way
in user-facing messages.
This will be used in a follow up change.
Test: m nothing --no-skip-soong-tests
Change-Id: I77e3445a5333f82067dd8f1bb6ad892c69754ece
To enforce that selects are only evaluated after a certain point
in a followup cl.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: Ib215fedb904aa2e5f4d65cfd26a23f527eb4983e
I'm going to be adding some methods to this interface, give it
a name based on how it's going to be used, not based on what methods
it contains.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I9bba04ba756c4dbe00625e2d04af81e78a11cae9
In the context of incremental soong, the inter-module communication
through AndroidMkEntries and AndroidMkData should be changed to
through the real provider.
This change adds the framework for the provider(AndroidMkInfoProvider).
A module will set its AndroidMkInfoProvider, which includes what's
in its AndroidMkEntries method, to be used in translateAndroidMkModule.
This change also changes module type vbmeta to use
AndroidMKInfoProvider.
The next step is to replace the AndroidMkEntries methods of all the
other module types to set the AndroidMkInfoProvider.
Test: m with tests and CI
Bug: 357907638
Change-Id: Icfd1363f97d31548bb78c6615e0f7076b22dcbe4
A target must define "USE_SOONG_DEFINED_SYSTEM_IMAGE := true" and
"PRODUCT_SOONG_DEFINED_SYSTEM_IMAGE := <name of soong system image>"
to use the soong defined system image.
The system image must install the files to $PRODUCT_OUT for adb sync
and build verification. Instead of using 'update_product_out'
property in Android.bp, copy the files only if the name of the image
matches with PRODUCT_SOONG_DEFINED_SYSTEM_IMAGE.
Bug: 350599535
Bug: 365700376
Test: lunch aosp_x86_64-trunk_staging-userdebug && m &&
m aosp_cf_system_x86_64
Test: lunch aosp_cf_x86_64_phone_soong_system-trunk_staging-userdebug
&& m
and adb sync on the cf device
Change-Id: If8673ba2855a753a5559a588bd83068d950fd7e4
It's been available for over a year, lets progress the python3 migration
by removing it.
Bug: 203436762
Test: Presubmits
Change-Id: I46a6477ec65e98b7e6df5cc1359f676dcbd0f08e
aosp/3255916 didn't add all of the required infrastructure.
Refactor it to be more like x86_64 so it requires less
boilerplate code.
Bug: 364383722
Test: presubmit
Change-Id: Idc5279ffc5fe964bea9f98873c01468944d90091
There are two versions of aosp extservices - one for Tplus and one for
Sminus. When prebuilts are active, the `contents` validation of both
variants of extservices bootclasspath fragments should be disabled to
account for BCP jar skew.
This CL adds ApexAvailableName to ApexInfo to achive that. If an
api_domain matching the ApexAvailableName has been selected in
`all_apex_contributions`, the source apex variants will be disabled.
Bug: 361771739
Test: lunch cf_x86_64_phone-next-userdebug
Test: m nothing with ag/28851886
Change-Id: I505a7ad8295c258e2eeef7f183669f7a75a1c88e
I'm rewriting how globs work in soong to make them compatible with
hash-based ninja implementations. As part of this, I'm removing this
unnecessary usage of globs to make them simpler.
In this case, since we're already globbing the directory at analysis
time and causing soong to rerun, we can ensure the aapt2 action also
reruns by putting a hash of the glob results onto the command line.
Bug: 364749114
Test: m framework-res, touch frameworks/base/core/res/assets/test1.txt, m framework-res rebuilt framework-res.apk, rm frameworks/base/core/res/assets/test1.txt, m framework-res rebuilt framework-res.apk again
Change-Id: I4f666367a9a0fd0dfa42dc51ef3a788a02b41747
This commit adds the libbpf_prog soong module which is heavily based on
the bpf soong module. Due to issues encountered and concerns around
compatibility and testability of mainlined bpf modules, support for
libbpf is added as a separate module.
Specifically, when changing the bpf module from
InitAndroidArchModule(... android.MultilibCommon) to MultilibFirst, the
soong apex bpfs functionality breaks. We have not identified a good
mechanism to fix this, and as we would then be creating architecture
specific bpf program binarys, additional testing and infrastructure
would be required.
It should be noted that libbpf_prog should not be used for features
which target 32bit kernel architectures at this point, as we do not
have a mechanism to identify the kernel arch at build time. I.E. 32bit
userspace could be on either 32bit or 64bit kernel arch, and we require
arch specific includes (vmlinux.h). Therefore, we default to 32bit
userspace on 64bit kernel to match the precedence set with the legacy
bpf programs.
Example use:
libbpf_prog {
name: "xyz.o",
srcs: ["xyz.c"],
arch: {
arm: {
local_include_dirs: ["vmlinux/arm64"],
},
arm64: {
local_include_dirs: ["vmlinux/arm64"],
},
x86: {
local_include_dirs: ["vmlinux/x86_64"],
},
x86_64: {
local_include_dirs: ["vmlinux/x86_64"],
},
},
}
Bug: 359646531
Test: manual
Change-Id: Ie58515d70abee061470cf4bb803228e00d496ac3
Signed-off-by: Neill Kapron <nkapron@google.com>
Revert submission 3235656-revert-3195743-compatibility_matrix-KLJOLWYIMW
Reason for revert: The root cause of the break is already be merged. Related changes: ag/29139095, ag/29139608
Reverted changes: /q/submissionid:3235656-revert-3195743-compatibility_matrix-KLJOLWYIMW
Change-Id: Ie23bdd343bebbd077553dc25f0bfd13539daf57a
