We have added a lot of metalava invocations since the highmem
differentation was added, most of which do not use a lot of memory.
By collecting data of max rss per process we have narrowed down
the set of highmem modules to a smaller set, and will annotate the
relevant modules as such.
Bug: 170701554
Test: NINJA_HIGHMEM_NUM_JOBS=3 m checkapi (no long tail of metalava)
Change-Id: Ic9c8c91388b02889111ef596fc6fd8bde9b42b9d
With this change, users don't need to figure out which libraries
actually hold the resources to be overlaid when targetting apps with a
core lib dependency (e.g. Settings, SystemUI).
Fixes: 169898727
Test: app_test.go
Change-Id: I3c3b9dc0a377b1828db1199858a73d080a173205
Add a property to support dependencies on JNI libraries for host
java binaries.
Fixes: 170389375
Test: TestBinary
Change-Id: Ieeca3c3997615f0b17ae1f058b94e6c9ba929cab
ctx.PrimaryModule() is wrong in the case of a java_binary that
supports both host and device, use an explicit dependency instead.
Once the dependency exists there is no need to manually request
the jar be installed, it will automatically be installed by the
host installation rules for dependencies.
Test: TestBinary
Change-Id: Iddeea2d08bc574c79d42139020558cd70d718ca1
This reverts commit 323dc60712.
Reason for revert: Possible cause of test instability
Bug: 170513220
Test: soong tests
Change-Id: Iee168e9fbb4210569e6cffcc23e60d111403abb8
Similar to Stubs_only_libs, this allows being a bit more specific
about what libs compile against what. In my usecase, it allows
removing a platform dependency from the appsearch stubs, which allows
the platform to depends on the stubs.
Bug: 169304493
Test: m
Change-Id: Ie997462819cd5266a761b2d415e81806c7877967
Merged-In: Ie997462819cd5266a761b2d415e81806c7877967
Putting t.Parallel() in each test makes them run in parallel.
Additional t.Parallel() could be added to each subtest, although
that requires making a local copy of the loop variable for
table driven tests.
Test: m checkbuild
Change-Id: I5d9869ead441093f4d7c5757f2447385333a95a4
Layoutlib requires access to the jar file (containing .class) files for
a number of libraries including "core-libart". It does that using the
{.jar} output tag, e.g. "core-libart{.jar}".
This change makes sure that works when "core-libart" is provided as a
java_import instead of a java_library.
Bug: 142938164
Test: m nothing
Change-Id: I605019d680c28e4a33f0ca14279d63fa62b9774b
This reverts commit 3666c7023f.
Reason for revert: This was originally reverted because it caused a breakage (b/167405890) in a branch that is no longer relevant.
Change-Id: I81063cd47b816b5b3c0ab8427432730d6b881a3f
This reverts commit 3a55c91f9d.
Reason for revert: build failed. Guess this is the cause but needs to confirm. Creating a revert per instructions
Change-Id: I30f1c8cd63e5ab84dba5d21ed354a42695c24ec4
Add a new helper SortedIntKeys similar to SortedStringKeys.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I08a43ec2cae7d1a82531295aca1a0658e3a0dd6f
Previously only the names were collected, and later used in the
manifest_fixer to add missing <uses-library> entries to the manifest.
Now we also need to collect build-time and on-device paths, to be used
in class loader context for dexpreopt. This commit only collects paths,
but does not pass them to dexpreopt yet.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I34b229ee68f16ba215ba03770feadb4d890ec2bf
The default is android.jar to maintain current behavior but allows users
to specify a different filepath to support generating api-versions for
docs other than the platform (e.g. auto).
Bug: 162552181
Test: m doc
Test: go test java_test
Change-Id: I9e51abaf7d5451d68ca782157d9b739f76c5da82
This will allow us to remove `create_stubs: false` throughout the
codebase easily, then remove the functionslity to create stubs from
droiddoc.
Test: m docs
Test: m checkapi
Test: m updateapi
Bug: 144248501
Bug: 143136634
Change-Id: Ib95f68bc064fbe1475e4b25433bee6292bc005dc
Previously, the prebuilt mutators were added by the
cc.RegisterRequiredBuildComponentsForTest() function as a convenience
but unfortunately it lead to some of the mutators being in a different
order in the tests than in the normal build.
This change:
* Extracts the RegisterPrebuiltMutators() call from
cc.RegisterRequiredBuildComponentsForTest()
* Makes sure that the prebuilt mutators are registered before the
visibility gatherer and enforcer mutators.
Bug: 162505935
Test: m nothing
Change-Id: I7d959b558200b502f0a5e4653c41ea01414e142a
When multiple os/arch variants are supported, java_test_host could not
find a matching arch due to java having arch:common, whereas native
binaries support a specific architecture. This change adds the property
`data_native_bins` in order to support binaries with the appropriate
os/arch variants.
Test: m FirmwareDtboVerification with data_native_bins
Test: forrest
Bug: 153848038
Change-Id: I45adebff0fde2811d5ef5620c697b97b768c951f
The property args is currently a string, but represents a collection of
arguments to metalava/doclava. This has resulted in variables being used
rather than default modules to share arguments.
Test: go test java_tests
Bug: 145644363
Change-Id: I670235e8f1cf19bfe8909049c4765637d0accd47
Previously, preferring a prebuilt of an sdk/module_exports's member
would cause the sdk/module_exports to depend on the prebuilt instead
of the source and cause problems with the build.
This chance prevents the dependency from an sdk/module_exports to its
members from being replaced with prebuilts.
Bug: 160785918
Test: m nothing
Change-Id: Iee4bcd438c11929e30fb5766701b05a0e89956d9
Previously, when java_sdk_library_import was preferred over a
java_sdk_library the latter ends up depending on the prebuilt child
modules created by the java_sdk_library_import instead of the source
child modules that it created itself. That was because all dependencies
on those source child modules were replaced with the corresponding
prebuilt child modules.
This change prevents those dependencies from being replaced to preserve
the dependencies from java_sdk_library onto its source child modules by
making the replacement conditional depending on the tag used. It also
updates the affected test.
Bug: 159902351
Test: m nothing
Change-Id: I4441b901dedfd44b9769df1ac2e248b94834cf85
Previously, java_sdk_library_import added the dependencies on its child
components in the deps mutator after prebuilts without a matching
source module are renamed to the source module name. That meant that
the java_sdk_library_import has to use the source module name and ended
up depending on the source module unless it was preferred.
This change adds a new component deps mutator that runs before the
PrebuiltRenameMutator so that the java_sdk_library_import can add
dependencies onto the prebuilt modules. It also updates an affected
test.
Bug: 159902351
Test: m nothing
Change-Id: I3576c4873302743e51aff547ea1497bef6d748ac
Adds some tests to track the current dependencies between
java_sdk_library, java_sdk_library_import and their child modules in
various configurations. This is in preparation for a series of changes
that will update the dependencies to ensure that the java_sdk_library
always depends on the source modules that it creates and
java_sdk_library_import always depends on the prebuilt modules that it
creates.
Comments in the tests highlight the parts that will be affected by the
follow up changes.
Bug: 159902351
Test: m nothing
Change-Id: I8eea3ac80061f5cbbc9dec201750c4b59e224b4b
Now that tests don't need to specify every path passed to
PathForSource or PathForModuleSrc, remove most of them from
java.TestConfig. Leave a few that are globbed by lots of tests,
and move a few that are globbed by a single test into the tests.
Test: all soong tests
Change-Id: Ica91d7203a6a7dbca0fd4fed84c78f149b8699e1
Previously, when a lib that doesn't have sdk_version property set
depends on a java_sdk_library, the impl library was used for linking.
This might be too permissive because the client lib might be using empty
sdk_version because it needed some private APIs from the platform, but
not from the java_sdk_library. This actually happend for some of the CTS
tests. They don't set sdk_version, but were directly depending on
android.test.[base|runner|mock].stubs libraries. If we switch the
references to the stub libraries into the corresponding java_sdk_library
modules (e.g. aandroid.test.[base|runner|mock]), then we would be
allowing private APIs to the CTS tests, which is not good.
To solve this problem, default_to_stub property is introduced. It when set
to true prevents the impl lib from being used for linking. When a module
that doesn't have sdk_version depends on it, the widest API surface that
the java_sdk_library provides is linked instead.
Bug: 157007292
Test: m
Change-Id: Id2acc3cafb71d1e90d4fdc9c0c70a73983355e0f
The implementation jars are not built if api_only: true. In that case
the jar paths must not be exposed implicitly as they will be nil and
they will just be ignored.
This change ensures that stubs are returned when the implementation
jars are not built.
Bug: 155164730
Test: m droid
Change-Id: Ic495982a5dcb2754916260e7d91d921a5da288ae
Previously, all java_sdk_library instances were assumed to be usable as
shared libraries, i.e. referenced from <uses-library> in Android
manifest. However, that was not true for any instances that specified
api_only: true and will not be true for many of the new Android
modules.
One consequence of this assumption is that use of one of the api_only
instances could (but fortunately does not appear to) have lead to an
invalid library being referenced in an app's manifest which would
prevent the app from loading. That would have been done automatically
by the implicit sdk library tracking and manifest fixing mechanism and
there would have been nothing a developer could have done about it.
Changes:
1) Prevents api_only instances from participating in the automatic
tracking which will prevent them from being added to Android
manifests and breaking apps.
2) Add a new shared_library property that can have the same effect as
api_only while still creating a runtime implementation library.
3) Renamed commonProperties to commonSdkLibraryProperties to
disambiguate it from the ModuleBase.commonProperties field.
4) Extracts requiresRuntimeImplementationLibrary() to remove duplicate
code accessing the Api_only property.
5) Tests for the api_only and shared_library behaviours.
Test: m nothing - added tests, tests broke, fixed code, tests passed.
Bug: 156723295
Change-Id: Iccf509e808d5ff53522188541a4c54d8f9ada93c
The build tracks the java_sdk_library/_import modules that are
referenced by libraries so that it can ensure that any Android app that
includes code that depends on one of those modules has the appropriate
<uses-library> entry in their manifest.
Unfortunately, there were a couple of issues with that:
1) It only tracks direct references to the java_sdk_library module
itself, e.g. android.test.mock. Direct references to the stubs
module, e.g. android.test.mock.stubs were not tracked. Making it
possible for Android apps to reference libraries which would not be
available at runtime.
2) The logic for determining whether something was a java_sdk_library
was repeated in a number of places making it difficult to allow
java_sdk_library/_import instances to determine whether they should
be treated as an Android shared library.
3) It tracks (and could use) even those java_sdk_library instances
which do not represent a shared library, e.g. the ones that set
api_only: true. While this change will simplifty fixing that the
actual issue will be fixed in a follow up change.
Changes:
* Added EmbeddableSdkLibraryComponent and embedded it into
java_sdk_library/_import, java_library and java_import. It provides
the common code to minimize duplication. It contains an
SdkLibraryToImplicitlyTrack field that if set will cause any
references to the containing module to add the SdkLibraryParent to
the list of implicit sdk libraries being tracked.
* Changed code that assumed that anything that implemented
SdkLibraryDependency required tracking to use the
OptionalImplicitSdkLibrary() method to get the optional name of the
sdk library to track. That will allow a follow up change to return
nil from that method to exclude an sdk library from being tracked.
* Moved SdkLibraryDependency from java.go to sdk_library.go as that is
a better place for it to be.
* Changed the stubs java_library/java_import creation code to initialize
the SdkLibraryToImplicitlyTrack field with the name of the creating
module.
* Initialized the SdkLibraryToImplicitlyTrack field in the
java_sdk_library/_import so that direct references to them will be
tracked too.
* Added tests to verify that direct access to the .stubs child of both
java_sdk_library and java_sdk_library_import are tracked properly.
Test: atest CtsProviderTestCases - which relies on android.test.mock
being implicitly tracked to verify that I had not broken
anything. Used aapt2 dump badging to read the manifest.
m nothing - to run the new tests which failed before fixing the
code.
Bug: 156723295
Change-Id: Ia99def91e9b74d2ed0a777de04b476c00ea0393d
Previously, in order to access say the public stubs source jar it was
necessary to directly reference the module by name. This change adds
support for accessing them indirectly via tags.
Test: nothing
Bug: 155164730
Change-Id: Id6d76e56c7b46944b2d2a44a2163fb05a5b03de9
The scopePaths struct is used by both java_sdk_library and its prebuilt
but was not populated in the same way. This change addresses those
discrepancies in preparation for a follow up change which will allow
access to some of those fields through OutputFileProvider.
Changes:
* Document the scopePaths field and struct.
* Switch those fields that may not be fully populated from Paths to
OptionalPath to make that 100% clear and protect against unchecked
use.
* Switch java_sdk_library_import to use the dependency extraction
mechanism driven by the dependency tag. This should actually have
been part of the change that added that mechanism.
* Only create prebuilt_stubs_sources if sources have been provided.
* Add dependencies from java_sdk_library_import on its stubs source
child modules if sources have been provided. That will ensure the
stubsSrcJar field is updated.
* Updates current/removedApiFilePath if provided for the scope in
java_sdk_library_import.
* Extracts ApiStubsSrcProvider from ApiStubsProvider to allow it to
be implemented by PrebuiltStubsSources so that it can provide access
to the stubs src jar that it creates.
Test: m nothing
Bug: 148080325
Bug: 155164730
Change-Id: Ic5bf884b2b1e79841843e7c3b4642796ecd49f5d
Previously, when using sdk_version: "module_current" any direct
reference to an sdk library would use the public not module-lib stubs.
This change corrects that.
Prior to the addition of the module-lib api scope almost all
java_sdk_library instances supported all the scopes to which a request
for jars could be redirected, i.e. public, system and test. The
exceptions to that are a few special instances that were used with
sdk_version: "none" and so were either caught by the java_sdk_library
special cases or dropped through to public.
The addition of module-lib, plus the flexible control over which scopes
are generated means that is no longer true. It is possible for a
java_sdk_library to be requested for a scope it does not have which
would have resulted in an empty set of paths being returned leading to
confusing compilation errors.
To avoid that this change also adds support for using the inheritance
hierarchy defined by the apiScope.extends field to fall back to the
closest available surface.
Test: m nothing
Bug: 155164730
Change-Id: I6aab75a772433ee0a36b6f1758a4aec4be2f9a49
Allow the sdk_version against which the stubs for a scope are compiled
to be specified in the module on a per scope basis.
Bug: 155164730
Test: m nothing
Change-Id: I5881e5ee7c2169c30f544882344a60a602dae917
The constants are only used in one place in the code and in the test.
This change switches the test code to use the apiScope methods to
generate the names and then inlines the constants in those methods. It
makes it easier to see the naming convention.
Test: m nothing
Bug: 155480189
Change-Id: I966e82b8ae67624da168e05f5a2b062b832cb8cd
Adds a per scope set of properties that allows explicit control over
the API surfaces generated.
Previously, the term active was used to determine whether it was
generated but that was a little abstract and unclear so has been
replaced by generated.
Test: m nothing
Bug: 155164730
Change-Id: I7539d89618b61f6b9d1a4b60cc3f9614b157f0d9
Move the NDK modules defined in app_test.go into cc/testing.go in
preparation for using sdk_version: "current" in more tests.
Test: all soong tests
Change-Id: I80bc31225fb4562fce42781219cefbbd6affae06
Previously, there were some places where a java_system_module_import
could not be used in place of a java_system_module. That was because
the code assumed a *SystemModules type not a *systemModulesImport type.
This change introduces a SystemModulesProvider interface that is used
instead and is implemented on both types.
Bug: 142940300
Test: m nothing
ran new tests before changes to make sure they detected the issue
and after to make sure the changes fixed the issue.
Change-Id: I7b16ac5708880bdf61e6f5b1e6616c986f0ed763
