This reflects that it has expanded from its initial purpose to include
more than just flag files. It is exported for use in tests in other
packages.
Bug: 179354495
Test: m nothing
Merged-In: I9f780b20e18ce3a774e4aa04a276463070a64c34
Change-Id: I9f780b20e18ce3a774e4aa04a276463070a64c34
(cherry picked from commit af99afa919790cc76a9b1a1947d473065ecb65a5)
Change 70cfdff3da2ea07cd5cb7f7b91474f6fa0c248e5 changed the hidden API
flags in com.android.i18n as it stopped the i18n-bootclasspath-fragment
from making the hidden API flag files available for use by
platform-bootclasspath.
This change fixes that by exporting the flag files even if hidden API
flag generation is skipped.
Bug: 179354495
Test: m com.android.i18 out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that the flags in
packages/modules/RuntimeI18n/apex/hiddenapi/hiddenapi-max-target-o-low-priority.txt
are reflected in the core-icu4j dex files in the apex.
Merged-In: I9b5c7c74bd996ab447bc0e0452da5fd49191a35d
Change-Id: I9b5c7c74bd996ab447bc0e0452da5fd49191a35d
(cherry picked from commit 62370923911827d0a9cf6103e47652f40ca2cd25)
Encapsulating the information needed by hidden API processing in a
struct makes it easy to add additional information in future and allows
the code to populate that struct from various different sources to be
grouped together.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Merged-In: I53805737dff36a3ae87aca5aad51cf46ae1361fe
Change-Id: I53805737dff36a3ae87aca5aad51cf46ae1361fe
(cherry picked from commit 1352f7c4715d3d311a2644b9337e4b1028d82cb0)
HiddenAPIFlagOutput encapsulates the paths to the files produced by the
hidden API flag generation of a single bootclasspath_fragment. It is
returned from hidden API flag generation and is embedded within the
hiddenAPIFlagFileInfo so they can be passed to other modules.
Unlike the fields it replaces in hiddenAPIFlagFileInfo the fields in
HiddenAPIFlagOutput are of type Path not Paths which makes it easier to
use.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Merged-In: I7373ba1001cac3a75eb54a23e62fa52f5013ee7f
Change-Id: I7373ba1001cac3a75eb54a23e62fa52f5013ee7f
(cherry picked from commit 1e6f5c4e633bab71d82eace7bad0f52494ef1839)
The hiddenAPIFlagFileInfo was being used for both the input and output
of bootclasspath_fragment and platform_bootclasspath and also to pass
information around to various hidden API rule methods. Supporting
multiple different uses in this way made it hard to reason about.
This change creates a separate structure for use by the
platform_bootclasspath. Follow up changes will split out other
functionality into separate types.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Merged-In: Ia5c5f65ae5645486c42819c669a8601588217f88
Change-Id: Ia5c5f65ae5645486c42819c669a8601588217f88
(cherry picked from commit 438eb57a2744b9b0bd38a5526e67cacf43c42b31)
There is no need to leak soong module names.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
Merged-In: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
Previously, the apex content info was populated with hidden API encoded
dex jars retrieved directly from the java module. This change retrieves
the unencoded dex jars from the java module, encodes them and then
stores the result in the apex content info.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Merged-In: Ib1b6eb8b62ac50e03b9e0d07c877ca70bb6f6d25
Change-Id: Ib1b6eb8b62ac50e03b9e0d07c877ca70bb6f6d25
(cherry picked from commit 54c98f5b4af1b47b922bd76a4dbf0aca50c2a453)
Previously, if the method was called multiple times by the same module
the resulting build rules would all use the same temporary directory
which meant that if run in parallel they would conflict with each
other. This change fixes that by providing a jar specific temporary
directory so it can be used by bootclasspath_fragment to encode its
content modules.
Also, cleans up, simplifies and improves the documentation.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Merged-In: I0ebe61abc8e16111c6e8a822eb96c57846b98461
Change-Id: I0ebe61abc8e16111c6e8a822eb96c57846b98461
(cherry picked from commit 0916595b1c9bf71224b98a6a2fdee941690446f6)
Bug: http://b/186576313
During a coverage build, pass the __ANDROID_CLANG_COVERAGE__ macro to
native compilations. This allows tools like dalvikvm and dex2oat, which
would otherwise call _exit(), to write profiles on coverage builds by
calling exit() instead.
Test: `m CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS="art" nothing`
and check compiler flags in out/soong/build.ninja.
Change-Id: I18315b89170abdd650e4c6c55577688348c42225
(cherry picked from commit 551b06d9e69066baf1b621b20d4b838ac2f28902)
* changes:
Skip TestDex2oatToolDeps on Darwin.
Don't fail if the target module is disabled in dex2oat tool dependencies.
Use oatdump rather than oatdumpd for boot jar boot.*.oatdump.txt files.
Previously, the DexBootJarPathForContentModule(module) simply called
directly through to the module to retrieve the dex jar path. This
change changes it so the bootclasspath_fragment retrieves the dex
jars from the module and stores them in the info structure for this
method to retrieve directly.
This makes it easier for the bootclasspath_fragment to stop retrieving
hidden API encoded dex jars from the module and perform the encoding
itself.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Merged-In: Ic79dea080f10f4017f1a75d6d1fb5a3bfe04c2ce
Change-Id: Ic79dea080f10f4017f1a75d6d1fb5a3bfe04c2ce
(cherry picked from commit 1a8010a24171c4ac1928b659f48dc680ee8b0353)
Previously, the hidden API encoding was done before resource merging.
However, hidden API modularization requires that the encoding be done
by the bootclasspath_fragment/platform_bootclasspath modules which will
be after the resource merging. Therefore, this change moves the hidden
API encoding after to match the future behavior.
It also moves the initHiddenAPI() method call after resource merging
too and passes it the result of the resource merging so it is available
for the bootclasspath modules via bootDexJar().
Although the resource merging was not always done when it was done it
would reorder the entries in the generated jar to match java ordering,
which puts the MANIFEST.MF first. This change preserves that behavior
by adding -j to the call to MergeZipCmds. This does mean that jars
which did not require resource merging now have a different order but
as both orders work that is not a significant change.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that apart from the ordering change in the jars that this does
not change the contents of the apex files
Merged-In: If74baad5659301ca6ca9c0f6484374420dda8c34
Change-Id: If74baad5659301ca6ca9c0f6484374420dda8c34
(cherry picked from commit 4de94504335e614efcdc4d0d86f1cfad758f83e8)
It's possible that a module will have a product variant
but not a core variant. In that case, we still need to
apply the vendor suffix to the androidmk module name.
Bug: 188720375
Bug: 187963715
Test: Build vendor image using vendor snapshot.
Change-Id: I190fdd707ca23357d1c324c1b1f3318457625f03
Merged-In: I190fdd707ca23357d1c324c1b1f3318457625f03
(cherry picked from commit 4016d7b53e70bdf53dfdc93c8a7969f70fe2eb05)
VNDK snapshots newer than v30 have LLNDK stub libraries. In that
case, the vendor variant for the BOARD_VNDK_VERSION must not be
generated from the LLNDK modules. They are already provided by the
VNDK snapshots.
Generate the vendor variant of the BOARD_VNDK_VERSION only if
BOARD_VNDK_VERSION has an integer value less than or equal to 30.
Bug: 187963715
Bug: 181815415
Test: m nothing
Change-Id: I31e90f4d7e7678c45558f6bf987f5582a4c34f78
Merged-In: I31e90f4d7e7678c45558f6bf987f5582a4c34f78
(cherry picked from commit dee806fd094c81515aa9ec88efd0f594a057afb0)
To avoid duplicates on *CLASSPATH environ variables at runtime, remove
split entries from platform-*classpath, i.e. all updatable jars that
have their own classpath fragments should not appear in the
platform-*classpath's classpaths.proto config.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a
Consider this case:
apex {
name: "com.android.foo",
native_libs: ["foo"],
}
override_apex {
name: "com.mycompany.android.foo",
base: "com.android.foo",
}
cc_library {
name: "foo",
}
There are two APEXes defined: "com.android.foo" and
"com.mycompany.android.foo" which is a copy of "com.android.foo" with
some properties overridden (e.g. signing keys).
The module "foo" is mutated into two variants by the apex mutator: the
platform variant and the apex variant. The former has the variation name
"" and the later has "apex<min_api_ver>" which usually is "apex10000".
Internally, the apex variant has an alias "com.android.foo".
ApexInfo.InApexVariants() returns only "com.android.foo" when called for
the module "foo".
We can see that the information that "foo" is also part of
"com.mycompany.android.foo" is completely lost. This is causing problem
when we compare the apex membership by their "soong module name", not
the "apex name". In the example above, the two modules have different
soone module names, but have the same apex name: "com.android.foo".
To fix that, this CL introduces a new field `InApexes` to the `ApexInfo`
struct. It has the actual name of the APEXes that the module is part of.
With the example above, `InApexes` is ["com.android.foo",
"com.mycompany.android.foo"].
Cherry-picked from https://r.android.com/1710529.
Bug: 180325915
Test: m nothing
Test: m nothing on non-AOSP targets with ag/13740887 applied.
Change-Id: I4e7a7ac5495d2e622ba92a4358ed967e066c6c2e
Merged-In: I4e7a7ac5495d2e622ba92a4358ed967e066c6c2e
.. in preparation for the upcoming change. This change doesn't alter any
behavior.
InApexes is a misleading name. People expects that it has the list of
soong module names of the APEXes that a module is part of. So, for
example, `core-oj` is a part of both `com.android.art` and
`com.google.android.art`. However, in reality, that's not true. The
field has `com.android.art` only. This is because the two APEXes
(android and Google) have the same apex name which is `com.android.art`.
That apex name is used in various places like the `apex_available` and
allows us to keep using the same name regardless of whether the APEX is
overridden or not.
However, this is causing problems in some cases where the exact list of
soong module names is required. The upcoming change will add a new field
to handle the case and the new field actually will get the name
'InApexes'. So, the existing field is renamed to a less misleading name
`InApexVariants`.
Cherry-picked from https://r.android.com/1710528.
Bug: 180325915
Test: m nothing
Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
Merged-In: I0c73361b452eddb812acd5ebef5dcedaab382436
dependencies.
dexpreopt.RegisterToolDeps runs late after prebuilt dependencies have
been resolved, and there's special code in dex2oatPathFromDep to
resolve the prebuilt from the source module. However, if the source
module is disabled then the dependencies check in validateAndroidModule
will complain, so we need to disable that check in this particular
situation.
Also add a comment to explain why dexpreopt.RegisterToolDeps needs to
run so late.
Cherry-picked from https://r.android.com/1711292.
Test: m nothing
Bug: 145934348
Bug: 172480615
Change-Id: Ibc673303d0336768fa23261a2068e91a08f46a30
Merged-In: Ibc673303d0336768fa23261a2068e91a08f46a30
oatdumpd isn't available as a prebuilt.
Cherry-picked from https://r.android.com/1711291.
Test: m SOONG_CONFIG_art_module_source_build=false droid
Bug: 172480615
Change-Id: I70317eb8f253272d629f23063cbe265d556caad3
Merged-In: I70317eb8f253272d629f23063cbe265d556caad3
This change adds a test to verify the existing behavior to provide a
baseline against which following changes can be compared.
Bug: 179354495
Test: m nothing
Merged-In: Ib7dadf3e65151f4e925251f7b1a9c099e824ea63
Change-Id: Ib7dadf3e65151f4e925251f7b1a9c099e824ea63
(cherry picked from commit f2fa0b5e8ee57369ac920969071eee2b56cc04db)
The AlwaysUsePrebuiltSdks() causes all java_sdk_library_import modules
to be preferred over the source, i.e. as if they had prefer: true set.
That interacts badly with the work that is being done to integrate the
bootclasspath_fragment/platform_bootclasspath modules into the build.
It would work fine once that integration has been completed but in the
interim it causes problems. e.g. it does not cause a problem in AOSP
because those java_sdk_library_import modules that are affected have
already been integrated into the build properly.
Unfortunately, internally that is not the case because there are
java_sdk_library/java_sdk_library_import modules that still need to
be updated.
Before the java_sdk_library_import can be safely preferred each
java_sdk_library/java_sdk_library_import module that contributes to the
bootclasspath must:
* Be in the contents of matching bootclasspath_fragment and
prebuilt_bootclasspath_fragment modules.
* Have an apex and one of a prebuilt_apex/apex_set that contains the
dex implementation jar and lists the prebuilt_bootclasspath_fragment
name in its exported_bootclasspath_fragments property.
Safely preferred in this context means that the whole build will
continue to work rather than the current situation which is that only
some of the build will work and some will fail if an attempt is
actually made to build it.
Unfortunately, many java_sdk_library_import modules are missing:
* The prebuilt_bootclasspath_fragment.
* The exported_bootclasspath_fragments property on the
prebuilt_apex/apex_set that contains them.
Together these cause the following symptoms:
1. The java_sdk_library_import does not have a dex implementation jar.
2. The java_sdk_library_import does not have a myapex variant.
These workarounds will avoid Soong reporting build failures. However,
the build will still fail if an attempt is made to build anything
produced by the platform-bootclasspath, e.g. hidden API processing or
a system image.
Bug: 188505921
Bug: 179354495
Test: m TARGET_BUILD_APPS=Calendar
Change-Id: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679
The intention before was to use relative paths to a partition where a
config is defined. However, jars in /system_ext partition are planned to
be declared in /system's classpaths.proto config.
Bug: 180105615
Test: derive_classpath_test, CtsClasspathsTestCases
Change-Id: Icc3e1a903c34187cfcd67a3ae7bc3dd746445c03
Merged-In: Icc3e1a903c34187cfcd67a3ae7bc3dd746445c03
(cherry picked from commit 7d22657c458b7cf7f79cdd3c298bfec13be93533)
Propagating enabling ASAN through shared library dependencies
doesn't make much sense, because only the non-ASAN variant is exposed
to Make, leading to an non-installed dependency.
Bug: 186487510
Test: TestAsan
Change-Id: I7d3f20f2d10beac09c66c6b6dcb7a34a513ff3b8
Merged-In: I7d3f20f2d10beac09c66c6b6dcb7a34a513ff3b8
(cherry picked from commit af98f58242c043b2f96dd6f415b18354af06b473)
- All contents of the fragment are added as java_lib dependencies.
- Generated classpaths.proto is added into etc as required.
Bug: 180105615
Test: m nothing
Merged-In: I8e8e8b019c4ca2909182f205a47deffa946de6da
Change-Id: I8e8e8b019c4ca2909182f205a47deffa946de6da
(cherry picked from commit 333a1732b17887260f2290ffacffffeff760eee5)
Similar to bcp_fragment's contents, this property lists all java library
contributions made by this fragment.
Bug: 180105615
Test: m nothing
Merged-In: Ifb1f54d5db290fffaa31933d15207014bb72d2fb
Change-Id: Ifb1f54d5db290fffaa31933d15207014bb72d2fb
(cherry picked from commit 9366a053da11ba44c9d70671dfac7c294c5427d0)
The new info struct can be easily shared with systemserverclasspath
fragments.
Bug: 180105615
Test: m nothing
Merged-In: I9986e64fdf19f4168da63c156de3dc9bcafac8d8
Change-Id: I9986e64fdf19f4168da63c156de3dc9bcafac8d8
(cherry picked from commit 14e49130bbeba7d222c8851e2f59710ac0f6eb71)
This would allow to start introducing these modules for apexes that
contribute to SYSTEMSERVERCLASSPATH.
In follow up, it will be evolved:
- platform_systemserverclasspath would have "fragments" property to
list all individual systemserverclasspath_fragments;
- systemserverclasspath_fragment would have "contents" property to list
contibuting java libs;
- systemserverclasspath_fragment would generate non-empty
classpaths.proto config within individual apexes.
Bug: 180105615
Test: m nothing
Merged-In: Ibaaa3fae5f1eab9a41ceecc1214a53be6bbc8ba6
Change-Id: Ibaaa3fae5f1eab9a41ceecc1214a53be6bbc8ba6
(cherry picked from commit aa86bac2b01f7565f1ea8ec7c88308ef5ed6e7e2)
In order for the bootclasspath_fragment to perform dex encoding on its
contents it needs to know whether the dex file is uncompressed or not.
This change makes that information available by passing it to
initHiddenAPI, storing it in hiddenAPI struct and providing access
through the hiddenAPIModule.
Bug: 179354495
Test: m droid
Merged-In: I913416b4836766de194203fd8ed5124b61dfa3dd
Change-Id: I913416b4836766de194203fd8ed5124b61dfa3dd
(cherry picked from commit 1bbd0626f2d83036b4e1225cc51edfea5e4055b7)
Now that the individual modules no longer participate in the generation
of the monolithic files it is no longer necessary to select a single
primary module to provide the information they need.
Bug: 179354495
Test: m droid
Merged-In: If09796de710927e3e3f2ccecad0b57ca5fce5dc9
Change-Id: If09796de710927e3e3f2ccecad0b57ca5fce5dc9
(cherry picked from commit 45897dd66327c4b1dd578650dc2f7f0ec572539b)
Paul Duffin