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
Stop calling onExtractTextContextMenuItem if "Select All"
is selected (the action does not modify text thus does
not need batch editing). Editor#finishBatchEdit reports
that text changed which in turn can stop the action mode
and the selection after it was started by onPreDraw.
Bug: 22059417
Change-Id: I5354cbe4bae374e0d5f3de39616336170ee33b92
Sockets accepted on a server socket didn't populate
the mPfd field, which is used to close out the java
end of the native-and-java communication socket when
the overall rfcomm socket is closed. #badnewsbears
b/21398841
Change-Id: I3adb0a9965f83d0f3006fa4f79ea4abeab5c9a17
For modern apps targeting M SDK and up the external storage state
is deterined by granted permissions. For apps targeting older SDK
the storage access is determined by app ops correspning to the
storage permissions as the latter are always granted.
When app ops change we do not remount as we kill the app process
in both cases enabling and disabling an app op since legacy code
is not prepared for dynamic behavior where an operation that failed
may next succeed. Hence, we remount when we start the app.
For modern apps we don't kill the app process on a permission
grant, therefore we synchronously remount the app storage.
bug:22104923
Change-Id: I601c19c764a74c2d15bea6630d0f5fdc52bf6a5a
1. When querying for components to which to grant default
permissions we are now getting disabled components as
well as we want such packages to get default pemrissions
on upgrade as disabled components may get reenabled.
2. When resolving activities to whose packages to grant default
permissions we skip the corss-profile and skip-profile filters
as they are set by device policy which should not affect
implicitly default permission grants. Policy has explicit
APIs for permission management.
bug:22405963
Change-Id: Idf56d35e567a6fd6e097cd45988d1561422ee6fc
In the case when multiple apps handle a given web-link action,
all of which have been marked as "launch the app instead of a
browser" and so are otherwise ambiguous, always prefer the app
that was most recently placed into the always-handle-links state.
Bug 22051035
Change-Id: I3f43c19b0d7b74e9843445e41971bb5433affb1c
Android Keystore provider's KeyFactory and SecretKeyFactory
implementations were throwing UnsupportedOperationException instead of
InvalidKeyException/InvalidKeySpecException from their
translateKey/generateKey methods.
Bug: 22459811
Change-Id: I6d5a5dc1bed724e858ad324d558b7480b9b848da
Bug: 22392651
ColorStateLists were never cached because the lazy-create
of the constant state had a typo.
Resource caching in general was broken because ThemeKey did not
clone the hash code, so all keys in the cache had a hashCode
of 0 which did not match the real, uncloned ThemeKeys hash code
so the binary search in ArrayMap based off of hash code was failing.
Change-Id: I9df1628b226bfa797bed97875354c19bf64f41ad
