Give more details about why we failed to create storage paths, and
search for underlying volumes using canonical paths.
Bug: 22135060
Change-Id: I75d3584403ece310438b05f5b9fe72d94c9096c6
Added Context.sendBroadcast(Intent intent, String[] receiverPermissions)
method, which allows an array of required permissions to be enforced.
Bug: 21852542
Change-Id: I3b8ff258fa9f3249c344bb8093b820b24eef00c0
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
The javadoc for newChooseAccountIntent says that a null
value for the allowableAccounts parameter is valid and
an acceptable default. This CL makes sure that when this
parameter is null, a NullPointerException is not thrown.
Bug: 22475546
Change-Id: Ieb0d67dd02628e1ae5629499b3be3c6382efc9aa
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
Schedule a reconnection after camera service crashes if any client
registered a camera availability callback or torch status callback.
Bug: 407755
Change-Id: Iabe0bf713863898ca468cff59d4c97c66a802630
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
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
