NetworkStatsService will register data usage requests
and keep data usage stats scoped to the request.
There are different types of data usage requests
- scoped to a set of NetworkTemplate; these are restrictred to
device owners and carrier apps and allow the caller to monitor
all activity on the specified interfaces.
- scoped to all uids visible to the user, if the user has
android.Manifest.permission#PACKAGE_USAGE_STATS permission.
The set of uids may change over time, so we keep track of that.
- scoped to a set of uids given by the caller, granted that
the caller has access to those uids.
- scoped to the caller's own data usage. This doesn't require
PACKAGE_USAGE_STATS.
Bug: 25812785
Change-Id: Ie11f35fc1f29d0dbe82f7fc924b169bb55c76708
With this it's possible for callers to:
Network network = ...
LinkProperties lp = ...
NetworkDiagnostics netdiag = new NetworkDiagnostics(network, lp, 5000);
netdiag.startMeasurements();
netdiag.waitForMeasurements();
boolean result = true;
for (Measurement m : netdiag.getMeasurements()) {
if (!m.checkSucceeded()) {
result = false;
// Additional error handling here.
}
}
return result;
Bug: 21832299
Bug: 26780890
Change-Id: Iaf7ff029e2c6a998b574c23d0dcde8d57a467a22
Slowly chipping away at TetherUtil to clean up this code.
This CL also adds an admin check to
ConnectivityService.isTetheringSupported to get parity with the
TetherUtil function before removing it.
Change-Id: Ibe7c5c9fb420d57e5458f77dad30e8a1e751a3e2
When the roaming status of the cell network changes, it is handled as
follows:
-DcActiveState gets an event (either EVENT_DATA_CONNECTION_ROAM_ON or
EVENT_DATA_CONNECTION_ROAM_OFF) and calls
NetworkAgent#sendNetworkInfo with updated NetworkInfo.
-ConnectivityService then gets an EVENT_NETWORK_INFO_CHANGED and calls
updateNetworkInfo with the new info.
With the previous code, the NetworkAgent's NetworkInfo object would be
updated internally, but because the state of the connection had not
changed from CONNECTED, the change would be considered a duplicate and
otherwise ignored.
With the new code, we call notifyIfacesChanged() when the state is the
same but the roaming status has changed. That should be all that is
necessary, as roaming is not exposed as a link property or network
capability today.
Bug: 26545456
Change-Id: I33d32d1fa84ce41dbe01542e5b498eda4b744b74
This intent will be broadcasted when:
- Global restrict background setting is changed (sent to all packages)
- An individual uid is added to or removed from the whitelist (sent just
to the packages belonging to that uid).
This intent is only sent to registered receivers.
BUG: 26451391
Change-Id: Ic0a5771f88baa52076ad04764f29098a386463cc
This will make it possible to find nethandles via, e.g.
"dumpsys connectivity --short".
Without this, native multinetwork API debugging requires running
"dumpsys connectivity --diag" in order to see the nethandle values.
Bug: 19537384
Change-Id: Icdd2b112523d4ecf88d5339f229e714a56d248f8
* changes:
Framework support to read newly added fields
Added an API to query GPS hardware version info
GPS Measurement and Navigation APIs go public
Supported GNSS multi-constellation in frameworks
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
Tethering just constructs its own Looper right below where it
assigns the looper param to mLooper.
Change-Id: I2d522942eff2ad3439bb3961e78ab0625d3fa9df
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
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
Removed the dependency on KeyStore encryption by removing that flag for
VPN profiles which don't use secure credentials when saving in Settings.
Old encrypted profiles will simply fail to load untile USER_PRESENT is
sent, as before.
Bug: 26108660
Change-Id: I2677d741d54252f15cb772c94ce1b39041f1e19c
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
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
Currently, access to network usage history and statistics requires a
signature|privileged permission, an AppOps bit (associated with the
PACKAGE_USAGE_STATS permission), or device/profile ownership. Once
access is granted via one of these mechanisms, it generally applies to
any UID running in the same user as the caller.
This CL expands access as follows:
-Any app can access its own usage history with no extra requirements.
-Carrier-privileged applications can access usage history for the
entire device.
-Device owners can access per-UID breakdowns for usage. Previously
they could access the summary for the whole device, but not the
individual breakdowns.
We simplify the permission model by defining three access levels -
DEFAULT (own app only), USER (all apps in the same user), and DEVICE
(all apps on the device), and propagate these levels throughout.
Finally, this CL fixes an apparent bug in
NetworkStatsSerice#hasAppOpsPermissions - if the AppOp bit was in
MODE_DEFAULT, hasAppOpsPermission would always return false instead of
falling back to the PackageManager permission check.
Bug: 25812859
Bug: 25813856
Change-Id: Ic96e0776e2a4215a400163872acea1ededfaced9
Breakages:
-ag/574873 - Renders testReportXtOverDev obsolete as this is no longer
a supported mode. Test has been removed.
-ag/600223 - Tests were sending a CONNECTIVITY_ACTION bcast to trigger
a call to updateIfaces(), but the listener was removed.
Tests now call forceUpdateIfaces() directly.
-ag/648284 - Calls to get VPN info were not mocked.
Change-Id: I309f2b5d006549104cb1d3cb83e99363dd6dac16
The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time. The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered. If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped. This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.
The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method. There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.
An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler. If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.
Cherry-picked from b481a892d2
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
You can now control the range of target SDKs that receivers
will be need to have in order to receive your broadcast.
Use this for CONNECTIVITY_ACTION to not allow N+ applications
to receive these broadcasts through their manifest.
Also tweak the broadcast debug output code to now include the
disposition of each receiver in the list. This is becoming
important as skipping receivers is becoming a more common
thing to have happen.
Change-Id: I251daf68575c07cbb447536286ab4e68b7015148
