1. We use auto scroll when a view gets accessibility focus.
Pros: Having magnification and TalkBack enabled together (not a common use case)
will have the accessibility focused view on the screen (it is auto panned).
Cons: A blind user can get stuck in a very lock scroll view - not good.
2. We do not auto scroll when a view gets accessibility focus.
Pros: A blind user cannot get stuck in a long scroll view as he has to explicitly
scroll.
Cons: The magnified area will not pan to ensure the accessibility focused view
is visible.
Option one is the better trade off and this change removes the auto scrolling.
bug:7265773
Change-Id: I209b54ed18acad36c1f35b4c09b980e45ec9bbff
Sending the unmasked soft input mode int setAttachedWindowFrames
included the SOFT_INPUT_STATE bits and guaranteed that the adjust
test would always pass.
Bug 7256294
Change-Id: Iaf5368432c7b350fe70687d08c0a08e814b35e94
Enable safe headphone volume feature for all countries that
do not opt otherwise in their mmc configuration.
Opt out for US.
Bug 7231029.
Change-Id: I2619d627508eb2cd1f73db9242e0cb5efa839a2a
The handle (which is now being drawn by the window and not by itself)
was floating over it.
Bug: 7267529
Change-Id: Ia8902f64ac81616c640bc42400272933063852f4
Display controller should always stay in sync with peer list to avoid
showing incorrect available status on peers which would
cause connectivity issues.
Bug: 7268307
Change-Id: If04644339c1ee3f567939e4441dd6f6a45e4179a
1. The accessibility layer announces user switches. Even though
the initial switch to the owner on a singe user device is a
valid use switch we should not announce it for accessibility.
bug:7264693
Change-Id: Idf022fab6b74c84b7a96bc4ed7c7fee2b83029a6
-> Showing correct page, as per discussions (issue 7205431)
-> Hide the time when the system status widget is showsing (issue 7216577)
Change-Id: I5b79d72e8fd8226952f6a8ea99b776feb4ddde1f
...java.lang.IllegalStateException: Can not perform this action
after onSaveInstanceStateat android.support.v4.app.FragmentManagerImpl
.checkStateLoss(FragmentManager.java:1300)
Framework fragment manager also needs to be told its state is not
saved earlier.
Change-Id: Ie5bb327fca6208f7eea6146a1b3223c61c9ecef6
When there are multiple activities that respond to MediaStore.INTENT_ACTION_STILL_IMAGE_CAMERA_SECURE
we need to show the disambiguation dialog to the user. However the disambiguation "dialog"
is actully an activity themed as a dialog. Hence, we can't show it in the secure keyguard.
This works around the issue by prompting the user for their credentials directly when the
intent needs disambiguation. This will take them out of keyguard and prompt them for
which activity they want to use.
We'll provide a more robust solution in a future release.
Fixes bug 7109816
Change-Id: I94e643d3cb503e1ce6de24c82400b4d5fcbb9d95
Mostly (turned off) debug output. Main fix is to resume the next
activity if we are pausing while sleeping and the top activity is
not the now pausing activity. Also helped things by fixing a problem
where removing a task would leave around dead destroy timeout
messages.
Change-Id: I9d550c216b4d7e2afe3d93553bb680cec41e2ed1
(padding is still hard)
- fix Toasts: basically the background drawable padding was not
taken into account
Change-Id: Iefd29782f50b6f6a56578cfeb2af119d381207f0
* changes:
Enable hardware acceleration for pointer location overlay.
Disable use of twilight mode for auto-brightness.
Use new API to override user activity timeout from keyguard.
MeasureSpec.makeMeasureSpec has a bug where a negative or very large
size parameter will cause the resulting MeasureSpec value to
overflow. RelativeLayout partially relies on this when measuring
children with mode UNSPECIFIED; a default value of -1 in a local
variable ends up being passed to makeMeasureSpec, overflowing a mode
value to create a measurespec that is very large in size, with AT_MOST
as the mode. The correct behavior is for RelativeLayout to propagate
the UNSPECIFIED mode.
Unfortunately a number of custom view implementations in apps rely on
the buggy behavior as they do not implement their own onMeasure
method. This makes them fall back to View's default onMeasure
implementation, which accepts the spec's size unconditionally for
AT_MOST or EXACTLY modes, but falls back on
getSuggestedMinimum[Width|Height] for UNSPECIFIED. If the view had no
background drawable with dimensions and no minWidth field set, this
fix for RelativeLayout causes some views to measure with a size of 0
rather than a size of the 30-bit version of 0xFF...
Revert these fixes in the interests of compatibility. The next version
will conditionally use the new behavior if targetSdk > JB-MR1.
This also required reverting a fix for ImageView's adjustViewBounds
functionality, as it cannot be implemented reliably if this
RelativeLayout fix is not also in place.
Revert "Fix UNSPECIFIED measurement in RelativeLayout"
This reverts commit 132a742b94b9716451ddef30cec20548b346f1b9.
Revert "Fix adjustViewBounds handling for ImageView"
This reverts commit d5edc7721791ad807b9a8fbd923b8d6e73c399cc.
