Updating comments for network preferences to better clarify that
preferences which include more than one network type will then rely on
scoring to determine which of those networks are chosen.
Bug: 171795464
Test: atest FrameworksNetTests
Change-Id: I9eb5683f2cd69281bbee9fb70028d45f07720914
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I8285daa8530260251ecad6f3f38f98e263629ca7
Change-Id: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Modern network agents are supposed to have the following
lifecycle :
• Construct the agent
• Declare itself to connectivity by calling #register()
• Possibly do some setup
• Declare connected by calling #markConnected()
• Declare disconnected by calling #unregister()
Internally ConnectivityService still manages the state
with deprecated NetworkInfo, which has a lot of possible
detailed states, most of which are now unused. Internally,
the steps above translate to the states below :
• When the agent calls #register() it starts in state
CONNECTING
• When it calls #markConnected() it goes to CONNECTED
• When it calls #unregister() it goes to DISCONNECTED which
triggers the flow that disconnects it immediately
• ConnectivityService also synthesizes the SUSPENDED state
under some situations, but that's not relevant here.
The translation above is done by the NetworkAgent class,
which translates #register(), #markConnected() and
The only valid lifecyle for new agents is thus :
CONNECTING → CONNECTED → disconnect
↕ ↑
SUSPENDED ───┘
Note that in the above scheme, there is no space for the
UNKNOWN state, which is only used by legacy network agents.
However, the constructor for NetworkInfo still starts with
UNKNOWN. Ideally the constructor for NetworkInfo would set
the info to CONNECTING instead, but this would be a very
visible change in behavior affecting many apps (especially
their tests), so for backward compatibility we can't do
that.
New network agents however don't expose their NetworkInfo
to the client code, so they can just be made to start in
CONNECTING the way it was meant.
Note that this didn't really have a concrete impact beyond
printing some logs as by and large the ConnectivityService
code handles UNKNOWN and CONNECTING the same way, or more
exactly it handles transitions to CONNECTED from UNKNOWN
and CONNECTING in the same way. The exception to this is
VPNs, which are not using the new agent API yet, and the
upcoming conversion is why this fix is actually needed now.
Bug: 170904131
Test: FrameworksNetTests NetworkStackTests
Test: new test in aosp/1460705
Change-Id: Ib7d906a7b29a0b9f000b90bc78558a7402852fa3
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
This patch adds a shell of the VcnManagementService and VcnManager
Bug: 163431877
Test: Compiles, Boots
Change-Id: I1f3d8ab9c9bff7d419ea6d3edaae3b6b41b1d775
Adding network capability to be used with networks to be only used by
OEM apps.
Bug: 171505922
Test: atest CtsNetTestCasesLatestSdk:NetworkCapabilitiesTest
Change-Id: Ib55ebec0e178b6317d92f17e1aff060dacdfb2b1
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
This change adds owners for the VCN files in the android.net.vcn package
Bug: 163431877
Test: No code changes; FrameworksNetTests passing
Change-Id: I7406083b958a9fd5f1b02c2e2046a9c686622f60
It is safe because these mandatory algorithms are already required
before new algorithms are added
It is also a quick fix to unblock b/171279612, whose root cause is
the device first sdk is wrong
Bug: 171279612
Test: atest CtsNetTestCases:IpSecManagerTest
Change-Id: I5b9d85b2bc8f13f54467c97160d138a4628265f7
Create a new target service-connectivity to split
ConnectivityService from services.core.
Add ConnectivityServiceInitializer for initializing
ConnectivityService and add systemReady() in
ConnectivityManager so that SystemServer can call systemReady()
through ConnectivityManager which won't change current behavior.
Bug: 158268939
Test: make target-java, make host-java
atest FrameworksNetIntegrationTests
atest FrameworksNetTests
make, device can boot,
atest CtsStrictJavaPackagesTestCases
wifi and mobile data work.
Change-Id: I99401772ba9c1c34adca20040da3c7c72d86ddd9
Merged-In: Ie732bfaf381404af0bb599ca2f421a96e7aa4257
LinkProperties.compare{Dnses,ValidatedPrivateDnses,AllRoutes,
AllInterfaceNames} actually have no users.
Test: LinkPropertiesTest
Change-Id: Ic54ab3c5520fbbc2be1309aeaf1e5a7857dbd194
This CL adds new mandatory IPsec algorithms and allows
OEM to enable them on old devices using resource overlay
Bug: 161716062
Test: FrameworksNetTests:IpSecAlgorithmTest
Change-Id: Ib827b05ea27dbe61b14ad236e858f825293ed994
Create a new target service-connectivity to split
ConnectivityService from services.core.
Add ConnectivityServiceInitializer for initializing
ConnectivityService and add systemReady() in
ConnectivityManager so that SystemServer can call systemReady()
through ConnectivityManager which won't change current behavior.
Bug: 158268939
Test: make target-java, make host-java
atest FrameworksNetIntegrationTests
atest FrameworksNetTests
make, device can boot,
atest CtsStrictJavaPackagesTestCases
wifi and mobile data work.
Change-Id: Ie732bfaf381404af0bb599ca2f421a96e7aa4257
Those annotations could be inferred by some tools (like Kotlin), but the
https://checkerframework.org/ doesn't check inherited annotations
complaining about all equals() invocations that get nullable argument.
The change was generated by running
find . -name \*.java | xargs sed -i 's/public boolean equals(Object /public boolean equals(@Nullable Object /'
in the frameworks/base directory and by automatically adding and
formatting required imports if needed. No manual edits.
Bug: 170883422
Test: Annotation change only. Should have not impact.
Exempt-From-Owner-Approval: Mechanical change not specific to any component.
Change-Id: I5eedb571c9d78862115dfdc5dae1cf2a35343580
Ensure that appropriate networking tests are triggered when submitting
changes in the frameworks/base directories.
Change-Id: Ibf8b567fa7721299120b0a6c6836dd770d92a9fc
Test: treehugger runs TEST_MAPPING tests
