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 630b11e9d4d63e5fabaa20adf5d1b1c81ede6681)
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 869de147abdb2c86a91cced4fda7d27746c52af4)
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 3f0290ef7940c70a491dcbd4b57cabd8b2e753ef)
Bug: 192446466
Test: m nothing
Merged-In: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Change-Id: I9e1cb82bea96022faaec98edc0c9ea7eac6204b0
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
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 71b33cca9d3a589badc714063e47a28b94df31a1)
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 b4bbf2ca10cc8509e3ae0ab104e9e3b55861831b)
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 fef5500a766d1f515ff19038e8e0e8f606e07287)
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)
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)
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)
.. 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
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)
These two methods did very similar jobs and merging them together
simplifies the behavior.
Bug: 179354495
Test: m droid
Merged-In: Ibe1a23d54105e6a0e5693079cd8743679301fc85
Change-Id: Ibe1a23d54105e6a0e5693079cd8743679301fc85
(cherry picked from commit 74d18d1d6ff1ad8ec47c34182d1a22945e05e9d5)
The configurationName was intended to separate the name of the module
from the name used in configuration (such as BootJars) so that the
child implementation library of a java_sdk_library on the bootclasspath
would have hidden API encoding performed on it just as for the main
java_library embedded within the java_sdk_library.
While that did use to work it no longer does as the test added in the
preceding change proves. It is not surprising that this regression does
not appear to have caused any issues as the the child implementation
library is only a build time artifact and not used at runtime.
In future the only modules that will require hidden API encoding are
those that are part of a bootclasspath module so there is no point in
maintaining this capability.
Bug: 179354495
Test: m droid
Merged-In: Ief8136fa9e98600cdd8d36108ec22edc2ebd7c69
Change-Id: Ief8136fa9e98600cdd8d36108ec22edc2ebd7c69
(cherry picked from commit 66cdbf07ef2af6caf42e2c7b77b1a5fb86a4cee3)
The rules to extract hidden API information from an individual module
in order to create module specific files are no longer necessary as
the monolithic files are created directly from the module's class jars
and not the module specific files.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I573ac17f3ea5da5a2a7e4f08718160dacca71c0c
Propagate strict_updatability_linting to transitive dependencies using a
top-down mutator.
Test: lint_test.go
Bug: 182349282
Change-Id: Ifc9e58f1a597e3c7725ee49b4027afb6f42f45cb
The libs property in java_sdk_library is not safe to export as it can
contain libraries that contain implementation specific classes. No
snapshot appears to need this capability but if it does become
necessary then either it will need to use the existing stub_only_libs
property or a new one will need to be added.
Bug: 157884619
Test: m nothing
Change-Id: I60a069177dbee4070d311b23d25f4eb3c5e7ea13
A follow up change will add methods to SdkBase which requires its
module field to have been initialized.
Bug: 181569894
Test: m nothing
Change-Id: I9b02f260ad3f82316cc7ab3b5717b7e81090b0d8
This change makes the tag that is used to add dependencies onto stubs
from the bootclaspath_fragment module cause the dependency to be
automatically exported from the sdk. If the dependency is a
java_sdk_library then it will be as if it was added to the
java_sdk_libs property, otherwise it will be as if it was added to the
java_header_libs property instead.
Bug: 177892522
Test: m nothing
Change-Id: I97010c4342dd39415dba81a4395db7831410436e
Allow java_sdk_libraries to include libraries statically into their
stubs. The immediate use-case of this is to embed libcore notice files
into their stubs.
Also extend the java_sdk_library tests for impl/stub-only-libs, plus
some not assert utils.
Bug: 173186484
Bug: 184839599
Test: soong tests
Change-Id: I1ebf2f35c048eab5cec5125482a0304fe660f188
The hidden API processing needs access to dex jars for the API stubs in
order to determine which dex members are part of an API surface. The
dex stubs used for the monolithic file are provided by normal
java_library modules for legacy reasons. However, the APEXes that
contribute to the bootclasspath, and so need to perform hidden API
processing, typically provide stubs created by a java_sdk_library.
This change adds support to java_sdk_library/_import to make the dex
stub jars available when requested, that involves:
1. Adding compile_dex property to java_sdk_library_import and
propagating it down the the java_import modules for the stubs. That
is already handled for java_sdk_library.
2. Propagating the java_sdk_library compile_dex property to the
java_sdk_library_import in the generated snapshot.
3. Refactoring and wiring to make the dex stubs jar available to other
parts of Soong.
Bug: 179354495
Test: m nothing
Change-Id: I5895d4f2ba0b684870862b9429b2364865e4afc6
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
- The public stubs were being matched against the string ".stubs.public"
which was never the suffix that these stubs used
- Remove obsolete naming pattern matching
Test: m
Change-Id: I1f7bd54e4629f42e34fb3c09828d8853813ba2a7
SdkSpec.Version was an int type. Now it becomes ApiLevel type which
is a better abstraction of the version (or api level).
Bug: 1655587
Test: m
Change-Id: I4d67b9b9eae45f653b6af4f5b73da9e091b3dfab
... in preparation for making the handling of sdk versions consistent
across java and cc modules.
Bug: 175678607
Test: m
Change-Id: I598f0454bce9b7320621022115412fbe97403945
Set baseline_file properties of droidstubs generated in sdk_libary.go to
incompatibilities modules auto-generated by prebuilt_api. This requires
prebuilt_api to generate the modules whether next_api_dir is set or not.
Test: TreeHugger
Bug: 180123247
Change-Id: I690604a8a54e9d9419f072a28a0c0e7734abbd85
Invokes hiddenAPIExtractInformation() on the java_sdk_library_import's
dex implementation jar provided by the deapexer (on behalf of
prebuilt_apex) so that hiddenAPI can extract the information it needs,
if anything, from the dex file.
The dex file provided by deapexer has already had the hiddenapi
information encoded into it so it does not need to do that again.
Usually, it would require a classes implementation jar as well in
order to extract information from UnsupportedAppUsage annotations but
that is not available for a java_sdk_library_import. Fortunately, the
modules that are currently affected by this do not contain any such
annotations. This just uses a public api stubs jar instead.
Bug: 181267622
Test: m nothing
Change-Id: I96275e46f8b7fecba88075319e9f2da5ae315c03
Add a ctx parameter to AndroidMkExtraEntriesFunc to allow them to
access providers.
Test: m checkbuild
Change-Id: Id6becc1e425c3c3d8519248f8c0ce80777fac7cc
Merged-In: Id6becc1e425c3c3d8519248f8c0ce80777fac7cc
Export information about java dependencies through a Provider
instead of accessing the module directly.
Test: java_test.go
Test: no changes to build.ninja
Change-Id: Ifc5d566bf6f6ebc0ad399e948effaa1ef6a22876
Add some instructions for what to do.
Bug: 177806245
Test: m nothing (with java_sdk_library with no tracking files)
Change-Id: I286018f4d9105d5ade1e76cddb8670d0d097d77d
This flag was only used by sdk_library.go, and is no longer needed
since sdk_library.go now knows which libraries are missing latest_api
tracking files.
Bug: 176092454
Test: m
Change-Id: I5a967f784bde99f103b85654c794e8d7110fd0db
Metalava used this attribute to potentially re-write some nullness
annotations from @Nullable to @RecentlyNonNull, and not doing so can
cause problems when compiling kotlin.
Bug: 176092452
Test: m art.module.public.api.stubs && \
rm -rf /tmp/lib && \
unzip -qd /tmp/lib art.module.public.api.stubs.jar && \
javap -v /tmp/lib/java/util/concurrent/ConcurrentHashMap.class | \
grep Recently
Change-Id: I9012798f27e39d9a53dbcf0976548f6cec2d3150
Paul Duffin