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
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)
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, 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)
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
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
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
Pedro Loureiro