Commit Graph

463 Commits

Author SHA1 Message Date
Treehugger Robot
68bfe074c6 Merge "Reland: Deduplicate APEX variants that would build identically" 2020-08-21 06:46:51 +00:00
Colin Cross
aede88c1c7 Reland: Deduplicate APEX variants that would build identically
APEX variants that share the same SDK version and updatability
almost always use identical command line arguments to build but
with different intermediates directories.  This causes unnecessary
build time and disk space for duplicated work.

Deduplicate APEX variants that would build identically.  Create
aliases from the per-APEX variations to the new shared variations
so that the APEX modules can continue to depend on them via the
APEX name as the variation.

This has one significant change in behavior.  Before this change,
if an APEX had two libraries in its direct dependencies and one
of those libraries depended on the other, and the second library
had stubs, then the first library would depend on the implementation
of the second library and not the stubs.  After this change, if
the first library is also present in a second APEX but the second
library is not, then the common variant shared between the two
APEXes would use the stubs, not the implementation.

In a correctly configured set of build rules this change will
be irrelevant, because if the compilation worked for the second
APEX using stubs then it will work for the common variant using
stubs.  However, if an incorrect change to the build rules is
made this could lead to confusing errors, as a previously-working
common variant could suddenly stop building when a module is added
to a new APEX without its dependencies that require implementation
APIs to compile.

This change reduces the number of modules in an AOSP arm64-userdebug
build by 3% (52242 to 50586), reduces the number of variants of the
libcutils module from 74 to 53, and reduces the number of variants
of the massive libart[d] modules from 44 to 32.

This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix
to always mark permissions XML files of java_sdk_library modules as
unique per apex since they contain the APEX filename, and a fix
to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes
instead of DepIsInSameApex to check if two modules are in the same
apex to account for a module that depends on another in a way that
doesn't normally include the dependency in the APEX (e.g. a libs
property), but the dependency is directly included in the APEX.

Bug: 164216768
Test: go test ./build/soong/apex/...
Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-19 10:21:17 -07:00
Pete Bentley
0c7b26e0e2 Revert "Deduplicate APEX variants that would build identically"
This reverts commit d6b2525b00.

Reason for revert: <Breaks tests - confirmed by Forrest: b/165188843>

Change-Id: I7cb68cb87522415004390c0672dc774e0067b122
2020-08-18 13:44:59 +00:00
Colin Cross
d6b2525b00 Deduplicate APEX variants that would build identically
APEX variants that share the same SDK version and updatability
almost always use identical command line arguments to build but
with different intermediates directories.  This causes unnecessary
build time and disk space for duplicated work.

Deduplicate APEX variants that would build identically.  Create
aliases from the per-APEX variations to the new shared variations
so that the APEX modules can continue to depend on them via the
APEX name as the variation.

This has one significant change in behavior.  Before this change,
if an APEX had two libraries in its direct dependencies and one
of those libraries depended on the other, and the second library
had stubs, then the first library would depend on the implementation
of the second library and not the stubs.  After this change, if
the first library is also present in a second APEX but the second
library is not, then the common variant shared between the two
APEXes would use the stubs, not the implementation.

In a correctly configured set of build rules this change will
be irrelevant, because if the compilation worked for the second
APEX using stubs then it will work for the common variant using
stubs.  However, if an incorrect change to the build rules is
made this could lead to confusing errors, as a previously-working
common variant could suddenly stop building when a module is added
to a new APEX without its dependencies that require implementation
APIs to compile.

This change reduces the number of modules in an AOSP arm64-userdebug
build by 3% (52242 to 50586), reduces the number of variants of the
libcutils module from 74 to 53, and reduces the number of variants
of the massive libart[d] modules from 44 to 32.

Bug: 164216768
Test: go test ./build/soong/apex/...
Change-Id: I0529837476a253c32b3dfb98dcccf107427c742c
2020-08-17 15:18:31 -07:00
Treehugger Robot
a07777d434 Merge "Rename ApexName to ApexVariationName" 2020-08-15 06:43:52 +00:00
Colin Cross
e07f2316b7 Rename ApexName to ApexVariationName
In preparation for reusing the same variation for multiple apexes,
rename ApexName to ApexVariationName.

Bug: 164216768
Test: all soong tests
Change-Id: I88f2c5b192ffa27acd38e01952d0cefd413222a0
2020-08-13 17:50:29 -07:00
Jeongik Cha
839fc6659c Update ApexAvailableBaseline
Remove ipmemorystore-aidl-interfaces-java in allowlist for
com.android.tethering

Bug: 146436251
Test: m nothing
Change-Id: I8b7f97d59c2fd191f467ad50a8fd66d9a5d37704
2020-08-11 13:07:18 +09:00
Jooyung Han
b0c4d3b319 Merge "apex: set ":vndk" as required for vendor apexes" 2020-07-30 00:00:44 +00:00
Paul Duffin
f91079f120 Merge "Avoid creating APEX variant for sdk member" 2020-07-29 11:33:12 +00:00
Jooyung Han
6c4cc9ce23 apex: set ":vndk" as required for vendor apexes
When a vendor APEX sets use_vndk_as_stable: true, then the apex doesn't
bundle VNDK libraries but instead it uses them from the "vndk" namespace
at runtime.

":vndk" is a pseudo-name for VNDK libraries, which is processed by
linkerconfig so that the generated linker configuration allows the
namespace for the apex to access VNDK libs.

Bug: 159576928
Test: test with a test-only vendor apex
      it runs okay with VNDK libs. (lsof shows that it opens libs from
      VNDK APEX)
Change-Id: I924ce0fea696162575f59589b8f858deddf436b3
2020-07-29 16:00:54 +09:00
Treehugger Robot
4514d96e18 Merge "Add apex.use_vndk_as_stable property" 2020-07-29 01:27:46 +00:00
Jooyung Han
df78e216a8 Add apex.use_vndk_as_stable property
Vendor APEXes(in general, APEXes for non-system partitions) which is
supposed to be tied to a specific VNDK version can set this new property
so that it excludes VNDK libs and use them from VNDK APEX (provided by
system parition).

For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should
link "vndk" linker namespace to the namespaces of these APEXes.

Bug: 159195575
Test: m (soong test added)
Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-27 11:36:52 +09:00
Yo Chiang
e812805e75 Use BaseModuleName() + SubName as apexFile.moduleName
This change fixes this error:
```
TARGET module com.android.adbd.flattened requires non-existent TARGET
module: prebuilt_libclang_rt.ubsan_standalone-arm-android
```

apexFile.moduleName is used as Make dependency name, so it should use
m.BaseModuleName() instead of m.Name(), because soong may prepend
"prebuilt_" to or mutate the output of m.Name() in other ways.

android/androidmk.go emits Android.mk modules with
`LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace
apexFile.moduleName with BaseModuleName() + <SubName> as much as
possible.

Bug: 7456955
Test: Add unit test in apex/apex_test.go
Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing
Test: Verify out/soong/Android-blueline_hwasan.mk
Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-24 20:05:20 +08:00
Treehugger Robot
13aa44fc15 Merge "Build transitive lint reports for apex modules" 2020-07-24 11:50:39 +00:00
Paul Duffin
a37eca27c8 Avoid creating APEX variant for sdk member
Previously, an APEX variant was created for a module that was a member
of an SDK just in case it had to be replaced with an APEX requested
snapshotted version of that member. That was necessary because that was
the only way to have APEX specific replacements.

Since then a new method called ReplaceDependenciesIf() has been added
which provides fine grained control over which dependencies are
replaced. This change uses that new method to handle the replacements
which allows the APEX variants to be removed.

Bug: 161928524
Test: m nothing
Change-Id: If3869dd6753dc182b099af566b20fbc9c9c6eff7
2020-07-24 11:10:10 +01:00
Jooyung Han
698dd9f007 apexDepsMutator uses WalkDeps
apexDepsMutator marks all dependencies of apex modules. Previously, it
was converted from WalkDeps() to Top-down mutator to avoid the pitfall
of WalkDeps() bug. (It did't handle multiple visits via different
paths.)

Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can
be reverted to use WalkDeps().

Even though there's no observable difference between them, I revert this
for the up-coming change, which requires different pruning strategies
per apexes.

Bug: 159195575
Test: m
Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-23 13:54:50 +09:00
Colin Cross
08dca38eb0 Build transitive lint reports for apex modules
Build and export transitive lint report zips for apex modules.

Bug: 153485543
Test: m TARGET_BUILD_APPS=com.google.android.wifi lint-check dist
Change-Id: I5a1805440452301a7e2c4ca91482b989638b54fb
2020-07-22 20:16:14 -07:00
Christopher Parsons
fef9d4b601 Merge "Install data_libs using relative_install_path property" 2020-07-21 17:26:57 +00:00
Chris Parsons
216e10a0f6 Install data_libs using relative_install_path property
Test: Added to data_libs tests
Test: Manually verified with bionic-unit-tests
Test: Treehugger
Change-Id: I28a8e08e3409f1e7c7bb72f4351310b57f35f513
2020-07-20 13:59:24 -04:00
Jiyong Park
10e926bc8d apex_set is force disabled when necessary
prebuilt_apex has been disabled when the device is configured for
flattened APEXes, sanitized, instrumented, or built unbundled. However,
apex_set which is another type of APEX prebuilt wasn't disabled for the
same conditions.

This change fixes the discripency. apex_set modules are also force
disabled when the prebuilts are not expected.

Bug: 161316762
Bug: 160933444
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m
The built image has only the flattened APEXes and the device boots

Change-Id: I6c90dfb28d565861a473a1bdce93269ec370601d
2020-07-17 12:37:16 +09:00
Martin Stjernholm
58c33f073d Do not follow prebuiltDependencyTags in APEX payload walks.
If prebuilts are active they will have the other direct dependencies
from the source modules.

Bug: 151303681
Test: m nothing
Test: `m` with prebuilts/runtime in the manifest (along with other
  fixes)
Change-Id: I1ffc7e7b528ed9db5ce6ca2ee96c9d23c6548c49
2020-07-07 18:12:41 +01:00
Treehugger Robot
0c6f111d7b Merge changes Ifd2858dd,I2585dd99,I65e7a456
* changes:
  apex: use SubName for requiredDeps
  apex: support "vendor: true"
  apex: AndroidMk writes common properties
2020-06-29 02:20:56 +00:00
Martin Stjernholm
c4fe0dd3cc Merge "Disable flattening only for unbundled apps." 2020-06-25 13:49:30 +00:00
Jooyung Han
efb184e499 apex: use SubName for requiredDeps
apexBundle keeps the required dependencies for native modules which are
external dependencies and then records it in .mk file as
LOCAL_REQUIRED_MODULES key.

LOCAL_REQUIRED_MODULES should list module name which are made of
cc.BaseModuleName() + SubName.

By the way, because a use_vendor:true apex is supposed to be installed
in /system/apex, we don't append SubName(.vendor) suffix.

Bug: 159211312
Bug: 155841765
Test: m
Change-Id: Ifd2858dda0b373110a0cd18a0c55db41f0fc2a99
2020-06-25 17:14:25 +09:00
Jooyung Han
85d61767b5 apex: support "vendor: true"
When an apex sets "vendor: true", it becomes a vendor apex.

Vendor apexes use vendor variants for native modules and are
installed in /vendor/apex.

Bug: 159211312
Test: m
Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-25 15:37:47 +09:00
Jooyung Han
dd85fd89b0 Merge "apex: add apex_manifest.pb in file_contexts" 2020-06-25 06:21:40 +00:00
Jooyung Han
14a08f5b28 Merge "apex/apk: enforce min_sdk_version of all deps" 2020-06-25 01:18:52 +00:00
Martin Stjernholm
56507b4e0d Disable flattening only for unbundled apps.
This allows the unbundled master-art branch to still use flattened
APEXes in its test builds.

Bug: 159109002
Test: art/build/apex/runtests.sh on master-art
Test: m nothing
Change-Id: I768c6b7f5afbc348cd7730e4ba96507678434778
2020-06-24 22:33:44 +01:00
Jooyung Han
580eb4fe38 apex: add apex_manifest.pb in file_contexts
apex_manifest.pb is added to payload.img by the build system and is
supposed to be read by apexd during activation.

So, it should be labeled as "system_file" so that apexd can read it
regardless of how file_contexts is defined.

Bug: 159767275
Test: add an apex with file_contexts with everything as vendor_file
      apexd should activate the apex.
Change-Id: Ie34eb7ad905828976152d67a7dfabf0add0a5de4
2020-06-24 23:00:32 +09:00
Christopher Ferris
a5d1fab176 Merge "Remove libc_scudo references." 2020-06-24 03:16:48 +00:00
Jooyung Han
749dc69af1 apex/apk: enforce min_sdk_version of all deps
Enforce min_sdk_version for every payload dependency of updatable
APEX/APKs.

android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion
for every transitive dependency from APEX/APK modules to see if it
meets the min_sdk_version requirements.

The common implementation for apex/android_app is provided in
android/apex.go.

Bug: 145796956
Bug: 152655956
Bug: 153333044
Test: m nothing
Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-06-24 02:00:33 +09:00
Colin Cross
c9ef6ee1b7 Merge "Make native_coverage clause work with ClangCoverage" 2020-06-23 03:06:53 +00:00
Christopher Ferris
f70926eef0 Remove libc_scudo references.
Test: Builds and boots.
Change-Id: Iad97159e6193f7afffd8fbc9456427eee5d150e3
Merged-In: Iad97159e6193f7afffd8fbc9456427eee5d150e3
(cherry picked from commit 1f16b27511)
2020-06-22 15:27:56 -07:00
Colin Cross
1a6acd4f39 Make native_coverage clause work with ClangCoverage
Make uses NATIVE_COVERAGE to enable gcov coverage and CLANG_COVERAGE
to enable clang coverage.  NATIVE_COVERAGE is translated to the Soong
Native_coverage product variable which triggers the native_coverage
clause in Android.bp files.  The clause also needs to be triggered
for CLANG_COVERAGE.

Rename the existing Native_coverage product variable to GcovCoverage,
and regenerate Native_coverage when either GcovCoverage or
ClangCoverage are set.

Also remove NativeLineCoverage, it wasn't doing anything differently
than Native_coverage.

Bug: 159059537
Test: m checkbuild
Change-Id: I215124a9b35a2ad50ad562079d392e3d33da11f4
2020-06-22 11:13:42 -07:00
Jooyung Han
938b593887 apex: make allowed_files prop overridable
Because override_apex can modify the contents of the base apex,
allowed_files (which describes the contents) should be overridable.

Bug: 159503079
Bug: 159392784
Bug: 158169437
Test: m (soong test added)
Merged-In: I12744b0465dc3cfc90a66643867e65b4092cd0f7
Change-Id: I12744b0465dc3cfc90a66643867e65b4092cd0f7
(cherry picked from commit faa5399b3f)
2020-06-23 02:10:46 +09:00
Paul Duffin
44b481b81b Fix check-boot-jars when a boot jar is provided by prebuilt
Previously, when a boot jar was provided by a java_sdk_library_import
module the check-boot-jars check failed because the file it depended on
was not available. In an incremental build the build failed due to the
file in the out directory not having a rule to generate it.

That was because the module was named prebuilt_<module>.<apex> instead
of <module>.<apex>. This was fixed by simply removing prebuilt_ prefix
from the name if it was present.

After fixing that the check-boot-jars still did not work properly
because it was expecting a jar file containing .class files but instead
was given a jar file containing .dex files which meant the check did
not work properly.

This was fixed by defining a new ApexDependency interface for use by
the apex/apex.go code to use instead of java.Dependency for generating
the androidmk entries. The *SdkLibraryImport type then implemented
those, by delegating to the implementation library.

Bug: 158304459
Bug: 159112414
Test: m check-boot-jars
      m checkbuild
	  manual inspection of the .jar file used by check-boot-jars to
	  ensure it contained .class files and not .dex files.
Change-Id: I545c5c9072dd472337d2f9b4dfdf08f53c981662
2020-06-17 16:59:43 +01:00
Colin Cross
a2e64e7b84 Merge "Use inclusive language in Android.bp files" 2020-06-17 01:04:26 +00:00
Colin Cross
cbd62d07d4 Use inclusive language in Android.bp files
Test: m checkbuild
Change-Id: Id9efbd99be54b191193eae1c5672230ca54cf1d2
Merged-In: Id9efbd99be54b191193eae1c5672230ca54cf1d2
2020-06-16 23:36:51 +00:00
Paul Duffin
e40383355b Merge "Let APEX build against preferred java_sdk_library_import" 2020-06-16 09:37:53 +00:00
Treehugger Robot
c41c1a9d13 Merge "Remove libnativehelper modules from whitelist" 2020-06-15 17:00:35 +00:00
Paul Duffin
eedc5d55ce Let APEX build against preferred java_sdk_library_import
If a java_sdk_library_import has a corresponding java_sdk_library then
make the java_sdk_library_import export both the xml and impl modules
created by the java_sdk_library.

Makes java_sdk_library_import consistent with java_sdk_library by
providing libraries within the same APEX access to the implementation
library instead of the stubs.

Bug: 158304459
Test: m nothing
      Test what happens when building com.android.tethering with and without
      a preferred "framework-tethering" java_sdk_library_import. Make sure that
      it does not change the generated APEX.
Change-Id: I2f4edea937ac377431a5696c92cbd467bded62ef
2020-06-15 16:57:09 +01:00
Orion Hodson
01615f36f2 Remove libnativehelper modules from whitelist
Bug: 147364041
Test: m nothing
Change-Id: I6a43511fee3feeb164e07d5620eea0564fbee302
Merged-In: I6a43511fee3feeb164e07d5620eea0564fbee302
Exempt-From-Owner-Approval: cherry pick
(cherry picked from commit 7e2354434907257f37255052d9bd08c554e263eb)
2020-06-15 13:32:14 +00:00
Jooyung Han
45a96778c1 VNDK APEX should not provide native libs
While libz has stubs for other mainline modules, it doesn't provide
stubs when it is used as a VNDK lib.

In general, VNDK libs are only for vendor modules. So, we skip them even
if they have stubs.

Bug: 155456180
Test: m com.android.vndk.current
      provideNativeLibs of the APEX should be empty
Change-Id: I22401a2b1732a8560802c5be850181682e183a8e
2020-06-15 15:14:12 +09:00
Colin Cross
440e0d0542 Use inclusive language in build/soong
Test: m checkbuild
Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 15:33:16 -07:00
Elliott Hughes
79ae341d4b Remove TARGET_PREFER_32_BIT support.
Bug: https://issuetracker.google.com/138812821
Test: builds
Change-Id: If96cccbd82ba1311165d61c947c928c6e7cd5593
2020-06-08 16:37:13 -07:00
Treehugger Robot
a5c94e1409 Merge "Allow apex module to have android_app_set as its constituent." 2020-06-05 05:52:51 +00:00
Sasha Smundak
18d98bc3e0 Allow apex module to have android_app_set as its constituent.
Fixes: 157166068
Test: treehugger & manual
Change-Id: I9f91f1b761286f489d175eb0772f78f702e8a2d6
2020-06-04 20:25:53 -07:00
Ulyana Trafimovich
5539e7b568 Revert^2 "Rename DexJar interface method to DexJarBuildPath."
This reverts commit b0dc851ff4.

Reason for revert: relanding original change. Build failures were
  caused by a race with another CL: https://r.android.com/1320920

Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Ic9016582dae7773b4d4f84a63425f1ef7a5d061f
2020-06-04 17:20:38 +01:00
Ulyana Trafimovich
c55b679e7b Merge "Revert "Rename DexJar interface method to DexJarBuildPath."" 2020-06-04 10:47:47 +00:00
Ulyana Trafimovich
b0dc851ff4 Revert "Rename DexJar interface method to DexJarBuildPath."
This reverts commit 562c240185.

Reason for revert: breaks `lunch full-eng && m checkbuild`.

Change-Id: Id7c7d6240d98afaf8edd49b6c96cd05534b784cc
2020-06-04 10:37:36 +00:00