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
This CL exposes startTethering and stopTethering functions which also
encapsulate all provisioning check logic. Right now, only silent checks
are implemented, but UI checks will come in a follow-up CL. GTS tests
and Settings changes are under the same topic ID.
BUG: 26247383
Change-Id: I65f61d899594cb3f9035d8496366af17a57a090f
usage while running in background.
The new API is 'int getRestrictBackgroundStatus()' and returns the
following values:
- RESTRICT_BACKGROUND_STATUS_DISABLED: no restrictions
- RESTRICT_BACKGROUND_STATUS_WHITELISTED: restriction but app is
whitelisted
- RESTRICT_BACKGROUND_STATUS_ENABLED: full restriction
The proper way to interprete these values for using metered networks
while running on background is:
- When disabled, there is no restriction and the application could use the
metered networks freely.
- When whitelisted, the application can use the metered network, but should try
to minimize the usage.
- When enabled, the application should not try to use metered networks at
all, since the usage will be denied.
BUG: 26451391
Change-Id: If07d42bb88e4c02802df0234861f38aef2cfead7
The new APIs are:
void addRestrictBackgroundWhitelistedUid(int uid);
void removeRestrictBackgroundWhitelistedUid(int uid);
int[] getRestrictBackgroundWhitelistedUids();
The whitelist is persisted in the same XML used for the other policies,
using the new 'whitelist and 'restrict-background' tags. Examples:
3 whitelisted apps:
<whitelist>
<restrict-background uid="10001" />
<restrict-background uid="10009" />
<restrict-background uid="10086" />
</whitelist>
No whitelisted app:
<whitelist />
BUG: 26451391
Change-Id: I01b114c346fd8abc05433ad43d010379384f8c2b
Whether a network is deemed roaming or not was already being tracked
as part of the NetworkIdentitySet, so the underlying data store
already tracks roaming and native data separately. However, this data
was being aggregated together in NetworkStatsCollection#getSummary,
since the NetworkIdentitySet is converted to an iface name for the
purposes of matching, and the iface name will be identical whether or
not the iface is considered roaming. Now it is separated.
Also fixes a long-standing bug in NetworkIdentitySet where an identity
read from a saved file would always be considered roaming == false,
even if it wasn't at the time it was written.
Bug: 25813438
Change-Id: I11ab5b51182ed8da7af8fde468df065f9fdc3dad
This also creates a hidden api for the captive portal server calculation
so that the Setup Wizard can use this as well.
bug:13246857
Change-Id: I4dfd0916df97cfce13252c7cc15f7bd05ed95f77
When hidden PackageManager methods take a userId argument, they
should be named explicitly with the "AsUser" suffix. This fixes
several lagging examples so that we can pave the way to safely
start passing flags to new methods without scary overloading.
Also fix spacing issues in various logging statements.
Change-Id: I1e42f7f66427410275df713bea04f6e0445fba28
This fixes the crash that occurs when getAllValidScorers() is invoked by
a non-primary user when a scorer is active.
BUG: 23040221
Change-Id: I42c9e18d74389be3191258ca5626f2c433ca7cc7
java.lang.IntegralToString is being removed, replaced
all its usage by com.android.internal.util.HexDump.
(cherry picked from commit 3f72604be8)
Change-Id: I0527d580f5975dca0dfaa6f86fa3695dd49d0849
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
Currently, we look at network requests that are created by the
current requestNetwork API to see if they look like requests
that could have been created using the legacy
startUsingNetworkFeature API.
This causes those networks to be added to LegacyTypeTracker,
and so cause CONNECTIVITY_ACTION broadcasts, be accessible
using getNetworkInfo(int type), etc. This was done in the L
timeframe so that apps could request networks using the
then-new requestNetwork APIs and still use them using legacy
APIs such as requestRouteToHost.
However, the resulting CONNECTIVITY_ACTION broadcasts are
expensive. requestRouteToHost has been deprecated since L, and
mixing the old and new APIs was never recommended, so it's time
to delete this hack.
Bug: 22513439
Bug: 23350688
Bug: 25295964
Change-Id: Id867058446e5ee44396743d126d26fa57da0c990
An upcoming change will remove "synchronized" from the API docs. This change
documents those cases where the guarantees can be determined from code
inspection.
Bug: 25767152
Change-Id: I75083ce01513ed315222304fe3f34190d40748cb
The documentation for this method says that the request can be
released using releaseNetworkRequest, but that's not true.
releaseNetworkRequest only takes a PendingIntent, and can only be
used to release a request filed with a PendingIntent.
Fix the docs to say that the request needs to be released using
unregisterNetworkCallback.
Change-Id: If044fd2d463ab8d09874172d5d56946251057a3c
This method is public @hide to support progressive refactoring of
tethering away from startUsingNetworkFeature to requestNetwork,
without getting in the way of the CONNECTIVITY_ACTION cleanup in
b/22513439 .
Bug: 9580643
Bug: 22513439
Change-Id: I9053ec746cc8f415a2d5849f044667eeb14e1b19
java.lang.IntegralToString is being removed, replaced
all its usage by com.android.internal.util.HexDump.
Bug: 24932279
(cherry-picked from 15fc0548a536750110e159e06a39ba943eccdd81)
Change-Id: Id6ab88337af12d93cd73c41775b9d5baa1e61d96
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 API will be used in WebView to help determine whether secure
connections to hostname A can be used for secure communication to
hostname B (e.g., HTTP/2 connection pooling).
This is needed because with the new network security configuration a
completely different trust configuration may be used for
foo.com and bar.foo.com, so even if the foo.com certificate contains a
SAN for bar.foo.com it may not be valid for bar.foo.com given the
applications trust configuration.
Change-Id: I87184d392b9a7eca53a9c837996ca7ab5cd5bf12
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
Per RFC 4330, a NTP server response should be discarded when:
- the stratum is 0 (unspecified), or
- the leap indicator is 3 (unsync'ed), or
- the mode is not 4 (server) / 5 (broadcast), or
- the transmitted time is 0.
Update SntpClient so that such responses would be discarded.
Additionally:
- make some variables suitably "final"
- enable logging
- add alternate requestTime() for testing
- add some miniscule test coverage
Cherry-picked from Jerry Wong's
https://partner-android-review.googlesource.com/#/c/460074
Bug: 24719581
Change-Id: Id11a79a6e53ce95500ed4b4d691a29c260666f6c
