Removes use of the special framework-modules naming scheme.
Bug: 155164730
Test: m java
Exempt-From-Owner-Approval: Build cleanup.
Change-Id: I3896d7c91e937f503b49f5df011c21ee51219652
Merged-In: I0c31e2183353dfb5bd49f04f3455cb7b10be6866
Merged-In: I3b78fcbcacc3df787e171d6eedeef1e51b087615
(cherry picked from adac7d2cc3)
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
Merged-In: Icc9bc5a9ef86cf7ba0f15c2b2a4abd596ec9f640
(cherry picked from a17cf677b5)
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 update-api
Bug: 155164730
Merged-In: If5c115f482751f9f4b5f047e9e401a18e36799ef
Merged-In: Id1c2e848430c49a2da7402244814cd084f5da77c
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
Change-Id: I4583539d11ba69320aa5a0dfcfee072c81affac2
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
Change-Id: Ifaecb49a47a1f43edea3ea06e1cf704a177d1044
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
Merged-In: I076f30931bf2524d57703873cd7de25b3f23b457
(cherry picked from commit d7f1fabc94)
It was using the systemapi stub defaults, but should be using the
module_lib default.
Bug: 144149403
Test: m
Change-Id: Iaab154d9d71900284d92d518a086fc1227c00d5c
Merged-In: Iaab154d9d71900284d92d518a086fc1227c00d5c
(cherry picked from commit dc8e0fc1a1)
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.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 152655547
Test: m
Merged-In: I1257c66de6dd42b2d32d47ed74cb2878f79d14fb
(cherry picked from commit 6c9c10c91e)
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
Merged-In: I5b9ffa211be9c1a7dd8f63d5e7ba2a825d0d3190
Makes it convenient to change all stubs from a central place.
Bug: 149293194
Test: m framework-tethering-stubs{public,system,module_libs_}api
Exempt-From-Owner-Approval: Approved internally
Change-Id: I330133824e78b3a8927e3d3ffbbd729bcdcb8822
Merged-In: I330133824e78b3a8927e3d3ffbbd729bcdcb8822
(cherry picked from commit 7939cb0a4a)
Per API review:
- @IntDef defined on the type integer parameter
- have getters on each parameter that is set in the
TetheringRequest.Builder
- new added API should not be deprecated
Below APIs is moved from system-current to module-lib-current that only
plafrom code(e.g. ConnectivityManager and Settings) can use them.
TetheringRequest.
onTetherableInterfaceRegexpsChanged, TetheringInterfaceRegexps:
Only platform code can use them because interfaces by regular
expressions are a mechanism which is planning to be deprecated.
Also rename some constants for easier to understand.
Bug: 149858697
Bug: 151243337
Test: m doc-comment-check-docs
atest TetheringTests
Change-Id: I45cb21d5bc919f6d32c42650326597d5173ea028
Merged-In: Idd041f0fbeca411ea23e49786a50dd7feb77ef45
This adds metalava api tracking generation to the module
stub rules, to make sure we know exactly what API a
particular module stub exports.
Bug: 147768409
Test: m update-api check-api
Exempt-From-Owner-Approval: approved internally
Change-Id: Iaf2ef5b5751eb208d119ddbc74481239366fe581
Merged-In: Iaf2ef5b5751eb208d119ddbc74481239366fe581
(cherry picked from commit e7c52c7e3f)
Application can specify static ipv4 server and client address to setup
tethering and this is one shot configuration. Tethering service would
not save the configuration and the configuration would be reset when
tethering stop or start failure.
When startTethering callback fired, it just mean tethering is requested
successful. Therefore, callers may call startTethering again if
startTethering successful but do not receive following tethering active
notification for a while. Tethering service never actually does anything
synchronously when startTethering is called:
-startProvisioningIfNeeded just posts a message to the handler thread.
-enableTetheringInternal doesn't do anything synchronously, it just
asks the downstreams to get their interfaces ready and waits for
callbacks.
If tethering is already enabled with a different request,
tethering would be disabled and re-enabled.
Bug: 141256482
Test: -build, flash, boot
-atest TetheringTests
-atest CtsTetheringTest
Change-Id: I0399917e7cefa1547d617e688225544c4fc1a231
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
Merged-In: I0ed44691b4e7080818442a9d0eb37d874f707195
Add comments to getters as requested in API review, and remove the
expirationTime private field that was planned to be replaced with
LinkAddress expiration.
Test: atest TetheringTests
Fixes: 150878126
Change-Id: Iecf65859cdeeaac2fa7b817b4f505c510424ac89
The callback would be fired when offload started, stopped, or failed.
If offload is not supported, "failed" callback would be fired when user
enable tethering. Enabling multiple tethering would not have multiple
offload status callbacks because offload should already be started or
failed.
Bug: 130596697
Test: -build, flash, boot
-atest TetheringTests
-ON/OFF hotspot
Change-Id: Ia0398601144b0e5f61dc0c5771eacf13e7cfbb59
BT tethering need to know whether tethering is supported for its caller
that call isTetheringSupported in binder thread under BT's process.
Current isTetheringSupported API is getting callerPkg inside
TetheringManager that would be BT's package name for bt tethering case.
Provide isTetheringSupported(String callerPkg) for caller to pass its
caller's package name if the use case is under binder IPC.
Bug: 146915889
Test: -boot, flash, boot
Change-Id: I2a35e1b6851e7a799c343be0dd60da23514768ba
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
Merged-In: Ia4222fa35a9a2f3c75cebb12f75c536f27e2fe16
The callbacks are fired when the list of connected clients or their IP
addresses / hostname change.
Test: flashed, connected 2 devices, verified callbacks
Test: atest TetheringTests
Bug: 135411507
Change-Id: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Merged-In: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
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
Merged-In: 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
Merged-In: I97ef83f7f9b4c1376f373713036f5256318f1050
- Ensure that addAddresses preserves the ordering of addresses
- Fix assertion that was supposed to check equality of TetheredClient
with a different tethering type, and used the same type.
Bug: 148996181
Test: atest TetheringTests
Change-Id: I86cef7b834d7ae7afa3d1d748ccac6b3a7e57ebc
Instead of blocking for the ITetheringConnector, in the rare case (only
on boot) that the connector is not ready, queue requests and poll for
the connector until it is available.
Bug: 146821053
Test: Flashed, verified tethering working
Change-Id: I4bd45fcbdce2336694c3b6a349f121e40230f001
Ethernet tethering can be started via
startTethering(TETHERING_ETHERNET).
Test: flashed, enabled ethernet tethering, verified internet access on
downstream.
Bug: 130840861
Merged-In: I34842acd94b972e440c3622f7617df10c18acf65
Change-Id: I34842acd94b972e440c3622f7617df10c18acf65
(cherry-pick with conflicts in test-current.txt)
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
Merged-In: 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
Merged-In: 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
Merged-In: 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
Merged-In: I251fabd773bc31f46d572d143c72dd9162f3f0a6
Replace some ConnectivityManager constants as TetheringManager inside
tethering module. No API change, will have follow up CL to delete
@hide tethering constants in ConnectivityManager and replace caller
to using TetheringManager.
Bug: 144753389
Test: build
Change-Id: Ia1b963669722c32d147375763205ed2f3af52fed
