The code is on infeasible path since we already have assertions in
common.BlockDifference().
Also remove the dead code that checks for OPTIONS.info_dict, as we
already set that in ota_from_target_files.main(), for both of A/B and
non-A/B.
Test: Generate incremental OTAs w/ and w/o the CL, and get identical
packages.
Change-Id: Ifb8fc101e78f5ce58c60c8e49028b66ce0d20246
The CL in [1] unintentionally breaks the OEM dict loading logic in the
incremental BBOTA path. We should always require and load the OEM
property dict if _either_ of the source and target builds uses OEM
properties. Otherwise with the current "and" operator, it skips loading
the OEM property dict and thus fails to generate an OTA package that has
OEM property changes (e.g. updating from build with fingerprint to
another one using thumbprint).
The CL in [1] actually makes the right change in the file-based OTA
path, but introduces the bug in the block-based OTA path.
This CL also cleans up the line that reads recovery_mount_options.
[1] commit 7f804ba71f ("releasetools:
allow for multiple OEM property values.").
Test: Genearte an OTA that has OEM property changes successfully.
Change-Id: Idce4ad59825d432618535ce09ab22bd7ddc524f2
The two make vars are exported to soong as OdmPath and OemPath.
Bug: 68187740
Test: out/soong/soong.variables has OdmPath and OemPath each of which
points to 'odm' and 'oem'.
Change-Id: Ia283e4eb4aacc61b5b3c46e9001ea924566ea898
Host (as opposed to hostdex) tools compile and run against OpenJDK's
core libraries. Before this CL, the core libraries of the default
toolchain were always used, even when targeting an earlier language
version.
This meant that code that uses APIs from a later version of OpenJDK
than corresponded to LOCAL_JAVA_LANGUAGE_VERSION would compile, but
would fail to run under that earlier version of OpenJDK. It also
meant that calls to existing APIs might be reinterpreted; for
example, the return type of java.nio.ByteBuffer.clear() changed from
Buffer in OpenJDK 8 to ByteBuffer in OpenJDK 9. At compile time, this
was noted via the warning:
bootstrap class path not set in conjunction with -source 1.8
After this CL, when targeting a language version <= 1.8 (which is
always the case when building with OpenJDK 8), some of OpenJDK 8's
core library/tools jars are now passed on the bootclasspath. The
decision to include the bootclasspath argument when building with
OpenJDK 8 was somewhat arbitrary, but has the advantage that we
discover any issues before we switch to OpenJDK 9.
Even when compiling with OpenJDK 9, use of OpenJDK 9 APIs will now
fail at compile time rather than at runtime; calls to existing APIs
will now be interpreted in OpenJDK 8 rather than 9 fashion. For
example, this means that dx and host-side CTS tests built with
OpenJDK 9 javac -target 1.8 will be runnable under OpenJDK 8.
Bug: 70521453
Bug: 70862583
Test: Checked that the bootclasspath argument was passed
in the javac invocation targeting 1.8 during:
make showcommands compatibility-common-util-hostsidelib
Test: make checkbuild
Change-Id: I9b6081edfdd2c3e9a450ae8a39c4e32c3d2cda92
classes-no-debug-var.jar is incorrect, jars in coverage builds
do have debug information. Remove full_classes_compiled_jar_leaf
and hardcode classes-full-debug.jar.
After the previous patch, all dex files have debug information,
so remove the no-local and with-local directories and replace
them with dex/.
Remove the unnecessary jarjar_leaf.
Bug: 70886092
Test: m checkbuild
Change-Id: I63eace8f8cda5ad8bc0cbd11eefda73dd063ed76
We use jacoco for coverage now instead of emma, so the workaround
is no longer necessary.
Bug: 70886092
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true WITH_DEXPREOPT=false
Change-Id: I103cbe58590689640a0b1520d22b3d3b7cd2208d
Tao Bao