while on background.
These commands will be used primarily in the CTS tests:
- list restrict-background-blacklist
- add restrict-background-blacklist UID
- remove restrict-background-blacklist UID
BUG: 27432317
Change-Id: Ie1148dcabbb2481ccd39659a813fac3776f84e3b
Changes:
- Removed hints.
- Added TextViews for field labels.
- Added padding for inner dialog
- Adedd autoCorrect and capSentences to title and summary
- Changed strings.
- Set name to be selectAllOnFocus initially.
Also improved some logging statements.
BUG: 26324085
Change-Id: I32597a7c2839ca706dbbcf13660e976469ab8dd0
On the lockscreen, the minheight was always based on the intrinsic
height and not actually the minHeight of the children. Because
children were userlocked, they were now reporting their small size
instead of the single line size.
This meant that the expand motion on the lockscreen wasn't following
the finger at all.
Bug: 27418617
Change-Id: I81daaf87887de1adc014cb4c6d46f4ef118061e5
The callbacks for the notification listener and notification
ranker were delivered on binder threads which is problematic
becuase: 1) permission checks and app ops checks would fail
unless the app developer knows to clear binder calling id and
restore it after that; 2) developers need to synchronize their
implementation as they get callbacks on different threads (
arguably callbacks should not be concurrent); 3) this doesn't
follow the pattern in the platform;
Also the code delivering callbacks was catching Throwable which
we shouldn't do in general and also masks bugs in the listener
or ranker implementation. Now that the callbacks are offloaded
to the main listener/ranker thread system code should not be
guarding against Throwable to handle exceptions propagated
over binder calls.
bug:26704777
Change-Id: I171fb41bbe25e6105dd05e4166193dbcec594f82
Unbundled apps should not be allowed to share
linker-namespaces with default namespace; it implies
that they will not have unlimited access to private
native libs once updated.
Bug: http://b/27189432
Change-Id: I60295b9b31d700016add93537418fdcce5a77719
Bug: 27407637
Texture layers will set a GL_NONE rendertarget
until they have managed to get the real rendertarget
from SurfaceTexture. If, however, copyLayer is called
prior to any calls to updateTexImage() (for example, if
no frames have yet been produced), this will
result in trying to use a Texture with a GL_NONE rendertarget
which is bad.
Change-Id: Ib7285d799cb94ebd44f07a89f2ef2075d79ef71f
-- Error if Parcelable classes aren't final.
-- Warn that MIN_/MAX_ constants that should be dynamic.
-- Error if throwing raw RemoteException.
-- Warn if methods accept File without stream variants.
-- Ignore upstream ICU project.
Bug: 27410989
Change-Id: I12d843e63078dc696c1798a20e088608f1ba9ed1
Which are now supported by Jack.
Retain a few preconditions checks that enforce contract.
Disable the one assert we had...because it failed in tests.
Change-Id: I2f6cb01e1af1534be4428ce4a3ee625a163dd163
The TaskRecord intent (usually the intent of the root activity) component
names are based on the realActivity (the activity we are actually launching
and not the input alias) and the ActivityRecord intent is based on the input
component name which can be an alias. This leads to issues when we are trying
to compare the intent of a task and an activity to see if they resolve to
the same thing since the component names will be different in the case of
aliasing.
We know base the activity intent component name on the realActivity before
comparing with the task record intent.
Bug: 27403679
Bug: 27112965
Change-Id: I196e03bb018582cbac977fb3ad45354f00f51578
This reverts commit 90bd36363c.
Seems that the semantics of InputConnectionWrapper#setTarget() is more
complicated than I thought. At least the following cases have worked
fine.
case 1:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, false);
wrapper.SetTarget(ic);
...
case 2:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, true);
wrapper.SetTarget(ic);
...
case 3:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(ic, true);
wrapper.SetTarget(null);
wrapper.SetTarget(ic2);
...
The previous code did not intended to break existing code. Let's revert
it we decide how to deal with above cases.
Bug: 27407697
Change-Id: I8bc84d484ab0b27a02e74f11110430f70646e69a
The default value of bluetotoh contact sharing is true.
So we should save when it is false.
Bug: 27410265
Change-Id: Icaf4ceeda09eca46d160acfecc53834819b66a18
bug:27381362
Also rejects ops with empty clip at record time, and short circuits clip
intersection, when one is empty.
Change-Id: I842612da14ad8fd9f1ba5e9e4fd027ba4e08d365
This CL makes it clear that InputConnectionWrapper does not support null
target. In other words, the semantics of null InputConnection can never
be emulated by a non-null InputConnectionWrapper.
This is particularly problematic when app developers are just forwarding
the return value of super.onCreateInputConnection() to
InputConnectionWrapper or its subclass, because there are many chance
that super.onCreateInputConnection() starts returning null, e.g. when:
A. the application is extending a Framework class, and the Framework
class is updated by OTA.
B. the application is extending system WebView, and the WebView is
updated.
C. the application is extending a 3rd party library, and the app
developer creates a new build with a new version of the 3rd party
library.
To make it easy to catch these kind of bugs, this CL lets the
constructor of InputMethodWrapper throw NullPointerException when target
is null. Bugs like crbug.com/571229 should be caught by developers
more easily.
Bug: 27407697
Change-Id: I83875bea886d4784f9507c930050efc29708d9db
