The AdapterStateListener registers with the underlying UWB Service for
UWB Adapter state changes and notifies registered client callbacks.
Bug: 170323306
Test: atest UwbManagerTests
Change-Id: Ie8ba8208909652b98ee2df15e08433627542f28b
Provides implementations for the basic UwbManager functions that
directly query the UWB Service.
Bug: 170323306
Test: atest UwbManagerTests
Change-Id: Ic45aa87ce90c414642e3186890f6ef08e1fd8486
This makes sure the write operation (NativeInputApplicationHandle
::updateInfo) is always called from window manager side once when
calling SurfaceControl.Transaction#setInputWindowInfo or
InputManagerService#setFocusedApplication. If the info of input
application handle is changed, a new instance will be created.
That avoids the race condition of reading the fields of the same
InputApplicationInfo instance from input dispatcher.
Bug: 171857140
Bug: 161334769
Test: WindowInputTests
Change-Id: I70de9835c7699fe6f56fc3655b0fee5c317ecc3a
Instead of setting NetworkIdentity.subscriberId only on telephony
networks, set it when provided on any network. At the moment only
telephony is expected to have a subscriberId in its NetworkState anyway,
and while there are plans for other network agents (wifi) to have a
subscriberId, it should also be set in that case.
This allows NetworkIdentity to stop depending on hidden network type
APIs to determine if the network is mobile.
Bug: 174436414
Test: atest FrameworksNetTests
Change-Id: I4f09987f8737d1801342eb5d6d7c2b9968b466b0
Remove usage of hidden NetworkType, transport APIs in toString()
implementations of metrics and data usage classes.
The toString implementations can log the transports or network type as
hex or raw indices. While slightly less readable, the metrics classes
and network type APIs are deprecated.
Bug: 174436414
Test: m
Change-Id: I79239a540b66dadd3bbe0a997960530878331358
The legacy metrics are deprecated, and CaptivePortal is planned to move
to a connectivity-specific jar which cannot reference MetricsEvents.
Bug: 171540887
Test: m
Change-Id: I409375de3844a7fedef707cf9e19a106d82a8e3a
This is boilerplate code for Bluetooth LE Audio profile
Bug: 150670922
Test: compilation
Tag: #feature
Change-Id: Iadc3af12fd8b2808db2f4e933a1906a819824ade
The existing method is confusing (the argument used to be called
includeDying) and it puts the burden on the caller (which need to
understand what the parameter means).
Furthermore:
- The majority of calls are for getUsers(excludeDying=true).
- The calls for getUsers(excludeDying=false) are equivalent to
calls to getUsers()
Test: m
Test: a VpnTest ConnectivityServiceTest PermissionMonitorTest
Bug: 157921703
Change-Id: Ife767a40b7b7790ba28b5377046de822ddbf275c
Merged-In: Ife767a40b7b7790ba28b5377046de822ddbf275c
(cherry picked from commit 6dc6d2b964)
This reverts commit efec091bcb.
Reason for revert: aosp/1513473 fixed the underlying issue That make this revert necessary.
Change-Id: Ic99a6d080b4b1140924cb89d44b1f650f283a28d
StorageManagerService#onVolumeStateChanged passes on a mutable
object to onVolumeStateChangedLocked and onVolumeStateChangedAsync.
This causes a race since the state of the object being passed can
be updated while onVolumeStateChangedAsync is processing it.
To fix this, a clone of the object is passed instead.
Bug: 174056195
Test: atest AdoptableHostTest
Test: atest com.android.tests.fused.host.FuseDaemonHostTest
Change-Id: I4de32279ae740544bd3abe33d788ebdbef1eab00
This follows other TYPE_* constants like TYPE_WIFI_P2P that are
@SystemApi or public.
TYPE_PROXY has a use-case for the system to set network policies based
on proxy network templates. Although network types are deprecated, that
use-case needs to be supported and significant amounts of network
management would need to be rewritten to stop using network types.
The constant needs to be API as ConnectivityManager is planned to move
out of framework.jar, so only its formal API will be available to the
system server.
Bug: 174436414
Test: m
Change-Id: I266ed6bc59f5eb72302afe14472c93933733c8f8
The code is unused, and based on ConnectivityManager#startNattKeepalive,
which is deprecated.
Bug: 174436414
Test: atest FrameworksNetTests
Change-Id: I08c6c1baec668a304d971bb6f2328891a5611e6a
Instead of sharing the constant from LinkProperties, use the already
defined constant in the NetworkConstants class.
This allows Ikev2VpnProfile to allow depending on non-public
LinkProperties APIs, as LinkProperties is planned to move to
framework-connectivity.
Bug: 174436414
Test: m
Change-Id: I594bb7e81bc7681799c16eff621a5ffd1b29624c
On top of being a cleanup this is useful for the S Network
Selection project that will need to enrich the Network
Agent API, and as such should not have to support legacy
agents.
Test: FrameworksNetTests NetworkStackTests
Bug: 167544279
Change-Id: Id3e5f6e19829c64074cd6a52c5f950cee56b860b
ConnectivityService may not be available in a NetworkProvider
constructor, if it is created (but still unused) before
ConnectivityService starts.
As ConnectivityManager is only necessary in
declareNetworkRequestUnfulfillable, which should not be called often,
just query ConnectivityManager at that point.
This is necessary for VcnManagementService, which is started before
ConnectivityService and creates its NetworkProvider in its constructor.
Fortunately VcnManagementService does not call
declareNetworkRequestUnfulfillable at this point.
ConnectivityManager may be migrated to classic service getters that
cache "null" when the service was not available the first time it is
queried, so no system service must query it before it starts.
Bug: 171540887
Test: atest FrameworksNetTests:NetworkProviderTest
Change-Id: I8dadcd0e1360a9464192f330493e13aa69dd9fe2
This CL allows an app that has the MANAGE_TEST_NETWORKS
permission to create test VPN networks.
The code enforces that such networks can never apply to any UIDs
and thus will never carry any traffic.
Bug: 173331190
Test: passes existing tests, moved tests pass
Change-Id: I5befea0e3b4b6dce4ca0c6a04471a055186b644c
Add support to ConnectivityService to track underlying networks
directly instead of through the Vpn class.
1. Communicate all information necessary to propagate underlying
network capabilities to ConnectivityService via NetworkAgent.
This includes:
a. Underlying networks:
- Add SystemApi for NetworkAgent to declare its underlying
networks to ConnectivityService, and use it in Vpn.
- Add a new declaredUnderlyingNetworks member to
NetworkAgentInfo and store the underlying networks in it.
Move propagation of underlying network capabilities to
mixInCapabilities, which is a natural place for it.
b. "Always metered" bit:
- Communicate this to ConnectivityService via the existing
NOT_METERED capability. Store it in a new declaredMetered
boolean in NetworkAgentInfo to separate it cleanly from
the NOT_METERED bit in the capabilities, which depends on
whether the underlying networks are metered or not. In
order to ensure that this is only ever changed when a NC
update is received from a NetworkAgent, define a new
processCapabilitiesFromAgent similar to the existing
processLinkPropertiesFromAgent.
2. Ensure that propagating underlying network capabilities does
not read the VPN's NetworkCapabilities. In order to do this,
ensure that all relevant information on underlying networks
and metering is sent to ConnectivityService at NetworkAgent
registration time. CS still calls Vpn#updateCapabilities when
a user is added/removed, but that is deleted in a future CL.
3. Slightly generalize propagating underlying network
capabilities because there may be other network types that
also have underlying networks that aren't VPNs (e.g., VCN).
- Introduce a new supportsUnderlyingNetworks() boolean method
in NetworkAgentInfo.
- Rename updateAllVpnsCapabilities to
propagateUnderlyingNetworkCapabilities.
This commit does not move the actual logic of calculating the
underlying capabilities out of Vpn.java. That can be done in a
subsequent change once CS stops calling getUnderlyingNetworks().
This commit also does not modify any of the other code in CS that
directly accesses VPNs' underlying networks.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Test: CTS test in r.android.com/1511114
Test: atest CtsNetTestCases:Ikev2VpnTest HostsideVpnTests
Change-Id: I5f76cb1aa4866efed3d5c4590e931fdb0e994f8d
Modify the suggestManual...() methods on TimeDetector and
TimeZoneDetector to be synchronous, and have them return true/false to
indicate if the call "succeeded". This is being done before adding more
calls that will be used by apps like SettingsUI; generally all calls
that are user facing and could conceivably fail should return
success/failure information and therefore need to happen synchronously.
Test: atest services/tests/servicestests/src/com/android/server/timedetector/
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/
Bug: 140712361
Merged-In: I5b6b7fb5af2ffe88392b2ca8d1e8fff2a187521b
Change-Id: I5b6b7fb5af2ffe88392b2ca8d1e8fff2a187521b
If neither Parcel nor Parcelable exists, ParcelableHolder'd better
write nothing like NDK and C++ backend.
In the case of empty ParcelableHolder
As-is(Java):
4 -> Size
-1 -> Existence(empty string)
To-be(NDK, C++ now):
0 -> Size
Test: atest CtsNdkBinderTestCases
Bug: 173682663
Change-Id: I816108fdc59170ea7408f0633295ba978f1ef9d5
