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
The commonSdkLibraryAndImportModule defines the methods that a module
which embeds the commonToSdkLibraryAndImport struct need to provide.
Bug: 179354495
Test: m nothing
Change-Id: I7a469ae03ea5c19922200284da08a9ae38a46751
Added test demonstrates the error case. The bug was that java modules'
ShouldSupportSdkVersion() converts min_sdk_version into effective
version before comparison, which discards "preview" version into
"future" version. That caused a weird case like rejecting with error
"should support "S"" even when it is set to "S".
Bug: n/a
Test: m nothing
Change-Id: Ieb53f0097b2969a8535778b1286dbfa0d4895ad4
Some modules use -XepDisableAllChecks to disable errorprone.
However, this still causes them to be compiled twice when
RUN_ERROR_PRONE is true. Allow the new enabled property to
be set to false to disable errorprone entirely, so that those
modules are only compiled once.
Bug: 190944875
Test: New unit tests
Change-Id: Ie68695db762fffcaf11bbbcb0509c4fcab73f5c5
Currently, errorprone is only run if the RUN_ERROR_PRONE
enviornment variable is true. Add a flag that individual
modules can use to always enable errorprone.
In a followup cl, I plan to add another flag that will
force all errorprone checks to be errors, so that modules
can be confident that they're not ignoring any errorprone
checks.
Bug: 190944875
Test: New unit test and manually
Change-Id: Iab0c81642ed22a736add054147829e91a891d179
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
Merged-In: Ic519ffa0c5b616abddf15b41c934421dfac2e78a
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
Change-Id: If74baad5659301ca6ca9c0f6484374420dda8c34
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
Change-Id: I913416b4836766de194203fd8ed5124b61dfa3dd
These two methods did very similar jobs and merging them together
simplifies the behavior.
Bug: 179354495
Test: m droid
Change-Id: Ibe1a23d54105e6a0e5693079cd8743679301fc85
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
Change-Id: Ief8136fa9e98600cdd8d36108ec22edc2ebd7c69
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
