...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
Scroll events are used to report position change and should not
contain the text content of the view that fires them because it
is usiually a containter for many other views and the text will
be long and not informative for accessibility purposes. Also
such evens are fired relatively frequently. If a client wants
to fetch some textual content for a scroll event he can use
the interrogation APIs.
bug:5352059
Change-Id: I43e02aca895c8ab16ba82ebe1cee3aea8ce7711a
The implementation of the method View#setTag(int, Object) stored tag
objects as entries in a static WeakHashMap associated with the View as
a key. This was problematic for any tag object that stored a hard
reference back to the View the tag was placed on, as it would cause
the WeakReference key to never be collected and the entry to persist
forever.
This was particularly nasty if an app used a keyed tag to store a
ViewHolder object referencing child views for use in the Adapter
implementaion for an AdapterView, since child views will always have
hard references leading back to the parent.
Change-Id: Ia17840a301ba0e0c928861405388fb2f625dac2c
If the default target button is hidden all activities are shown in the list from
which to choose. In this case due to off by one error the list was not showing the
option to expand it if the activities are one more than the initially shown.
bug:5358475
Change-Id: I8c3db37dab008637d78330f8de830cec92720264
- Autofocus does not lock AE and AWB.
- stopPreview and takePicture do not clear AE and AWB locks.
bug:5356404
Change-Id: I55d9b35f4ff746ecd2bff112c2674f1aa2543aca
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
