Removes use of the special framework-modules naming scheme.
Bug: 155164730
Test: m java
Exempt-From-Owner-Approval: Build cleanup.
Change-Id: I3b78fcbcacc3df787e171d6eedeef1e51b087615
Merged-In: I0c31e2183353dfb5bd49f04f3455cb7b10be6866
(cherry picked from 8b864fb45ce79051437f13c2a19510718ea3b7aa)
Switching from java_library to java_sdk_library switched the meaning
of the module name from referring to the implementation library to
referring to the stubs. This change updates the visibility rules to
reflect that new meaning.
Visibility rules that were previously set for the java_library have
been moved to the impl_library_visibility property and the special
//visibility:override value has been prepended to prevent it from
inheriting the values from the visibility property.
Visibility rules set for the stubs (via stubs_library_visibility)
property have been moved to the visibility property.
Bug: 155164730
Test: m nothing
Exempt-From-Owner-Approval: Build cleanup
Change-Id: Icc9bc5a9ef86cf7ba0f15c2b2a4abd596ec9f640
The names of the individual modules do not quite follow the pattern
that java_sdk_library uses so this temporarily sets the following:
naming_scheme: "frameworks-modules"
That causes java_sdk_library to use a naming scheme that matches the
one used by the individual modules of this. It will be cleaned up
later.
Part of the purpose of the java_sdk_library is to hide the
implementation code and force users of the library to depend on stubs
for a well defined API. Ideally, it would allow access to the
implementation in those cases where it is safe, e.g. from within the
same APEX, or from tests for the implementation. Unfortunately, due to
limitations in the build it does not yet have enough information to
make that decision correctly which means that any code that needs to
compile against the implementation is broken which would prevent us
from converting the module to java_sdk_library.
However, the only way to provide the additional information to allow
the implementation to be correctly exposed is to convert the modules
to java_sdk_library; a cycle.
In order to break that cycle the java_sdk_library creates a special
<module>.impl target which is used directly by tests and any other code
that needs it. Once all the modules have been converted to a
java_sdk_library then we can resolve the limitations in the build and
remove the direct references to <module>.impl.
Test: m Tethering InProcessTethering checkapi
Bug: 155164730
Merged-In: If5c115f482751f9f4b5f047e9e401a18e36799ef
Change-Id: Id1c2e848430c49a2da7402244814cd084f5da77c
Merge the otherwise unused tethering-aidl-interfaces into
framework-tethering.
This is in preparation for converting to use java_sdk_library.
Bug: 155164730
Test: m droid
Merged-In: I4583539d11ba69320aa5a0dfcfee072c81affac2
Change-Id: I4583539d11ba69320aa5a0dfcfee072c81affac2
(cherry picked from commit 267dd95c3e93f75c42c3f4e5cf576829b528f6c2)
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 145796956
Bug: 150999716
Test: m
Merged-In: Ifaecb49a47a1f43edea3ea06e1cf704a177d1044
Change-Id: Ifaecb49a47a1f43edea3ea06e1cf704a177d1044
(cherry picked from commit 33aa294e96f13906f596e427b96652fe80cf199b)
This adds checking of module api compatibility to the individual module
api rules. Until now, this checking has been done via the monolithic
metalava runs which we are aiming to get rid of.
Now is a good time to do this because we can compare them to the just
finalized version 30 API, which we have no diffs with. Baseline the
existing wifi failures that metalava fails to find in the previous API.
Bug: 144149403
Test: m checkapi
Change-Id: Id222895daa3a769c265965b052a17d5a1ca18462
This makes the filenames of the disted artifacts (api txts and stubs)
match the module name of the modules they're from. This matches the
naming scheme used by java_sdk_library, which should make the future
transition to this build rule easier.
Bug: 149293194
Test: lunch sdk_phone_armv7 && m sdk dist && find out/dist/apistubs
Change-Id: I076f30931bf2524d57703873cd7de25b3f23b457
It was using the systemapi stub defaults, but should be using the
module_lib default.
Bug: 144149403
Test: m
Change-Id: Iaab154d9d71900284d92d518a086fc1227c00d5c
With b/152655547, all aidl_interface modules are considered as stable
unless it is explicitly with "unstable: true". This change marks the
aidl_interface that are not used across updatable module bounraries
as unstable, so that the build system does not run the API
dumping/checking on them.
Bug: 152655547
Test: m
Change-Id: I1257c66de6dd42b2d32d47ed74cb2878f79d14fb
This filegroups strips the "src" prefix away from the src path
for the filter_packages check in droiddoc.
Bug: 149293194
Test: m update-api (no change)
Change-Id: I5b9ffa211be9c1a7dd8f63d5e7ba2a825d0d3190
Makes it convenient to change all stubs from a central place.
Bug: 149293194
Test: m framework-tethering-stubs{public,system,module_libs_}api
Change-Id: I330133824e78b3a8927e3d3ffbbd729bcdcb8822
Add separate publicapi, systemapi and module_libs stubs for tethering.
Bug: 147768409
Test: m
Test: m framework-tethering-stubs-{public,system,module_libs_}api
Change-Id: I0ed44691b4e7080818442a9d0eb37d874f707195
We don't want new modules exposing stable aidl directly. APIs should
be defined as java @SystemApi. It also seems like nothing actually
depend on these interfaces, except one simple exception.
Bug: 147200698
Test: m
Change-Id: Ia4222fa35a9a2f3c75cebb12f75c536f27e2fe16
Annotations such as @SystemApi cannot be jarjared to a different
package, as the members would not match the system API declarations.
Instead, only build against the annotations from
framework-annotations-lib, but do not include them as classes in the
output jar; annotations are not required to be available to the
classloader at runtime.
Test: builds, boots, tethering working
Bug: 147812912
Fixes: 148609988
Change-Id: I1fae97a1c1e0ba07fa3e2d64cde7650cd26d0acd
The non-updatable part of the platform now is built with
framework-tethering-stub, which is a stub library of
framework-tethering.
Bug: 147200698
Test: m
Change-Id: I97ef83f7f9b4c1376f373713036f5256318f1050
Add a onClientsChanged callback to OnTetheringEventCallback.
The callback will provide information on connected clients combining
at least DHCP leases and WiFi AP information (WiFi AP tethering used).
Test: atest TetheringTests
Bug: 135411507
Change-Id: I7065d081c11bc606d691f76ac8b499dd075d6504
This is initial work to allow caller to pass their prefered
configuration to start tethering. Caller may able to specify the
downstream interface ipv4 address with dhcp server disabled for
static IP configuration, or able to exempt entitlement check if
they have permission in follow up CL.
Bug: 141256482
Test: -atest TetheringTest
-ON/OFF wifi tethering
Change-Id: Ic7c3a33195bbd7e72f9b8e73fa148be476b87bf3
Also deprecated tethering APIs in ConnectivityManager.
Will have follow up change to remove @hide tethering function in
ConnectivityManager.
Bug: 145093446
Bug: 148038547
Test: -build, flash, boot
-atest TetheringTests
Change-Id: Ia432057bf9056727c4a0ca97d160a49274d33581
The non-updatable part of the platform shouldn't directly link to the
boot jars in APEXes. Ensure this by
1) setting the visibility property for the boot jars so that they are
not visible to non-APEX modules and
2) setting the apex_available property so that the boot jars are only
built for the corresponding APEXes, but not for others.
Bug: b/146167933
Bug: b/146218515
Bug: b/147200698
Test: m
Change-Id: I251fabd773bc31f46d572d143c72dd9162f3f0a6
Move tethering out of ConnectivityService. All client would
use TetheringManager to talk with TetheringService directly.
Bug: 144320246
Test: -build, flash, boot
-atest TetheringTests
Change-Id: Ib051bea724a256f9c4572b566e46ae7b9c4abe6e
Now tethering would be run in dedicated service.
TetheringManager is the interface used to communicate with
TetheringService. The new call flow would be: ConnectivityManager
-> ConnectivityService -> TetheringManager -> TetheringService.
Note: the return value of #tether(), #untether() and #setUsbTethering()
APIs would always be no error. Client can use #getLastTetherError()
or #getTetheredIfaces or listen tether state change to check
status of corresponding interface.
Bug: 136040414
Bug: 144742179
Test: -build, flash, boot
-atest TetheringTests
-atest FrameworksNetTests
Change-Id: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
This is initial patch that don't contain any service for now.
Bug: 136040414
Test: -build, flash, boot
Change-Id: I0b49d7e9c3fcba5af3025163f9cc9eafb0778116
