Make sure that a restricted user cannot use adb shell commands
to grant/revoke runtime permissions.
Bug: 27418014
Change-Id: I518b09f56ca7d77cc2bfa1d0b4faaf129e19000d
We grant default permissions to the default SMS and
Phone apps when they are selected as such to ensure
they can do their job. We don't grant default permissions
to apps if the version on the system image does not
declare them. This is correct for default grants on
first boot or a new user creation. This is a problem
for default Phone and SMS as we want to grant them
the permission as a result of a deliberate user action
and therefore should not care if the version on the
system image declares the permission.
As a result if an SMS app that ships as a stub to reduce
image size is later updated to the full version and
made the default SMS it would not get the default grants
while an installed third-party app that did not ship
on the system image would get the grants.
This change ensures the default SMS and Phone get
their default grants regardless whether the verion on
the system image declares the permissions.
bug:25288760
Change-Id: I2fecf5cbce4ebabb145a3f29abb555bcb65d54d6
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
This CL makes the settings icon row invisible when it's not displaying,
this way it won't get the click event on the notification row before
the parent.
Bug: 27389571
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 90bd36363c5738b3f526aa1f1d44f432236300a0.
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
