* commit '1a8a8b73d48261384a0f63df894b68db97e7b02c':
docs: change that stated as a few doc fixes and turned into fully documenting the device default themes and fixing many more, including adding API level information for older themes to avoid confusion. Oh and fix an unclosed <em> tag causing a format bug.
fully documenting the device default themes and fixing many more,
including adding API level information for older themes to avoid confusion.
Oh and fix an unclosed <em> tag causing a format bug.
Change-Id: Ia4b33559bd5ad2cbae8b53966999cf7f5038b125
The comment of this field is also aggregated in the android.R.styleable#View
description. As a result, the @deprecated in the comment of this field also
applies to android.R.styleable#View which incorrectly appears deprecated.
This fixes the problem, although fadingEdge will no longer be marked as
deprecated in IDEs. I believe it is less important that to make View
deprecated.
Change-Id: I96d8e868001c4c853eb1536f8401275b9b1e689b
We now have an animation that can start as soon as we detect to
rotate the screen, and have a different phase once the new UI
is ready to complete the transition into it.
Change-Id: I05b9c12a699232acbddc36b4a994a4452db71476
Bug 5806267
Use visual selection to determine the webkit selection.
The webkit selection can be used to cut text from an editable
area. It can also be used to do better complex character text
copy.
Webkit change: I194c6d9e2add67151b97092a1a54f5c081296000
Change-Id: I56543d17670a8c98484314c89c7fa6a94cb809e4
incorrectly specified.
This affected search bars and alert dialogs spawned from activities
using Theme.DeviceDefault.Light as a base.
Change-Id: I219d38d486498db5b4b283560256afd7d6051535
- cherry-picking framework CLs from master into ics-mr1 that are
needed for FU to work on tablets
- needed for OEM partners even FU isn't going on xoom
Squashed commit of the following:
commit 3258f2528f558efdaf34ae15c5425f2d879848fe
Author: Brian Colonna <bcolonna@google.com>
Date: Tue Dec 13 15:49:48 2011 -0500
Added Face Unlock to tablet lockscreen layouts
The Face Unlock Area was not part of the tablet layouts, so prior to
this change, Face Unlock would not show up on tablets when selected as
the unlock method. The backup unlock method would show up instead.
The goal here is for the pattern and PIN unlock layouts (in both
portrait and landscape mode) to look the same as before this change.
This was a little harder than it was with the phone layouts for two
reasons:
1) For the phones it was ok for Face Unlock to be sized such that it
just covers the backup method. For the tablets we want Face Unlock
to cover far more real estate.
2) The phones were based on a grid layout, whereas the tablet is a
linear layout.
Note that the diff makes the modifications look way more extensive
than they actually are. Basically, in most cases I am putting a
relative layout around some existing portion of the layout and
putting the Face Unlock Area area inside of the new relative layout.
Change-Id: I478becddf2a9ee9fe7b6d653e604fa3ad89b822f
commit 821cfe85cf2b3daf074d9749dbf6e0a5663af0de
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 19 15:51:10 2011 -0500
Unbinding from FU when going to backup
Lockscreen was stopping Face Unlock when going to the backup lock, but
not unbinding from the Face Unlock service until the device was
unlocked.
This caused a bug on the tablets where Face Unlock would reappear when
switching between portait and landscape orientations, even after the
backup lock was exposed. On an orientation change, Face Unlock is
restarted if the service is bound to during the orientation change.
Since it was bound to when it should not have been, Face Unlock was
restarting when it should not have been.
The wakelock is also now being poked on an orientation change because
on the tablet you can keep Face Unlock alive by switching the
orientation back and forth, but eventually the screen would go dark
with Face Unlock running.
Also, a conditional was moved in activateFaceLockIfAble() so the whole
section isn't executed if Face Unlock is not in use. Part of it was
being executed with only the inner-most part having the check. This
did not cause any issues that I am aware of.
Change-Id: Ib452b8ced28a507bf9272dbf5d3477a8abd1ba90
commit fa90bb76ac6b311d12b55d23df4ac44cec62c7b3
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 12 18:02:23 2011 -0500
Changed how Face Unlock coordinates are specified
Was using View.getLeft() and View.getTop() to specify the upper-left
corner of the Face Unlock area. That gives coordinates relative the
view, which was fine for the phones. For the tablet it needs
coordinates relative to the window (which still works for the phones).
Also fixed a 'bug' where h and w were swapped. However, it wasn't
causing a problem because it was swapped in two places.
Change-Id: I86c1f68439f1dcef826cfe6b8fb56c9a4a6b8dc3
Change-Id: I962c0486be85949e002b0a2701286a6a39251f36
Run a background "watchdog" thread that will check for
the WebCore thread stopping processing messages (this
can happen if a piece of JavaScript goes into an infinite
loop, for example) and offer to close the WebView app when
it detects such a case, much like the normal system ANR.
Bug: 2563868
Change-Id: Ic74813b1e630d657c340a7017a4b0814071eb041
Nested brackets are not supported in JvaDoc and the resulting link is
broken and the rest of the comment ignored.
Used an hardcoded 14 value and removed the link.
Change-Id: I4982e827d81e06edf0c4dd5bcb20e9ff89455a4d
When using a PIN backup method, Face Unlock was touching the bottom of
the status text on the top and the top of the carrier text on the
bottom, which made it look crowded and bad.
4 dips of padding was added to the bottom of the status text and
another 4 dips was added to the top of the carrier text. This
corresponds to 8 pixels on the prime and 6 pixels on the crespo. The
effect of this is that the keypad is 6 pixles closer to the entry text
on the crespo and 8 pixels closer to the entry text on the prime. On
crespo, the keypad and entry text views are now as close as possible
when examining the pixel locations, but visually there is still space
between them and the difference is hardly noticable to the eye.
Despite the small change, Face Unlock looks a lot better when it is
not literally touching the text.
Change-Id: I01a7a6ace4789232595c5aa7683c1342ebbb2ee2
The idea is that this is a device which is more-or-less headless. It
might have some limited interaction capabilities, but it's not something
that you want to rely on having.
Change-Id: Ib92f53a120bf83de781728011721a4859def7d9f
The Face Unlock Area was not part of the tablet layouts, so prior to
this change, Face Unlock would not show up on tablets when selected as
the unlock method. The backup unlock method would show up instead.
The goal here is for the pattern and PIN unlock layouts (in both
portrait and landscape mode) to look the same as before this change.
This was a little harder than it was with the phone layouts for two
reasons:
1) For the phones it was ok for Face Unlock to be sized such that it
just covers the backup method. For the tablets we want Face Unlock
to cover far more real estate.
2) The phones were based on a grid layout, whereas the tablet is a
linear layout.
Note that the diff makes the modifications look way more extensive
than they actually are. Basically, in most cases I am putting a
relative layout around some existing portion of the layout and
putting the Face Unlock Area area inside of the new relative layout.
Change-Id: I478becddf2a9ee9fe7b6d653e604fa3ad89b822f
The ICS navigation guidelines state that the OK action should be to the
right of the cancel action in UI dialogs. Update the SIM PIN unlock and
SIM PUK unlock layouts to swap the OK and Cancel buttons (for soft keypad)
and the OK and Emergency Call buttons for the physical keyboard landscape
layout.
Bug: 5730977
Change-Id: Iaf565bc2b584292a34f5a72a7a763003f9149f27
Fixed a problem where the key up for the ALT or META key was not
delivered to the task switcher dialog because it was deemed
to be inconsistent with the window's observed state. Consequently
the dialog would not be dismissed when the key was released.
Moved global hotkey handling for META+* shortcuts and ALT/META-TAB
into the window manager policy's interceptKeyBeforeDispatching
method. This change prevents applications from hijacking these
keys.
The original idea was that these shortcuts would be handled only
if the application did not handle them itself. That way certain
applications, such as remote desktop tools, could deliberately
override some of these less important system shortcuts.
Unfortunately, that does make the behavior inconsistent across
applications. What's more, bugs in the onKeyDown handler of
applications can cause the shortcuts to not work at all, for
no good reason.
Perhaps we can add an opt-in feature later to enable specific
applications to repurpose these keys when it makes sense.
Bug: 5720358
Change-Id: I22bf17606d12dbea6549c60d20763e6608576cf7
Bug: 5721663
Added content descriptions and made the listview allow navigation between nested
views.
Change-Id: I69d78d65e1bab829f63c2e6025051206e511f00f
3-state item to toggle between Silent/Vibrate/Ringer in long-press power menu.
No volume dialog on lockscreen, unless Power menu is up.
Set VIBRATE_IN_SILENT=1 when upgrading device.
Change-Id: I097d216f96c4abdbd83420e0c477106951b3607d
