build_soong/dexpreopt, branch android-platform-11.0.0_r2

Fix host path for dexpreopted system server modules defined in Make.

2020-04-28T08:31:35+00:00

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
Merged-In: Ia7ea8ac383e32042c31d64971cdc8101ea3068cd
(cherry picked from commit 6cf2c0c19751a42b18dd316e92a054822a1202b0)
Exempt-From-Owner-Approval: cherry-pick of approved CL.

Don't append build directory to the output path twice.

2020-03-24T14:09:43+00:00

Soong already uses build directory as a part of the generated output
path. Besides, trying to append it second time breaks if the build
directory is an absolute path.

Test: frameworks/rs/build_rs.py  (uses absolute build directory path)
Test: walleye-userdebug boots

Bug: 152235239
Change-Id: Ie03c9e688013b9a3e6bc859c936d89c538ded76a

Fix null pointer dereference in Soong on dexpreopt arc-services.

2020-03-23T14:35:58+00:00

The null pointer dereference was caused by trying to get device name
from a config passed to dexpreopt. For Make modules, the config is a
stub that doesn't have a device name. The fix is to use build directory
instead of device name (it is provided both by the full config passed
to Soong modules and by the stub config passed to Make modules).

Test: walleye-userdebug boots.
Test: aosp_bertha_arm-userdebug builds and generates arc-services.odex.

Bug: 152193534
Change-Id: I7adc173646cae6eaee188c6672629a5a942aea06

Simplify the construction of class loader contexts for system server jars.

2020-03-20T15:23:18+00:00

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

Simple refactoring of prefix related functions.

2020-02-14T22:33:49+00:00

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

Do all dexpreoptDisabled checks before registering a dex2oat host dep.

2020-02-13T17:46:48+00:00

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

Pass dexpreopt config structs by reference.

2020-02-13T17:46:48+00:00

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

Reland: Get the dex2oat host tool path from module dependency on the

2020-02-13T17:46:48+00:00

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

Reland: Move the Once cache for dexpreopt.GlobalConfig into the

2020-02-13T17:46:48+00:00

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

Reland: Separate dexpreopt.GlobalSoongConfig to allow independent

2020-02-13T17:21:13+00:00

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