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)
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)
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)
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)
The configuration of the bootclasspath, e.g. PRODUCT_BOOT_JARS,
includes libraries that are standalone and libraries that are part of
an APEX. All libraries that are part of an APEX must also be part of a
bootclasspath_fragment. Currently, the libraries and fragments are
handled separately but that is limiting as it does not make it easy to
process all the libraries while treating those from fragments
differently to standalone libraries. That is needed for hidden API
processing as it needs to use classesJars from standalone libraries
but pre-generated flag files from fragments.
This change adds support for ClasspathElements which is represents the
classpath as a whole while differentiating between standalone libraries
and fragments.
Bug: 177892522
Test: m nothing
Merged-In: I7a4adc67164a46079eb8ec0a17fc755044b4949d
Change-Id: I7a4adc67164a46079eb8ec0a17fc755044b4949d
(cherry picked from commit e245b61aa2)
While this seems like a simple refactoring it does actually fix an
issue. Previously, when the ExtraEntries func was being defined inline
within the for ... loop it used the loop variable "fi". Unfortunately,
that meant that the func created on each iteration ended up using the
value for "fi" that was set on the last iteration.
Extracting the creation of the entry into a separate method means that
each func created gets its own "fi" variable with the correct values.
Bug: 177892522
Test: m SOONG_CONFIG_art_module_source_build=false nothing
- without this change it reported duplicate rules for apache-xml.jar
which is the last entry in the art-bootclasspath-fragment. With
this change it works fine.
Merged-In: Ia063b513f758e1bbe73407c0441b72453f412acf
Change-Id: Ia063b513f758e1bbe73407c0441b72453f412acf
(cherry picked from commit 155c17779c)
Previously, the prebuilt art-bootclasspath-fragment did not provide any
boot image files. That meant it was impossible to build any module that
requires access to those files from prebuilts, e.g. any module that
needs to be dexpreopt-ed.
This change enables that module to retrieve those files from the
prebuilt_apex.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Merged-In: I1d4d9545172d79282918130df6b9aa55471bffc1
Change-Id: I1d4d9545172d79282918130df6b9aa55471bffc1
(cherry picked from commit 5466a3699c)
Previously, the boot dex jars were only copied to the predefined
locations used by the build from the source art-bootclasspath-fragment
if it was preferred, otherwise no files were copied. That caused build
failures when attempting to build with ART prebuilts. This change
copies the files from prebuilts too.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Merged-In: I35b37355170546daf6ecac2134d1ca9a73d0e3bc
Change-Id: I35b37355170546daf6ecac2134d1ca9a73d0e3bc
(cherry picked from commit ce918b0278)
Previously, the rules to perform hidden API encoding were generated
separately to the rules to perform hidden API flag generation. This
change combines them within the (renamed) produceHiddenAPIOutput()
method and makes the paths to the encoded dex files an output of the
generateHiddenAPIBuildActions method alongside the paths to the
generated flag files.
As encoded dex jars are now an output of the produceHiddenAPIOutput()
method which is implemented for both prebuilts and source
bootclasspath_fragment modules that necessitated the prebuilt also
providing paths to encoded dex files. That in turn required updates to
some of the tests to provide dex files from prebuilt_apex modules.
Similarly, as the produceHiddenAPIOutput() method may not be called
for some bootclasspath_fragment modules as they do not yet provide all
the information needed to perform hidden API encoding then it is
necessary to extract the encoded dex files produced by the modules
themselves. That also required a few changes to tests that did not
previously provide dex files.
Bug: 177892522
Test: m com.android.art
- check that this change does not change the contents of the apex
file, i.e. is byte-for-byte identical.
Merged-In: I60996a34d06ed1c87ed244ab3509621999ad86ec
Change-Id: I60996a34d06ed1c87ed244ab3509621999ad86ec
(cherry picked from commit e521881bd4)
Fixes test issues caused by a jar containing a classes.dex file was
copied to a place that was expected a jar containing class files.
Bug: 191360201
Test: - in master-art
find out/ -name \*core-icu4j\* | xargs rm -fr
art/tools/buildbot-build.sh --target --installclean
art/tools/bootjars.sh --path --core
- examine file output from previous script for core-icu4j,
before this change it contained classes.dex file after this
change it contained *.class files.
Merged-In: I05ecf652535ec097125fb76d6ca80fee6587f98d
Change-Id: I05ecf652535ec097125fb76d6ca80fee6587f98d
(cherry picked from commit 85fa344d09)
Previously, the apex variants of modules exported from prebuilt_apex
and apex_set modules were not exported to make. Neither by the modules
themselves or by the prebuilt apex module. The master-art build relied
on the platform variants of the conscrypt and core-icu4j libraries
being exported to make so that they could be used by vogar.
Unfortunately, a change to export the prebuilt_bootclasspath_fragment
modules that contain the conscrypt and core-icu4j prebuilt libraries
from the corresponding prebuilt_apex prevented the platform variants
of those libraries from being exported at all which broke the
master-art builds as it only has prebuilts of those modules. It did not
break the aosp/master build as that has source modules.
The difference between the two builds is that the apex module type
makes its contents available in make but the prebuilt_apex/apex_set
module types do not.
This change causes the prebuilt_apex/apex_set module types to behave
more like the apex module type by making its exported libraries
available in make.
Bug: 179354495
Test: m droid
- in aosp/master
art/tools/buildbot-build.sh --target --installclean
- in master-art and aosp/master
Merged-In: I57537d17d4920d37d896ed491c6aaa15302cb25d
Change-Id: I57537d17d4920d37d896ed491c6aaa15302cb25d
(cherry picked from commit a35f8db127)
Previously, the prebuilt_apex/apex_set did not have an apex specific
variant created which meant that they depended upon the platform
variant of the modules it depended upon. This change creates an
apex variant for them just as is done for the apex module type which
causes it to depend upon the apex specific variant of the modules it
depends upon.
Test: m droid
Bug: 179354495
Merged-In: I7d6f3609c267b3e90b90b9befe7d76f351a0c2bd
Change-Id: I7d6f3609c267b3e90b90b9befe7d76f351a0c2bd
(cherry picked from commit 6717d88f46)
Moves common properties, fields and method into the prebuiltCommon
type.
One slight change is that this change causes the Prebuilt module to use
the outputApex when generating the AndroidMkEntries instead of the
inputApex that it used before. They are the exact same files as the
inputApex is simply copied to the outputApex. The only impact will be
on build time as some rules now depend on the cp rule being run when
they did not before and the base name of the file may be different.
Test: m droid
- check generated out/soong/Android...mk file before and after
to make sure the only difference is due to switching from the
inputApex to outputApex.
Bug: 179354495
Change-Id: I8437af00d6bb7d0d339f25b3b02cd1cf67d6938a
Merged-In: I8437af00d6bb7d0d339f25b3b02cd1cf67d6938a
Previously, copyBootJarsToPredefinedLocations relied on all its
parameters having the same length and the same order. That made it
quite fragile as changes to one of the parameters without corresponding
changes to the other would cause failures. It also combined the
retrieval of the boot dex jars from the modules, handling of missing
boot dex jar files and the generation of the rules to copy the files.
This change separates the retrieval of boot dex jars and handling of
missing files from the copying of those files while at the same time
making the function less fragile by replacing the three ordered
parameters with two maps that shared common keys.
Bug: 179354495
Test: m nothing
Merged-In: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
Change-Id: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
(cherry picked from commit 5f148ca7cf)
Move the bootclasspath_fragment to be part of an apex to match how they
are expected to be used. Also adds the bar library to the boot jars
config as every module in a bootclasspath_fragment that is referenced
from a platform_bootclasspath module is expected to be in the config.
Bug: 179354495
Test: m nothing
Merged-In: I6f826dce9c006d630ee31d4171fe6fb458cc9442
Change-Id: I6f826dce9c006d630ee31d4171fe6fb458cc9442
(cherry picked from commit dc3f9566a2)
This test checks that fragments which are referenced from a
platform_bootclasspath module contribute their hidden API flags to those
used by platform_bootclasspath module. Previously, it was unrealistic
because the bootclasspath_fragment does not belong in an APEX.
This change moves the test from the java package to the apex package to
allow it to be modified to make the bootclasspath_fragment part of an
apex.
Bug: 179354495
Test: m nothing
Merged-In: Icb57f2e1eaea4b14aab5f47f3af7d05ea0555816
Change-Id: Icb57f2e1eaea4b14aab5f47f3af7d05ea0555816
(cherry picked from commit ffa8375f07)
In order not to introduce any changes in the system image default value
of generate_hashtree is currently set to false. Once all the APEXes that
shouldn't have hashtree enable (i.e. non-updatable ones) explicitly set
`generate_hashtree: false` default value will be switched to true.
Test: checked that are no diffs between ${OUT}/system/apex without this
change and with this change.
Test: m
Bug: 190621617
Change-Id: I5a3144f8f6ea7dee25678af43e2b07a8c85daa9e
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 c33e5216f1)
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 58e0e769c9)
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 f1b358cb57)
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 54c98f5b4a)
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 1a8010a241)
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
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 f2fa0b5e8e)
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
- 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 333a1732b1)
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 14e49130bb)
The destination path, i.e. the path the file will occupy in the APEX is
more stable and less likely to change than the source path, i.e. the
path of the file in the out or source directories. This makes it easier
to diff changes in the copy commands.
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
- verify that this does change the order of copy_commands for the above apexes
Merged-In: Ia9ebe8418c59903cd738ee0fb9262b3f32a4ddbf
Change-Id: Ia9ebe8418c59903cd738ee0fb9262b3f32a4ddbf
(cherry picked from commit 5606029007)
Instead of encoding the hidden API with an empty set of flags when the
monolithic flags are not available this simply disables encoding
altogether which should have the same behavior at runtime.
This change also removes the unused flags field in hiddenAPISingleton
which was set but never read.
Bug: 179354495
Test: m nothing
Change-Id: I32d5825e5271829993dd4e5be4d4ee1b22fa7b22
Previously, the monolithic hidden API files, e.g. hiddenapi-index.csv
file, were generated in two steps. First, each module created its own
files using the information in its class jars. Then, the monolithic
files were created by merging those module specific files into a larger
file.
This change switches to generating the monolithic files directly from
the class jar files and bypassing the intermediate files.
In order to ensure that this change did not change the monolithic files
it is necessary for the hiddenapi-metadata.csv to go through a
reformatting step. Hopefully, this will be able to be removed in a
follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I5a78e747516014b7c0f402a4b4431b14be6a84b2
