1. Unhide MSIM APIs in TelephonyManager that already have non-MSIM equivalent
APIs public.
2. Make MSIM API naming consistent (overloaded, no suffix).
3. Unhide APIs in SubscriptionManager that are necessary for MSIM.
Bug: 26772894
Change-Id: Ibebab7379ea79c8e4812bbd190342827048e30e2
Current usage of NetworkSpecifier: network factory will match a request
if the request has either a (1) empty network specifier, or (2) a
network specifier which is identical to that of the network factory.
Note: 'matching' w.r.t. network specifier - all other matching rules
are still in effect.
Change: add rule (3) or the network specifier of the network factory
is the special string (which is defined as "*" and which user-facing
network requests aren't allowed to use).
Rationale: allows on-demand network creation.
Example:
- Can specify a Wi-Fi NetworkRequest with NetworkSpecifier="ssid"
- It will match a Wi-Fi network factory specifying NetworkSpecifier="*"
- That network factory will bring up a Wi-Fi network, connecting to the
specified SSID.
- Once the network is created it will create a NetworkAgent which will
now have a NetworkSpecifier matching that of the request (not the
match-all special string!)
That final step of making sure that the NetworkAgent matches the request
and not the match-all is critical to delivering any subsequent callbacks
correctly. I.e. your network will only get callbacks which match it.
Bug: 26192833
Change-Id: I49e3b492e0bb48a3f6e9a34e3f94f0e1cf89741f
- netlink from core to services/net/netlink
- IpReachabilityMonitor from core to services/net/ip
Cherry-picked from 02cc5a030a
Change-Id: I45ac3f591bade45dd5ec441111b02b621234c0e4
X509TrustManagerExtensions assumes that the default X509TrustManager is
an instance of conscrypt's TrustManagerImpl. That's no longer going to
always be the case. Instead use duck typing to support any
X509TrustManagers that have the extra methods required for
X509TrustManagerExtensions.
Change-Id: If23471bda590d5e131bb1e802a60599957bc7f37
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
In rare cases, we might have created a network policy before an IMSI
was available. Because this policy is persisted, and we incorrectly
think that it always applies, we end up annoying the user when data
usage goes over the 2GB default warning threshold.
This patch fixes the network matching logic to ignore these empty
network policies when present.
Bug: 24972775
Change-Id: Id26499b6716121dddf0f2c05b848b0bed5995e72
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: Ib090273a417f7eb2ac1ee3309260249b72fb8345
getActiveNetworkInfo() and friends already know how to augment their
results to help apps detect when network access is blocked. This
change wires up the new app-idle and device-idle firewall rules to
be reported through these APIs.
This also causes other platform tools like DownloadManager and
SyncManager to respect these new policies.
Bug: 24050462
Change-Id: Id9517b0b70be7e3ca2ab27bed8049db916e4d829
* commit '22262f31b964d595b56eb1277e4d88550a03e54c':
Require the new PACKET_KEEPALIVE_OFFLOAD permission.
Add an error code for generic hardware error.
Fix bugs and crashes in PacketKeepalive API.
Add tests for the PacketKeepalive API.
Add a PACKET_KEEPALIVE_OFFLOAD permission.
Use a CountDownLatch instead of sleep() in NetworkFactory tests.
Get rid of shortSleep() in ConnectivityServiceTest.
Make ConnectivityServiceTest a bit more readable.
* commit '017223acda5bfe16cb87d0a33d72dd28d2fccd3b':
Require the new PACKET_KEEPALIVE_OFFLOAD permission.
Add an error code for generic hardware error.
Fix bugs and crashes in PacketKeepalive API.
Add tests for the PacketKeepalive API.
Add a PACKET_KEEPALIVE_OFFLOAD permission.
Use a CountDownLatch instead of sleep() in NetworkFactory tests.
Get rid of shortSleep() in ConnectivityServiceTest.
Make ConnectivityServiceTest a bit more readable.
This is necessary because currently the wifi code just returns
whatever hardware-specific integer it gets back from the HAL,
which is bad because that will be interpreted by the caller as
one of the error codes defined in this class.
In parallel we'll also modify the wifi code to return this new
error code if the hardware returns an error.
Bug: 21405946
Change-Id: Ic9fa1193ced69a4e7ff543e397221c89b10a5a13
Move SUPL CONNECTIVITY_ACTION bcasts to a different, hidden intent
to reduce the churn of apps when SUPL comes/goes.
Short term hack until SUPL moves to use the new APIs and there's
no bcast.
bug:23350688
Change-Id: I3dc14b42afa72465260aa41ccedfe1df27baabd9
If an app uses the new api (requestNetwork) to bring up MMS, don't
mark it as a legacy request. This was done because the messaging
service had to use a combination of new API and old
(requestRouteToHost) due to api problems. This has been resolved
so don't mark these as legacy requests anymore.
The general stuff is still in for other types due to lack of testing
time but this should be removed altogether in the future.
bug:23350688
Change-Id: I41c27efb253c39d8af1357ae7916ed5315c716db
Requests without NET_CAPABILITIES_INTERNET and just the default network
capabilities should not be marked restricted. Without this fix apps
can hit permissions exceptions if they inadvertently make requests
without NET_CAPABILITIES_INTERNET.
Bug:23164917
Change-Id: I4c7136821315bcb05dfc42ffbc505a5d4f6109e6
Broadcasts information about network policy notifications
to a custom component, if specified, so it can handle them.
Also exposes an API to snooze warning notifications.
Change-Id: Ic89478fa437861e2d4b6a9443858bcaf12122fba
