This change is a no-op change. It doesn't enable userfaultfd GC by
default. ENABLE_UFFD_GC=true can be passed to the build system to enable
userfaultfd GC for testing purposes.
Bug: 242553398
Test: -
1. lunch aosp_oriole-userdebug
2. ENABLE_UFFD_GC=true m
3. See "--runtime-arg -Xgc:CMC" in .invocation files.
Change-Id: I789b49a71b9604fd41bf1ef77d0ac5bac4cbdf25
Bug: 245383870
Bug: 155630745
Test:m nothing
Test:-
1.Add a jar installed in the system_ext partition toSYSTEMSERVERJARS
(e.g.b/245383870 PRODUCT_SYSTEM_SERVER_JARS_EXTRA += system_ext:oem-services)
2.Build a ROM
3.See the odex and vdex files generated in $ANDROID_PRODUCT_OUT/system_ext/framework/oat/
4.Flash the ROM to a device
5.Check the maps information of the system_server , the newly added odex has the r-xp flags
6.Run `adb shell am restart;adb root;adb shell setprop dalvik.vm.extra-opts
-verbose:deopt,heap,jit,oat,image,dex,verifier;`
7.Check ClassLoaderContext classpath size matching information
8.Run `atest art_standalone_odrefresh_tests`
`atest art_standalone_dexpreopt_tests`
`atest CtsSdkExtensionsTestCases`
Change-Id: Ib1083ee130b5fef9c23d56523868fa1e29be879a
Signed-off-by: liulvping <liulvping@xiaomi.com>
The motivation is to reduce file size and in-process memory footprint
for "services" (which is currently the only system server jar that has a
profile). For other system server jars that have no profile keep using
"speed", as enabling "speed-profile" for them would completely disable
AOT-compiled code.
Compare .odex file size:
- before: 44360 services.odex
- after: 24968 services.odex
Bug: b/237399630
Test: lunch aosp_sargo-userdebug && m
Change-Id: I844b9607c496d3d6e7048dc6bb8cd958ecbaa441
Standalone system server jars are dynamically loaded by system server
using a `PathClassLoader` whose parent is `SYSTEMSERVERCLASSPATH`. They
are listed in `PRODUCT_STANDALONE_SYSTEM_SERVER_JARS` and
`PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS` in Makefile. We need to
dexpreopt them to achieve better performance.
Bug: 203198541
Test: m nothing
Test: -
1. Add a standalone system server jar (e.g., by patching
aosp/1906158)
2. Build a system image.
3. See the odex and vdex files generated in
$ANDROID_PRODUCT_OUT/system/framework/oat/
4. Flash the image to a device.
5. Run `atest art_standalone_dexpreopt_tests`.
Change-Id: I358a62d34989c5c8eba12e18fe6167e0b72ff69d
This change adds a Soong module that stores the paths to the compilation
artifacts of system server jars in a variable, which will then be
consumed by Make to check if the artifacts are installed. When the check
fails, it means that dexpreopting is not working for some system server
jars and needs to be fixed.
Bug: 201371822
Test: m nothing
Test: manual -
1. Add "service-permission" to DEXPREOPT_DISABLED_MODULES (https://cs.android.com/android/platform/superproject/+/master:build/make/core/product_config.mk?q=DEXPREOPT_DISABLED_MODULES)
2. m nothing
3. See the error:
Missing compilation artifacts. Dexpreopting is not working for some system server jars
Offending entries:
system/framework/oat/x86_64/apex@com.android.permission@javalib@service-permission.jar@classes.odex
system/framework/oat/x86_64/apex@com.android.permission@javalib@service-permission.jar@classes.vdex
Change-Id: I4816f19668f1dae180a34adafdbfa448c97aa0db
This is necessary in order to expose the copy rule to Ninja. Otherwise
Ninja has a build rule that depends on the copied jar (namely, dexpreopt
commands for all subsequent system server jars that have the current one
in class loader context), but no rule that creates it, so Ninja fails
with a "no rule to make ..." error.
The change only affects system server ed in Android.mk
Previously the problem existed, but was hidden by the fact that the only
system server jar defined in Android.mk was the last one on the list, so
no other jar depended on it. Now that updatable apex jars are also
dexpreopted (https://r.android.com/1828115) the problem was uncovered.
Bug: 200297762
Test: lunch bertha_x86_64-userdebug && m
Change-Id: Idbf2eacdf7ae89847aa9d755ef688eda3720ce89
This reverts commit 92346c4832.
Reason for revert: Fixed build error.
The build error is fixed by ag/15841934. This CL remains unchanged. This
CL will be submitted AFTER ag/15841934 is submitted.
Bug: 200024131
Test: 1. Patch this CL and ag/15841934 into internal master.
2. sudo vendor/google/build/build_test.bash
Change-Id: I5f2b8357846fc7dda56e25ebe6ffb095e8047ec8
The path to the artifacts will in the form of
/system/framework/oat/<arch>/<encoded-jar-path>@classes.{odex,vdex,art},
where <encoded-jar-path> is the path to the jar file with "/" replaced
by "@". For example,
/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
There will be a follow-up CL to update ART runtime to recognize
artifacts in that path.
Test: m com.android.art
Bug: 194150908
Change-Id: Ic89fd63c4b1cd565684cead83fc91dae3bc97a4c
This special-casing is actively unhelpful nowadays, as it breaks
callstack unwinding and symbolisation by tools that work using the
on-device debug info (e.g. perfetto's profilers). It's also highly
surprising that eng builds have less debug info than userdebug/user.
As far as I can tell, the history behind this case is (with some
internal-only references as the context is in the review comments): the
minidebuginfo was originally rolled out in device-specific makefiles
(e.g. ag/2433691). Eng builds were excluded, presumably due to time/size
concerns for rebuild+resync workflow, as well as the assumption that
engineers using eng builds already have the necessary debug info
off-device. Later, as some more makefile variables were introduced, the
conversation in ag/990059 shows that the overheads were no longer a
concern, and the last patchset generalised the option to include eng
builds. However at a later point, during device-specific makefile
cleanup, the eng-exclusion got restored: ag/2455645. This then ended up
in the makefile->soong transition, leaving us with the current special
casing that is undesireable.
Checking things with an internal master build on my workstation:
dexpreopting system services is 10s regardless of this minidebuginfo
flag, and the resulting odex size is 37MB vs 38MB. Overall, I only see 4
dexpreopt invocations as part of a local build, so the effect of this
patch should be negligible.
Bug: 194835631
Change-Id: I80de75a84259c056cdae0696fe611afe7e0162f5
For running dex2oat on the target_files, the paths should be use the
device install path instead of the path starting with $(OUT).
So add usesTargetFiles option and basePath option which indicates
extracted path. With those options, the path is replaced with
$(basePath)/$(device path)
And also, add DexPreoptImageDeviceLocations in the config which refers
to the boot image path(without arch) on the device. Because
DexPreoptImage related device path was missing.
Bug: 158843648
Test: dexpreopt_gen -usesTargetFiles -basePath (extract path) and then
check if paths in the generated shell script are based on on-device
path.
Change-Id: I9667fadbf3b7c6f770e0d1bcbee5d67c1ecd8a3d
Add 'host' into the name of fields regarding path on the host side to
distinguish between paths on the device(which will be added in the
following commit), and paths on the host.
Bug: 158843648
Test: build and flash, and then
adb wait-for-device \
&& adb -s $S root \
&& adb -s $S logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
Change-Id: Ib2645ed51591ba2f4b726c115b401ad2bd6675da
Consistent with plumbing of boot jars. SystemServerJars only support /system/framework/ jars.
Bug: 180105615, 155630745
Test: m && launch_cvd
Change-Id: I58b005b7c4103c8e250090e995b1d9b2f9ed4a76
This fixes a discrepancy between clean and incremental
builds exposed by
https://android-review.googlesource.com/1671710 .
Test: m
Bug: 148067697
Change-Id: I0de078045075417a4123f7c3821c723f1e8e6b68
Dexpreopt uses AAPT to parse `targetSdkVersion` from the manifest, so it
the generated dexpreopt.sh script that calls AAPT must depend on it,
otherwise AAPT might not be built by the time it is used. Tool
dependencies are handled via the global Soong config and the
DEXPREOPT_GEN_DEPS variable that Soong generates for Make. This config
always uses Soong tool paths, like out/soong/host/linux-x86/bin/aapt
rather than out/host/linux-x86/bin/aapt.
This CL fixes a mistake in dexpreopt rule that used context-dependent
AAPT path (so, when called from Make, the dependency was on Soong tool,
but a Make tool was actually used, so it failed sometimes).
Bug: 132357300
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I1f0ab4afac98e6239f324e7f3571d670fd7a36cd
There are modules that would have passed verify_uses_library check, but
don't run it for some reason (the check gets enabled either with an
explicit setting, or if the module has nonempty <ues-library> lists in
the build properties). Previously all such modules were assumed to have
empty CLC, which is not always true. In particular, compatibility
libraries are ignored, which affected e.g. Calendar and messaging apps.
This CL gives such apps a chance to have correct CLC. The goal for the
future is to enforce verify_library_check by default.
Bug: 132357300
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: Iea3be0fc9d7775c52950848b5a3fd3b7fcd36c53
Previously there were two different scripts that did similar things:
1) build/soong/scripts/manifest_check.py
2) build/make/core/verify_uses_libraries.sh
Both scripts extracted <uses-library> tags and `targetSdkVersion` from
the manifests of Java modules, but 1) worked for XML manifests, and 2)
worked for APKs. This CL reimplements the functionality from 2) in 1),
so that one script can handle both XML manifests and APKs.
Bug: 132357300
Test: lunch cf_x86_64_phone-userdebug && m && launch_cvd \
adb wait-for-device && adb root && adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty grep output, no errors
Change-Id: Id1b66e4f3f30f307dba70cb111c7571762cb546a
In cases when class loader context cannot be computed at build time and
verify_uses_libraries check is relaxed (RELAX_USES_LIBRARY_CHECK=true)
dexpreopt uses a special compiler filter that suppresses AOT-compilation
to native code and applies only those optimizations that do not require
class loader context. Previously the "extract" filter was used. Now ART
supports using "verify" filter in this configuration.
Bug: 132357300
Test: lunch cf_x86_64_phone-userdebug && m && launch_cvd \
adb wait-for-device && adb root && adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty grep output, no errors
Change-Id: Id4933aa94ea96894278355283383c16d103e98c9
The new mode is enabled with environment variable
RELAX_USES_LIBRARY_CHECK. If the variable is set to true, then a
verify_uses_libraries check failure does not fail the build, instead it
sets a special compiler filter "extract" for dexpreopt, which means that
the DEX file will be extracted, but it won't be compiled to native code.
Class loader context will be set to empty in this case (not &, as it is
going to be deprecated soon).
If the variable RELAX_USES_LIBRARY_CHECK is unset or set to something
other than "true", then the old behaviour of the verify_uses_libraries
check is preserved.
The intended use case for this flag is to have a smoother migration path
for the Java modules that need to add <uses-library> information in
the build files. The flag allows to quickly silence build errors. This
flag should be used with caution and only as a temporary measure, as it
masks real errors and affects performance.
verify_uses_libraries check is reworked so that it writes the error
message to a status file (which is used instead of the former timestamp
file). Currently the stored error message is not used, but it may be
used later to produce a warning. Dexpreopt command checks if the status
file exists and is nonempty; if that is the case, then compiler filter
is set to "extract".
Bug: 132357300
Test: Manually add some mismatch between the libraries in the Android.bp
and Android.mk files for dexpreopted apps, build with
RELAX_USES_LIBRARY_CHECK=true and obsserve that the build doesn't
fail and they are compiled with compiler-filter "extract".
Unset RELAX_USES_LIBRARY_CHECK and observe that the build fails.
Change-Id: Ibb5d993a25b1df1d2e70b7d5aafc6997f9d64e67
Enable the RuleBuilder and RuleBuilderCommand methods to access
the BuilderContext by passing it to NewRuleBuilder instead of
RuleBuilder.Build.
Test: genrule_test.go
Test: rule_builder_test.go
Test: m checkbuild
Change-Id: I63e6597e19167393876dc2259d6f521363b7dabc
The old representation consisted of a list of libraries (UsesLibraries),
a list of optional libraries (OptionalUsesLibraries) and a mapping from
library name to its build/install paths (LibraryPaths). The separation
into lists and map was necessary because of special handling of
compatibility libraries, which is now unified with normal libraries.
The new representation is a mapping from target SDK version to a tree
structure ClassLoaderContext. Each node of the tree represents a library
and contains library name, build/install paths and a slice of
subcontexts for dependencies. The same library may occur in the tree
multiple times in case it is a dependency of multiple libraries. The
order in which libraries are added matters (the resulting tree shape may
be different).
Test results have to be updated, as the resulting <uses-library> list is
reodered (previously it was a sorted list of map keys, and now it is
formed by a depth-first preorder traversal of the class loader tree).
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Bug: 168686456
Change-Id: I11be8cd2967f004fd58753d7c5fb99fed179cd63
construct_context.py is a script that runs at Ninja stage and constructs
class loader context arguments for dex2oat. Previously it accepted lists
of library paths and concatenated them into one class loader context
string. The script also handled the dependency of "android.hidl.manager"
on "android.hidl.base" that is not tracked by the build system and must
be handled in a special way.
Now that class loader context representation is going to change from
flat lists to trees, passing paths to individual libraries as script
arguments is no longer possible, because a list of paths cannot
represent a class loader context tree. Passing the trees in a serialized
form is also inconvenient, because the script would have to parse them,
which would complicate it a lot.
Therefore this patch ports all the concatenation and "android.hidl.base"
handling to Soong. It is not possible to port the remaining script to
Soong because Soong has no information about the targetSdkVersiion of
the dexpreopted apps (it is in the manifest and sometimes in an APK, and
has to be extracted at Ninja time).
Test: construct_context_test.py
Test: new subtests in TestUsesLibs
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Icdb03cf00d1e27e4cff3844b89bfaec4de502dd7
Mimick the way PackageManager handles it at runtime: do add it to class
loader context for apps with targetSdkVersion < 30, but only if
"android.test.runner" is used. Previously it was not added at all.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I4c06635277ab13e21069b9fa0b46eb6a2547dfdd
Also, add tests for compatibility libraries in class loader context.
This CL separates special-case handling of compatibility libraries into
a "fixup" step that is done after class loader context is constructed by
Soong. This allows to handle compatibility libraries and normal
libraries uniformly, which should enable further simplification of class
loader context representation (in subsequent CLs).
Currently the only "fixup" step is removal of libraries from conditional
class loader context if they already are in unconditional context. This
check cannot be done at the time when the libraries are added to
conditional context, because the full uncoditional context is not yet
known at that time. Previously construction of unconditional context was
delayed, now it is no longer delayed and handled in the same way as
unconditional context, and the "fixup" does the filtering.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Ie71e9fb2d3d529b5317cd84e09ab3c853017c349
This doesn't apply to compatibility libraries (those added to
conditional class loader context base on the targetSdkVersion in the
manifest), because Soong doesn't know if they are needed or not (the
build rule that parses the manifest runs at Ninja stage).
In the future we may need to relax this and instead of failing the build
to disable dexpreopt in such cases. But currently there are no use cases
that fail.
Also, this patch replaces hardcoded install path with a constant.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Ic894bc17e8ffd8ff173111ea09366252001ef3e9
Previously, the patterns in SYSTEM_OTHER_ODEX_FILTER only matched
subpaths of /system. Broaden this to match /<p> as well as /system/<p>.
Because SYSTEM_OTHER_ODEX_FILTER includes system_ext and product apps,
the immediate effect of this is that the odex and vdex files of
apps on those partitions move to system_other for A/B devices.
This makes the product and system_ext partitions smaller, which
in turn makes OTAs smaller.
Bug: 141707536
Test: soong unit tests
Test: (adb shell dumpsys package com.android.stk &&
adb shell dumpsys package com.android.quicksearchbox) | grep -i dexopt -A3;
verify dexpreopt state is 'prebuilt' for both
Test: adb shell find /data/dalvik-cache -name '*QuickSearch*.vdex' | wc -l == 1
Test: adb shell find /data/dalvik-cache -name '*Stk*.vdex' | wc -l == 1
Change-Id: I0cf141014b9ddf32159cff47b0325d9c78b549f2
For some dependencies, like stubs, the SDK library may not be found at
build time (either because the implementation library is not among the
dependencies of the dexpreopted module, or because it's part of a
prebuilt, or because it's missing from the build altogether). In such
cases dexpreopt is useless, because dex2oat does not have access to the
full classpath (unless the &-classpath is used). Therefore do not
dexpreopt in such cases.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: If289088cfd103011ccb16165e95a97b30fd31b81
Add a new helper SortedIntKeys similar to SortedStringKeys.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I08a43ec2cae7d1a82531295aca1a0658e3a0dd6f
With the addition of apexes and /system_ext some of the bootclasspath
and system server jars have moved from /system to the new locations.
This has been implemented by using lists of colon-separated strings
called "apex-jar pairs" (although "apex" was misleading as it could
refer to "platform" or "system_ext", not necessarily a real apex).
Using the colon-separated string representation is inconvenient, as it
requires splitting and reassembling the list components many times,
which harms performance and makes error handling difficult. Therefore
this patch refactors the colon-separated lists into a struct that
hides the implementation details.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Id248ce639a267076294f4d4d73971da2f2f77208
This allows to reuse SDK version comparison routine from other Python
scripts. With the addition of non-numeric versions comparison has become
more complex, and the deleted shell script did it incorrectly: it used
comparisons like `[[ "S" -lt 28 ]]` which results in "true" as strings
are converted to zero in numeric context. This resulted in adding legacy
libraries to class loader context of apps targeting recent SDK versions.
The error was masked because currently there is only one non-AOSP app
that uses the script (GoogleDialer), and it targets numeric SDK version.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I26e752e29b5453fd3e29d5dbfbe4d9df9c0a55b7
There are essentially three different cases: 1) system server dexpreopt,
2) the case when uses-library information is known, and 3) the case when
uses-library information is unknown and the &-classpath hack is used.
This patch reorganizes the code into three branches that correspond to
the above cases.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Ife2d01a612e0a608ae1346d7007741498e938bc5
Different names of the same field in Make and in Soong resulted in
the field being dropped when unmarshalling the JSON from Make to Soong.
As a result, the list of optional used libraries for Make modules was
always empty.
Test: lunch aosp_cf_x86_phone-userdebug && m
Test: Cherry-pick in internal master and observe that the logcat error
"ClassLoaderContext shared library size mismatch" for GoogleDialer
has disappeared:
terminal-1 $ lunch cf_x86_phone-userdebug && m && launch_cvd
terminal-2 $ adb wait-for-device && adb root \
&& adb logcat | grep 'size mismatch'
(nothing after the change, one error message before the change)
Bug: 132357300
Change-Id: I57820646fa7c1d8af01b2cbc8a3521da450719c0
This is a preliminary CL before fixing on-device paths to DEX jars.
It groups together the inormation about on-host build paths and
on-device install paths to library DEX jars.
This CL changes the structure of module dexpreopt.config files
generated by the build system. Aside of that, no functional changes.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I059654be7670f2ba66248d9c49b9694a0591f9c1
The order is non-optimal if some jar X precedes its dependency Y. In
that case dexpreopt will be unable to resolve any rerefences from X to
Y. Raise an error unless the product sets variable
PRODUCT_BROKEN_SUBOPTIMAL_ORDER_OF_SYSTEM_SERVER_JARS to true in the
makefile. This is to prevent regressions in existing products that
currently have correct order.
Test: lunch cf_x86_phone-userdebug && m nothing
Test: lunch aosp_car_arm && m nothing
Bug: 140451054
Change-Id: Iafe8fe0e992deb628e38f2321d4601a4804a3c79
Merged-In: Iafe8fe0e992deb628e38f2321d4601a4804a3c79
(cherry picked from commit fb863c87c4)
Deduplicate code for conditional class loader contexts that depend
on the target SDK version in the manifest.
Test: lunch aosp_cf_phone-userdebug && m
Change-Id: I69d51b212bf502b2659d43f124ea3922f90e1881
This library no longer exists on device and "org.apache.http.legacy"
should be used instead. The error lingered in the code for a while
because the code was not exercised at all. (The only app that sets
EnforceUsesLibraries is GoogleDialer (not in AOSP), and it specifies
"org.apache.http.legacy" explicitly as an optional used library.)
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I05fa115476315d35a8877fc42bd1c2042f72f2de
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: Ic229159fdcdaf6182210a53b63850a389dd786fc
Previously there was a discrepancy between the generated paths for
Soong modules that used "out/soong/system_server_jars" and Make modules
that used "out/system_server_jars". This happened because the default
output directory is $OUT/soong for the normal Soong config and jsut $OUT
for the reduced "null config" created by dexpreopt_gen.
As a result, class loader context for system server jars defined in Make
was referring to nonexistent jars, which caused non-fatal dex2oat errors
(the build was not broken, so the errors remained unnoticed):
Failed to determine oat file name for dex location out/system_server_dexjars/[...]
Could not open dex files from location: out/system_server_dexjars/[...]
Test: aosp_walleye-userdebug boots
Test: cherry-picked in master-arc-dev that has a Make system server jar
arc-services, `lunch lunch cheets_x86-userdebug && m`, check that the
generated dexpreopt.sh for arc-services contains paths starting with
"out/soong/system_server_jars" rather than "out/system_server_jars".
Bug: 140712566
Change-Id: Ia7ea8ac383e32042c31d64971cdc8101ea3068cd
