Previously, adding java_library to an sdk required that the names of
any APEXes that transitively compiled against it were added to its
apex_available property. This change removes that requirement.
Also corrects the dependency path in the TestApexAvailable_IndirectDep
error which previously passed through "shared from static" static
dependency tags even though those are explicitly NOT followed when
checking apex_available settings.
Bug: 152878661
Test: m droid
Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
Added droidstubsArgs field to the apiscope structure to avoid
switching on api scope type.
Bug: 153443117
Test: m nothing
Change-Id: I96f0eb033d44c6a74787ba7f1523799b05a58092
The java_sdk_library code used to create droiddoc and now it creates
droidstubs but it still referenced droiddoc internally. This change
removed all the remaining references except the ones that are visible
externally.
Bug: 153443117
Test: m nothing
Change-Id: Ie883eb4590f9c091d4149d7b17d7d3d91b1b5c6a
This is to guard against the potential situation when someone adds
updatable modules to the list of boot jars by mistake.
Test: aosp_walleye-userdebug builds.
Test: Manually break the checks and observe the errors:
- move updatable module 'conscrypt' from
PRODUCT_UPDATABLE_BOOT_JARS to ART_APEX_JARS:
internal error: module 'conscrypt' from updatable apex 'com.android.conscrypt' is not allowed in the ART boot image
- add updatable module 'conscrypt' to ART_APEX_JARS
(but do not remove it from PRODUCT_UPDATABLE_BOOT_JARS):
error: A jar in PRODUCT_UPDATABLE_BOOT_JARS must not be in PRODUCT_BOOT_JARS, but conscrypt is.
- move updatable module 'framework-tethering' from
PRODUCT_UPDATABLE_BOOT_JARS to PRODUCT_BOOT_JARS:
internal error: module 'framework-tethering' from updatable apex 'com.android.tethering' is not allowed in the framework boot image
- add non-updatable (in AOSP) module 'android.net.ipsec.ike'
to PRODUCT_BOOT_JARS:
internal error: failed to find a dex jar path for module 'com.android.ipsec.ike', note that some jars may be filtered out by module constraints
Bug: 147579140
Change-Id: I25ca2f52530fcfa1f9823b2cfa3485db9c0d0db1
Revert submission 1242911-sdk_version_variant
Reason for revert: b/153394225
Reverted Changes:
Ife99745fb:Use libnativewindow for platform variant of libagq...
I1bae84c43:Use libnativewindow for platform variant of androi...
I6e6021ed3:Use stl to depend on libc++
Ife99745fb:Use libnativewindow for platform variant of libRSS...
I2c9f439b9:Fix static dependency on libprotobuf-cpp-lite-ndk
Iff2aff9cf:Set sdk_version for cc_genrules used by modules wi...
I7d72934aa:Add sdk mutator for native modules
Ief378a007:Use sdk variant of Soong modules when LOCAL_SDK_VE...
Bug: 149591340
Change-Id: I798fa902c779469c6382b6699351e5d12bf14785
Fixes: 153394225
If "v4_signature: true" is set, the v4 signature file,
named [outputApkFile].idsig
will be generated along side the outputApkFile.
Test: m nothing
Test: atest PackageManagerShellCommandIncrementalTest
BUG: 149354175
Change-Id: Ie84725a15406f96f65042ea9909460e4eb34d57f
Merged-In: Ie84725a15406f96f65042ea9909460e4eb34d57f
Make `permitted_packages` mandatory for updatable boot class
path jars. Collect the permitted_packages from those jars to
a file installed as /system/etc/updatable_bcp_packages.txt .
Test: aosp_taimen-userdebug boots.
Test: adb shell cat /system/etc/updatable-bcp-packages
Test: Manual, remove permitted_packages from framework-tethering,
build fails.
Bug: 151314205
Change-Id: I21def97ace9081e707910d449943c683189f16cf
Compiling native modules against the NDK disables platform features
like ASAN. For anything shipped on the system image there is no
reason to compile against the NDK. Add a new mutator to Soong that
creates a platform and an SDK variant for modules that set
sdk_version, and ignore sdk_version for the platform variant. The
SDK variant will be used for embedding in APKs that may be installed
on older platforms. Apexes use their own variants that enforce
backwards compatibility.
Test: sdk_test.go
Test: TestJNIPackaging
Bug: 149591340
Change-Id: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
ART tests require that "out/host/linux-x86" is included.
This requires making the dexLocations per-variant specific.
Test: m test-art-host-gtest
Bug: 147817558
Bug: 147819342
Change-Id: I7839ee15cb6dfc62508bdd3fa0f306336af17055
Reuse the generic Dist support instead of writing
custom mk rules for it. Use the new Tag support to
grab the classes.jar instead of the dexed jar.
Bug: 152618077
Test: m sdk dist
Change-Id: Id893d52cc24b66e6bd900b5062a59f3820000bcd
Merged-In: Id893d52cc24b66e6bd900b5062a59f3820000bcd
(cherry picked from commit 6bb8810c8e)
Make java_library support this mode of output, to allow
callers to dist the classes.jar file rather than the dexed
jar file.
Bug: 152618077
Test: followup CL
Change-Id: I5ba6949833a0fbb95376142aec5096ff5f084c00
Merged-In: I5ba6949833a0fbb95376142aec5096ff5f084c00
(cherry picked from commit 1e65f94a4b)
Use droidstubs for public and system stubs to provide a list of @removed APIs. As these APIs are not present in the stubs, they are not whitelisted / greylised automatically. Keep them on greylist manually.
Bug: 143864733
Test: diff out/soong/hiddenapi/hiddenapi-flags.csv
Change-Id: I4c8e6899fadfdfd1da82f6f453cc92e71aa9b78c
Implement support of dumping host boot.art.
That was not possible before because imageLocation is different on host.
This CL makes imageLocation per-variant so can access for the host variant.
Test: m dump-oat-boot
Change-Id: Id82161e4901a6b77f220238aec460b8609fd765f
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
Paul Duffin