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
Also ignore the requestedPermissionFlags of yet to be installed
packages when trying to determine if a permission is new.
Bug: 22229417
Change-Id: I59d579cdc42d64bcfdefdb06e1576959355bb7a4
In extract mode, on every screen touch
TextView#setExtractedText gets called which calls
SpannableStringBuilder#sendTextChanged which in turn stops
the action mode. As a fix, if the text is the same only
copy the spans without replacing everything.
Bug: 22315095
Change-Id: I28da760b3dc11e1cfbaf720e547bd817c5b89d7e
Raised the protection level of WRITE_SETTINGS permission to appop and also
allowed backwards compatibility with pre23 flag. Also made sure that this
permission is not added as RuntimePermission in DefaultPermissionGrantPolicy as
that breaks a lot of gmscore stuff.
Introduced new action to manage write system settings as a new API and
renamed the string that describes the managing of overlay permission.
Change-Id: Ifd25a6ddc06de68ee37015cb9fb23452e4ef10f4
The existing documentation is very terse and users were getting
confused whether the method escapes HTML metacharacters or not. Expand
the description a bit and explicitly state that metacharacters are
escaped.
Bug: 17456925
Change-Id: Icaae7fe1344629de5c0860674f3913781de18013
Previously touch slop for line movement was based on the line position
of the HandleView, not the previous line touched.
Thai and CJK languages don't have a space at the end of a line so
the handle jumps to the beginning of the next line. This meant that
when calculating the touch slop it'd be from the incorrect line.
This CL tracks the previous line touched and uses that instead to
calculate touch slop and applies it to the selection and insertion
handles.
Note this is *not* added to the drag accelerator because
it does not have the problem of the handle jumping to the next line
since it has no handles.
Bug: 21925162
Change-Id: If4b231725c06489ec780a5b5a308ceffee804c20
Bug 22403868
Initial attempt only helped if setImageBitmap() was the only
thing called but during new-loading content it's common for a
placeholder to be set via setImageDrawable.
Tweak ImageView slightly to just have a BitmapDrawable that it
lazy-creates but will hold on to for any subsequent calls
to setImageBitmap
Change-Id: I7380521c7b363d458e4cda041f1f8b2b1fb3a93a
