Include the module_api stubs in system_server one instead of
putting both of these jars on the classpath. Also rename it
to be in line with the other stubs.
Bug: 149293194
Test: m
Exempt-From-Owner-Approval: approved internally
Change-Id: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
Merged-In: Iead5af4152a49cd59a4fd7afc0312c2f0c872c1e
(cherry picked from commit bbd78556da)
This reworks CL https://r.android.com/1180134 as follows:
1) Do not reorder the list of system server jars passed from Make to
Soong via the product variable PRODUCT_SYSTEM_SERVER_JARS. This means
that for some products the order of jars on the system server
classpath may be non-optimal: a jar X that depends on Y may be
dexpreopted before Y, so that all references to the classes and
methods from Y wil be unresolved.
Unfortunately for such products, fixing the order is not a simple
matter of rearranging their PRODUCT_SYSTEM_SERVER_JARS, because the
conflicts may arise when the product-specific variable gets merged
with the common variable.
2) As a consequence of 1), do not add artificial dependencies between
system server jars: this is now impossible, as it would create
circular dependencies for those products that have non-optimal order
of jars.
3) Copy dex files for system server jars to a predefined build location.
This is necessary because at the time when Soong generates class
loader context for k-th jar, it needs to know the paths to jars 1 ..
(k-1), and it might have not processed those jars yet (so Soong can't
query the paths from the modules).
This approach is similar to the way Soong handles bootclasspath jars.
4) Do not exclude from dexpreopting system server jars that are not
Soong modules (those that are Make modules). The previous CL excluded
them because Make modules do not have ModuleContext. But it turns out
that ModuleContext is not necessary, as all the information is passed
via the dexpreopt config.
Test: aosp_walleye-userdebug boots and there are no messages in the
logcat regarding class loader context mismatch:
$ adb logcat | grep 'mismatch'
# empty
Test: Class loader contexts in the oat files for system server jars
match expectations:
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex 2>/dev/null | grep '^classpath'
classpath = PCL[]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/ethernet-service.odex 2>/dev/null | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1989208671:/system/framework/services.jar*4040443083:/system/framework/services.jar!classes2.dex*2210087472]
Test: The phone boots and logcat has no scary messages related to
class loader contexts:
$ lunch aosp_walleye-userdebug && m
$ adb reboot bootloader && fastboot flashall -w && adb wait-for-device
$ adb root
$ adb shell stop
$ adb logcat -c
$ adb shell setprop dalvik.vm.extra-opts -verbose:oat
$ adb shell start
$ adb logcat | egrep -io 'system_server: .*load.*/system/framework.*'
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1
system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
Bug: 141785760
Bug: 140451054
Bug: 148944771
Bug: 147017252
Change-Id: I33c4087f8bfacd0ecb89877aa150b75360d06710
Merged-In: I33c4087f8bfacd0ecb89877aa150b75360d06710
(cherry picked from commit a4a83b0ef9)
Exempt-From-Owner-Approval: cherry-pick.
Migrates system modules and droid stubs over to use the new API for
creating the snapshot modules and removes the old API.
Test: m nothing
Change-Id: Ia825767f1f7ee77f68cfe00f53e09e6f6bfa027f
Previously, java snapshot properties (java_library and java_test)
relied on the properties not being optimized when there was a single os
type and instead being added directly to the common os type properties.
However, that means that the behavior is inconsistent for other member
types depending on whether there was one os type or not.
This change updates the java sdk member handling to support
optimization. This involved:
1) Adding AidlIncludeDirs field to librarySdkMemberProperties to
specify the aidl include dirs instead of extracting that from the
library field.
2) Renaming jarToExport to JarToExport (in both
library/testSdkMemberProperties)to allow it to be optimized.
3) Adding MemberType() and Name() methods to SdkMemberPropertiesContext
to avoid having to store the former in the properties struct and
retrieve the latter from the library/test fields.
4) Removing the now unused library/test fields from the properties
structures.
5) Separating the processing of the jar/test config in
AddToPropertySet(...) as they may be optimized separately.
6) Ditto for the jar/aidl include dirs.
7) While doing this work I noticed that although the contents of the
aidl include dirs are copied into the snapshot the java_import does
not make use of them. Raised bug 151933053 and added TODO to track
that work.
Bug: 142935992
Test: m nothing
Change-Id: Iba9799e111ca5672b2133568163d8c49837ba9cd
Previously passing additional information to the implementations of
AddPrebuiltModule() or the SdkMemberProperties interface would have
required making changes to the API. This change added an
SdkMemberContext object into which additional information can easily
be added without requiring changes to existing implementations.
The BuildSnapshot() method was not modified because it is deprecated
and will be removed in a follow up change.
It also switches the API from passing variants as android.SdkAware to
android.Module. That is for a couple of reasons:
1) SdkAware is designed for managing the relationship between the
module and the SDK, not for generating the output snapshot. As such
there is nothing in SdkAware that is needed for generating the
output snapshot.
2) Accepting android.Module instead makes it easier to use the
underlying code for generating the snapshot module as well as the
individual member modules.
This is in preparation for a number of improvements and bug fixes in
both the snapshot creation code and implementations to address found
while trying to built the platform against ART prebuilts.
Bug: 151937654
Test: m nothing
Change-Id: Iac10f1200c0f283aa35402167eec8f9aeb65a38e
Revert submission 1254009-vdex-symlinks
Reason for revert: This causing some devices to fail to boot. See b/151836042 for details.
Reverted Changes:
Iced89071b:Expect vdex files in a target-independent director...
Ifbceb8457:Share vdex files in the ART apex between architect...
Change-Id: I5bd88f8e61d442eed921d840c90777a2750ddb16
Test: aosp_walleye-userdebug boots.
Test: Check symlinks to *.vdex files in the ART apex:
$ adb shell 'find /apex/com.android.art -name '*.vdex' | xargs ls -l'
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-apache-xml.vdex -> ../boot-apache-xml.vdex
lrw-r--r-- 1 system system 25 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-bouncycastle.vdex -> ../boot-bouncycastle.vdex
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-core-icu4j.vdex -> ../boot-core-icu4j.vdex
lrw-r--r-- 1 system system 24 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-core-libart.vdex -> ../boot-core-libart.vdex
lrw-r--r-- 1 system system 19 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-okhttp.vdex -> ../boot-okhttp.vdex
lrw-r--r-- 1 system system 12 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot.vdex -> ../boot.vdex
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-apache-xml.vdex -> ../boot-apache-xml.vdex
lrw-r--r-- 1 system system 25 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-bouncycastle.vdex -> ../boot-bouncycastle.vdex
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-core-icu4j.vdex -> ../boot-core-icu4j.vdex
lrw-r--r-- 1 system system 24 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-core-libart.vdex -> ../boot-core-libart.vdex
lrw-r--r-- 1 system system 19 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-okhttp.vdex -> ../boot-okhttp.vdex
lrw-r--r-- 1 system system 12 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot.vdex -> ../boot.vdex
-rw-r--r-- 1 system system 1229 1970-01-01 01:00 /apex/com.android.art/javalib/boot-apache-xml.vdex
-rw-r--r-- 1 system system 2043 1970-01-01 01:00 /apex/com.android.art/javalib/boot-bouncycastle.vdex
-rw-r--r-- 1 system system 2883 1970-01-01 01:00 /apex/com.android.art/javalib/boot-core-icu4j.vdex
-rw-r--r-- 1 system system 865 1970-01-01 01:00 /apex/com.android.art/javalib/boot-core-libart.vdex
-rw-r--r-- 1 system system 395 1970-01-01 01:00 /apex/com.android.art/javalib/boot-okhttp.vdex
-rw-r--r-- 1 system system 7125 1970-01-01 01:00 /apex/com.android.art/javalib/boot.vdex
Bug: 150934453
Change-Id: Ifbceb845749f4c218693f4118e8b35b59ff26de1
Follow-up to CL/1235086 which renamed the rules.
Preserve the name for target since ART tests depends on it.
Test: m dump-oat-boot-x86
Change-Id: I67c7ea9e99fea24f089d38856811bfa320258b54
This change ensures that the runtime dependencies between a
binary/shared library are correctly specified in the snapshot so that
the build can ensure that shared libraries are built before the targets
that use them.
It adds support for differentiating between references that are
required to refer to another sdk member (required) and those that may
refer to either an sdk member or a non-sdk member (optional). The
latter is used for shared library references as the libraries used by
an sdk member may be provided from outside the sdk. e.g. liblog is not
part of the ART module but is used by some members of the ART sdk.
Bug: 142935992
Test: m nothing
Change-Id: Ia8509ffe79b208c23beba1880fe9c8a92b732685
We only need documentation (javadocs) when building docs stubs,
for regular stubs, we can drop printing out all the docs.
Tested with:
touch frameworks/base/core/java/android/view/View.java && time make -j framework
Before (with just r.android.com/1254909)
Run #1 2m4.779s
Run #2 2m6.672s
Run #3 2m4.179s
Average: 125.2 seconds
After (with this patch and r.android.com/1254909)
Run #1 1m58.682s
Run #2 1m58.820s
Run #3 1m57.724s
Average: 118.4 seconds
Speedup ~6.8 seconds (5.4%)
Bug: 151160048
Test: make checkapi
Change-Id: I27eafb5a61bb9d26a74ca25f84c9daca17a8394f
Checking apex_available was missing some corner cases.
For example, the deps of share deps of cc_library modules are missed
while those from cc_library_shared are correctly tracked.
This was due to..
* calling DepIsInSameApex in WalkDeps: both work fine separately, but
when they are used together, it fails to work. It's due to how WalkDeps
works. (We might fix this bug too risky since it is used very widely)
* incorrect receiver for DepIsInSameApex in apex_deps mutator: receiver
is supposed to be parent, but child was used before. Interestingly lots
of deps are within the same group of module types(cc to cc, java to
java), it has worked. (note that receiver's DepIsInSameApex
implementation can be different).
This change fixes them by..
* walkPayloadDeps is now relying on ApexVariation, which is calculated
correctly by TopDown apex_deps mutator.
* use correct receiver for DepIsInSameApex in apex_deps mutator, which
requires for java.SdkLibrary to override the method and for
java.Library/Import to use passed dep instead of receiver to check its
membership of sdk.
Bug: 151071238
Test: build/boot
Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
This will allow us to remove the core.art image compiled in make.
Test: lunch aosp_x86_64 && m test-art-host-gtest
Bug: 147817558
Bug: 147819342
Change-Id: I864f72198d875dc1421c9c029a683bafbe7b71ac
Updates the member snapshot creation code to support multiple os types.
It basically sorts the variants by os type, then applies the code to
optimize the arch properties and then it optimizes the properties that
are common across architectures and extracts any properties that are
common across os types.
The java and cc member types needed to be modified to make the location
of the generated files within the snapshot os type dependent when there
is more than one os type. That was done by adding an OsPrefix() method
to the SdkMemberPropertiesBase which returns the os prefix to use when
there is > 1 os type and otherwise returns an empty string.
Added three tests, one for cc shared libraries, one for cc binary and
one for java header libraries.
Bug: 150451422
Test: m nothing
Change-Id: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
goma can't handle the --system argument that Android must pass to
javac.
Bug: b/143658984
Test: treehugger
Change-Id: I207668d8baa4ab28160938732a38f696aeac3f44
Adds support for handling the common arch to the sdk module type
snapshot generation code and then refactors the java_library
and java_test snapshot processing to take advantage of that.
Bug: 150451422
Test: m nothing
Change-Id: If746f375f1c4288ab6b67c7d216593b70258b043
1. Check if system sdk version of apps from product partition is one of BOARD_SYSTEMSDK_VERSIONS.
2. The logic that check system sdk version doesn't work after aosp/1212908 because it always returns early
Bug: 147711383
Test: m
Test: set sdk_version the version that doesn't exist in BOARD_SYSTEMSDK_VERSIONS, and check if it cannot build
Change-Id: I923477cffbcd9c763ee2deb5e7cce29aa005c715
Adds the accessor function for retrieving the impl/header jars to the
librarySdkMemberType structure instead of passing it into its
buildSnapshot() method.
That enabled:
* The removal of the [header/impl]LibrarySdkMemberType structs.
* The removal of their implementations of BuildSnapshot.
* Replacing buildSnapshot() with BuildSnapshot()
This will make subsequent refactoring of the SdkMemberType interface
a little simpler.
Test: m nothing
Bug: 150451422
Change-Id: I1f96986bb497cf9d9df9916e40065f66b35a4704
If an APEX contains APKs and the manifest package name of the APKs are
overridden (either via override_android_app
orPRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES), that the path to the APK
(relative in the APEX) and the overridden manifest package name is
recorded in the bundle config file.
Bug: 148002117
Test: m
Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
Remote execution and other tools can be confused by references to
build_number.txt without a dependency. Add an order-only dependency,
which maintains the current behavior.
Test: BUILD_NUMBER=1 && m aapt && aapt version # shows 1
BUILD_NUMBER=2 && m aapt && aapt version # shows 1
rm out/soong/.intermediates/frameworks/base/tools/aapt/aapt/linux_glibc_x86_64/aapt
BUILD_NUMBER=2 && m aapt && aapt version # shows 2
Change-Id: Icfa98d6840b1dc2e273ba29c33011635d1cf93b1
We plan to add boot image variants for host tests.
Distinguishing the variants by arch does not work,
since both host and device can have the same arch.
Change-Id: Iea73c77367affb074f97a0fc318389417ce537da
ike has been renamed to android.net.ipsec.ike. This commit applies
this name updates to the code coverage configuration.
Bug: 148625578
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true WITH_DEXPREOPT=false android.net.ipsec.ike.com.android.ipsec_intermediates/ contains jacoco-report-classes.jar
Change-Id: Ic46a1091899eb5bc9560739ec86a9bea08585075
hiddenapi expects that all members in a class to have corresponding hidden
API flags. However, this can't be satisfied when the java module having
the class is instrumented; JaCoCo added a few number of synthetic
members. In this case, give 'no-force-assign-all' option to the hidden
api tool so that it doesn't complain about the synthetic methods.
Also, disabling instrumenting jacocoagent itself, because it doesn't
make sense.
Exempt-From-Owner-Approval: PS3 fixes a typo in a comment. PS2 got ORV.
Bug: 149353192
Test: SKIP_ABI_CHECKS=true EMMA_INSTRUMENT=true
EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true m
out/soong/.intermediates/external/apache-xml/apache-xml/android_common_com.android.art.debug/hiddenapi/unaligned/unaligned.jar
Change-Id: Ibaf383c439945ab664e885af319548b56e2c8cb6
This reverts commit c021ea0b35.
Bug: 149353192
Change-Id: I2b1c0736202de26c5ea88c0ab14574bd7207a5fb
Test: N/A (this is a clean revert) forward fix will be followed
Apps that expect to run on older platforms should use JNI libraries
that will also run on older platforms. Require that apps that set
sdk_version have jni_libs modules that also set sdk_version, or
set jni_uses_platform_apis: true to bypass the check.
Fixes: 149591057
Test: app_test.go
Change-Id: I76b9b45fb5773bc4dfc10520108f4f3578723909
Sharding uses the header jar of all of the classes of the module
with the sources of a subset, but was incorrectly used the jarjar
version of the header jar, which may have renamed some of the
classes.
Fixes: 149969343
Test: m framework-minus-apex
Change-Id: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8
Merged-In: I568c939f8030d3ddc1e7fa8796cffcac4d6172e8
(cherry picked from commit f5a6628b27)
As a second step to removing the go/android3p instructions to copy or
to link NOTICE to LICENSE, include LICENSE files in the notices, which
will allow deleting all of the copied/linked NOTICE files.
The change causes a few additions to the system image notice files.
Test: manually built and compared before and after notices
Change-Id: Ia7bc58e2eba7bed5e63934881b5298201a93bc3e
Flow:
1. Annotation processor generates a CSV file per class as a CLASS_OUTPUT resource.
2. hiddenapi.go extracts individual .csv files and merges them into an index.csv file per module.
3. hiddenapi_singleton.go merges individual index.csv files into a combined .csv file.
In a follow up hiddenapi-index.csv would replace unsupportedappusage_index.csv
Bug: 145132366
Change-Id: I87d92f9c8d4b1cc1df526fc576ee3c2101116b58
Test: diff unsupportedappusage_index.csv hiddenapi-index.csv
Add a jni_uses_platform_api property that will be used to allow
an app that builds against the SDK to use JNI libraries that build
against platform APIs. For now it is a noop, but the next CL will
make it enforcing.
Bug: 149591057
Test: m checkbuild
Change-Id: Id7b7c8186bf0e28498a4cfb15c6a6ccc95df3679
Move the NDK modules defined in app_test.go into cc/testing.go in
preparation for using sdk_version: "current" in more tests.
Test: all soong tests
Change-Id: I80bc31225fb4562fce42781219cefbbd6affae06
Previously, there were some places where a java_system_module_import
could not be used in place of a java_system_module. That was because
the code assumed a *SystemModules type not a *systemModulesImport type.
This change introduces a SystemModulesProvider interface that is used
instead and is implemented on both types.
Bug: 142940300
Test: m nothing
ran new tests before changes to make sure they detected the issue
and after to make sure the changes fixed the issue.
Change-Id: I7b16ac5708880bdf61e6f5b1e6616c986f0ed763
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
Unit test: go test ./... -test.v -run TestOverrideAndroidApp
Unit test: python manifest_fixer_test.py
BUG: 148198056
Change-Id: Ib5ff235d2a93e88b86aec1c0b16327ea938a094d
Rename the two prefix-in-list funcs so that their usages are clearer.
Also find and replace all the code that essentially does either.
This introduces additional loops in some places, but I think the added
readability and simplicity outweighs the performance degradation, which
should be negligible anyway.
Test: m nothing
Test: TreeHugger
Change-Id: I37e2276ca0c815105ed0031f23c0b1264b480e4f
Also disable dexpreopting for host. These are necessary to avoid adding
dependencies on dex2oat in various non-platform builds where they will
break.
Since we cannot assume at least one module enables dexpreopting now,
the two dexpreopt singletons are silently disabled if there has been no
call to dexpreopt.GetGlobalSoongConfig.
Bug: 145934348
Bug: 148312086
Bug: 148319588
Bug: 148690468
Test: m
Test: env OUT_DIR=out-tools prebuilts/build-tools/build-prebuilts.sh
on the aosp-build-tools branch
Test: build/soong/soong_ui.bash --make-mode static_sdk_tools dist DIST_DIR=out-dist BUILD_HOST_static=1
on internal (cf b/148312086#comment8)
Test: build/soong/soong_ui.bash --make-mode dist DIST_DIR=out-apps TARGET_BUILD_APPS=Launcher3 TARGET_BUILD_VARIANT=userdebug
on internal without art/ and external/vixl/ (cf b/148319588)
Change-Id: I240dade7204b87fc2d12181534ab23439eca8b46
Should cut down on a bit of copying, and also required for an upcoming
CL that'll change GetCachedGlobalSoongConfig.
Test: m nothing
Bug: 145934348
Change-Id: I6bed737d9b061b5239cc603ad881f4ccd4312e43
binary module.
This uses the Once cache for GlobalSoongConfig to propagate the dex2oat
path from a module dependency to the singletons (both the one that
writes out dexpreopt_soong.config and the one that creates the
dexpreopted boot images). Unless dexpreopting is disabled altogether
through DisablePreopt in dexpreopt.config, that means:
- We must ensure at least one module registers a dex2oat tool
dependency and resolves a GlobalSoongConfig using it, or else the
singletons fail. That means we litter dex2oat dependencies in java
modules even when they won't get dexpreopted and hence don't really
need them.
- We still assume there's at least one java_library or android_app in
the build.
This relands https://r.android.com/1205730 without changes - the
necessary fixes are in the child CLs.
Bug: 145934348
Test: m
(check that out/soong/dexpreopt_soong.config points to dex2oatd64)
Test: env USE_DEX2OAT_DEBUG=false m
(check that out/soong/dexpreopt_soong.config points to dex2oat64)
Test: env OUT_DIR=out-tools prebuilts/build-tools/build-prebuilts.sh
on the aosp-build-tools branch
Change-Id: I66661711b317d1e4ec434861982919bdde19b575
dexpreopt package.
Preparation for a future CL that will need to get the make-written
GlobalConfig from within dexpreopt.
Also rename the Load*Config functions to Parse*Config, since they don't
actually load the config files anymore.
This relands https://r.android.com/1211982.
Bug: 145934348
Test: m
Change-Id: Icb9332a93811d77d2d8b06e983b92501b180a358
caching of it.
Introduce a Once cache for GlobalSoongConfig to allow it to get binary
tool paths from ordinary module dependencies (coming in a future CL)
that are then reused in singletons.
This relands https://r.android.com/1205729.
Bug: 145934348
Test: m
Change-Id: I039d6e204bee5ddc16d8e2d85057fbec20e326fe
This patch excludes non-Soong system server jars from dexpreopting.
System server jars should be dexpreopted together for better
performance: each jar should have all preceding system server jars
in its class loader context (that is passed to dex2oat and recorded
in the resulting .oat file to be used by the loader).
This means that we need a total order on system server jars. The
default order provided by PRODUCT_SYSTEM_SERVER_JARS is not good, as
it does not always respect genuine dependencies between jars (counter-
examples are rare, but non-trivial to fix: b/148219586).
This patch adds a post deps mutator pass that creates additional
dependencies and enforces global order. These are later used to
generate precise class loader contexts and system server classpath.
Test: Class loader contexts in the oat files for system server jars
match expectations:
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/com.android.location.provider.odex | grep '^classpath'
classpath = PCL[]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/services.odex | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1919890654]
$ oatdump --oat-file=out/target/product/walleye/system/framework/oat/arm64/wifi-service.odex | grep '^classpath'
classpath = PCL[/system/framework/com.android.location.provider.jar*1919890654:/system/framework/services.jar*4269704903:/system/framework/services.jar!classes2.dex*134345935]
...
Test: The phone boots and logcat has no scary messages related to
class loader contexts:
$ lunch aosp_walleye-userdebug && m
$ adb reboot bootloader && fastboot flashall -w && adb wait-for-device
$ adb root
$ adb shell stop
$ adb logcat -c
$ adb shell setprop dalvik.vm.extra-opts -verbose:oat
$ adb shell start
$ adb logcat | egrep -i 'system_server: .*load.*/system/framework'
02-03 14:14:26.912 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
02-03 14:14:26.914 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
02-03 14:14:26.914 5016 5016 I system_server: Loading /system/framework/oat/arm64/services.odex with executable: 1
02-03 14:14:26.916 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 1
02-03 14:14:26.927 5016 5016 I system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 1
02-03 14:14:26.933 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 1
02-03 14:14:26.933 5016 5016 I system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 1
02-03 14:14:26.934 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 1
02-03 14:14:26.946 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
02-03 14:14:26.947 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 0
02-03 14:14:26.947 5016 5016 I system_server: Loading /system/framework/oat/arm64/services.odex with executable: 0
02-03 14:14:26.948 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/services.odex with executable: 0
02-03 14:14:26.948 5016 5016 I system_server: Loading /system/framework/oat/arm64/wifi-service.odex with executable: 0
02-03 14:14:26.948 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/wifi-service.odex with executable: 0
02-03 14:14:26.949 5016 5016 I system_server: Loading /system/framework/oat/arm64/ethernet-service.odex with executable: 0
02-03 14:14:26.949 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/ethernet-service.odex with executable: 0
02-03 14:14:30.480 5016 5016 I system_server: Loading /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
02-03 14:14:30.481 5016 5016 I system_server: Successfully loaded /system/framework/oat/arm64/com.android.location.provider.odex with executable: 1
Bug: 141785760
Bug: 140451054
Bug: 148944771
Change-Id: Idac678dbd1f5fe0e381ce8e0e3561423f8a31389
This is to unify boot jars with system server jars:
PRODUCT_SYSTEM_SERVER_JARS and PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS
do not overlap.
Test: aosp_walleye-userdebug boots
Exempt-From-Owner-Approval: cherry-pick.
Bug: 146363577
Change-Id: If001049a46f8e9d38921dabeedbd61e971ebfe73
Merged-In: If001049a46f8e9d38921dabeedbd61e971ebfe73
(cherry picked from commit ef4358e536)
The new sdk version "system_server_current" is for system server
components that needs to use all public APIs, system APIs, module APIs,
and the system server APIs.
Bug: 146757305
Test: m
Change-Id: I24fd5af010532a110393676607dc90889f2ec17e
Previously, the .docs suffix was used for droidstubs internal modules
that generate the stubs source. The name was confusing so this change
replaces the suffix with .stubs.source to clarify the purpose of those
modules.
Bug: 148080325
Test: m droid
Change-Id: I9d7a2ab19e4a331b515408912ac8f7e8b0e1b35d
Previously a java_sdk_library_import module did not replace the
corresponding java_sdk_library module, even when it was marked as
prefer=true. That is because the java_sdk_library_import had an empty
set of sources. However, the stubs modules that are created by the
java_sdk_library_import did override the stubs modules created by the
corresponding java_sdk_library module.
That created inconsistent behavior between the cases where only the
prebuilt is available and both source and prebuilt are available and
the prebuilt is preferred. e.g. assume a java_sdk_library/import module
called SDKLIB.
When both prebuilt and source modules are available for SDKLIB then
even if the prebuilt is preferred then any dependencies on the
SDKLIB module would use the source module.
This change fixes that inconsisteny by making the array of sources
non-empty.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I25395e020393921735ada20c5492f27f1260f6c5
Prior to this change droidstubs modules that set sdk_version
did not get framework.aidl added to its aidl includes.
Bug: 149138391
Test: patch CL in bug && m system_aidl_test-droidstubs
Change-Id: I92ab344c8a4311e10c1e5c8ebf525fa2dc704075
(cherry picked from commit f278ca60e06da86c67f6a3865c290f8451657ce9)
When building java.lang classes it is necessary to compile them using
patch_module: "java.base". This change causes patch_module to be passed
through to the java_library created to compile the stubs to allow this
to be used to generate stubs for java.lang.
Test: m droid
Change-Id: I7c27953a5d782eeedd7f25e849ab444d28e28228
Adds an SdkMemberType implementation for java_system_modules. It
specifies that java_system_modules can be used with sdk as well as
module_exports, and also that the libs property should be included
as transitive members in the sdk.
It also adds support for treating appropriate tagged properties in
the snapshot prebuilts module as references to sdk members so that
they are correctly transformed when creating the versioned modules.
Bug: 142940300
Test: m nothing
Change-Id: Ic10b5a6d5b92b6018334fe876f06feaf79cc55e9
Framework and other dex files are used without image.
Test: taimen-userdebug boots when built with
DEXPREOPT_USE_ART_IMAGE=true
Test: Check logcat for checksum verification failures.
(Build ART with extra logging in OatFileAssistant.)
Test: Check that bootclasspath-checksums from some prebuilt
oat files (say input.odex) contain only one image
checksum followed by dex file checksums with
grep -az -A1 -E '^bootclasspath-checksums$' <oat-file> | \
xargs -0 echo | gawk '{print $2}'
Bug: 119800099
Change-Id: I65c2f247656e41f2c37df1ecb9e06af7dabab76e
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
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
