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
When the scorer is changed send a targeted broadcast to the previous
scorer (if any) and then a targeted broadcast to the new scorer.
BUG:26815773
Change-Id: If28414f4373a531b10f581ecd096cbc27a7318a4
Allow holders of android.Manifest.permission#PACKAGE_USAGE_STATS
to be notified when data usage has exceeded a given threshold.
This allows an app to update its data usage metrics without
polling.
Bug: 25812785
Change-Id: I3a4904a97f3c7fbaf8071b460f9ee6ca9c1ba4ed
Network tags could be set since ICS but was not exposed
through the SDK. This CL extends existing functionality
of NetworkStatsManager to return network tags.
Bug: 25813338
Change-Id: I414b98193249ba88a3f2d64cb2e0d2633f64fa3f
Unless SELinux blocks it, all apps have identical access to files
included on the system partition. Since there are a handful of
useful files stored there, like ringtones and license files, carve
out an exception to allow file:///system/ style paths.
Note that StrictMode isn't a security mechanism, which is why we're
not concerned about resolving canonical paths.
Bug: 26895798
Change-Id: If0b659d30c4e51377edcf01445392759d1e4962e
For several releases now we've told developers that sharing raw files
between apps is a recipe for trouble. There are at least three major
problems with sending raw files:
-- Apps sending generic intents can't know who is at the other end,
so they may not have access to shared storage locations. This is
more likely now that runtime permissions require apps to explicitly
ask users for permission.
-- Apps making files in their private storage world-readable has been
deprecated for several releases, and now in N it's fully blocked. If
we let these intents through, the receiving app would fail to open
the file, when the real blame rests on the sending app.
-- Devices with user profiles can't share raw files when using
cross-profile intent filters, since filesystem access is fully
locked down between users.
The time has finally come to communicate clearly that if you're
sharing content between apps, you need to use content:// Uris. We
added the simple FileProvider several years ago to give apps a clean
way to migrate with minimal work on their part.
Bug: 26860922, 9069185
Change-Id: I075f627f6a0d6c7fca2c090ca133b9aae9801c64
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
* 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
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
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
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
