Calling dexpreopt.GetGlobalConfig can return errors, move the checks
that don't depend on dexpreopt.GetGlobalConfig first to avoid
breaking all modules when the global config is invalid, for example
in a partial branch that is missing the BootProfileImages file.
Bug: 207813628
Test: tradefed branch builds
Change-Id: Id1689de3f1ef986a41a60622cb357edb9d323b8a
These attributed define a range for dessert releases where the jars
should be active, and included in corresponding CLASSPATH varibles by
derive_classpath.
Bug: 190818041
Test: presubmit
Change-Id: Ieb9aef29657ad0694d48a63019f93faca2678252
Artifacts that go into apexes should only be active on certain SDK
versions. There is now a need to upper bound the range to support
expressiong statements like "this jar should only run on platforms
30-31".
Bug: 190818041
Test: presubmit
Change-Id: I6985ebb671841cdd9f0f37f916267ac5ed76e4f4
This CL updates platform_systemserverclasspath,
systemserverclasspath_fragment, and
prebuilt_systemserverclasspath_fragment to write entries for
STANDALONE_SYSTEMSERVER_JARS to systemserverclasspath.pb. A new property
`standalone_contents` is aded to `systemserverclasspath_fragment` and
`prebuilt_systemserverclasspath_fragment` to list the standalone system
server jars in the APEX, and entries will be written to
systemserverclasspath.pb accordingly at build time.
To add more context, these entries will be consumed by derive_classpath
in order to generate an environment variable
PRODUCT_STANDALONE_SYSTEM_SERVER_JARS. The environment variable will
then be comsumed by odrefresh to determine what jars to preopt on early
boot.
Note that the variable should not end with "CLASSPATH" because the list
is not used by runtime as a classpath. It is just a colon-separated list
of jars. System server loads the jars separately with paths hardcoded in
the code.
Bug: 203198541
Test: manual -
1. Add some jars to PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
2. Add some other jars to PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
and standalone_contents.
3. Build an image.
4. Flash the image to a device.
5. adb shell echo \$STANDALONE_SYSTEMSERVER_JARS
6. See the correct list of jars.
Change-Id: I09a6fd1d3db85c194330da9b751702a9bf069e26
Previously it would write min_device_sdk whereas the correct name should
be min-device-sdk. This happened for all shared libs attributes.
Test: m nothing
Test: manually installed an apex with a shared lib and made sure PM used
the attributes as expected
Bug: 191978330
Change-Id: Iecf7edd6bae98c7af908d3f320f10ae4973d0396
Merged-In: Iecf7edd6bae98c7af908d3f320f10ae4973d0396
(cherry picked from commit bde653e5fd)
Perform consistency checks as per http://go/updatable-shared-libraries
These include:
* no attribute can specified can be less than T
* max-device-sdk can't be less than min-device-sdk
* min and max-device-sdk need to be at least the module's
min_sdk_version
* using on-bootclasspath-before implies that the module's
min_sdk_version is at least T or the library has min-device-sdk of at
least T
Test: m nothing
Bug: 191978330
Change-Id: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
Merged-In: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
(cherry picked from commit f9e584dd20)
We are expanding PackageManager's supported attributes and this change
enables the developer to define them in the .bp file.
Test: m nothing
Bug: 191978330
Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57
Merged-In: I01d579190fb585662086a7fc456f3b33cb89fb57
(cherry picked from commit 826863c8e0)
It is the default, and hence unnecessary to pass explicitly. This
allows some other compiler filter to be passed through BootFlags.
Test: m out/host/linux-x86/apex/art_boot_images/javalib/x86_64/boot.oat
on master-art and check that it doesn't change
Test: m droid
on master and check that
out/soong/.intermediates/art/build/apex/com.android.art/android_common_com.android.art_image/image.apex/javalib/x86_64/boot.oat
and out/target/product/vsoc_x86_64/system/framework/x86_64/boot-framework.oat
are identical.
Bug: 174746397
Change-Id: Ie281e55aaa641d5fd8dcc5c7e201c7870cc934c1
When compiling without sharding javac will prefer classes built from
source over classes in the classpath. Compiling with sharding puts
the header classes for all the sources onto the classpath, including
the sources that are not part of the current shard. Emulate the
behavior when building without sharding by putting the header jar
first on the classpath so classes are resolved from the rest of
the sources before the real classpath.
Also switch to using the header jar without static libs dependencies
merged in, as those will already be present in the classpath.
Test: m framework-minus-apex
Test: m services.core
Test: TestSharding
Change-Id: Id11b39c15d89ce70da27d746a5c7e6b603c3c0f9
Add support for installing extra files from a zip file when installing
a primary file, and use it to support installing android_app_set modules,
which install a primary APK and then an unknown set of additional splits
APKs.
Test: app_set_test.go
Test: install test android_app_set
Bug: 204136549
Change-Id: Ia92f7e5c427adcef3bcf59c82a2f83450905c01d
Extract and install the primary apk normally, and then unzip the rest
of them as a post install command.
Bug: 204136549
Test: app_set_test.go
Change-Id: I17437ff27f49df6bc91bdbbea6173b46c7d3ec4e
CompOS is an optional module so it may legitimately be omitted from
some products.
Bug: 199147668
Test: Builds if PRODUCT_ISOLATED_COMPILATION_ENABLED not set
Change-Id: I4e031ca6184d920b64f9c370d35b5525ecbe8a1f
The updated error message is more descriptive about the incompatibility
between platform_apis and sdk_version. Implemented as per the discussion
in b/204447559#17
Test: In build/soong, run go test ./java
Bug: 204447559
Change-Id: I826f0ce47313b337f1754a1b6bc11ce65c837a41
Native coverage builds create a second variant of APKs and set
PreventInstall on the non-coverage variant. Skip calling
ctx.InstallFile for APKs and in dexpreopt when PreventInstall
is set.
Fixes: 205865567
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS="*" NATIVE_COVERAGE_EXCLUDE_PATHS="art bionic/libc device external/compiler-rt external/clang external/llvm external/swiftshader/third_party/llvm-10.0"
Change-Id: I9e38ac737315db12475e8f9bfb3e0e7c0327fc06
The art tests rely on a dependency existing from
out/host/linux-x86/framework/core-oj-hostdex.jar to
out/host/common/obj/JAVA_LIBRARIES/core-oj-hostdex_intermediates/classes.jar,
override LOCAL_SOONG_INSTALLED_MODULE for the hostdex modules so that
soong_java_prebuilt.mk adds the dependency.
Test: art/tools/buildbot-build.sh --host && art/tools/run-libcore-tests.sh '--mode=host' '--variant=X64' --debug
Change-Id: I9412147fc66d5e5f0dae52d522868a37251f781e
* changes:
Revert "Temporarily add method to get java binary tool"
Move java module installation into Soong
Fix ctx.InstallFile calls for java modules
Make HostJavaToolPath use pathForInstall
cc/java modules can have .aidl files as srcs. Pass min_sdk_version to
the aidl compiler so that it can check some features against it.
For example, ParcelableHolder AIDL type is available since 31.
Bug: 205338951
Test: soong test && m
Change-Id: I7ecab913e00c9b6a3ce870dacbe9773d2ddb7e93
Java binaries and cc binaries are in the same directory again, the
separate method can be removed.
Bug: 204136549
Test: m checkbuild
Change-Id: I2e7ca82448aba5c7e54d3c3c376fe14a953ef4af
Move java module installation rules into Soong by overriding
InstallBypassMake. Update the locations that find host java tools
to look in the Make installation directory instead of the Soong
installation directory, which will no longer be used.
Bug: 204136549
Test: m checkbuild
Change-Id: I5af6d764c97e7ddb5ee121fc9830166c25d831b1
Call ctx.InstallFile on the primary install file last so that the
primary install file can depend on the extra install files, and so that
the primary install file can be inferred from the last installed file.
Add missing ctx.InstallFile calls for the dexpreopt and hostdex outputs.
Fix the install subdirectory for modules installing to the testcases
directory.
Bug: 204136549
Test: m checkbuild
Change-Id: I7edd7647be27439d3ca0ecc589ca5e89d4ba8474
Use pathForInstall instead of PathForOutput for HostJavaToolPath
so that it internally produces an InstallPath that can later support
being converted to Make installpath.
Bug: 204136549
Test: m checkbuild
Change-Id: If4f5d3552b27ffe6b9bc709c4a08d9513c49ef7d
Abandon the use of SOONG_COLLECT_CC_DEPS and SOONG_COLLECT_JAVA_DEPS,
soong can generate module_bp_cc_deps.json and module_bp_java_deps.json
without passing any variables.
BUG: 204397180
Test: rm out/soong/module_bp*json
"m nothing" should see both json files were generated.
Change-Id: If30ad5dbabb6709f834134cbc9a513a9bdc9d9de
cc binaries are moving from out/soong/host/linux-x86/bin to
out/host/linux-86/bin first, to be followed by java binaries.
Temporarily add a method that gets the java binary path while
it is different from the cc binary path.
Bug: 204136549
Test: m checkbuild
Change-Id: I04a7e741436da6be68078f23d074870413a5bb5e
We're not sure what formatting is applied to this but it sure
isn't markdown.
Fixes: 204572072
Test: Build and compare docs
Change-Id: Ib023f0cb490a7c7c5605d426ce5e70a7130d5162
Previously, the selection of system modules was duplicated, once for
source and once for prebuilts. This change dedups that by switching the
source code to use the same mechanism as the prebuilts which will ensure
consistent behavior in future.
Bug: 204189791
Test: m nothing
Change-Id: Ia1729017ae332181c95f7b205dab87fb47d43fb8
Renames to core-public-stubs-system-modules so that it is of the format
core-<sdk-kind>-stubs-system-modules.
Bug: 204189791
Test: m nothing
Change-Id: Iac565c940c2ef92be9cc64c0c6b8102a26afe0dd
Initially prebuilt stub sources only supported directories as input, but
support has been added for packaging them up in srcjar as well. However
the build action was not updated accordingly.
Add support to determine if our input is a srcjar, and if so just use
it directly.
Bug: 204978699
Test: m sdk (with prebuilts)
Change-Id: I302cd34ebd55414d35c4f936cd563a4af89b22c6
When building from source the build uses the java system modules for
the public or module APIs as needed. However, previously when building
from prebuilts it would always use the public API. That difference lead
to build failures when building from prebuilts.
This change makes the selection of java system modules when building
from prebuilts consistent with the selection when building from
sources.
As API levels 30 and 31 (which are the only previous releases to
provide system modules) did not provide separate java system modules
for the module-lib API those levels always use the public APIs.
Bug: 204189791
Test: - before applying these change
m TARGET_BUILD_APPS=framework-connectivity
- build fails with compilation error due to missing module APIs
m sdk dist
cp out/dist/system-modules/module-lib/core-for-system-modules.jar prebuilts/sdk/current/module-lib/core-for-system-modules.jar
- apply these changes
m TARGET_BUILD_APPS=framework-connectivity
- build passes as expected
Change-Id: Id113ff014e7892b1009fbcaad89b1ae23a7c3b79
Previously, system modules were only created for the public API scope.
This change creates them for any API scope as long as its directory has
a core-for-system-modules.jar.
It does that by hooking into the existing logic for creating a
java_import for all jars in the API directories and creating a
java_system_modules for every core-for-system-modules.jar file. That
avoids the need for extra path globs.
Test: m droid
m sdk_public_current_system_modules
- works as expected.
m sdk_module-lib_current_system_modules
- fails with missing target as expected.
touch prebuilts/sdk/current/module-lib/core-for-system-modules.jar
m sdk_module-lib_current_system_modules
- fails with invalid jar file as expected.
Bug: 204189791
Change-Id: I27a264941009e03439d5d847dab14a7b4f6f119f
Previously, the fixture preparer for prebuilt_apis would add a
core-for-system-modules.jar file in every API directory even though
currently they only exist in the public API directories.
This change makes the test environment more realistic by only creating
them for the public API. Rather than hard code that into the test code
(which would duplicate the hard coding in the decodeSdkDep func) this
extracts a function that is used by both. That ensures that any changes
to that func will be reflected in both the test and runtime behavior.
Bug: 204189791
Test: m nothing
Change-Id: I346ac9c0dcf407c61de16b6027663a05821bcf62
