Most dependencies on java_sdk_library instances (JSL) simply reference
them by name and rely on the build to pick the correct part, impl,
stubs for a specific scope, headers or implementation jars or dex jars.
Generally, the build gets that decision right. If it does not the for
most of the components of the JSL there is a way to reference them
directly. However, that is not true for the implementation library as
that is created the JSL itself.
Access to the implementation library should be avoided as it opens up
the possibility that use will be made of an API that is not tracked and
maintained which could lead to compatibility issues. However, there is
a case where use of the implementation library is required and safe.
That is when it is being used from other libraries within the same APEX
as the JSL. In that case the JSL and its dependencies will be updated
together so compatibility is not an issue.
This change adds a new <module>.impl java_library that compiles the
implementation library in the same way as the JSL itself does. This will
allow the modules that are blocked from converting to JSL because of
this limitation to progress. Initially the library is only for use
for compiling but follow up changes will switch the rest of the build
from using the implementation library created by JSL to the separate
module.
It also adds the ability to give the separate .impl library a more
restrictive visibility than the JSL further limiting misuse.
Bug: 156618935
Test: m droid, flash, atest CtsProviderTestCases - sniff test
tested that it fixes compilation issues with mainline module
Change-Id: Ifc4799feb4ada9dec8021efc13fe6a953bf2edd3
Filenames specified in the "symlinks" property are passed to
LOCAL_MODULE_SYMLINKS, and kati would install these symlinks.
For example:
```
prebuilt_etc {
name: "foo",
symlinks: [
"bar",
"baz",
],
}
```
Installs these files on device:
- system/etc/foo
- system/etc/bar -> foo
- system/etc/baz -> foo
Bug: 157537895
Test: Add some symlinks to a prebuilt_etc module and check artifact
Change-Id: If50844e8a212a966be931117cfdff5bf73aadf25
Drop down to a single high-mem task when we've got <=16GB, as the system
probably isn't completely free RAM, ninja will be using a couple gigs,
along with whatever "normal" actions will be running concurrently. So
it's unlikely that we can handle two 6-8GB actions along with everything
else.
Also print warnings when we detect <=16GB total RAM, or when we're
running more parallel jobs than than we have GB RAM. These both notify
the user and suggest lowering the `-j` value if they run into problems.
Test: fake totalRAM to [0.5,8,16]GB, checking warning
Test: fake totalRAM to 17GB, `m -j4 nothing` has no warning
Test: `m -j187 nothing` on a 188GB system
Test: `m -j188 nothing` on a 188GB system
Change-Id: Ieb008e9f462d5f40fb65781d94cf116b1caf8446
I made a mistake and only fixed android_test_import in my previous
change, I5bbb2d2b733bbd6b868898285683ba5ff45be10b.
Bug: 154281342
Test: TreeHugger
Test: chromium-webview
Change-Id: I1575d9ef3f8596f1eb8db0867db09de08945d711
Previously, droiddoc was using SdkImplementationJars() to get a JAR to
add to the classpath in order to resolve unknown references in the
source.
Given that SdkHeaderJars() returns jars created by Turbine which are
(for compilation at least) functionally identical to the implementation
jars there is no point in using the implementation jars.
Bug: 148080325
Test: m nothing
Change-Id: I2b718cc1445c04e849dcb0b1f53bba2b0bd90c95
Access to the implementation JARs is restricted to avoid code from
depending on implementation details that could change from one release
to the next which could cause compatibility issues. That is not a
problem when referenced from within the APEX that contains the
java_sdk_library.
As references from within the same APEX often need to access
implementation specific details of the java_sdk_library and doing that
from within the same APEX is safe this change all references to a
java_sdk_library made within the same APEX to use the implementation
jars instead of stub jars.
Bug: 155164730
Test: m droid
Change-Id: If239059690de61683c2ad2d8a0ce2e47286a3637
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
Since the metalava invocations have been merged into a single one,
and checkapi already requires the other timestamp, this has no effect.
Bug: 151160048
Test: m checkapi
Change-Id: I560058f0f4cdeaedaf247cd35119da2cf0b86ea0
Adds support to translate app prebuilt tests to android_test_import and
LOCAL_REPLACE_PREBUILT_APK_INSTALLED to preprocessed property.
Test: androidmk_test.go, bpfix_test.go
Bug: 155412211
Change-Id: I77c07c684125adf228ba91911998823a68b3a65d
apex_available/min_sdk_version are required to be available for mainline
modules(APK/APEX).
- java_import/java_library_static
- android_library/android_library_import
Bug: 156996905
Test: prebuilts/sdk/update_prebuilts.sh
Change-Id: I201ebabaa533c5ee19e394ab30ca2fa0e3d7ce0e
The expression !sdkVersion.specified() is equivalent to the following:
!sdkVersion.valid() || sdkVersion.kind == sdkPrivate
That means that the else if clause "sdkVersion.kind == sdkPrivate" will
never be reached so it was removed.
There is also no need to check sdkVersion.valid() as that will already
have been checked, and an error reported, before this code has been
called. Therefore that has been removed.
Bug: 148080325
Test: m nothing
Change-Id: Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49
If set to true, preprocessed indicates that the prebuilt apk is
installable as is and does not need any further processing (e.g.
zipaligning, signing).
Test: app_test.go
Bug: 155412211
Change-Id: If0c27c1e340c1bdb270064f636dc6bf33a0fc949
ART tests need to explicitly control the compression.
Bug: 157239179
Test: "atest ArtGtestsTarget" with http://go/aog/1302773
Change-Id: I4490aa0a61fa71f830feb6a46dffd8d20fccfc66
Merged-In: I4490aa0a61fa71f830feb6a46dffd8d20fccfc66
Paul Duffin