Commit Graph

429 Commits

Author SHA1 Message Date
Jiyong Park
2d6d5d8995 Merge "Permissions XML file for java_sdk_library is mutated for APEX" 2020-02-19 23:57:14 +00:00
Jiyong Park
e383388f98 Permissions XML file for java_sdk_library is mutated for APEX
This change fixes a regression that was introduced with
I597bccbb177b6b6320c3a3edeff467243230d384. With the change, the content
of the permissions XML file for a java_sdk_library was determined before
the java_sdk_library is mutated for an APEX. As a result, the file path
to the implementation jar library was always set to
/system/framework/*.jar regardless of whether the java_sdk_library is
part of an APEX or not.

This change fixes the problem, by creating the permissions XML file via
a new module type. The content of the xml file is determined after the
xml file is mutated for APEXes.

Bug: 149600642
Test: m

Change-Id: Id21f8d8285df49b0b3be1daf0f101f2bc978eeb0
2020-02-19 09:47:37 +09:00
Peter Collingbourne
dc4f986b2a Statically link the unwinder into binaries packaged into an unbundled APEX with legacy_android10_support: true.
Bug: 149075752
Test: tapas com.android.conscrypt com.android.tethering arm64
Test: m out/target/product/generic_arm64/{,symbols/}apex/com.android.{tethering,conscrypt}/lib64/libc++.so
Test: Verified that unwinder was dynamically linked to tethering's
Test: libc++ and statically linked to conscrypt's.
Test: lunch flame-userdebug && m
Test: Verified that unwinder was dynamically linked to /system/lib64/libc++.so
Change-Id: I98eed7cb4316962b19b5c12e150c224c25d0e91d
2020-02-13 22:29:44 -08:00
Jeffrey Huang
7d8ecd0bc1 Merge "Remove liblog from whitelist" 2020-02-14 00:45:22 +00:00
Treehugger Robot
680afd7bc7 Merge "apexDepsMutator is a top-down mutator" 2020-02-13 22:29:23 +00:00
Jeffrey Huang
f0ae6ccaa7 Remove liblog from whitelist
Bug: 145923087
Test: m -j
Change-Id: Ib1b711c01262ce9466cdd49daa3cc7142376004c
2020-02-13 12:33:39 -08:00
Jeffrey Huang
9401b187f8 Update apex.go to remove libutils
Bug: 145922701
Test: m -j
Change-Id: I13078f43129a7a9478b9bb97bb94c2c70fdb148c
2020-02-12 17:35:59 -08:00
Jiyong Park
f760cae41b apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }

apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.

libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.

As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.

Fixing the problem by changing the mutator a top-down one.

Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-12 17:01:26 +09:00
Treehugger Robot
4e29184a4e Merge "Update apex dependency even for test and non-installable APEXes" 2020-02-12 07:45:47 +00:00
Treehugger Robot
6655756230 Merge "Automatically set compile_dex:true and hostdex:true for APEX variants" 2020-02-12 05:35:25 +00:00
Jiyong Park
6b21c7d2ab Automatically set compile_dex:true and hostdex:true for APEX variants
... unless they are turned off explicitly.

Bug: 147221965
Test: m
Change-Id: I6b91d6409d9cf06ad09467c53d5d51a9c693256e
2020-02-12 10:47:36 +09:00
Jiyong Park
2bb26d3fad Merge "<apex_name>-deps-info correctly tracks dependencies" 2020-02-12 00:47:21 +00:00
Treehugger Robot
45f3c9b6a6 Merge "m <module_name> builds <module_name>.<apex_name>" 2020-02-12 00:35:55 +00:00
Jiyong Park
ab872e0295 Update apex dependency even for test and non-installable APEXes
The apex dependency map wasn't updated for test or non-installable
APEXes to work around the problem that a module being in such APEX
prevented the module from being installed in the system partition.

Since that problem is not happening any more, removing the unnecessary
work-around.

Bug: 123892969
Test: m
Change-Id: I43e07a9611a3e08ff39b9a64454b1c67949d35bc
2020-02-12 07:45:16 +09:00
Steven Moreland
7072100760 Merge "rm libbinderthreadstate" 2020-02-11 18:45:39 +00:00
Jiyong Park
31af2678fe m <module_name> builds <module_name>.<apex_name>
When a module is not available for platform (i.e.
//apex_available:platform is missing in the apex_available property), m
<module_name> previously just didn't work because there is no platform
variant of the module.

This change fixes the behavior; regardless of whether the platform
variant is available or not, m <module_name> builds all the apex
variants of the module along with the platform variant if it exists.

Bug: 147728094
Test: m conscrypt
Change-Id: Iedd3fa6fc0ed779c5f7c5d65f23d86f799ac0cbe
2020-02-11 09:44:06 +09:00
Jiyong Park
fce0b4209f Document apex and apex_test
Bug: 149082647
Test: m
Change-Id: I39e72eecda1d0e2984a3dde4987c4928f58d2afc
2020-02-11 03:56:06 +09:00
Jiyong Park
58b5030e30 Merge "add walkPayloadDeps" 2020-02-10 05:20:59 +00:00
Jiyong Park
22f3ce1ea7 Merge "<apexname>-installed-file.txt shows symlinks" 2020-02-10 03:44:00 +00:00
Jiyong Park
bd63a108a0 <apexname>-installed-file.txt shows symlinks
Bug: 147605944
Test: m and inspect the generated txt files
Change-Id: I26ecaf66a531478d22fb4611bb4ea19e92ef132e
2020-02-08 17:18:03 +09:00
Steven Moreland
14850a5139 rm libbinderthreadstate
This library is empty, and its functionality has moved
into libbinder/libhwbinder.

Bug: 148692216
Test: N/A
Change-Id: I5874efda9ab43fc00cf90395a1aabde45cf49579
2020-02-07 16:22:28 -08:00
Treehugger Robot
9be2556d90 Merge "java_sdk_library - Allow it to be replaced by prebuilt" 2020-02-07 11:16:41 +00:00
Jiyong Park
678c881a4f <apex_name>-deps-info correctly tracks dependencies
The APEX dependency is more correctly tracked. Previously, the
dependency was tracked while we gather modules that will be installed to
an APEX. This actually was incorrect because we skipped many dependency
types that we don't need to follow to gather the modules list, such as
the headers dependency.

Now, the dependency is tracked directly when a module is mutated for an
APEX. In other words, if a module is mutated for an apex X, then the
module will appear in the X-deps-into.txt file.

This change also changes the format of the txt file. It now clearly
shows why a module is included in the APEX by showing the list of
modules that depend on the module.

Bug: 146323213
Test: m
Change-Id: I0a70cf9cce56e36565f9d55683fdaace8748a081
2020-02-07 18:53:12 +09:00
Jiyong Park
201cedd608 add walkPayloadDeps
The function visits dependencies of an APEX that contribute to the
payload. checkApexAvailability is rewritten using the generic function.
There is no change in behavior.

Bug: N/A
Test: m

Change-Id: I1a8b4eb0a60a432f667a61b4f6f457c3b8f1cd3d
2020-02-07 18:48:26 +09:00
Treehugger Robot
570147469f Merge "Do not add bootstrap libs as providing from apex" 2020-02-07 07:23:14 +00:00
Jiyong Park
f48392279c Merge "Don't use apexName where apexBundleName is expected" 2020-02-07 05:41:26 +00:00
Jiyong Park
a594801999 Don't use apexName where apexBundleName is expected
With I63f8a1de463011c6e0b97f5f6eee83103e22bc30, a flattened APEX is
installed to /system/apex/<apexBundleName> not /system/apex/<apexName>.
The change was to be in sync with the non-flattened APEXes that are
installed to /system/apex/<apexBundleName>.apex.

apexName is from the 'name' property while apexBundleName is from the
'apex_name' property. The two names are mostly the same, but can be
different, notably for the ART and the VNDK APEXes. e,g apexName =
com.android.art, apexBundleName = com.android.art.release.

However, there was a bug in the fix; we haven't updated the path for the
flattened APEXes in other places: filecontexts and symlinks. As a
result, the files for the APEXes where apexName is different from
apexBundleName were incorrectly labeled and caused a boot loop.

Fixing the bug.

Bug: 140136207
Bug: 149013536
Test: m
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m; then inspect the built
system.img to verify that
/system/apex/com.android.vndk.current/lib/libcrypto.so is correctly
labeled as system_lib_file.

Exempt-From-Owner-Approval: cherry-pick from internal

Merged-In: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
(cherry picked from commit be95e6b245)
Change-Id: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
2020-02-07 13:20:13 +09:00
Paul Duffin
e74ac73bc9 java_sdk_library - Allow it to be replaced by prebuilt
Previously, a java_sdk_library called "SDKLIB" would create a
prebuilt_etc module called "SDKLIB.xml" which installs the generated
XML permission file to /etc/permissions/SDKLIB.xml. That module
depended on the java_sdk_library "SDKLIB" to generate the XML file
as one of its outputs by specifying srcs: [":SDKLIB{.xml}"].

If the java_sdk_library is replaced by a prebuilt then the SDKLIB.xml
module expects the prebuilt to provide the XML permissions file which
it doesn't because that is an implementation detail and so the build
breaks.

A couple of alternative approaches were looked at to fix this. One was
to have the logic that replaced the source module with the prebuilt to
inform the source module that it was being replaced so it could disable
its created module. That lead to a dependency cycle where
    SDKLIB -> SDKLIB.xml -> SDKLIB{.xml}

Another solution was to mark dependency tags in such a way that the
prebuilt could automatically identify and disable the SDKLIB.xml
module. Similar to how the visibility code will ignore dependencies
that are tagged with ExcludeFromVisibilityEnforcementTag. That became
very convoluted.

Instead the java_sdk_library was changed so that it was not responsible
for creating the XML permissions file. Instead it created a genrule
called "gen-SDKLIB.xml" to create it and then "SDKLIB.xml" depended on
that. The java_sdk_library also depended on the genrule to make the XML
permissions file available for APEX and testing.

Some refactoring of the APEX code and tests was necessary because they
had knowledge of the internal implementation of java_sdk_library. The
refactoring insulates them a little better from those details.

Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I597bccbb177b6b6320c3a3edeff467243230d384
2020-02-06 15:58:05 +00:00
Jooyung Han
faa2d5f0e5 Do not add bootstrap libs as providing from apex
Currently, com.android.runtime provides libc/libm/libdl to system. But
they are supposed to be used from symlinks under /system/lib not
directly from runtime apex.

This helps linkerconfig to generate ld.config.txt automatically for
apexes.

Bug: 144664390
Test: m com.android.runtime
      deapexer info com.android.runtime.apex

Change-Id: I1620e88e489fba88a06cc3bd6eb5b86a9b581e4f
2020-02-06 17:42:40 +09:00
Jiyong Park
0f80c1848a apex_available tracks static dependencies
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.

Exempt-From-Owner-Approval: cherry-pick from internal

Bug: 147671264
Test: m

Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
(cherry picked from commit fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-02-06 14:45:08 +09:00
Treehugger Robot
22b08b4af6 Merge "Use module name as the suffix for apex variant" 2020-02-06 04:22:22 +00:00
Jiyong Park
db334861b2 Use module name as the suffix for apex variant
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
2020-02-06 10:54:30 +09:00
atrost
6e12625c0f Add support for compat config in APEX.
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
2020-02-05 13:33:50 +00:00
Treehugger Robot
86ef38cfbf Merge "Add native_coverage to product variables" 2020-01-31 03:12:22 +00:00
Treehugger Robot
f9192060bd Merge "Set LOCAL_CERTIFICATE for flattened apex APKs" 2020-01-29 17:42:51 +00:00
Ulyana Trafimovich
28e36b1455 Merge "Store uncompressed and aligned DEX files for java libs in APEXes." 2020-01-29 10:25:33 +00:00
Treehugger Robot
70b0162472 Merge "Fix rebuilding with whitelisted_files" 2020-01-29 01:54:06 +00:00
Dan Willemsen
81e43c5994 Fix rebuilding with whitelisted_files
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
2020-01-28 15:40:19 -08:00
Colin Cross
503c1d06e8 Set LOCAL_CERTIFICATE for flattened apex APKs
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
2020-01-28 14:03:08 -08:00
Treehugger Robot
76fde9212a Merge "License info for APEXes are correctly gathered" 2020-01-28 18:56:47 +00:00
Jiyong Park
19972c7935 License info for APEXes are correctly gathered
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
2020-01-28 17:20:45 +00:00
Jiyong Park
7aa3f76696 Remove unnecessary symlink for non-flattend APEXes
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
2020-01-28 16:51:34 +09:00
Colin Cross
d9a121ba2a Add native_coverage to product variables
Allow native_coverage to adjust sources in product_variables.

Fixes: 148088129
Test: m checkbuild
Change-Id: I9c9d491cda92d69726a0d598408de2060241365b
2020-01-27 16:09:57 -08:00
Ulya Trafimovich
f491dde8ea Store uncompressed and aligned DEX files for java libs in APEXes.
Test: aosp_walleye-userdebug boots.

Test: In internal, cherry-picked this CL, walleye-userdebug boots.

Test: In internal, ensure that DEX file wifi-service.jar in the
  com.android.wifi APEX is now stored uncompressed:

    $ zipinfo out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar
    Archive:  out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar
    Zip file size: 3086879 bytes, number of entries: 3
    -rw----     2.0 fat  3086304 b- stor 08-Jan-01 00:00 classes.dex
    -rw----     2.0 fat      339 b- defN 80-Feb-01 00:00 META-INF/proguard/androidx-annotations.pro
    -rw----     2.0 fat       45 b- defN 08-Jan-01 00:00 META-INF/MANIFEST.MF
    3 files, 3086688 bytes uncompressed, 3086480 bytes compressed:  0.0%

  Before the change it was:

    $ zipinfo out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar
    Archive:  out/target/product/walleye/apex/com.android.wifi/javalib/wifi-service.jar
    Zip file size: 1241938 bytes, number of entries: 3
    -rw----     2.0 fat  3086304 bl defN 08-Jan-01 00:00 classes.dex
    -rw----     2.0 fat      339 b- defN 80-Feb-01 00:00 META-INF/proguard/androidx-annotations.pro
    -rw----     2.0 fat       45 b- defN 08-Jan-01 00:00 META-INF/MANIFEST.MF
    3 files, 3086688 bytes uncompressed, 1241526 bytes compressed:  59.8%

Bug: 148099857
Bug: 146984232

Change-Id: Ia302967b280be85665032cc870c5d5d2419586fc
2020-01-27 10:19:10 +00:00
Baligh Uddin
cf0bba7a30 Merge "Revert "Revert "Allow codename.fingerprint format for minSdkVersion""" 2020-01-25 04:12:30 +00:00
Baligh Uddin
f62013736a Revert "Revert "Allow codename.fingerprint format for minSdkVersion""
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
2020-01-24 23:15:44 +00:00
Treehugger Robot
8c94763bf7 Merge "Fix symlinks to system libs for flattened apex" 2020-01-24 08:32:05 +00:00
Jooyung Han
75de261056 Fix symlinks to system libs for flattened apex
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
2020-01-24 02:02:45 +09:00
Jooyung Han
a57af4adc0 Revert "Revert "apex_vndk uses vendor variants only""
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
2020-01-23 14:48:29 +09:00
Jooyung Han
7dfb229936 Merge "Revert "apex_vndk uses vendor variants only"" 2020-01-23 05:34:42 +00:00