This reverts commit a952495643.
Reason for revert: PermissionController may need to be built outside of APEX
Fixes: 148957736
Change-Id: I80a2cd666ea5028741250dd2cebf2bd7d7b331ad
apex {
name: "myapex",
native_shared_libs: ["libfoo"],
apex_name: "apex_name",
}
override_apex {
name: "myapex.override",
base: "myapex"
}
Previsouly, above wasn't supported because both APEXes have the same
apex_name and that apex_name is used as the suffix of libfoo. i.e.,
there are two libfoo.apex_name modules defined.
Now, the two apex variants of libfoo are named as
libfoo.myapex and libfoo.myapex.override.
Bug: 140136207
Test: m
Change-Id: I63f8a1de463011c6e0b97f5f6eee83103e22bc30
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Bug: 147671264
Test: m
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
apex module accepts PlatformCompatConfigIntf as prebuilt,
and places it in the etc folder of the apex.
Test: m
Test: flash device with dummy config in mediaprovider APEX -
the config is present
Change-Id: Ifc62cd262f6c6571c1bf6c2943879aa20877ecad
All commands must produce their output files, or they'll trigger
rebuilds the next build.
Test: m com.android.apex.cts.shim.v3; repeat; "ninja: nothing to do"
Change-Id: If30e9d90ce3efc0689cd04ac62cc8207f3a38dd5
Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes
the apkcerts.txt to have empty keys for those APKs, which
confuses the signing tools. Set LOCAL_CERTIFICATE for them.
Also refactor the Certificate support to avoid introducing
duplicated handling for presigned certificates.
Bug: 147765187
Test: m apkcerts-list
Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
This change fixes a bug that license info for non-flattened APEXes are
not captured in /system/etc/NOTICE.xml.gz file. For non-flatted APEXes,
we have been creating NOTICE.html.gz file by concatenating all the
license infos of the modules that contributes to the APEX and embedding
the file into the asset directory of the APEX. Then at runtime, the info
is shown through the "Google Play System Update Licenses" UI. However,
this was problematic because the UI only shows license info for the
Google-signed APEXes, leaving OEM-signed APEXes (a.k.a. optional
modules).
The problem is now fixed by associating a merged license file with each
APEX and exporting them to Make, so that the merged license files are
included in the partition level /system/etc/NOTICE.xml.gz file
regardless of whether the APEX is a Google-signed one or not.
This also fixes a bug that license info entries are created for the
runtime paths /apex/<apex_name>/<path_to_a_file>, which is not necessary
as they are already included in the license info of the containing APEX.
Bug: N/A
Test: Go to Settings->About Phone->Legal information and check
that a) /system/apex/*.apex files are shown and b) /apex/<apex_name>/*
files are not shown
Change-Id: I2c25c803b6a4c39b24bb3f724502699382fab50c
This change fixes a bug that symlinks to the system partition are
created in /system/apex/<apex_name> directories even when the APEXes are
non-flattened. The symlinks are needed only for flattened APEX (of
course regardless of whether the APEX is a primary one or not).
Bug: N/A
Test: examine /system/apex directory manually
Change-Id: I00bb1423d0a2497408f05e49767b42437210bab8
This reverts commit 230e241f58.
Reason for revert: This is a revert of a revert. Downstream problem has been fixed and have been validated locally and via Forrest build.
Change-Id: I89c51d25b3adb818ea44a983d0ac681a88790d8c
Symlinks to system libs should be created for flattened apex regardless
that it is primary or not.
For example, GSI installs non-primary flattened apexes as well. These
flattened (non-primary) apexes could be activated on non-updatable
devices.
Bug: 148195518
Test: GSI runs on P
Change-Id: I238b226473d923e03280b1b28dd0d5d1f77ae74a
This reverts commit 5df3b11f78.
Reason for revert: re-land with a fix
Fix a broken soong test
Add implicit dependency (libprofile-clang-extra) to make a test pass.
Bug: n/a
Test: m
Change-Id: I0b179199bc032501354f8e24782837453781bd8c
VNDK APEX is supposed to contain "vendor" variants of VNDK libraries.
This is different from normal APEXes which have "apex" variants.
Bug: 146758869
Test: build / flash / boot
Change-Id: I5e035678c337334092616b58d2e0e404788a6639
Exempt-From-Owner-Approval: Got ORV, but rebased with resolving merge conflicts.
This reverts commit 014a85712d.
Reason for revert: Caused vendor/google/build/build_mainline_modules.sh to fail with `Error: minSdkVersion (10000) is greater than maxSdkVersion (30)`.
Bug: 130541924
Change-Id: Ifa233bf40a674481d21b61ee816c5fdde8201080
Use codename.fingerprint format for minSdkVersion if it is unset
in the manifest and
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true.
Using a utility function in sdk.go to check whether to apply
api.fingerprint.
BUG: 130541924
Change-Id: I748a25c419033bf54b63171d334644fcd0ecc78f
This reverts commit 31c65d4fe4.
Bug: 144533348
Test: checkout master-art-host and run
ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host
the result is successful
Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
