This is no longer required to find package.html files, so remove it.
Bug: 153703940
Test: m checkapi
Merged-In: I80ec219cb9ef8922094336a5d45652c8e59aa113
Change-Id: I80ec219cb9ef8922094336a5d45652c8e59aa113
(cherry picked from commit 556e8149cb7781cbe01ea01a8b8a05eb1b018f1a)
Metalava now expects html files to be specified explicitly. This
filtering was originally added because jdiff could not cope with html
inputs, but jdiff support has been removed in r.android.com/1455335.
Bug: 153703940
Test: m checkapi
Merged-In: I34164b633bab2892e3a1c0fd0257fcf98d537655
Change-Id: I34164b633bab2892e3a1c0fd0257fcf98d537655
(cherry picked from commit edd61643be3096af46d1f6aea1091897f668c66b)
Use FixtureWithLastReleaseApis to create the necessary files instead
of disabling the check with unsafe_ignore_missing_latest_api.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I162b0f68eec596274f8d98dca9d3f0500ab13f5d
Merged-In: I162b0f68eec596274f8d98dca9d3f0500ab13f5d
(cherry picked from commit 67c17aede87e3e6d9e1abefc6ad86e987fc9bee9)
Its not used, remove it.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I1689b670a8ae6a614e5e4ec5e79cb5e283b2e277
Merged-In: I1689b670a8ae6a614e5e4ec5e79cb5e283b2e277
(cherry picked from commit f0eace9eed83c0d7cd06df29379ed7e090bd2c27)
The owner property is no longer used, the dist subdirectory is determined
by the dist_group property.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: Id6d997eef05f6511070677974219674f248cb754
Merged-In: Id6d997eef05f6511070677974219674f248cb754
(cherry picked from commit 59b92bfdb300d93558d685e9ea9f4cb5c7378a3b)
Change the default dist_group from "android" to "unknown" to prevent
accidentally including java_sdk_library stubs that do not set
dist_group or owner in the public SDK.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I9aae2a16254ac1a8d444acfa63bc571d1ef4b045
Merged-In: I9aae2a16254ac1a8d444acfa63bc571d1ef4b045
(cherry picked from commit 3dd662509d02914a09f9954b37eaa7dd164a3523)
As long as we have boot jars defined in make, we should try to keep
global.UpdatableBootJars as a source of truth when it comes to classpath
configuration. However, for testing purposes there is a need to add
java libraries to bootclasspath that aren't present in
PRODUCT_UPDATABLE_BOOT_JARS variable.
Ideally, we would unconditionally add all contents to the config for
test apexes, however, I don't fully understand apex merging to support
it.
Bug: 180105615
Test: atest sdkextensions_classpaths_e2e_tests
Change-Id: I552f93289c27b3713e75dcda1faed909b0bfcef2
Merged-In: I552f93289c27b3713e75dcda1faed909b0bfcef2
(cherry picked from commit 1b75a3ce623357020ec6f1446edff974a0dc283a)
Sourcepath is set to dir of the Android.bp, but that dir does not
necessarily have any inputs for the metalava invocation defined in that
Android.bp. This leads to problems when metalava tries to read a
non-existent dir, so create it first.
Bug: 153703940
Test: m sdk dist
Change-Id: I8c2ca45c8f066cabf3247b9652a7094cefc047a9
Introduce and set the variable LOCAL_DISABLE_TEST_CONFIG varaible to be
true for the `android_test_helper_app` type modules.
Bug: 188927912
Test: rum 'm module-name' (`android_test_helper_app` type module)
Test: TreeHugger
Change-Id: I5db1029f31d8afe1ca5e9fab95e39d751971058d
Merged-In: I5db1029f31d8afe1ca5e9fab95e39d751971058d
Reusing the owner property is confusing, especially when the property is
required on every java_sdk_library module. Create a new dist_group property
to use instead.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I9e62c703a95d6b63cafa60bffb1b37ba85388593
Merged-In: I9e62c703a95d6b63cafa60bffb1b37ba85388593
(cherry picked from commit 986b69aa51062309f58923eee8571e824d1896d9)
Seperate the java_sdk_library tests into their own file.
Bug: 186723288
Test: go test ./java/...
Change-Id: I899c2946cb2234dc595a4281e64bbb239b89bda8
Merged-In: I899c2946cb2234dc595a4281e64bbb239b89bda8
(cherry picked from commit 1d2b6b3b2ecc6dac49b1a8be697d7374dbed5d79)
Metalava increments the SDK level by one when it's not "REL", so we
temporarily force the build to be "REL" while we're still in the
process of finalizing it.
This CL must be reverted as part of actually declaring "REL".
Bug: 171506470
Test: Build
Change-Id: I95ee4879268eab3e28a653ca8c169bf6a83e2a19
* changes:
Treat java libraries in classpath fragments as directly in apex
Make CopyDirectlyInAnyApex match the documentation
Remove unused cc.copyDirectlyInAnyApexDependencyTag
Coverage is applied to java libraries that are directly in an apex.
Mark java libraries that are in an apex through a bootclasspath_fragment
or a systemserverclasspath_fragment as directly in the apex by
implementing CopyDirectlyInAnyApexTag on the dependency tags used for
their contents.
Bug: 183759446
Test: TestApexJavaCoverage
Change-Id: I0116f5f415083b5194000988cb257454ef115200
Merged-In: I0116f5f415083b5194000988cb257454ef115200
(cherry picked from commit c33e5216f1eb3f837dee89cc65208eff058e9c5e)
Nothing uses this argument anymore, so simplify the droidstubs code by
removing the argument.
Bug: 189426360
Test: m
Change-Id: I0e4b84d73a954b3819db1149be3da287cf604eec
For testing purposes, a boot jar may be provided by a test java_library
that has a different content name, but sets "stem" property to match
the original java_library.
Given that Stem() returns either the property value or module name,
it is safe to replace all content names by their stems.
Bug: 180105615
Test: atest CtsClasspathsTestCases sdkextensions_e2e_tests
Change-Id: Ic519ffa0c5b616abddf15b41c934421dfac2e78a
Previously, due to legacy reasons, the property validation did not
require a contents property and allowed the image_name to be either
"art" or "boot". Those reasons no longer apply and so this change
requires a contents property and only allows the image_name to be set
to "art" if specified.
Bug: 177892522
Test: m nothing
Merged-In: I8855d6e5365ef0b55490e90e7b6c0081cf070ee5
Change-Id: I8855d6e5365ef0b55490e90e7b6c0081cf070ee5
(cherry picked from commit 8018e50ddb141dea7891918c4178a7a394a788d8)
Previously, the generation of the rules to create the boot image files
was separate from the code to provide those files to the APEX which
meant that it was possible for the APEX to try and use files that had
no rules to create them.
This changes avoids that by only exporting the files once the rules
have been created.
This necessitated a few changes to tests that were relying on the
previous behavior. Including removing completely the test that used an
image_name: "boot" as that is no longer a valid configuration name as
its functionality has been replaced by platform_bootclasspath.
A follow up change will make the validation of the properties of
bootclasspath_fragment stricter to prevent "boot" being used as the
image_name.
Bug: 177892522
Bug: 188680624
Test: lunch qemu_trusty_arm64-userdebug
m droid dist
- verify that before this change it fails and after this change
it works.
m com.android.art
- verify that this change does not change the APEX contents with
either qemu_trusty_arm64-userdebug or aosp_arm64-userdebug
Merged-In: I0497a151eb0731cbe6a1a7e7bbbb1e4dda75898f
Change-Id: I0497a151eb0731cbe6a1a7e7bbbb1e4dda75898f
(cherry picked from commit 58e0e769c9b1f4dbad95acfd1792dd91e716e456)
Previously, the hidden API flags generated for a bootclasspath_fragment
did not include removed API members. That was because it did not supply
a file containing the dex signatures of the removed API members.
The monolithic hidden API processing uses combined-removed-dex which is
the output of a genrule that takes as input the *removed.txt files from
all the APIs and uses metalava to construct the dex signatures file.
This change does the equivalent for the *removed.txt files for the APIs
provided by a bootclasspath_fragment and then passes them to the rule
that generates the final all-flags.csv.
Bug: 179354495
Test: - Update packages/modules/RuntimeI18N to enable hidden API
processing.
m out/soong/hiddenapi/hiddenapi-flags.csv
- Before this change that fails as the flags generated for the
i18n-bootclasspath-fragment differ from the monolithic flags.
After this change that passes.
- Verify that this change does not change any of the monolithic
hidden API files.
m com.android.i18n
- Verify that the apex file before and after this change are byte
for byte identical.
Merged-In: I6a21edb8a5231666e3f35b2c99a8687f36dd98fd
Change-Id: I6a21edb8a5231666e3f35b2c99a8687f36dd98fd
(cherry picked from commit 32cf58a8fcfc043246a9c402b32c863e8aebc499)
Previously, a bootclasspath_fragment that depended on classes provided
by another bootclasspath_fragment did not support hidden API processing
as it would not supply information about those dependencies.
This change adds support for that as follows. Each fragment:
1. Exports the transitive sets of stub dex jars for each of the public,
system, test and core_platform APIs (where relevant).
2. Adds dependencies onto its dependent fragments.
3. Retrieves the API stubs dex jars from its dependent fragments and
passes them to the "hiddenapi list" tool which will use them to
resolve dependencies but will not output them to the generated
flags.
Once the flags are generated the existing encoding functionality
encodes the flags into the dex files of the bootclasspath_fragment's
content modules which are then packaged into the apex.
Bug: 179354495
Test: m com.android.sdkext
- verify that this does not change the contents of the apex files
Merged-In: I3e82a6dbb437f1e417e5d7e25aeb212e378603d0
Change-Id: I3e82a6dbb437f1e417e5d7e25aeb212e378603d0
(cherry picked from commit f1b358cb5764039ff7502e9f73ad0abfdc91c7aa)
Previously, the bootclasspathApiInfo was only used for tests and follow
up changes will need to provide the stub dex jars. This change moves
the stubJarsByKind into HiddenAPIInfo and removes bootclasspathApiInfo
and the corresponding provider.
Bug: 179354495
Test: m nothing
Merged-In: I5459c56de561c053ed671dc9d5cb3ee4820c0ee8
Change-Id: I5459c56de561c053ed671dc9d5cb3ee4820c0ee8
(cherry picked from commit 18cf19745e2fffb184a7b42f50609ea98d4adb1d)
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)
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)
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)
* 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)
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
Anton Hansson