Added Context.sendBroadcast(Intent intent, String[] receiverPermissions)
method, which allows an array of required permissions to be enforced.
Bug: 21852542
Change-Id: I3b8ff258fa9f3249c344bb8093b820b24eef00c0
Previously, once a network validated, for the purposes of comparing networks
to select the default network, we always considered it validated.
With this change if a network later fails to validate, we'll take this latest
validation result into account. This means if WiFi and cellular are up
(e.g. if we recently switched from cellular->WiFi, and cellular is now
lingering) and both are validated, but for some reason WiFi fails a validation,
cellular will become the default network connection.
Bug:20896761
Change-Id: I858aa10c1aaec5cd9032067f960963409107bdb1
Reduce the duplication of some logic so when falling back to Cellular
when WiFi fails to validate is enabled, there's less chance for bugs
and failures:
1. De-duplicate several Network vs NetworkRequest matching functions
2. Remove the very tricky nascent logic by adding a simple "lingering" bit.
Bug:20896761
Change-Id: I21da9e827eec9cfd6835fcaa650192b9186ed053
1. We don't parse PAD options properly, leading in failure to
parse packets sent by DHCP servers that put the end of options
marker after pad options and at an odd offset.
2. We get the DhcpResults vendorInfo from the wrong option type
(60 instead of 43).
Fix these and add unit tests for the offer packets sent by a few
different DHCP servers.
Bug: 21955617
Bug: 22281295
Change-Id: I5d13f1a6a3ff0b53112f18f3db8792fa32ad2da3
It's not clear what it means to request a network with a mutable
NetworkCapability like NET_CAPABILITY_VALIDATED or
NET_CAPABILITY_CAPTIVE_PORTAL. Presently requesting such a network
would fail in a number of different ways:
1. The NetworkFactories would fail to match the request against their
filter which doesn't include stateful NetworkCapabilities.
2. If the NetworkFactories did match, they'd bring up networks to try
and satisfy the requests, but the networks would not have any
mutable NetworkCapabilities initially so they'd be reaped.
Because of these problems it's safest to simply disallow these
requests.
Bug: 21343774
Change-Id: I56303242b81d39b370b8d5d1e32059bfcfc25949
Aggregate and then periodically report stats that are high-frequency
because they are driven by app behavior, not user behavior.
Reuse the NotificationUsageStats facility.
Remove redundant stats.
Lessen memory foot print.
Enable in-memeory aggregates with small, bounded memory footprint.
Bug: 20258744
Change-Id: I87e391419c53917fa13c68a56f8cdb40a7c8e548
Add exceptions/checks for keysetmgrservice interractions which *should* never
happen, but would result in NPE or invalid metadata. Also handle mismatches
between package and keyset metadata in packages.xml.
Bug: 20128916
Change-Id: Ia0f63f78d232d9d8d9fbe4cd8e6cc3406e5192a7
We used to only remove requests that we'd acted on but that's
just wrong.
Also adds test case which exposed the problem but passes with the fix.
bug:20731384
Change-Id: I581a005560cc71167b857abf2452769399a9e1b7
Overlapping the NetIDs can cause the ConnectivityService instance under test
to inadvertently use real networks, for example when NetworkMonitor attempts
to validate a network. This fixes test hangs when run on devices with
active internet connections.
Change-Id: I5e1898953f0117b9f75beccac4a52ae2db173567
Move the binder stub inside the service and inherit from SystemService
to take advantage of SystemServiceManager.
Change-Id: Ic6fff50ccfcf6c9626ffca8d61f627c055608953
The initial implementation of toDhcpResults attempted to get the
leased IP address from ciaddr if yiaddr was 0.0.0.0, but it never
actually did so because a) it used == instead of equals(), and b)
the parsing code never populated mClientIp for a DhcpOfferPacket
or DhcpAckPacket.
Fix this and add a test for it.. Technically DHCP does not use
ciaddr (only bootp uses it), but in 5.0 we would use ciaddr if
yiaddr was 0.0.0.0 and a bit more compatibility shouldn't hurt.
Bug: 19704592
Change-Id: I1f58555f0c10b9c576995a6edb759a83d8938ea0
Currently we treat a lease time larger than 2**31-1 as a negative
value, which causes DhcpClient to attempt to renew its IP address
constantly. Fix this by properly handling large and infinite
lifetimes, and while we're at it, impose a minimum lease time of
60 seconds.
Bug: 21352084
Change-Id: If62c9efeffad6222e2fe0c110f77d0e4c70de96d
Add unit tests for the keyset portion of packages.xml. Also fix previously
broken test by adding UserManagerService reference.
Bug: 19530911
Bug: 19530120
Change-Id: I251fc3e9dc983f1d63f9e84905d3ed0e64843def
We mostly follow RFC 2131, which says that secs is the number of
seconds "since client began address acquisition or renewal
process", and thus set secs to zero on renew. This is different
from our current behaviour, which keeps on counting without
resetting secs to zero on renew.
Bug: 19704592
Change-Id: Ifbb7644094c579be626ffb698eee87047425dbf0
Add idle mode support to the alarm manager. Introduce
a new concept of flags associated with alarms to tell
the alarm manager how to treat the alarm -- they allow
everything from the alarm that will bring us out of idle
mode, to alarms that are allowed when idle or should
also bring us out of idle. The standalone boolean is
now also a flag.
(Note there is currently no protection from user space
setting the flags however it wants; I will be working
on that in a follow-up change.)
When in idle mode, the alarm manager pushes all alarms
that shouldn't execute during that time over to a
separate list that is not executed until out of idle.
To help with this, I reworked a bit how Alarm objects
are managed, so that when rebatching or moving between
lists we don't have to allocated new objects but can
just use the same existing instance.
Also tweaked the sync manager to deal with idle mode,
which currently just means doing the same thing as when
low on storage -- turning off sync.
Add new ACTION_CHARGING and ACTION_DISCHARGING broadcasts
that apps can listen for to know when the device is actively
charging and discharging. These are better than the old
POWER_CONNECTED and POWER_DISCONNECTED ones because we only
report charging when we actually see that there is enough
power being provided to charge the battery (and will report
discharging if there is not enough power).
The job controller uses these new actions for scheduling
jobs that want to run while plugged in. Removed the
"stable charging" stuff while doing so, since the new
charging state serves as an even better signal for that.
Introduced two new process states: FOREGROUND_SERVICE and
TOP_SLEEPING. This will allow us to treat foreground services
specially (such as still allowing network access to them for
background music playback) while not mixing them together with
whatever happens to be the top activity while the device is
asleep.
Also some other small cleanup here and there.
Change-Id: I7a9808b578bad6f50deb8e1baf919298512a0d3a
Added public api to query creation time of the user or of a managed profile
associated with the calling user.
Bug: 20049349
Change-Id: I7f9263fe434233e6f7d4f165c974cab64ca7107c
This currently truncates all strings at the first NULL character,
except for vendorInfo, which is an opaque string.
Bug: 19985674
Change-Id: Ie53b2c55eb8a5204d7b2c7e2d8587743d923647a
This currently truncates all strings at the first NULL character,
except for vendorInfo, which is an opaque string.
Bug: 19985674
Change-Id: Ie53b2c55eb8a5204d7b2c7e2d8587743d923647a
Added new restriction types - bundle and bundle-array.
Modified RestrictionsManager.getManifestRestrictions to support new
hierarchical restrictions.
Added RestrictionsManager.convertRestrictionsToBundle, which enables
programmatic conversion from a list of RestrictionEntries to a Bundle.
Modified read/write methods for application restrictions in UserManagerService.
Added unit tests.
Bug: 19540606
Change-Id: I32b264e04d5d177ea5b4c39a8ace5ee0ce907970
