Not currently setting the atttribution tag for location
permission checks. Plumb the attribution tag for all location permision
checks (so that location access is correctly attributed to individual
components within an app)
Bug: 162602799
Test: atest android.net
Test: atest com.android.server
Change-Id: Iee95f05204f51a4f8cb1f36acfb60e8cdeb156f4
* changes:
Change ConnectivityServiceTest to prepare for VPN code move.
Add to VpnManager the VPN APIs used by Settings and SystemUI.
Remove temporary hack in VpnTest.
The static validate() method an PROXY_* constants in Proxy are
used by both module and Settings. After Proxy is moving into
connectivity module, Setting will not able to access them.
Thus, move them to ProxyUtils in net shared lib.
Bug: 172183305
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases:ProxyInfoTest
Change-Id: I02c88aeaeb53d62b87a42a2d8ead9b140b054650
Settings and SystemUI use these through raw AIDL calls.
Make them proper manager calls so we can move the implementation
without touching the callers again.
For now these still call into ConnectivityService via
IConnectivityManager. In an upcoming CL the implementation will
move to VpnManagerService.
Test: m
Bug: 173331190
Change-Id: I91528e1ad9948fbaa1fc5e37c61c5eb95f54964e
Currently, NetworkRequest has several types of requests (LISTEN,
TRACK_DEFAULT, REQUEST, BACKGROUND_REQUEST), and we expect more
to be added.
There are really three categories of request:
1. Requests satisfied by only one network and will keep that
network up, and thus need to be sent to NetworkProviders:
REQUEST, BACKGROUND_REQUEST.
2. Requests satisfied by only one network but will not keep that
network up: TRACK_DEFAULT
3. Requests satisfied by multiple networks and will not keep any
networks up: LISTEN.
Unfortunately the separation is not very clear. Currently, for
any valid request, either isListen() will return true or
isRequest() will return true. This makes it impossible to tell
whether a particular request should be sent to NetworkProviders,
so the current code sends TRACK_DEFAULT requests to
NetworkProviders as well. This is incorrect - a TRACK_DEFAULT
should never keep a network up, for example.
This CL attempts to clarify things by making isRequest() return
false for TRACK_DEFAULT requests and thus never sending them to
NetworkProviders. After this CL:
- isRequest will return true only for requests that attempt to
bring up or keep up a network.
- isListen will return true only for requests that match multiple
networks but do not keep any of them up.
- Neither will return true for TRACK_DEFAULT.
Test: atest ConnectivityServiceTest
Change-Id: I7aad30ade8f7ab2a179e53483d9afd8675f64a12
This is a partial cherry-pick of change:
I5eedb571c9d78862115dfdc5dae1cf2a35343580
for connectivity classes.
Bug: 170883422
Test: m
Merged-In: I5eedb571c9d78862115dfdc5dae1cf2a35343580
Change-Id: I7dc661863b73f4198ddb4f3a1566583d0f07db3c
Deduce the NET_CAPABILITY_NOT_VCN_MANAGED capability from other
capabilities and user intention, which includes:
1. For the requests that don't have anything besides
VCN_SUPPORTED_CAPABILITIES, add the NOT_VCN_MANAGED to
allow the callers automatically utilize VCN networks
if available.
2. For the requests that explicitly add or remove
NOT_VCN_MANAGED, do not alter them to allow user fire
request that suits their need.
Test: atest NetworkRequestTest#testBypassingVcnForNonInternetRequest
Bug: 175662146
Change-Id: I9936894b9530a22fb186cfd25cbee0fced65b72b
Nothing on the system is using registerNetworkFactory,
unregisterNetworkFactory at the moment.
registerNetworkFactory, unregisterNetworkFactory are protected by
signature permissions, so could not be used by anything outside of the
system.
Remove the two methods and the underlying support for this legacy,
deprecated mechanism.
Bug: 179229316
Test: atest FrameworksNetTests
Change-Id: I7cdc9eed67f846c8774474af038133040aeccab3
Both of readArraySet and writeArraySet are hidden APIs inside
Parcel, so reimplement those two methods inside NetworkCapabilities
to prevent calling hidden APIs.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I70f75c1a0db92c6a5575c6a9917843d783dfaeea
As connectivity services are planned to move to a separate module, move
the manager classes registration from SystemServiceRegistry to
ConnectivityServicesRegistrar, using the registerContextAwareService
APIs.
This follows patterns and naming in WifiFrameworkInitializer.
Bug: 171540887
Test: device boots, connectivity working
Change-Id: I62ced1275750c73f209bac8ec3a3204b95695b83
Files that are planned to be part of the connectivity module are grouped
in packages/Connectivity, so they can be built separately and moved in
one operation with their history into packages/modules/Connectivity.
This places the files in the existing framework-connectivity-sources
filegroup instead of the current framework-core-sources filegroup. Both
are used the same way in framework-non-updatable-sources.
Bug: 171540887
Test: m
Change-Id: I62d9d91574ace6f5c4624035d190260c3126b91e
All sources for the connectivity module are being moved to
frameworks/base/packages/Connectivity, so that they can all be moved to
packages/modules/Connectivity in one move keeping history.
INetworkAgent and INetworkAgentRegistry were created in
packages/modules/Connectivity directly, but this makes managing the
sources until the move harder as the module needs to pull sources from
two different locations. Considering that they do not have history to
move, just move them to frameworks/base/packages/Connectivity without
the commit history.
Bug: 171540887
Test: m
Change-Id: Ic4353115a98b6235c2b5d5ce24741223e618d0a6
