libvintf reads all entries from vintf directory. The apex build rule
should match with it.
Bug: 331474817
Test: build with aosp/3017012/1
Change-Id: Ida5fce2436ec5985e2fb4c2a3608bf20f4933582
1. Output the aconfig flags pb and storage files to /etc
2. Fix a bug where aconfig flags were not collected for java_sdk_library
Bug: None
Test: manual and unit tests.
Change-Id: I0896e91918c1b53c98ac9dc0f4a636f158200891
UNBUNDLED_BUILD_TARGET_SDK_WITH_DESSERT_SHA enables user to specify
${codename}.${sha} as min_sdk_version and target_sdk_version in order to
support mainline train building into android build.
Test: TH
Bug: 295905124
Change-Id: I032d464aaa7314520f98b8eafa53d962940075ce
Add a method to DataPath that converts it to the relative install path
in preparation for adding additional complexity to DataPath.
Bug: 311428265
Test: builds
Change-Id: I65b06238aafda2db72c6a253744a3087976451cd
Installed files should only depend on other installed files, change
the deps arguments of the ctx.Install* methods from Paths to
InstallPaths.
Bug: 311428265
Test: builds
Change-Id: I1ebef60a943bdbe907744cc43aa985371ac56d32
Merged-In: I1ebef60a943bdbe907744cc43aa985371ac56d32
To support trunk stable, file_contexts files should be processed before
creating APEX images. That means that file_contexts may be under out/.
This change relaxes the path check so we can use Soong-generated
file_contexts, not only the real source file_contexts. Of course the
restriction that modules should be under system/sepolicy is still
enforced.
Bug: 306563735
Test: build with generated file_contexts; see virt apex
Change-Id: I3aa368b338141d4826fc8622e1c8d2838bfd8484
It was 'vendor_apex_metadata_file', but root directories can be simply
labelled as 'vendor_file' so that linker can resolve paths in vendor
apexes.
Bug: 310528686
Test: m blueprint_tests
Change-Id: I689b23efccb7be61980e791e185fcef28a76d9bc
apex.unwanted_transitive_deps can break the APEX when any of listed deps
is actually needed. To avoid that, a new validation is added to see if
"unwanted" deps are actually not used by any ELF files in the APEX.
The new validation runs only for non-test apexes with
unwanted_transitive_deps set because test apexes can be broken
intentionally.
Bug: 295593640
Test: m com.android.virt
Change-Id: I29a3f7ef76b59594a08cfacca4811f16bf7172cc
Instead of listing all apexes in the source tree, now each apex emits
its own fragment for apexkeys.txt, which is pointed by
LOCAL_APEX_KEYS_FILE. Makefile collects apexkeys.txt from installed apex
files. This is to avoid listing unrelated apexes (not installed,
testdata, unexported namespaces, etc.)
Bug: 304914238
Test: m apexkeys.txt
Test: m blueprint-tests
Change-Id: Iefbe6e486cb418955584ad1a282455307e90be95
With aosp/2681229, assemble_vintf modifies the input, instead of
checking. APEX should use the output of assemble_vintf instead of
running it as validation.
Bug: 299034304
Test: m
Change-Id: I9446908e1df85b4f3f89d29ebe9cace3982d7757
In Make, vintf fragments are checked with assemble_vintf. Since vendor
APEXes can have vintf fragments, perform the same check with vintf
fragments in APEX.
Bug: 299034304
Test: m test.bad2.com.android.hardware.wifi
(should fail if its module type is `apex`)
Change-Id: I2f9ed50066b9b499b3562bfa51214c1e375d5747
`conv_linker_config validate` command is used to validate the linker
configuration embedded in APEX to detect common mistakes.
For example, when used in APEX, linker configuration can't set
provideLibs/requireLibs. For APEX, there are
provideSharedLibs/requireSharedLibs in APEX manifest for that purpose.
One might make mistake by setting provideLibs in linker config.
Now, when these unsupported properties are set, there'll be build-time
error like:
// set provideLibs key in com.android.art's linker config.
$ m com.android.art
...image.apex/etc/linker.config.pb: provideLibs is set. Use provideSharedLibs in apex_manifest
Bug: 264341796
Test: m com.android.art (see above)
Change-Id: Ibaf7322616ad333569e6d721680f3d72243402a2
Since we no longer support "zip" APEX, we don't need "host" support.
For example, we don't need go/python binary support.
Bug: 279835185
Test: m
Change-Id: I6e8d2b205e42662f31866dc9ac7507524effd144
This property allows modifying the variant version that is put into the
APEX manifest.
Bug: 285138555
Change-Id: I42b8c0ddad8822a0a329e99ec4ec62f8c3546ee9
Since vendor APEXes are installed in vendor partition, there shouldn't
be system_file according to Treble. Instead, we can force-label / and
/apex_manifest.pb as vendor_apex_metadata_file so that apexd (and other
system components) can still read them.
Bug: 285075529
Test: m nothing (soong test)
Change-Id: Idb36b8c4c68b29e2235dbda38ee323d4b781e1d5
For now ext4 is the only supported fs_type.
Bug: 279689445
Test: m apex.apexd_test_erosf
Test: m apex.apexd_test_f2fs
Change-Id: Idd1b2e61e25110da6d3805b082195e6ec031f573
This reverts commit 9551384f65.
5bedfee448 is a better solution for the
same problem.
Bug: 279247159
Test: m checkbuild (presubmit)
Change-Id: Ifd3117a4450b5275c09258d1ce896adb41a75158
These should be handled by Makefile dependency (LOCAL_REQUIRED_MODULES).
Bug: 278832320
Test: build and see symbol files
Change-Id: I80ad9d8e7e8384e2ae3537cc681bc1d1b327d04c
Apexer rule with symbol files causes "no build rule" error when the apex
is replaced with prebuilt.
Bug: 251299786
Test: m checkbuild (presubmit)
Change-Id: I7390f72c321beaeb49fcee4e02a219c07f184664
.. as a validation for apex.
apex_sepolicy_tests checks the contents of the apex against
precompilec_sepolicy. This is to avoid common mistakes in file_contexts.
For example, etc/vintf directory should be read-able by servicemanager.
Bug: 267269895
Test: m com.google.cf.wifi (with wrong file_contexts entry)
Change-Id: Ic363345df43e5b2108b07de787f5f6817bbe6af4
This relands aosp/2457063. The original change broke T and U since those
branches still contain soong modules of type (kind+level). Those soong
modules have been cleaned up now
Test: Used go/abtd to test T and U branches with this change
Bug: 208456999
Change-Id: I0ef7933c055f88cb512a02108f1173e51156ef1c
min_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid min_sdk_version in bp
files
Will do a similar cleanup for targetSdkVersion and maxSdkVersion in a
followup CL
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: Ie6ae7e267d093c5e4787e82685daaca1021d202e
When set true, use file_contexts file as is and do not force-label / and
/apex_manifest.pb
Bug: 268439003
Test: m (soong tests)
Change-Id: I252eef9569deeac87bb71a3425a8eb07bab3c634
Previously, the symlink optimization for APEXes assumed that the target
of the symlinks are in the system partition. The assumption however
doesn't hold always because the file that was added to the APEX might be
with system_ext_specific: true or vendor: true.
Bug: 265598720
Test: m nothing
Change-Id: Ieb9a6769320c0ec697a88c0cae977e7d65288362
This reverts commit d1209a89c7.
Reason for revert: apex_name was still in use in the internal/intermediate branch. Fixed(removed apex_name) in the internal branch.
Change-Id: I10b8e0cfdb01dcdb6b623bddf9c04f4dac71fc90
apex_name was used to install symbol files under /apex/<apex name>,
which caused duplicate rules when there's two apexes with the same
apex_name. (e.g. override_apex or multi-install apexes)
Since symbol files can be looked up via ELF Build-Id, we don't have to
install symbol files with the actual "apex name", but instead we can
install them with soong module name.
Bug: 267581665
Test: m (soong test)
Change-Id: I1cbe5c86d287f180c7deef93ba85ea5552680011
This has been a workaround to avoid duplicate build rules for
multi-install apexes. The reason for duplicate errors was that apex_name
was used to install symbol files.
We don't need to rely on apex_name for symbol files, hence no need for
the workaround.
Note that symbol files for apexes are still available via the paths
based on "soong module name".
Bug: 267581665
Test: cuttlefish (which uses multi-apex) build & run
Change-Id: Icaca667e139ef2aca32339a75b54b12a00449c2d
VNDK APEX has been using "apex_name" property to set "name" field in
apex_manifest. But setting apex_name had a side-effect of emitting
duplicate rules for symbol files for VNDK APEX and its override_apex.
(Please see the removed comments for more details about error)
Not using "apex_name" fixes the duplicate errors.
There're a few more vendor apexes with the same issue, which I will
handle in follow-ups.
Bug: 267581665
Test: m (soong test) && boot
Change-Id: I00f617cef8af4d21880d4e8b9c0b9ab9322ba15c
Since fe4ff29b4d47fa8ae242fb7e084215d3afada4b5 (in system/apex), apexer
doesn't check keyname (--key vs --manifest.name). So, passing
--do_not_check_keyname doesn't make any sense.
This is a preparation to remove (or deprecate) "apex_name" property from
"apex" module.
Bug: 267581665
Test: m
Change-Id: I3737d1e36d305375a523a23a6bbeb2d23586e578
variable.go:
add a new product variable TrimmedApex which is controlled by
environment variable PRODUCT_TRIMMED_APEX
config.go:
all config to check if trimmed build is turned on or not
apex.go:
add overridable apex module property:
use_DCLA: <DCLA apex module>
"use_DCLA" allows user to just use the lib list in DCLA to determine
which native shared libraries to trim. This property is no-op if
TrimApexEnabled is set to false.
builder.go
1, if it is to produce a trimmed variant, fix the default version code
by making the last variant digit to 2. this is only useful in local
build. in production build, there is apex manifest injection by
coastguard that determines the actual version code.
2, create a new apex rule called: "TrimmedApexRule", this rule invokes
an apexer wrapper called apexer_with_trim_preprocessing which will
properly trim the target libs.
BUG: b/259381334
TEST: adbd banchan build for both static and trimmed variant
Change-Id: I38a91cdef86a3c9185d00610ab3dd7acd07fd90a
These instances could use WriteFileRule instead of
making their own shell code to write a file.
Test: Presubmits
Change-Id: I9c809b2164a68b4ce1c22fbbd0d7497240110b39
Vendor apex with "use_vndk_as_stable:true" sets the dependency in
"requireNativeLibs: ":vndk"". But this isn't enough because the APEX
won't work if VNDK version mismatches.
Now, when a vendor apex uses VNDK libs, "vndkVersion" is set as well in
apex_manifest so that apexd can abort the installation/staging when
device's VNDK version mimatches.
Bug: 222620439
Test: VendorApexHostTestCases
Test: built vendor apex how has "vndkVersion" field in its
apex_manifest
Change-Id: If03340c230efe854ab932cdf472c276f7646ad0c
Add an option to override defaultManifestVersion using environment
variable. The environment variable will be used to override the apex
version locally when developing a desert release feature in
mainline-prod branch. Overriding the apex version in mainline-prod
branch allows us to install apex built in mainline-prod branch to device
running code from git_master which has a higher apex version than
mainline-prod branch.
Bug: b/233608815
Bug: b/196860838
Test: presubmit
Test: go test -v ./build/soong/apex/
Change-Id: I8ac2aae2b6b29da7f09db6edb893e0a0f0691e51
