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
It's not read outside of the function / action generation logic, so keep
it inside the function.
Test: presubmits
Fixes: 190817312
Change-Id: I0626e6c86adc584abb2a251cbc7ffb1bec2c7f59
This fixes a bug that only the primary output of an appSet is installed
when the appSet is part of a flattened APEX.
Bug: 247072627
Test: m GoogleExtServices on a device using flattened APEX.
system/apex/com.android.extservices.gms/priv-app/GoogleExtServices@TM
has these apks:
GoogleExtServices.apk GoogleExtServices-arm64_v8a.apk
GoogleExtServices-hdpi.apk GoogleExtServices-ldpi.apk
GoogleExtServices-mdpi.apk GoogleExtServices-tvdpi.apk
GoogleExtServices-xhdpi.apk GoogleExtServices-xxhdpi.apk
GoogleExtServices-xxxhdpi.apk
(before the fix, there only was GoogleExtServices.apk)
Change-Id: Icbc4dd002f856a3f751badec781ad132c423ac9b
This change fixes a bug that base APK of an AppSet is not put into the
APEX.
Bug: 236299724
Test: m nothing
Change-Id: I1010ec66d8551fcc1e2d9119be7ecdba22186607
When an app_set module is included in an APEX, we don't use its
`builtFile` which is the main APK, , but `PackedAdditionalOutputs()`
which is the zip file where all APK files (main + additional) files are
packed. We then unzip them into the corresponding directory inside the
APEX.
However, `buildFile` still has been used when constructing
canned_fs_config whose content should match with what are actually
included in the APEX. Fixing the bug by using
`PackedAdditionalOutputs()` instead.
Bug: 236299724
Test: m nothing (apex_test.go amended)
Test: follow https://buganizer.corp.google.com/issues/236299724#comment34
* mkdir for-236299724
* cd for-236299724
* repo init -u https://android.googlesource.com/platform/manifest -b
* master --partial-clone --clone-filter=blob:none
* repo sync -c -j8
* unzip -l ~/Downloads/mainline_t_2022_jun_t1004275.zip | cut -c31- | grep | xargs rm -f
* unzip ~/Downloads/mainline_t_2022_jun_t1004275.zip
* source build/envsetup.sh
* choosecombo 1 aosp_arm64 userdebug
* m com.android.extservices.gms
Change-Id: If9752c07748300dbb963568de4e879b041b0a206
Currently, DCLA is built in rapid. With new train build, DCLA will be
directly built in soong, just like a regular module, refer to
b/239679485. In old rapid built DCLA, native shared libs are placed the
following way inside apex:
/lib(64)?/foo.so/<sha256 foo.so>/foo.so
The sha256 hash is used to differentiate different libs. To ensure the
same lib placement in soong built DCLA, three changes are made:
(1) in apex.go, added an apex soong module property called
dynamic_common_lib_apex to indicate if this apex is a DCLA
(2) in builder.go, update apexRule to call into run_apexer binary
instead of apexer binary. run_apexer binary is a wrapper of apexer
binary. If it is DCLA, the wrapper binary will place the native
shared libs in desired location and update canned_fs_config accordingly.
TEST: manuualy added this field to adbd. Local build by banchan
and then inspect the payload image contensts. All libs are proprely
placed.
BUG: 241096765
Change-Id: I2a5e7ea75a6e9a7af1932ff7dccb9dc3a3785db9
The default version needs to be used by both apex and apk updatable
modules. Moving it to android package so it can be accessed without
circular dependencies.
Test: presubmit
Bug: 231691162
Change-Id: Icafd50d0b065e89a115ae9c9b6ea55adf2730b49
Merged-In: Icafd50d0b065e89a115ae9c9b6ea55adf2730b49
