* commit '19a048626e29524e17bbe30f1f235aa365b6212b':
Fixed the problem where getEntityAndIncrementCursor would always return "0" for attendeeIdentity & attendeeIdNamespace instead of the actual string.
* commit 'a13730f42449d97ec7206769ccaad9d95bc2924f':
Fixed the problem where getEntityAndIncrementCursor would always return "0" for attendeeIdentity & attendeeIdNamespace instead of the actual string.
Optimizations in drawing and invalidation in JB did not correctly
account for static child transforms
(View.getChildStaticTransformation()).
For the invalidation part, this meant that views were not properly
setting the invalidation bounds (which should be transformed by
the static transform), so the affected area of the invalidation
was potentially incorrect. For the drawing part, this meant that
views outside of their parent's bounds were being incorrectly
rejected when the static transform would, in fact, place the views
inside of those bounds.
The fix is in two parts:
- drawing: avoid the early quickReject() logic for containers that
have static transformations set on them
(ViewGroup.setStaticTransformationsEnabled()).
- invalidation: Include the static transform in the invalidation
area propagated up the view hierarchy.
Issue #6864203 The child position outside of parent is not drawn
even it will be drawn inside of the parent after applying static
transformation
Change-Id: I73bea01feab250bdcae2d575313be355a4a3c8f5
Currently, WebViewFactory is hardcoded to always load
android.webkit.WebViewClassic$Factory. This change allows us to
load the Chromium powered WebView by setting the
"webview.use_chromium" system propery to true.
Change-Id: Icebfc4d5c4a61230c5e5dccac1ec5eca59f650ac
The objective of this refactoring is to remove the reliance on
WindowManager wrapper objects for compatibility mode and for
managing sub-windows.
Removed the WindowManager.isHardwareAccelerated() method since
it is never used.
Change-Id: I4840a6353121859a5e0c07d5cc307a437c595d63
1. If a view's important for accessibility attribute is set to auto the
framework is responsible to determine if it really is. Views with
accessibility node providers should be important for accessibilty
since they are roots of virtual view trees and such trees are
always important.
bug:6843043
Change-Id: I4b352c59fdefdf9ad220714a43ecb9e01d1c1c1f
Allow a second tap of a selected item in ResolverActivity to launch
the target as "just once" for sloppier/quicker choices.
Change-Id: If05fc7c1ac622195f6253e6ca0868fd87954dd46
For activities with a null taskAffinity, simply finish the current task.
(They probably shouldn't have specified a parentActivityName anyway.)
When launching into app info from ResolverActivity, launch the app info
page in the current task with FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET. Back
will return to the resolver, and Up will jump to Settings.
When launching into app info from RecentsPanelView or BaseStatusBar,
since this is a system affordance akin to notifications or widgets,
build the full task stack for the app info activity with
TaskStackBuilder and launch it as a new task.
Change-Id: I73b1941d0f52bd8b30382b5e17edd8ceb058c70d
