There's a few advantages to having ApfFilter in IpManager:
1. If things go wrong, crashing a particular transport is less bad then
crashing ConnectivityService. We also don't want to use
ConnectivityService as a dumping ground for transport-specific logic.
2. This makes implementing WifiManager.MulticastLock a lot simpler and
safer because enabling/disabling it doesn't have to go through the
NetworkAgent, which could risk various races (e.g. installing a filter
into the wrong WiFi network).
3. IpManager is the ultimate source for LinkProperties for a particular
transport and since ApfFilter uses the LinkProperties it's better to
have it closely paired with the IpManager. Likewise, ApfFilter needs
to know the APF capabilities of the transport, so having it in
the transport avoids having to parcel this information through the
NetworkAgent.
Bug: 26238573
Change-Id: I99b85f2b64972f0e7572170ec5d1926081aa3429
Create a common singleton thread to be shared among all
connectivity tasks. Instead of launching separate threads to
handle downstream messages from the various service instances used
in connectivity, these managers can choose to share this instance.
Bug: 27695292
Change-Id: Idd1e37a3e793c5485091509c3d7351e4d29288f0
API changes to allow a meteredHint to be passed
from a network scorer through to the wifi subsystem.
BUG:27702356
Change-Id: Ic466852d855af54c1754c4663388f24f54ed0691
Granular per-UID network statistics can be used to infer user
behavior over time, so they fall under the umbrella of the
PACKAGE_USAGE_STATS permission.
Since we can't check app-ops based permissions in the kernel, the
best we can do is redirect users to the NetworkStatsManager class,
which offers a much more robust historical data set.
Bug: 27577101
Change-Id: I696bdc5e0b3d7e24acf35f388d0ab13617ed8af3
When power-save mode was first implemented, there were no firewall rules
on netd, so the solution was to make all network interface metered and
re-use the bw_penalty_box chain.
This change removes that workaround by creating a explicit fw_powersave
chain, whose behavior is similar to fw_dozable (in fact, it reuses some
of its code); such change not only makes network restrictions on
power-save mode simpler, but it also allows to optimze how the restrict
network rules are changed (which will be done in a separate change).
BUG: 27127112
BUG: 26685616
Change-Id: I7f7a7b1c1855e916c6651ad90da29fe187a7bea2
Listen for ICMP6 router advertisements on networks that support
packet filters. Construct packet filters and install them to
ignore redundant future ICMP6 router advertisements.
Bug: 26238573
Change-Id: If78300b9fda257c21f3ee6533e1da7de9f897cb4
Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
Similar to first patch, but now using new "rethrowFromSystemServer()"
method which internally translates DeadObjectException into
DeadSystemException. New logic over in Log.printlns() now
suppresses the DeadSystemException stack traces, since they're
misleading and just added pressure to the precious log buffer space.
Add some extra RuntimeInit checks to suppress logging-about-logging
when the system server is dead.
Bug: 27364859
Change-Id: I05316b3e8e42416b30a56a76c09cd3113a018123
Also add the appropriate changes to api/test-current.txt, which
is not present on mm-wireless-dev from which this change came.
Change-Id: Ic4df6d0f89add73b7e5252ef662de07a4e8fce31
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