1. Check the length of the fixed-length portions of the packet.
2. Catch BufferUnderflowException while parsing options.
Change-Id: If907f49f02a04a4a3360f46a3192e94ab099af0e
The behaviour of the client is intended to mirror the behaviour
of the current DhcpStateMachine + dhcpcd combination, except it
does not store leases across network changes.
Bug: 19704592
Change-Id: I110b58003da2d8293059d48a0181e16f7f7f145c
1. Define and add parsing code for MTU, max message size, T1, T2.
2. Add common TLVs (message size, hostname, vendor ID) to all
packets sent by the client.
3. Don't include requested IP and server ID in renew messages,
since the RFC says MUST NOT.
4. Don't hardcode the broadcast flag to true in DISCOVER packets,
use what the caller passed in.
5. Make some methods static.
Bug: 19704592
Change-Id: I42a0997e468b12e19cad9b403b98fe266e6cea73
1. Add a method to make a DhcpResults object from a DHCP packet.
2. Add a method to fetch the client MAC from the packet. This is
needed to check that the message is for us (lots of DHCP
messages are broadcast).
3. Add a length argument to the method that parses DHCP packets,
so the caller can use the same MTU-sized array all the time
instead of having to pass in a new array for every packet.
Bug: 19704592
Change-Id: I58223f5ec90fb5c762bc2934649e02f9122018b2
1. Support L2_ENCAP when building packets as well as when parsing.
2. Skip IP options when parsing DHCP packets.
Bug: 19704592
Change-Id: Ic27a45790ed1cf7cf5b82d63b6c0b64c909a570f
1. Delete the DhcpStateMachine, since we don't plan to use it.
2. Make all InetAddresses Inet4Addresses, since that's what they
are. In order to do this, define INADDR_ANY and
INADDR_BROADCAST, constants, since Inet4Address.{ANY,ALL} are
not Inet4Addresses but InetAddresses.
Bug: 19704592
Change-Id: I5a0499be889076992a60aaad0bd8be5ea66bd560
There's no need for it to be in frameworks/base/core, since it
will only be used by services.
Bug: 19704592
Change-Id: I2f5277eca848b7000ca46db575e8602eacb5c8bd
Any device that supports USB OTG is capable of running Ethernet
via a USB OTG cable and Ethernet to USB adapter.
Currently, we only start the Ethernet system service if the
device has FEATURE_ETHERNET, but this requires that every device
explicitly declare FEATURE_ETHERNET, which causes bugs like
http://b/18515146 , where the L OTA broke Ethernet on nakasi.
Therefore, start the Ethernet service on all devices that have
FEATURE_USB_HOST.
Bug: 18515146
Change-Id: I3b4e85d1ad8e1aea9baa046a27f5b4dd68c42028
A security leak was discovered whereby a malicious app could get the
IActivityContainer object from one app and use it to inject events
into another app. This fix removes the availability of the
IActivityContainer and replaces its one use with a method for
returning the information the IActivityContainer was used for.
Fixes bug 19394591.
Change-Id: Ib3cec25b25130cd8e098892c057742cfd575cfdd
Clearly document which methods in Vpn.java are designed to be used to
service a Binder call, and which must therefore check permissions and
clear the calling identity, and which methods are designed for
internal use only and which therefore need not check permission.
Add a new startLegacyVpnPrivileged method which bypasses the
permission checks, to be used by lockdown VPN which is a trusted
system service. Ensure that the existing startLegacyVpn method checks
permissions as this is used whenever we respond to a binder call.
Bug: 19311172
Change-Id: I34f13258ee7481f1356bc523124cf5db068b4972
1. If reportInetCondition says the network is not working, and
the network is already marked not validated, don't revalidate
it. This was superfluous and should save battery.
2. If reportInetCondition says the network is working, and the
network is not marked as validated, revalidated. This will
allow us to get out of a validated state quickly based on app
input (e.g., allowing GCM's exponential backoff timer to drive
revalidation instead of our 10-minute timer).
Bug: 19258761
Bug: 19209043
Change-Id: Iaa4bac82d117ed1f4088dab106e6f6ce46b34bc3
If a user is subject to a VPN, getActiveNetworkInfo() will return
the VPN's underlying network (e.g., TYPE_WIFI), so that apps that
call getActiveNetworkInfo to answer questions like "is the device
connected to wifi?" will continue to work. Make getNetworkInfo
do this as well: if the query is for a network type that is
underlying the current user's VPN, then return that network.
Bug: 19196545
Change-Id: Ic5a651735b927c758594a26d26a03fbd704b52e6
Instead of hard coding the available channel list, we should
get channel list from driver
Bug:19237543
Change-Id: Id2ec689273407f54709cb034d6ba666f91da51c0
As a backstop against missed alarm delivery / wakeups or clock slew,
make sure to always schedule a kernel alarm for the next alarm events
of interest when we've reexamined the set of deliverable alarms.
Bug 19201933
Change-Id: I3cd37a63dfb0c8258941497d4ba516ed00e2edad
On networks with a per-network PAC, Network.openConnection(URL) will
fetch using NO_PROXY. This will fail on networks where Internet
access is only permitted via the proxy. Always failing network
validation has the potential to disable WiFi auto-join. Instead
of performing the normal connectivity check, instead attempt to
fetch the PAC, as this is meant to succeed with NO_PROXY.
bug:19143573
Change-Id: Ia482f5c046d338c27daf42571f20851dfa36671c
We were using an approximation to determine where to send a pair of down
and up events to click on the view that has accessibility focus. We were
doing reverse computation to figuring out which portion of the view is
not covered by interactive views and get a point in this region. However,
determining whether a view is interactive is not feasible in general since
for example may override onTouchEvent. This results in views not being
activated or which is worse wrong views being activated.
This change swithes to a new approach to activate views in accessibility
mode which is guaranteed to always work except the very rare case of a
view that overrides dispatchTouchEvent (which developers shouldn't be
doing). The new approach is to flag the down and up events pair sent
by the touch explorer as targeting the accessibility focused view. Such
events are dispatched such that views predecessors of the accessibility
focus do not handle them guaranteeing that these events reach the accessibiliy
focused view. Once the accessibiliy focused view gets such an event it clears
the flag and the event is dispatched following the normal event dispatch
semantics.
The new approach is semantically equivalent to requesting the view to perform
a click accessiblitiy action but is more generic as it is not affected by
views not implementing click action support correctly.
bug:18986806
bug:18889611
Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
