* changes:
Consolidate the code to resolve a deapexer module dependency.
Propagate the dex jar path as an OptionalPath which is either valid or invalid with a message.
It will get more logic in upcoming CLs.
Add a property to DeapexerInfo for the APEX name, for use in error
messages.
Test: m nothing
Bug: 192006406
Change-Id: I957f3df8b34543a38cde38768dac93e78132d672
invalid with a message.
This will allow propagating any error from the deapexer module for
prebuilt APEXes to the location where the dex jars get used. It's only
at those points that we can raise errors about not being able to
extract files from the deapexer modules if they are invalid, and this
way we avoid encoding knowledge there about why they may be invalid.
To keep the refactoring limited it intentionally does not change any of
the existing logic for when dexJarFiles are set or not (non-nil vs nil
prior to this change), although there may be opportunity to use this
for more conditions when dex jars aren't available.
The refactoring is also not extended to
dexpreopt.ClassLoaderContextMap.
Test: m nothing
Bug: 192006406
Change-Id: I68986dccd9a9b3fee4d24caa1947ea17a36caedc
The annotations zip file is produced by the "main" sdk build and is
primarily consumed by android studio.
In order to support building the main SDK without requiring the sources
of all modules, we are adding module SDK artifacts that allows
reconstructing these outputs. The annotations zip contains XML files
which should be fairly easy to merge from all the individual parts.
Bug: 187397779
Test: unit tests in this CL
Test: m sdkextensions-sdk and inspect output
Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
This arg provides the ability to pass sources to the metalava
invocations that are part of a java_sdk_library without affecting
the runtime library.
This is useful in various scenarios, e.g.: when javadoc in some source
files affects the metalava behavior. For example, the javadoc-generation
javadoc tags @paramDoc, @returnDoc etc. Passing these as a library does
not work because class files do not contain javadoc.
Bug: 186197911
Test: manually inspect module stub src for doc enhancements
Merged-In: I2ce98f891283514e1896c52d9335550c1f5435fb
Change-Id: I2ce98f891283514e1896c52d9335550c1f5435fb
This arg provides the ability to pass sources to the metalava
invocations that are part of a java_sdk_library without affecting
the runtime library.
This is useful in various scenarios, e.g.: when javadoc in some source
files affects the metalava behavior. For example, the javadoc-generation
javadoc tags @paramDoc, @returnDoc etc. Passing these as a library does
not work because class files do not contain javadoc.
Bug: 186197911
Test: manually inspect module stub src for doc enhancements
Change-Id: I2ce98f891283514e1896c52d9335550c1f5435fb
Similar to the previous CL, but for jars from prebuilts.
Test: manual - 1. Patch aosp/1818020 and aosp/1810840.
2. m SOONG_CONFIG_art_module_source_build=false com.android.art
Bug: 194150908
Change-Id: Idc0c73a78045a602ad3a91cb5071d291bd611015
We are expanding PackageManager's supported attributes and this change
enables the developer to define them in the .bp file.
Test: m nothing
Bug: 191978330
Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57
Replaces the BottomUpMutatorContext parameter with a new
SdkDependencyContext type that extends BottomUpMutatorContext. This is
to allow the sdk to pass additional information to the implementations
of that method to allow the behavior to be more finely tuned.
Bug: 195754365
Test: m nothing
Change-Id: I69c6d2c523934eb67d7a7e6c55c241e9b8a81773
Previously, the java_import and java_sdk_library_import modules did not
make their permitted_packages available to the rule that generates the
updatable-bcp-packages.txt file. This change corrects that.
Bug: 193095050
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Merged-In: If0706e4551a331b48d383123088e63924dded48b
Change-Id: If0706e4551a331b48d383123088e63924dded48b
(cherry picked from commit 630b11e9d4)
Previously, permitted_packages were not copied to the sdk snapshot.
This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Merged-In: I4560987f746f78c0ae706058195b6db4bea438aa
Change-Id: I4560987f746f78c0ae706058195b6db4bea438aa
(cherry picked from commit 869de147ab)
Previously, the java_import and java_sdk_library_import modules did not
make their permitted_packages available to the rule that generates the
updatable-bcp-packages.txt file. This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: If0706e4551a331b48d383123088e63924dded48b
Previously, permitted_packages were not copied to the sdk snapshot.
This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: I4560987f746f78c0ae706058195b6db4bea438aa
Even though actual installed module path is the same as source module,
it uses impl's one.
Bug: 188179858
Bug: 193082464
Test: compare dexpreopt_config.zip files from
1. TARGET_BUILD_UNBUNDLED_IMAGE=true m dexpreopt_config_zip
2. m dexpreopt_config_zip
(note that m clean should run between steps)
Test: build aosp_cf_x86_64_phone, launch_cvd, and then
adb wait-for-device \
&& adb root \
&& adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
and then check if there is no message.
Change-Id: I34ffd9a2d214a6614c2befc35b2beec003cfcd25
Without these errors, the last encountered deapexer would silently be
used, and we wouldn't know if it was taken from the prebuilt APEX that
actually get installed in the system image.
With this error check there may be only one enabled prebuilt_apex or
apex_set for each apex_name (which defaults to the module name). E.g.
if there are both prebuilt com.android.foo and com.google.android.foo,
it is necessary to disable one of them in the .bp file.
Merged-In is set from https://r.android.com/1745454, a change that has
gone into AOSP and internal master, as well as sc-dev-plus-aosp, but
specifically not sc-dev. This change cannot merge into sc-dev-plus-aosp
and others, because they may or may not have the com.google.android.art
prebuilt APEX present depending on manifest, and with this check
exactly one of com.android.art and com.google.android.art prebuilts has
to be present and enabled. It'll be cherry-picked to AOSP along with a
full fix for b/192006406, when it can be safely enabled everywhere.
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Test: m nothing SOONG_CONFIG_art_module_source_build=true
Test: m nothing
with enabled:true for the com.android.art prebuilt APEX - check that
it fails with an "ambiguous duplicate deapexer" error
Bug: 192006406
Bug: 192542393
Change-Id: I44566fd26b12f82a8a67fe4a69e56303460756d0
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Previously, if a bootclasspath_fragment had both a java_sdk_library
module and one of its components in stub_libs properties they would be
treated as separate modules instead of simply different APIs from the
same module. That would result in them both providing stub dex jars to
"hiddenapi list" which would fail because it found duplicate
definitions of the same class.
e.g. Specifying something like this:
api: {
stub_libs: [
"art.module.public.api",
],
},
core_platform_api: {
stub_libs: [
"art.module.public.api.stubs.module_lib",
],
},
would cause "hiddenapi list" to fail because it would have been passed
paths to two dex jars (actually the same dex jar but that does not
matter) each of which defined the same class, e.g. java.lang.Object.
This change treats the "art.module.public.api.stubs.module_lib" and
"art.module.public.api" modules as being the same for the purposes of
hidden API processing.
(cherry picked from commit 3f0290ef79)
Bug: 192446466
Test: m nothing
Merged-In: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Change-Id: I9e1cb82bea96022faaec98edc0c9ea7eac6204b0
Previously, if a bootclasspath_fragment had both a java_sdk_library
module and one of its components in stub_libs properties they would be
treated as separate modules instead of simply different APIs from the
same module. That would result in them both providing stub dex jars to
"hiddenapi list" which would fail because it found duplicate
definitions of the same class.
e.g. Specifying something like this:
api: {
stub_libs: [
"art.module.public.api",
],
},
core_platform_api: {
stub_libs: [
"art.module.public.api.stubs.module_lib",
],
},
would cause "hiddenapi list" to fail because it would have been passed
paths to two dex jars (actually the same dex jar but that does not
matter) each of which defined the same class, e.g. java.lang.Object.
This change treats the "art.module.public.api.stubs.module_lib" and
"art.module.public.api" modules as being the same for the purposes of
hidden API processing.
Bug: 192446466
Test: m nothing
Change-Id: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Previously, a java_sdk_library with shared_library = true would create
a variation per APEX because it depends on an sdkLibraryXml module
which generates a file containing the APEX name. However, a shared
java_sdk_library_import would create a merged APEX variation. The
inconsistent variations caused failures in sdkDepsReplaceMutator.
This change ensures that both java_sdk_library and
java_sdk_library_import create an APEX specific variation when their
shared_library property is true.
Bug: 190499958
Test: m nothing
- ran the above command after modifying the test to reproduce the
problem and then after fixing to verify that it fixed the problem.
Change-Id: Iee81776a8569db3e871c40cbde14d248dfeb56e4
Previously, a java_sdk_library with shared_library = true would create
a variation per APEX because it depends on an sdkLibraryXml module
which generates a file containing the APEX name. However, a shared
java_sdk_library_import would create a merged APEX variation. The
inconsistent variations caused failures in sdkDepsReplaceMutator.
This change ensures that both java_sdk_library and
java_sdk_library_import create an APEX specific variation when their
shared_library property is true.
Bug: 190499958
Test: m nothing
- ran the above command after modifying the test to reproduce the
problem and then after fixing to verify that it fixed the problem.
Change-Id: Iee81776a8569db3e871c40cbde14d248dfeb56e4
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Merged-In: I515f235fe21755b5275af12366e96c24c94c0273
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
(cherry picked from commit a1aa7387f7)
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
The commonSdkLibraryAndImportModule defines the methods that a module
which embeds the commonToSdkLibraryAndImport struct need to provide.
Bug: 179354495
Test: m nothing
Merged-In: I7a469ae03ea5c19922200284da08a9ae38a46751
Change-Id: I7a469ae03ea5c19922200284da08a9ae38a46751
(cherry picked from commit 71b33cca9d)
The commonSdkLibraryAndImportModule defines the methods that a module
which embeds the commonToSdkLibraryAndImport struct need to provide.
Bug: 179354495
Test: m nothing
Change-Id: I7a469ae03ea5c19922200284da08a9ae38a46751
Uses the apex relative path to the file as the identifier that is used
to obtain the path to the corresponding file extracted from the apex.
That is instead of a special constructed string id.
Bug: 177892522
Test: m nothing
Merged-In: I5dc77c8fb272bac289b8891d1eac801e541af1f5
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
(cherry picked from commit b4bbf2ca10)
Removes the special case in createDeapexerModuleIfNeeded for handling
java libraries and just get the Import and SdkLibraryImport module
types to implement RequiredFilesFromPrebuiltApex instead.
Bug: 177892522
Test: m nothing
Merged-In: I5cc341b5b4168b8eb196f72273a00d498de6856f
Change-Id: I5cc341b5b4168b8eb196f72273a00d498de6856f
(cherry picked from commit fef5500a76)
Uses the apex relative path to the file as the identifier that is used
to obtain the path to the corresponding file extracted from the apex.
That is instead of a special constructed string id.
Bug: 177892522
Test: m nothing
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
Removes the special case in createDeapexerModuleIfNeeded for handling
java libraries and just get the Import and SdkLibraryImport module
types to implement RequiredFilesFromPrebuiltApex instead.
Bug: 177892522
Test: m nothing
Change-Id: I5cc341b5b4168b8eb196f72273a00d498de6856f
Its not used, remove it.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: I1689b670a8ae6a614e5e4ec5e79cb5e283b2e277
Merged-In: I1689b670a8ae6a614e5e4ec5e79cb5e283b2e277
(cherry picked from commit f0eace9eed)
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 59b92bfdb3)
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 3dd662509d)
The owner property is no longer used, the dist subdirectory is determined
by the dist_group property.
Bug: 186723288
Test: TestJavaSdkLibraryDist
Change-Id: Id6d997eef05f6511070677974219674f248cb754
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
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 986b69aa51)
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
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 32cf58a8fc)
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.
Change-Id: I6a21edb8a5231666e3f35b2c99a8687f36dd98fd
java_sdk_library modules in builds with AllowMissingDependencies may
be missing defaults modules that cause them to look for api files that
they normally wouldn't need. Move the error to runtime so it doesn't
block the build unless the branch tries to build that module.
Test: prebuilts/build-tools/build-prebuilts.sh in aosp-build-tools
Change-Id: I279b0cd8493779f972c0ac02235967c10b35a5a0
.. 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
