am skip reason: Change-Id I4490aa0a61fa71f830feb6a46dffd8d20fccfc66 with SHA-1 98c71228f1 is in history
Change-Id: Ie745342896635768f56e2806b64d4e3197328d6e
am skip reason: Change-Id I2b718cc1445c04e849dcb0b1f53bba2b0bd90c95 with SHA-1 649dadfb87 is in history
Change-Id: I73da5e0a9b25509d514cfd334313be347319f972
am skip reason: Change-Id Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49 with SHA-1 c91f5d0cc7 is in history
Change-Id: If55f001bbb8c07016dbeb130a35387a6aac226a6
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
Merged-In: I2b718cc1445c04e849dcb0b1f53bba2b0bd90c95
Change-Id: I2b718cc1445c04e849dcb0b1f53bba2b0bd90c95
(cherry picked from commit 649dadfb87)
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
(cherry picked from commit 9b879594ed)
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
(cherry picked from commit daaa332827)
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
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
Merged-In: Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49
Change-Id: Ib7c544b48dfb53bad3e15f9f73f71bd05cff9b49
(cherry picked from commit c91f5d0cc7)
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
am skip reason: Change-Id Ibe63352c2fc474dd816d87ac79b31a56d32b35d2 with SHA-1 5f6771e160 is in history
Change-Id: I61c2c14bd97c91ca18f8710d6980c7c7bd8e1677
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
