Owners files update for VCN now that primary development
is complete and the codebase is stable.
Bug: 8675309
Test: compilation
Change-Id: Ie686729b33f0a7e1c3414374ce4bf3d7ef514a22
This change adds a basic prioritization framework in the VCN, and signal
strength thresholds for WiFi.
Bug: 188104094
Test: atest FrameworksVcnTests
Change-Id: Iee4e3dbecf1102ddc127a8c8daf08a00b6fccbbd
Currently we rely on GC to close them.
This may cause system_server crash depending on the timing of GC.
Bug: 187879195
Test: atest UpdatableSystemFontTest
Change-Id: I09ac3f349e5ec100e4164320cbf27977474cc4bb
As a part of internal core libraries cleanup move usages of
IoUtils#deleteContents from CorePlatformApi set to framework.
Bug: 154796679
Test: m update-api
Change-Id: If7037029026b6753ab64be09aa52c40e04d5c7b1
AOSP contains the core networking redaction changes, but not the
wifi redaction changes, so the tests that depend on wifi S
behaviour will not pass on AOSP.
Fix testApplicableRedactions by checking that the applicable
redactions are the same ones as returned by the underlying
WifiInfo object.
Fix testMakeCopyRedactForAccessFineLocation by testing the wifi
redaction code iff Build.VERSION.SDK_INT is S or later. This is
different from SdkLevel.isAtLeastS, because the latter returns
true in AOSP.
Bug: 183938194
Test: atest VcnTransportInfoTest
Change-Id: Ia5bc896c92be19f570638f8051492e0f2d7342f9
Redaction of NetworkCapabilities is changing from redacting at
parcel time to redacting immediately when makeCopy() is called.
Update VcnTransportInfo redaction accordingly.
Bug: 183938194
Test: atest VcnTransportInfoTest
Change-Id: I0c9406f426b66fd36b47d11799955def531c16ba
Move the tests together with packages/Connectivity code, so both can be
moved to packages/modules/Connectivity together.
Also reorganize unit tests in a unit/ directory, as other tests
(integration/, common/ etc.) have been added in tests/net since they
were created. This makes the directory structure consistent.
Test: atest FrameworksNetTests
Bug: 187814163
Merged-In: I254ffd1c08ec058d594b4ea55cbae5505f8497cc
Change-Id: I254ffd1c08ec058d594b4ea55cbae5505f8497cc
Move the tests together with packages/Connectivity code, so both can be
moved to packages/modules/Connectivity together.
Also reorganize unit tests in a unit/ directory, as other tests
(integration/, common/ etc.) have been added in tests/net since they
were created. This makes the directory structure consistent.
Test: atest FrameworksNetTests
Bug: 187814163
Ignore-AOSP-First: needs per-branch move for merge conflicts
Change-Id: I254ffd1c08ec058d594b4ea55cbae5505f8497cc
* changes:
Request Test Networks for VCNs when in Test Mode.
Specify if a VCN is in 'test-mode' in VcnContext.
Create test-mode for VcnConfig.
Require MOBIKE for IkeSessionParams in VCN configs.
VPN types are defined in both VpnManager.java and NativeVpnType.aidl.
The definitions on both sides should match (except TYPE_VPN_NONE).
VpnManager.java:
TYPE_VPN_NONE = -1
TYPE_VPN_SERVICE = 1
TYPE_VPN_PLATFORM = 2
TYPE_VPN_LEGACY = 3
TYPE_VPN_OEM = 4
NativeVpnType.aidl:
SERVICE = 1
PLATFORM = 2
LEGACY = 3
OEM = 4
Bug: N/A
Test: atest android.net.VpnManagerTest#testVpnTypesEqual
Change-Id: Ie618e227d861100c5318da696140e486af1093a0
This CL restructures the NetworkRequests used for TestNetworks
in UnderlyingNetworkTracker to clearly show that they only require
TRANSPORT_TEST and the relevant subIds.
Bug: 182291467
Test: atest FrameworksVcnTests CtsVcnTestCases
Change-Id: I4b135749fdde9f91c66b87b1ded921700e6440fd
This CL updates UnderlyingNetworkTracker to request Test
Networks for route selection when the VCN it is tracking
for is in test-mode.
Bug: 182291467
Test: atest FrameworksVcnTests CtsVcnTestCases
Change-Id: Icb59b15df61ec43fe76e250977a985caa6a1dffc
This CL updates VcnContext to include whether the VCN instance
it is created for is in test-mode (as specified by the VcnConfig).
This also changes the lifetime of VcnContext to be created uniquely
for each VCN instance (as opposed to a single VcnContext created in
VcnManagementService and used for all VCNs).
Bug: 182291467
Test: atest FrameworksVcnTests CtsVcnTestCases
Change-Id: I6fc6a266bf67ab2aa64202153c3c109ee98a16ca
This CL creates a test-mode for VcnConfig so that they will only
match with Test Networks. This is necessary for CTS testing so
that VCNs can run on test networks and IKE negotiations can be
injected over the Test Networks.
Bug: 182291467
Test: atest FrameworksVcnTests CtsVcnTestCases
Change-Id: I5cc340e5aaa34c5de8efafa52de49185a18d4bd3
This CL updates VcnGatewayConnectionConfigs to require
IkeTunnelConnectionParams with MOBIKE enabled for the
IkeSessionParams. This is necessary for VCNs - without it,
they do not support IPsec mobility (one of the main features
of the VCN).
Bug: 187851560
Test: atest FrameworksVcnTests CtsVcnTestCases
Change-Id: I94db52a8c42d9fa4681fefb8f787f006933caa18
Redaction of NetworkCapabilities is changing from redacting at
parcel time to redacting immediately when makeCopy() is called.
Update VcnTransportInfo redaction accordingly.
Bug: 183938194
Test: atest VcnTransportInfoTest
Change-Id: I0c9406f426b66fd36b47d11799955def531c16ba
Currently, NetworkCapabilities always redacts the TransportInfo
objects it contains whenever a defensive copy is made. This makes
it impossible to make a defensive copy on a TransportInfo
parcelled from another process without redacting it.
Stop redacting by default; instead rely on ConnectivityService
explicitly calling NetworkCapabilities' redacting constructor
when it returns a NetworkCapabilities object to an app via a
callback or synchronous call. This is currently done by
- createWithLocationInfoSanitizedIfNecessaryWhenParceled, which
is called from callCallbackForRequest, getNetworkCapabilities,
and getDefaultNetworkCapabilitiesForUser.
- getNetworkCapabilitiesWithoutUids, which is used when sending
ConnectivityDiagnosticsManager callbacks. In this method,
unconditionally redact all information, which is what the code
did previously due to the default redaction setting for empty
NetworkCapabilities objects being REDACT_ALL.
Bug: 183938194
Test: atest NetworkCapabilitiesTest
Test: atest FrameworksNetTests CtsNetTestCases HostsideVpnTests
Change-Id: I3108ee94cb0930958e071ba678c3554525b0db82
Addresses API council feedback.
Bug: 184890428
Test: atest FrameworksNetTests CtsNetTestCases
Test: atest CtsNetTestCasesLatestSdk:NetworkCapabilitiesTest on R device
Change-Id: Id7c68fbf56ee08fcad8e8e3aacf037fa1885936b
networkCreatePhysical and networkCreateVpn are non-extensible. In order
to pass OEM requested VPN type to Netd, we need to migrate to
networkCreate API.
Modify test code accordingly since networkCreatePhysical and
networkCreateVpn have been deprecated on Netd.
Bug: 171872481
Test: atest FrameworksNetTests
atest atest HostsideVpnTests
Change-Id: I50ab8615346c49559c16e815482e7804a1e765c8
sendNetworkConditionsBroadcast is removed, so
TestNetworkStackService.kt cannot override it anymore,
otherwise there will be a build break when running this
test.
Also add a comment for NETWORK_CONDITIONS_MEASURED in
AndroidManifest.xml.
Bug: 124415874
Test: atest FrameworksNetIntegrationTests
Change-Id: I7b43940dc32826c70fa82f471b35bc5cb8394aad
Merged-In: I7b43940dc32826c70fa82f471b35bc5cb8394aad
This change allows the VCN to trigger the application of IpSecTransforms
as in the FWD path, ensuring that tethering works across interfaces
Bug: 185495453
Test: atest FrameworksVcnTests
Test: manual testing with cross-device tethering
Change-Id: I90fc77226ca971dbd8ac549b96a4828da1079cd5
This change adds support for IPsec forward policies, which are necessary
for packets to be allowed to be forwarded to another interface, as is
the case with tethering. This is necessary and useful only within the
system server, and as such is not exposed as a public API.
This change is safe, since the addition of a FWD policy on IPsec tunnel
interfaces will by default block forwarded traffic (as would be the case
without this patch). In the event that the (system) owner of the tunnel
requires support for forwarded packets (eg tethering), this patch allows
application of transforms in the FWD direction as well.
This will be used to ensure that the VCN can be used as the underlying
network for the purposes of tethering.
Bug: 185495453
Test: atest IpSecServiceTest
Test: atest IpSecServiceParameterizedTest
Test: manual testing with tethering over VCN
Change-Id: I74ecea71f1954029f6fbdbe34598c82e0aac386b
Addresses API council feedback.
Bug: 184890428
Test: atest FrameworksNetTests CtsNetTestCases
Test: atest CtsNetTestCasesLatestSdk:NetworkCapabilitiesTest on R device
Change-Id: Id7c68fbf56ee08fcad8e8e3aacf037fa1885936b
Try to submit the 'Check mInputEventReceiver' patch again.
This reverts commit 35fccc4535dd8eedd5e60af21651e20215ef4768.
Reason for revert: Added a check to ensure that only valid data is
getting sent. Now, the InputChannel will not be closed because all
InputMessages will always be valid.
Added logging to help investigate the reason why the present time is in
the past of the gpuCompletedTime.
Original commit message:
Previously, it was possible to receive a FrameMetrics callback after the view was already detached from window. In that situation, the mInputEventReceiver is set to null and the object is disposed.
But InputMetricsListener used to store another reference to mInputEventReceiver. So it's own object was never set to null. We would then try to send the timeline to native input receiver, and crash because the native object has already be deleted by the earlier dispose() call.
So the sequence of events was:
dispatchDetachedFromWindow
mInputEventReceiver.dispose()
native input receiver is deleted
InputMetricsListener::onFrameMetricsAvailable
mInputEventReceiver.reportTimeline
try to access a native object using a null pointer
crash
A few options to fix this were investigated:
1) Unregister the observer when mAttachInfo.mThreadedRenderer is set to null.
This is good to do, but it's not sufficient. The problem is that the native call to RenderProxy 'removeObserver' is not serviced immediately, but is posted to be completed sometime in the future. Therefore, the crash would not be fixed by it.
Still, we should always register the observer for the active threadedRenderer, which is done in this CL.
2) Keep a weak reference to mInputEventReceiver inside InputMetricsListener. This would allow InputMetricsListener to check on the status of mInputEventReceiver. When it's disposed, it would be also set to null, so the weak reference resolution would fail.
Unfortunately, 'mInputEventReceiver' is not the only reference to the object of WindowInputEventReceiver. It turns out that the receiver is also stored inside the queued events (see class QueuedInputEvent { private InputEventReceiver mReceiver }). From reviewing ag/153113, it should be OK to remove the receiver from QueuedInputEvent and simply keep track of whether the event is synthesized or not.
But, that change would be too significant to make in this CL. Also, weak references have performance impact, so this may not be desirable anyways.
3) Do not store mInputEventReceiver in InputMetricsListener
The chosen option is to simply use the variable mInputEventReceiver from the outer class. If the receiver is null, we don't notify about the metrics.
Bug: 169866723
Bug: 184255546
Bug: 184771626
Bug: 185015591
Bug: 186664409
Test: verified on fold 2 device, open/close the phone, touch remains
operational
Test: atest InputEventSenderAndReceiverTest
Change-Id: I01076d771e9432f08a3b5f8426c14759b56f3e12
Change-Id: Ie71c9ed38051e3e5ec9cb089951d759f52937fdd
