Two things: (1) make sure the boot message is always positioned within
the entire unrestricted display, and (2) allow the dim background to go
on top of the nav bar when being used for the boot message (this latter
is really a hack that should be more generally fixed in the future).
Change-Id: I7261b044eb802a39cadff931b50a679ff18781d6
For kiosk-type devices that do not present any navigation UI. This allows
for clean selection of the implementation based on resource overlays,
without the need for the tablet or phone status bar implementations to
accomodate the desired behaviors.
Bug 5824373
Change-Id: Ia5aca7df70a11e632eaf9be6e67900ded8ea2f7d
Remove the right-to-left cascade effect from action mode menu
items. Animation time is now fixed at 300ms for scaling in menu items.
Change-Id: I8eef2ed9f93c2af804663dd5e6b3f4915ed45cb1
This adjust various paths through InputMethodManager so that the flow
in switching focus from one application to another is cleaner, resulting
in less work being done, resulting in it being able to happen quicker.
Some of the changes here avoid doing stuff when not needed, such as when
we are told to unbind but are not currently the active input. A big part
is also a change to the flow when a window receives input. Previously
this would first do a checkFocus() which would tell the input method to
switch focus to whatever view has focus in the window, followed by the
windowGainedFocus() call telling it the window had gained focus. This
would result in extra work because the input method service would first
handle the focus switch, seeing the IME is currently displayed, so the IME
would remain up and reset its focus to the new view. The app would
immediately then tell it about the window, causing the service to find out
the IME should be hidden and telling the IME, but the IME couldn't hide
itself until it had first take care of switching its input.
There is the definite potential of this breaking IME showing/hiding in
cases depending on the order things may be relying on them to happen. I
haven't seen any problems with a brief trip through the UI.
Change-Id: I8494cbd6e19e2ab6db03f2463d9906680dda058b
* commit '2a1d19174e32bb6056086ec603948cd476a2ea67':
docs: move USB installation info into the OEM USB Drivers document because the Google USB Driver is deprecated, so consolidating the USB info makes more sense for the common case of needing an OEM driver A few changes to the device setup doc also; such as removing the "unknown sources" step, because that doesn't apply to adb installs.
the Google USB Driver is deprecated, so consolidating the USB info makes more sense
for the common case of needing an OEM driver
A few changes to the device setup doc also; such as removing the "unknown sources"
step, because that doesn't apply to adb installs.
Change-Id: Ice78c997cbb147865ead78fb037d0b6b64db75bd
This is a grotesque hack to avoid showing status bar controls. The real
solution will be coming via master but not extremely soon; stay tuned but
this gives the right presentation for now without affecting normal products.
Bug 5824373
Change-Id: Ib5348024853ad2e7715b824aba522d80b6a99048
Change clock sync control to velicity form PI loop. Tuned for office LAN and
WiFi conditions, will probably perform better in clean environments.
Improve packet filtering to prevent clock sync on bad rtt.
Changed diag interface to take rtt times, P, I, D are no longer supported.
Change-Id: Id7758262c5f987f07d7091aba6c0874d7c19f387
Backported from master, including a bug fix and a cdma enhancement.
Even if other people are sharing the connection (ie, carrier wants
default and tethered traffic on the same APN) stop using a carrier-
described APN when the tethering stops.
bug:5972599
Change-Id: I25e4831855e6b62c0c3ab3a6f4d4846aaee6ac50
Since CDMA doesn't use APN settings there was no place to say what a cdma
device's DUN connection would support, so by default normal device
originating traffic would be blocked on a tethering single-connection device.
With this change you can (via overlay) say that it supports everything
so mms and on-device browsing/email will still work even when on a dun connection.
The reason to allow both: some carriers will charge per byte for dun access
and so they don't want lots of non-tethering traffic used (costs the user alot)
but other carriers just use a dun connection to limit access to tethering, but
once there give unlimited data, so it makes sense to support everything there.
bug:5972599
Change-Id: I78fd7f3ac63c51a0560b659ed5ec219b10a93f8d
If config_alwaysUseCdmaRssi is true, the RSSI signal bar only
shows the CDMA value, no matter it connects to EVDO or WiMax .
bug:5941743
Change-Id: I4187571898a9fb47162e1ccf0cc4c59c3136ae0b
