Unless the prebuilt dex jar files are explicitly required to build
system images or dex preopting defer reporting of any missing dex boot
jars from Soong to Ninja.
This will prevent builds that contain prebuilt sdks, containing prebuilt
bootclasspath_fragment modules but without a corresponding apex_set or
prebuilt_apex module from failing even when it is not building against
the prebuilt sdk.
Bug: 179354495
Test: m nothing
Merged-In: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
Change-Id: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
(cherry picked from commit ef083c9556)
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, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: I0cbf11986adff1f2f967b96f86e6bfe0e9b8b1ef
Before this fix, compiling a java_library against sdk_version:
"module_current" can't use the @SystemApi(MODULE_LIBRARIES) provided
by the ART module because the system module "core-current-stubs-system-modules"
contains only the public APIs.
Use the new system module with module lib APIs.
(cherry picked from commit b54f5aa359)
Bug: 183097033
Test: m droid
Merged-In: I274e2710d1ff34e896aa620bfafb4481180c53b5
Change-Id: I374bc4899ef8f60344e37a94ad3cb8492f47fb4d
Previously, when determining which dependencies, direct or transitive,
of a prebuilt_apex/apex_set required APEX variants the code assumed
that all dependencies implemented ApexModule. While that is true for
the modules that can be explicitly mentioned in the exported...
properties it is not true for all of them. e.g. A
prebuilt_apex/apex_set can depend on license modules which do not
implement ApexModule.
This change simply ignores any module that does not implement
ApexModule.
Bug: 179354495
Test: m nothing
Change-Id: Iead6f9d1085d169335b88ceadcce2d8cc042254d
Previously, the stub dex jars for each HiddenAPIScope was created by
merging the stub dex jars provided by each module for that scope. Then
the widest stub dex jars were chosen. So, if module A provided public,
system and test stub dex jars and module B provided only public then
the stub dex jars for each scope would be:
* public -> A,B
* system -> A
* test -> A
So, the widest API scope for which there are stub dex jars is "test"
and so the widest stub dex jars would just come from module A and not
module B. So, when "hiddenapi list" is run for module C which depends
on modules A and B it only gets given stub dex jars for module A which
means that it cannot resolve all the types that C may use which can
lead to incorrect flags being generated.
This change does not merge the stub dex jars from each module together
and instead keeps them separate by module. The widest stub dex jars
list is constructed by asking each module in turn for their widest stub
dex jars. e.g. Given the above example we would have:
Module A:
* public
* system
* test <- widest
Module B:
* public <- widest
So, the widest stub dex jars will be A's test and B's public stub dex
jars.
Bug: 179354495
Test: m out/soong/hiddenapi-flags.csv
- make sure that this does not change the file.
Merged-In: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
Change-Id: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
(cherry picked from commit 280a31aac3)
The widest stub dex jars should include the widest stub dex jars
provided by each module. So, if module A has public, system and test
and module B has only public then the widest stub dex jars should
include module A's test and module B's public stub dex jars. Instead,
they just include module A's test.
That behaviour is needed so that when the "hiddenapi list" tool is run
against a module C that it is passed stub dex jars from both module A
and module B so that any references to the types provided by those APIs
can be resolved.
A follow up change will fix this issue.
Bug: 179354495
Test: m nothing
Merged-In: Ibd31964e8d2a33fa92fbd0b800c9fe054ee359c7
Change-Id: Ibd31964e8d2a33fa92fbd0b800c9fe054ee359c7
(cherry picked from commit d2b1e0ca92)
When generating the stub-flags.csv for a bootclasspath_fragment the
hiddenapi list tool is not given a complete set of all classes and
members. This change causes it to ignore them by passing the new
--fragment option to it.
This does not risk changing the flags as the stub-flags.csv files
created with the --fragment option are compared with the monolithic
out/soong/hiddenapi/hiddenapi-stub-flags.txt file which is not run
with this option to ensure that they match.
Bug: 179354495
Test: m out/soong/hiddenapi-stub-flags.csv
- make sure that this does not change the file.
Merged-In: I890c7374c445759cade4d685f51e81261b7ccea2
Change-Id: I890c7374c445759cade4d685f51e81261b7ccea2
(cherry picked from commit 156b5d3b61)
Previously, hidden API processing could only be done by those
bootclasspath_fragment modules that either did not depend on any other
fragments (e.g. art-bootclasspath-fragment) or only depended on APIs
provided by other fragments (e.g. i18n-bootclasspath-fragment). That
meant that modules like com.android.os.statsd-bootclasspath-fragment
that depended on APIs provided by parts of the platform which are not
yet part of another bootclasspath_fragment could not perform hidden
API processing.
This change adds support for a bootclasspath_fragment to specify the
additional stubs needed to perform hidden API processing. It adds a new
additional_stubs property that can be used to specify the additional
stub libraries.
Most bootclasspath_fragments that need to use the property will need
access to the APIs provided by the android-non-updatable.* libraries.
Rather than have each fragment explicitly specify the correct module
for each scope it treats "android-non-updatable" as if it was a
java_sdk_library that can provide different jars for each scope.
Soong will handle mapping that to the correct android-non-updatable.*
module.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv \
out/soong/hiddenapi/hiddenapi-index.csv \
out/soong/hiddenapi/hiddenapi-stub-flags.txt \
out/soong/hiddenapi/hiddenapi-unsupported.csv
- make sure that this change does not change the contents.
m TARGET_BUILD_APPS=Calendar nothing
Merged-In: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
(cherry picked from commit 5cca7c44e5)
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-stub-flags.txt
- check that an error is reported if a modular stub-flags.csv file,
i.e. one created by a fragment is not a subset of the monolithic
file, e.g. because a signature in the modular file has different
flags than it does in the monolithic or is not present there.
Merged-In: I46ebb495cb093a5e3abe7571c49933c845318549
Change-Id: I46ebb495cb093a5e3abe7571c49933c845318549
(cherry picked from commit 2e88097152)
Previously, the func created a rule and returned it for the caller to
create with the appropriate name and description. This change passes
the name and description into the func and causes it to create the rule
itself. The func is also renamed to make it more consistent with the
other similar rules.
Bug: 179354495
Test: m nothing
Merged-In: I2a4455daa8a6090ed5568994b255848d063e1ab2
Change-Id: I2a4455daa8a6090ed5568994b255848d063e1ab2
(cherry picked from commit 4539a37a61)
Add an apex_name property to prebuilt APEX modules to allow specifying
the "runtime" name of the APEX, i.e. the one it gets mounted as in /apex/,
which is also the one used for the apex variations.
Introduce a callback to retrieve that name consistently for all APEX
modules (apex, override_apex, prebuilt_apex, and apex_set), and update
some apex mutator code paths to use it.
For APEX source modules (apex and override_apex), it's necessary to add
a new field in apexBundle, since the name property gets overridden for
the override variant that override_apex creates.
Cherry-picked from https://r.android.com/1748294.
Test: m nothing
Bug: 191269918
Change-Id: If8612639bffdf91cbcab3387b0603bf5dffef1f5
Merged-In: If8612639bffdf91cbcab3387b0603bf5dffef1f5
Lint's NewApi checks currently produce a lot of false positive findings.
The filtered lint database removes information of classes defined by
mainline modules which are the cases that might become a false positive.
This commit updates soong to use this database instead of the normal one
when linting mainline modules.
Test: m lint-check
Fixes: 186478867
Change-Id: Ica646081b9189303c393b36b2f02914d69eee291
Merged-In: Ica646081b9189303c393b36b2f02914d69eee291
Although the hidden API runtime does not support a module-lib API flag
the hidden API processing does need to used them as they are needed by
the "hiddenapi list" tool for any bootclasspath_fragment module whose
contents builds against an sdk_version of "module_current". Without it
the "hiddenapi list" tool could fail to resolve references to classes
provided by other modules which would break the build.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Merged-In: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
Change-Id: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
(cherry picked from commit b51db2ed8e)
Adds a test to establish a baseline for a follow up change that adds
module_lib support to hidden API processing.
Bug: 179354495
Test: m nothing
Merged-In: I5630075825c674b2e4f38bd459c7b061c01fc362
Change-Id: I5630075825c674b2e4f38bd459c7b061c01fc362
(cherry picked from commit 48b6741510)
Previously, the hidden API processing used SdkKind to identify the API
scopes, e.g. public, system, etc. that are of interest for hidden API
processing. Unfortunately, there is a mismatch between the SdkKind and
what hidden API processing needs. e.g. SdkKind includes values that are
not used by hidden API processing and hidden API processing needs
additional API scope specific information not provided by SdkKind. The
apiScope struct used in sdk_library.go is also not a suitable
representation for similar reasons.
This change adds the HiddenAPIScope (following a similar approach as
apiScope) that rectifies that and uses it as a replacement for SdkKind
in most parts of the hidden API processing. The SdkKind is still used
for retrieving information from java_sdk_library[_import] modules.
Follow up changes will extend the HiddenAPIScope with more information.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Merged-In: I97968f58535121652852b8d25217aa288afd2bfd
Change-Id: I97968f58535121652852b8d25217aa288afd2bfd
(cherry picked from commit 31fad800a7)
Bug: http://b/189328402
This contains a fix to AArch64 __clear_cache.
Test: TH + Manual verification by emulator team.
Change-Id: Iff1064df8361163a6828b01256d5a7950f618652
Merged-In: Iff1064df8361163a6828b01256d5a7950f618652
(cherry picked from commit 3e54508a3a)
Previously whether prebuilt properties were customizable was dependent
on the order of calling various inits.
Test: go test soong tests
Bug: 191975220
Change-Id: Icaa1fe811a5f5fc4aa5fc9fa0ec0b90debe3d537
Merged-In: Icaa1fe811a5f5fc4aa5fc9fa0ec0b90debe3d537
(cherry picked from commit 69d6413dd0)
Bug: 158843648
Test: check if dexpreopt.config for the module defined in mk file has
DexPreoptImageLocationsOnDevice field
Change-Id: Idb2de398871ff114245393a9dd92b5a1b5c942e7
Merged-In: Idb2de398871ff114245393a9dd92b5a1b5c942e7
(cherry picked from commit e3165c8de3)
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
This is a workaround for a compiler bug that makes this combination
extremely slow to build.
Bug: 191808836
Test: m net_test_btm_iso with SANITIZE_TARGET=hwaddress
Merged-In: Ide7436bbc564413cb2f29355ada5286976607205
Change-Id: Ide7436bbc564413cb2f29355ada5286976607205
(cherry picked from commit b15a564869)
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)
Some codes assume that the first arch is the primary arch. But ndk/aml
arch order have been [arm, arm64, x86, x86_64]. This fixes the order to
workaround possible breakage while building ndk.
Bug: 187196593
Test: OUT_DIR=out build/soong/scripts/build-ndk-prebuilts.sh
Change-Id: I33164a7e7c64a23f2cc1860acb24a2584f4dffad
Merged-In: I33164a7e7c64a23f2cc1860acb24a2584f4dffad
To support init_first_stage, install_in_root property is added to
cc_binary. The output is installed to {partition}, rather than
{partition}/{mount_point}/bin.
Bug: 187196593
Test: build init_first_stage
Change-Id: Ibc351645308676ed188f748972eb6312c9cbd64f
Merged-In: Ibc351645308676ed188f748972eb6312c9cbd64f
This change adds a test for an sdk that includes a java_sdk_library
directly as well as transitively includes one of the component modules
that it creates. It also adds a test for the names of a versioned
java_sdk_library_import's components as fixing one requires fixing the
other.
The use case added is one that does occur in the art-module-sdk. It has
a couple of pairs of java_sdk_library and java_system_modules that
cause both the java_sdk_library and one of its component modules to be
included in the sdk snapshot. That causes problems when building
against prebuilts.
e.g. The art-module-sdk_art.module.public.api.stubs module is a
duplicate of the art.module.public.api.stubs module created by the
art.module.public.api java_sdk_library_import. The former is added
because the art-module-public-api-stubs-system-modules depends on it.
A follow up change will avoid the component being added to the sdk
snapshot separately and instead cause the snapshot to use the
component created by the java_sdk_library_import in the snapshot.
Bug: 179354495
Test: m nothing
Merged-In: Ifdc1b4a5a7968db2ded3fdb7eb02f9cff77c7c3f
Change-Id: Ifdc1b4a5a7968db2ded3fdb7eb02f9cff77c7c3f
(cherry picked from commit 3302871b7d)
Prebuilt modules do not provide classesJars containing annotations.
Previously, the monolithic hidden API processing just used classesJars
from all the modules that provided them so when building against
prebuilts would have fewer classesJars than when building against
sources and so would produce different hidden API flags.
This change will generate the monolithic files from both classesJars
and files previously generated from hidden API processing. A fragment
that has performed hidden API processing will contribute its generated
files whereas standalone libraries and fragments which have not
performed hidden API processing will contribute classesJars.
Bug: 177892522
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
m SOONG_CONFIG_art_module_source_build=false out/soong/hiddenapi/hiddenapi-flags.csv
- verify that the files are identical whether built from
source or prebuilts.
Merged-In: I06f3c7df49626bec21a452bc9abf1bb9e7545e5c
Change-Id: I06f3c7df49626bec21a452bc9abf1bb9e7545e5c
(cherry picked from commit d061d40eb6)
Adds a message parameter and allows leading spaces in the expected file
string to allow them to be nicely indented.
Bug: 177892522
Test: m nothing
Merged-In: I33df26610738c48879fa0b8250dc377dd04bb07d
Change-Id: I33df26610738c48879fa0b8250dc377dd04bb07d
(cherry picked from commit 51d7da2c4e)
Use classpath elements in newMonolithicHiddenAPIInfo. That means the
method can collate information from both fragments and libraries rather
than just fragments. So, this change moves the collation of the
classesJars into the method.
Bug: 177892522
Test: m out/soong/hiddenapi/hiddenapi-flags.csv out/soong/hiddenapi/hiddenapi-index.csv
- make sure that this change does not affect the contents.
Merged-In: I7c2a229fab60d02bd211438735a8d7303ed83386
Change-Id: I7c2a229fab60d02bd211438735a8d7303ed83386
(cherry picked from commit 89f570ac44)
