High cpu times are expected as multiple cores can be running at the
same time, so comparing against the time between samples is incorrect.
I am reasonable certain that the values we see now are correct, so disabling this
check. However, checking for negative values (overflows) is still enabled and
will remain enabled because there is no case where we will be ok with negative deltas.
Bug:22461683
Change-Id: If9c7cdbb75ceaed059d1e0f4dd83cfdd3e021a93
Currently PopupWindow used for the floating toolbar specifies
neither FLAG_LAYOUT_NO_LIMITS nor FLAG_LAYOUT_IN_SCREEN.
As a result, the floating toolbar can overlap the selected
text when the attached window does not have enough height.
Here is the repro code.
final TextView textView = new TextView(this);
textView.setLayoutParams(
new ViewGroup.LayoutParams(
ViewGroup.LayoutParams.MATCH_PARENT,
ViewGroup.LayoutParams.WRAP_CONTENT));
textView.setText("A test sentence.");
textView.setTextIsSelectable(true);
final AlertDialog dialog = new AlertDialog.Builder(this)
.setView(textView)
.create();
dialog.getWindow().setGravity(Gravity.BOTTOM)
dialog.show();
If you tap a word in the dialog, the floating toolbar
unintentionally overlaps the selected text due to the limited
height of the AlertDialog.
It also turns out that just calling
PopupWindow.setClippingEnabled(false)
to specify FLAG_LAYOUT_NO_LIMITS is not sufficient and ends up
showing the toolbar on the NavBar because we have mistakenly
compared bounds in window-local coordinates
(e.g. FloatingActionModemContentRectOnWindow) with bounds in
screen coordinates (e.g. FloatingActionMode#mScreenRect).
Hence the confusion of window-local coordinates and screen
coordinates in FloatingToolbar and FloatingToolbar also needs
to be addresses.
To summarize here are the notable changes in this CL:
- Specify FLAG_LAYOUT_NO_LIMITS so that the floating
toolbar can be placed outside of the attached window.
(We do this with PopupWindow#setClippingEnabled)
- Switch to use screen coordinates from window-local
coordiantes in FloatingToolbar and FloatingActionMode
because some system components such as WindowManager
prefer screen coordinates.
- Put -OnScreen suffix for Rect and Point variables
as long as they are in screen coordinates.
Bug: 22335001
Change-Id: I71a8d356e868dc7715b030ca1078da4ec39368c3
Activating the assistant will now route through SysUI, so
we have the logic whether to start an activity or to start a voice
interaction session in one single place.
Bug: 22201770
Change-Id: I0f4699533aea2a1e595ee25a844434c82f548c01
This reverts commit 001d51496d.
Background: To just inherit AlertDialog, the content view should include
a title as we do in support library (AlertDialog uses NO_TITLE feature),
but up-streaming support library implementation to the framework at this
point might cause more issues. Verified that the narrow dialog issue
(b/22044600) does not happen in the framework implementation regardless of
whether it uses AlertDialog or not.
Bug: 22286869
Change-Id: Ic2554cc9e683beff29d1deee91945c1dace83ab1
Apply an automated decay factor if apps decide to claim all of their
targets are SUPER IMPORTANT. Apply the multiplier from the apps
themselves as well as a penalty for apps that come in late - let's see
how fast developers get their ChooserTargetServices to start!
Also fix a bug with ResolverDrawerLayout where dragging from the title
area wouldn't always work properly.
Bug 22302285
Change-Id: Ib6eb2b6fb92608790b2267c0f671c9ae59b2907e
Argh, this explains some weird instances of negative power
given to Wakelock usage. Realtime and uptime were switched in the
parameter list, and since they're both longs, compiler was happy.
Bug:22295225
Change-Id: I6759504f2690baf66af567d8b1a6d0478bc22228
Perform app op check in addition to the permisison check for all four
paltform components - activities, content providers, broadcast receivers,
services - if they are guarded by a permssion that has an associated app
op. This ensures that legacy apps will behave correctly if the permission
of the caller has been revoked, i.e. the app op for that permission was
disabled.
bug:22199666
Change-Id: Ia22d1c38d58b3cd6aabdc655cb7c7bddd85da7a2
Add new VoiceInteractionSession.closeSystemDialogs() API that closes
everything except the session itself.
Change-Id: If45f1e120d8ca095b6c8055b6485acb5e710820e
An intent may bounce several times between users.
In this case, we want mContentUserHint to refer to the original
user.
BUG:19656340
Change-Id: I22a35fab0c228140dcb223899f5e38ff33ee5aed
windowSoftInputMode="adjustPan" config causes the root view to be
offset if necessary when the soft keyboard is shown to keep the text
selection visible. Account for this offset when calculating the
global visible rect of the textview in relation to the screen.
Bug: 21687644
Change-Id: Id44cad387d0a3f1f063880497c234052924717ea
Counts may differ from user perception. For example, if notifications arrive
after the shade is open (even if it is only peeking) there will not be another
panel_reveal before the user sees the shade. User perception is more accurately
measured by visibility events.
Peek events will report the notificaiton load as 1.
Bug: 20088581
Change-Id: I10221d4b66a18c223aae21e616615f087c65b1e1
Caused by ActionMenuItem's SubUiVisibilityListener
not being nulled when it is replaced via setActionProvider().
BUG: 22189734
Change-Id: Id4deaa05cd5554ca7bdf969a592e4812e39dcb75
Fixed by making sure to update visibility immediately after setting a
hide flag on the FloatingToolbarVisibilityHelper.
Bug: 22101632
Change-Id: Iea2d9786c14f6451da836e55f0d880025aa00ed2
